-
Title
Setting up SAP SSO in a SAP clustered environment using a shared host object -
Description
Setting up SAP SSO in a SAP clustered environment using a shared host object -
Resolution
Setting up SAP SSO in a SAP clustered environment using a shared host object is necessary when wanting to use other GSSAPI authentication methods such as SSH with the same virtual hostname as the SAP cluster. This setup will require you to rejoin each node in the cluster to active directory, if it has already been done. The below setup assumes that DNS failover will occur so that the virtual hostname will always resolve to a working machine.
Step 1: Join the first node in the cluster to AD using the virtual hostname; this is the same name that will be used for each node in the cluster.
# vastool -u <username> join -f -n virtualhostname.mydnsdomain domain_name
This command will join the UNIX machine to active directory with a host object name ofvirtualhostname***Make sure thatvirtualhostname.mydnsdomainis a fully qualified DNS name
The -u parameter, <username>, is the name of the active directory user with administrative privileges to join the machine to Active Directory. The user will be prompted for their Active Directory (AD) password which is required to authenticate them to AD. For a better understanding of the vastool join command and its available options, please read the vastool man page.
You can check the newly created object attributes with the following command:
# vastool -u host/ attrs host/ cn distinguishedName samaccountname dNSHostname userPrincipalName servicePrincipalName
cn:virtualhostname
distinguishedName: CN=virtualhostname,CN=Computers,DC=example,DC=com
sAMAccountName: VIRTUALHOSTNAME$
dNSHostName:virtualhostname.mydnsdomain
userPrincipalName: host/virtualhostname.mydnsdomain@MYDOMAIN
servicePrincipalName: host/VIRTUALHOSTNAME
servicePrincipalName: host/virtualhostname.mydnsdomainStep 2: Configure Kerberos to look for the host.keytab file in a shared directory within the cluster.
# vastool configure vas libdefaults default_keytab_name /home/vas/host.keytab
The following entry will be created/modified in /etc/opt/quest/vas/vas.conf:
[libdefaults]
default_keytab_name = /home/vas/host.keytabStep 3: Move the host.keytab to the shared directory within the cluster.
# mv /etc/opt/quest/vas/host.keytab /home/vas/
Step 4: Change the file permissions on the host.keytab file so that the SAP SNC service has the rights to read from the keytab file.
# chgrp sapsys /etc/opt/quest/vas/host.keytab
This command changes the group ownership of the keytab to the sapsys group.
# chmod 640 /etc/opt/quest/vas/host.keytab
Or
# chmod g=r /etc/opt/quest/vas/host.keytab
These commands change the file access permissions so that group has read rights
Step 5: On each SAP node in the cluster set the environment variable KRB5_KTNAME to point to the shared location of the host.keytab file. This environment variable needs to be set for the SAP admin user that will be starting the SAP services
Step 6: Create a soft link back to the original location of the host.keytab file. Many of the internal VAS calls rely on the host.keytab to be in this location.
# ln -s /home/vas/host.keytab /etc/opt/quest/vas/host.keytab
Step 7: Set the password change interval to 0. This will tell VAS to never update the password, which is necessary so that the nodes within the cluster will not cause password synchronization errors with active directory.
# vastool configure vas vasd password-change-interval 0
The following entry will be created/modified in /etc/opt/quest/vas/vas.conf:
[vasd]
password-change-interval = 0Step 8: Set the snc/identity/as value to p:SAMACCOUNTNAME@MYDOMAIN, on each SAP server in the cluster.
You can obtain the sAMAccountName by running the following vastool command:
# vastool -u host/ attrs -q host/virtualhostname.mydnsdomain@ADDOMAIN.TLD sAMAccountName
Step 9: Stop vasd.
Step 10: Complete steps 1-9 on each node of the cluster.
Note: When joining each node in the cluster the same virtual hostname will be used.
Step 11: After steps 1-10 have been completed restart vasd and the SAP services on each node of the cluster.The following additional steps can be taken if you need to access each node of the cluster via its hostname through GSSAPI:
With the above setup, only the virtual hostname exists in the host.keytab file. You can use thevastool ktutilcommand to view the principals that are currently stored in the host.keytab file.
# vastool ktutil list -keys /home/vas/host.keytab:
Vno Type Principal Key
4 arcfour-hmac-md5 VIRTUALHOSTNAME$@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 host/VIRTUALHOSTNAME@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 host/virtualhostname.mydnsdomain@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 cifs/virtualhostname.mydnsdomain@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
Each node in the cluster needs to have an alias created for its hostname in the host.keytab file. Both a short name and a fully qualified domain name (FQDN) should be created.
Step 1: Create an alias for the nodes FQDN in the host.keytab file
# vastool -u host/ ktutil alias host/virtualhostname.mydnsdomain host/<FQDN_Hostname>
Step 2: Create an alias for the nodes short name in the host.keytab file.
# vastool -u host/ ktutil alias host/virtualhostname.mydnsdomain host/<hostname>
Vastool ktutilcan be used again to see the additional principals created in the host.keytab file:
# vastool ktutil list --keys
#home/vas/host.keytab:
Vno Type Principal Key
4 arcfour-hmac-md5 VIRTUALHOSTNAME$@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 host/VIRTUALHOSTNAME@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 host/virtualhostname.mydnsdomain@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 cifs/virtualhostname.mydnsdomain@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 host/<FQDN_Hostname>@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
4 arcfour-hmac-md5 host/<hostname>@MYDOMAIN e65ef04bdb6f9fc410595fc311daa74d
Step 3: Each alias that was added to the host.keytab file needs a corresponding servicePrincipalName (SPN) in the hosts Active Directory computer object. Thevastool setattrscommand can be used to add these additional SPNs.
Note: You MUST specify the existing servicePrincipalName values in the command line, otherwise they will be replaced. For example:
# vastool -u Administrator setattrs -m host/ servicePrincipalName host/VIRTUALHOSTNAMEhost/virtualhostname.mydnsdomainhost/<hostname> host/<FQDN_Hostname>
Attribute changed: servicePrincipalName
Step 4: Check that the new SPNs have been correctly updated:
# vastool -u host/ attrs host/ servicePrincipalName
servicePrincipalName: host/VIRTUALHOSTNAME
servicePrincipalName: host/virtualhostname.mydnsdomain
servicePrincipalName: host/<hostname>
servicePrincipalName: host/<FQDN_Hostname>
Step 5: Check to verify that there are no problems with the host setup by running:
# /opt/quest/libexec/vas/scripts/vas_check_host.sh
If any problems were encountered when running the script, use the scripts suggestions to resolve each issue until there are no more issues. If the test was successful you should see the following:
"Everything checks out, no serious issue with this machine's connection to AD has been found.
If this is incorrect, please contact Quest Support for additional help."
Step 6: Complete steps 1-5 for each node in the cluster.