Single Sign-On with SAP HANA Scale-out System using Kerberos and Microsoft Active Directory

Preamble: Being an SAP technology consultant, throughout my career I have been getting so many helps from the contents written by the experts of SAP Community , hence I thought this is the pay-back time.

If you are well aware of the architecture of SAP HANA Platform and Kerberos , then needless to say this SSO works for a SAP HANA Scale-out system as well. But when I had implemented it for a customer , I found it hard to find any relevant documentation that could’ve supported my understanding and made my life bit easy. So, as I dealt with it already ,here I am with this blog , that will depict the exact configuration steps for the aforesaid to move forward.

SSO , Kerberos and SAP HANA: Single Sign-On allows a user to log on once and gain access to multiple resources without being asked to produce credentials repetitively. Kerberos is a network authentication protocol based on secret key cryptography, originated by MIT scientists. SAP HANA supports Kerberos v5 for single sign-on based on Active Directory (Microsoft Windows Server) or Kerberos authentication servers.

I am not going into the theoretical details of  SSO and Kerberos and as many experts had already come up with excellent documentations for each of the topic. In this blog, I will remain focused onto the SAP HANA Scale-out configuration steps for the same.

Example scenario: Let us assume a SAP HANA Scale-out engine having 4 Active nodes and 1 Standby node being used for Production workloads. Essentially you are using default failover solution for SAP HANA Scale-outs.

So now if  you want to implement SSO to that SAP HANA engine by Kerberos, you may feel sufficient configuring SSO to your Acting Master Node to get your requirement accomplished . But what if your Acting Master Nodes crashes and one of the other Master nodes becomes the acting master node ? Eventually the failover would be automated and should result into no data loss but switching your master node will lead to breakage of Single Sign-On to the users who were actively using that SAP HANA engine.

Hence you come up with a node redundant SSO solution that can deal with SAP HANA auto host failover. If I reframe it, then you have to configure Kerberos SSO to each of the nodes of the SAP HANA engine so that if failover happens, then also users can access SAP HANA engine by logging into other SAP HANA worker nodes through Single Sign-On.

Configuration and descriptions: To allow users to log on to the SAP HANA Scale out database from a client using Kerberos authenticated SSO, the following configuration steps are necessary:

1. FQDN test and Reverse Lookup test

2. Check and install Kerberos packages if needed

3. Create service user in AD (Active Directory), map SPN

4. Maintain Kerberos Configuration file across nodes

5. Get automation script from SAP Note : 1813724 – HANA SSO using Kerberos and SPNEGO: Create keytab and validate Kerberos configuration

6. Configure Kerberos

7. Copy generated keytabs in each SAP HANA nodes

8. Reboot SAP HANA

9. Perform user mapping

10. Update client tools if required

11. Test

Now let’s go through little bit details of each one stated above :

1. FQDN test and Reverse Lookup test: First you are going to see by which FQDN and IPs your SAP HANA servers are sitting in, easiest way to perform the following:

Now for checking the reverse lookup try following , replace IP with the IP of your current node, this python snippet should get you the FQDN for the current node:

Point to remember is that the reverse lookup must be configured consistently with the hostname lookup, since this will be used by the SAP HANA database server Kerberos implementation for determining the SPN. This SPN eventually will be used for the lookup into the keytab.

As per our example scenario, we have 5 nodes for our SAP HANA system, hence this check must be successful for each of the nodes i.e. for each node FQDN lookup and reverse lookup should be consistent.

2. Check and install Kerberos packages if needed: You should have Kerberos packages installed with your Linux distribution , if not check with this command and get it installed. Though since V5 Kerberos is supported for SAP HANA, it is always recommended to use latest versions for enhanced security.

3. Create service user in AD (Active Directory), map Service Principal Name(SPN) :

Now you are going create a Service User that will represent SAP HANA in AD, being mapped by a Service Principal Name. Ideally this user would be a generic account set with ‘password never expires’ option and with a complex password. Now once you create this user, you have to map your all 5 SAP HANA nodes as SPNs. For Kerberos on SAP HANA, the SPNs would like below :

hdb/<FQDN of SAP HANA node>

Setting up SPNs should look like this :

Now once you set all the SPNs respective to each nodes , you may verify the same with below , this command should pop up all the SPNs set to that service user :

4. Maintain Kerberos Configuration file across nodes: In this step, you need to create Kerberos Configuration file that will contain KDC and Realm information of your current architecture. I am not going into the nomenclatures of a standard Kerberos Config file as plenty resources are available from experts and parameters will vary as per your realm design and use cases. But one thing to keep in mind that if you are having SAP HANA 1.0 SPS11 and lower, then the file name would be krb5.conf , otherwise it should be krb5_hdb.conf and would be located at /usr/sap/<SID>/home/etc. Create this file if you don’t have one otherwise modify as per your design.

Now in order to implement Kerberos authentication for each of the nodes, you have to place same configs to all 5 nodes available for your SAP HANA system. And please ignore #ed-out KDC inputs in my sample picture, I was doing some trial and errors with the backup AD instances available at that time.

5. Get automation script from SAP Note: 1813724 – HANA SSO using Kerberos and SPNEGO: Create keytab and validate Kerberos configuration :  Configuring Single Sign-On with SAP HANA using Kerberos and Microsoft Active Directory is a very complex and process and manual configurations are pretty much error prone . Keeping this in mind SAP had launched a python script: hdbkrbconf.py to create and extend keytabs automatically , I used this one as I found convenient but please note that it supports rc4-hmac encryption only.

The above mentioned note contains a zip file , choose the version of the zip as per requirement. Once you extract it , you will find a directory  containing that python script.

6. Configure Kerbero: The script is an interactive one , I pasted here one of my execution . Wherever manual interaction is required , I tried to keep them bold . Another thing to keep in mind that this script uses ICMP, I struggled a lot with this when I did the execution, you need ICMP flow throughout your KDC to SAP HANA nodes.

Run this script in your active master node.

<SID>adm@<Active_Master_Node>:/usr/sap/<SID>/home/etc> python hdbkrbconf.py -k

——————————————————————————–

hdbkrbconf.py v 1.2 for HANA DB SPS 12 and above – started at YYYY-MM-DD HH:MM:

SS

——————————————————————————–

——– CHECKS for preparation ————————————————

Checking Kerberos environment … OK

Checking IP configuration … OK

——————————————————————————–

HANA DB Service User for Active Directory [default: XXXXXX]: <Service_User>

——– CHECKING local conf —————————————————

Checking Kerberos conf file /usr/sap/<SID>/home/etc/krb5_hdb.conf … OK

——————————————————————————–

[ENTER]

Active Directory Domain as defined via [domain_realm] mapping in /usr/sap/<SID>/home/etc/krb5_hdb.conf: <Deafult_Realm>

[ENTER]

Specify encryption type [default: rc4-hmac]:

[ENTER]

Specify the Service Principal Name(s) as a space-separated list [default:<SPN_of_Active_Master>]: SPN1,SPN2,SPN3,SPN4,SPN5

——– CREATE Service User in Active Directory ——————————-

Delete and (re-)create HANA DB Service User (choose <passwd>):

> dsrm “cn=<Service_User>,cn=users,dc=<Deafult_Realm>,dc=NET”

> dsadd user “cn=<Service_User>,cn=users,dc=<Deafult_Realm>,dc=NET” -pwd <passwd> -disabled no -pwdneverexpires yes -acctexpires never

—————————————————————————–

Hit [ENTER] when completed …

[ENTER]

——– MAP SPN to Service User in Active Directory ——–

Map Service Principal Name(s) to HANA DB Service User:

> setspn -S <SPN_Node_1> <Service_User>

> setspn -S <SPN_Node_2> <Service_User>

> setspn -S <SPN_Node_3> <Service_User>

> setspn -S <SPN_Node_4> <Service_User>

> setspn -S <SPN_Node_5> <Service_User>

——————————————————————————–

Hit [ENTER] when completed …

[ENTER]

——– CHECK SPN in Active Directory —————————————–

Verify mapping of SPN to HANA DB service user:

> setspn -L  <Service_User>

[ENTER]

Verify existence of HANA DB SPN:

> setspn -Q  <SPN_Node_1>

> setspn -Q  <SPN_Node_2>

> setspn -Q  <SPN_Node_3>

> setspn -Q  <SPN_Node_4>

> setspn -Q  <SPN_Node_5>

[ENTER]

Verify uniqueness of all SPNs registered in AD (Caution: may take some time):

> setspn -X

——————————————————————————–

[ENTER]

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Password for Active Directory Service User <Service_User>: XXXXX

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Checking Service User “<Service_User>” … OK

Checking Service Principal Name “<SPN_Node_1>” … OK

Checking Service Principal Name “<SPN_Node_2>” … OK

Checking Service Principal Name “<SPN_Node_3>” … OK

Checking Service Principal Name “<SPN_Node_4>” … OK

Checking Service Principal Name “<SPN_Node_5>” … OK

——————————————————————————–

[ENTER]

——– CREATE keytab ———————————————————

Specify path for new keytab [default: /usr/sap/<SID>/home/etc/krb5_hdb.keytab]:

Writing keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab with encryption type rc4-hmac …

OK

Created keytab:

***************

Keytab name: /usr/sap/<SID>/home/etc/krb5_hdb.keytab

KVNO Timestamp           Principal

—- ——————- ——————————————————

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

——————————————————————————–

[ENTER]

——– CHECK keytab ———————————————————-

Checking key version number and key in keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab for SPN <SPN_Node_1> … OK

Checking key version number and key in keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab for SPN <SPN_Node_2> … OK

Checking key version number and key in keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab for SPN <SPN_Node_3> … OK

Checking key version number and key in keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab for SPN <SPN_Node_4> … OK

Checking key version number and key in keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab for SPN <SPN_Node_5> … OK

——————————————————————————–

[ENTER]

——————————————————————————–

For changes to take effect

1) The productive keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab must be replaced by the new keytab /usr/sap/<SID>/home/etc/krb5_hdb.keytab

2) A restart of HANA DB is required.

——————————————————————————–

7. Copy generated keytabs in each SAP HANA nodes: Now the keytab file is generated that contains encryption keys of Kerberos authentication. Now you need to manually copy this keytab file to each nodes of your SAP HANA system irrespective of node roles. Now the catch is, if you consider yourself intelligent enough, then you may place the script and config file in a shared path( accessible from all nodes) and generate keytab onto that location, it should allow you not to manually copy the configs and keytabs. I wasn’t that intelligent though

8. Reboot HANA: So, it the time to restart your HANA system to get the changes in live . Oh, yes , don’t forget to use sapcontrol commands (instead of HDB stop/start) so that all nodes would be restarted and unnecessary failover can be avoided

9. Perform user mapping: Now your SAP HANA  system is Kerberos enabled but in order to make users enabled with it you need to map the AD External IDs to your SAP HANA users. Easy-peasy, either you hit below command in SQL editor or in Security Tab of the SAP HANA studio do the following :

alter user <DB USER> identified externally as ‘<aduser>@<MYDOMAIN.COM>’;

alter user <DB USER> enable kerberos;

10. Update client tools if required: Now you have to modify ,edit or maybe add connection details of the clients so that all of your efforts gets into success i.e. SSO can be consumed. Here’s an example of Tableau connection that uses Kerberos SSO :

11. Test: Now if steps 1-10 are all fine , then you should  be able to test and use the SSO now. So step 11 is just a click if step 10 is configured , then you should able to get into the system without using any credential. If your Studio is still not configured, add a new connection with any of your hostname (except the Standby one, as it will only accept SQL connection in case of a failover) and select windows authentication like below :

And Bingo!! Smoothing green lights are here

You may enjoy the beauty configuring studio connection using each of the worker nodes.