Hi everyone,
I wanted to share the purpose behind a technical guide I recently put together. I faced quite a few challenges while setting up SSO—especially with the keytab configuration—for Kerberos-based Integrated Windows Authentication (IWA) in a SAS environment connected to Microsoft Active Directory.
Since there wasn't much help available around keytab setup, I decided to document the entire process. The article provides a step-by-step walkthrough for configuring and validating the setup needed to support Kerberos authentication, along with LDAP-based user access for SAS web applications.
****************CHECKLIST*********************
(To be Performed By AD/Infrastructure Team)
Category Steps and Checklist
Active Directory Account Configuration: To be Performed on the AD Server • Create a New/Existing Account for SSO authentication.
• AD service account must have read access to the LDAP directory to retrieve user and group information.
• Read access to the OU (Organizational Unit) and CN (Common Name) hierarchy used for authentication.
Account Options in Active Directory:
The following settings must be enabled for the user created in AD (e.g., keytab user) within Active Directory • This account supports Kerberos AES 256-bit encryption.
• This account supports Kerberos AES 128-bit encryption.
• These options can be configured by navigating to:
Active Directory Users and Computers → [User Object] → Properties → Account → Account Options
Sample screenshot from AD server once user is created:
C. STEPS TO BE PERFORMED BY ACTIVE-DIRECTORY ADMINISTRATOR
Below are the step-by-step processes/steps which need to be performed by the AD/infrastructure administrator
Step 1 – Creating the User/service account in AD (Active Directory)
First and foremost, the requirement is to create the user /service account in Active directory. This identity will be used to create the Kerberos file and read ad.
• Create the user/service account in the active directory e.g. account created is keytab.
• Make sure that “This account supports Kerberos AES 128 bit encryption” and “This account supports Kerberos AES 256 bit encryption” is checked inside the Account account options.
• Also, make that password does not expire
• The username and password along with the OU, CN, etc must be shared with the application team (SASVADashBoard Team).
Step 2: SPN Registration
The next step is to perform the SPN registration in the AD. Please make sure that the SPN is registered to the account created in step 1 and not to some other account. If it is registered to some other account, delete the SPN.
Check for registered SPNs related to the server using the below command
• Command : setspn -Q */<SERVERNAME>.<DOMAIN>
Here the “servername.domain” is the actual server on which SASVADashBoard is hosted.
In-case SPNs are already created then delete using the below command:
• Command: Delete SPNs
e.g. Delete HTTP/SASVADashBoard.abc.com (sasnode.abc-xyz.com is just for demonstration)
Create SPN with the Newly created user as created in Step 1:
• Command: setspn -A HTTP/<URL of Application> <ADuser>
Here the <URL of the Application> will be SASVADashBoard.abc.com which is the URL of SASVADashBoard and <AD User> is the user created in step 1.
e.g setspn -A HTTP/ SASVADashBoard.abc.com keytab
Ensure SPNs are not simultaneously registered under both the user account and the computer account, as this will cause Kerberos ticket negotiation to fail.
Step 3: SPN Validation
Confirm that the SPNs are correctly linked to the intended user account by running the below command.
• Command: setspn -L <AD_USERNAME>
Here the <AD_Username> is the same user created as per step 1. The output should show the SPN name registered as per the step 2.
Step 4: Keytab File Generation
Next step is to generate the keytab file which need to be shared with the application team (SASVADashBoard Team).
From the AD server Open the PowerShell with Admin Privileges and Run below commands:
• ktpass -princ HTTP/<hostname>.<domain>@<domain> -mapuser <user>@<DOMAIN> -pass <PASSWORD> -ptype KRB5_NT_PRINCIPAL -crypto all -out <keyTabName>.keytab
• ktpass -princ HTTP/<hostname>.<domain>@<domain> -mapuser <user>@<DOMAIN> -pass <PASSWORD> -ptype KRB5_NT_PRINCIPAL -crypto AES128-SHA1 -out <keyTabName>.keytab
• ktpass -princ HTTP/<hostname>.<domain>@<domain> -mapuser <user>@<DOMAIN> -pass <PASSWORD> -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -out <keyTabName>.keytab
Total 3 files will be generated. These files need to be shared with the SASVADashBoard Application team.
D. Information to be Shared with Application Team of SASVADashBoard:
• Username & password of the user created at step 1.
• OU & DC information for the user created at Step 1.
• LDAP information like IP/Name , port number etc.
• 3 .keytab files generated at step 4.
Steps for Implementing IWA (Integrated Windows Authentication) After Prerequisites Are Completed
1. Verify Keytab File
Once the keytab file is generated, verify its contents using the klist command.
Windows:
klist -k -e D:/keytab/12apr/saskeytab_WD.keytab
Linux Equivalent:
klist -k -e /path/to/saskeytab_WD.keytab
2. Check JRE Version on the Server
Command (Windows):
From E:\SASHome\SASPrivateJavaRuntimeEnvironment\9.4\jre\bin\java open the cmd and enter the command as
java –version
Equivalent path in linux -
/path/to/java -version
3. Confirm User is Linked to Service Account
setspn -L prathmesh.howale
4. Create or Modify krb5.ini / krb5.conf
Linux Path: /etc/krb5.conf
Windows Path: C:\Windows\krb5.ini
Content of file (krb5.ini):
[libdefaults]
default_realm = SOOS.COM
forwardable = true
default_tkt_enctypes = aes256-cts
default_tgs_enctypes = aes256-cts
permitted_enctypes = aes256-cts
[realms]
SOOS.COM = {
kdc = adServer.SOOS.com
}
[domain_realm]
SOOS.com = SOOS.COM
.SOOS.com = SOOS.COM
abc-xyz.com=SOOS.COM
.abc-xyz.com=SOOS.COM
Note: Above 2 lines are for if the application is running on some other URL compared to domain name.
5. Generate Kerberos Ticket Using Keytab
E:\SASHome\SASPrivateJavaRuntimeEnvironment\9.4\jre\bin\kinit.exe -k -t D:\keytab\30apr\sas.keytab HTTP/sasnode.abc-xyz.com@SOOS.COM
alternative with decoding (InCase RCA for Failure)
E:\SASHome\SASPrivateJavaRuntimeEnvironment\9.4\jre\bin> kinit "-J-Dsun.security.krb5.debug=true" -k -t D:/keytab/30apr/sas.keytab HTTP/sasnode.abc-xyz.com@SOOS.COM -J-Djava.security.krb5.conf=C:/Windows/krb5.ini
6. Verify LDAP Access
ldapsearch -x -H ldap://adServer.SOOS.com -D "CN=keytab,OU=sas,DC=SOOS,DC=com" -w 'password' -b "DC=SOOS,DC=com"
If ldapsearch is not already available, try to install from the default Linux packages
Configure the Realm for SAS Web Application Serve
1. Locate the existing /Server/Service/Engine/Realm definition in the SAS-configuration-directory\Levn\Web\WebAppServer\SASServern_m\conf\server.xml file.
Note: If you have more than one web application server instance, you must make the following changes to each one.
Modify the realm information:
Configure Fallback Authentication
To configure IWA fallback authentication to SAS form-based authentication, follow these steps:
Add in E:\SASConfig\Lev1\Web\WebAppServer\SASServer1_1\conf\Catalina\localhost\SASLogon.xml
-->
Add inside the <Context> tag:
<Valve className="com.sas.vfabrictcsvr.authenticator.SasFallbackAuthenticatorValve"
authMethod="SPNEGO" />
Uncomment the fallback error page in: E:\SASConfig\Lev1\Web\WebAppServer\SASServer1_1\sas_webapps\sas.svcs.logon.war\WEB-INF\web.xml
<error-page>
<error-code>401</error-code>
<location>/WEB-INF/view/jsp/default/ui/401Fallback.jsp</location>
</error-page>
9. Configure jaas.config
Directory of E:\SASConfig\Lev1\Web\WebAppServer\SASServer12_1\conf jaas.config
Update the PFS section to include idpropagation and sspisecuritypackagelist. Do not modify other parameters.
NOTE::place ur trustedpw
PFS {
com.sas.services.security.login.O.comoginModule required
"debug"="false"
"aliasdomain"="DefaultAuth"
"port"="8561"
"domain"="DefaultAuth"
"host"="sasnode.abc-xyz.com"
"repository"="Foundation"
"trusteduser"="sastrust@saspw"
"trustedpw"="{sas002}***************************"
"idpropagation"="sspi"
"sspisecuritypackagelist"="KERBEROS"
;
};
10. Comment out Default Authentication (SPNEGO and FORM)
In the appropriate web.xml file inside <web-app>:
<!-- Enable SPNEGO authentication -->
<!--
<security-constraint>
<web-resource-collection>
<web-resource-name>HTMLHostManager and HostManager commands</web-resource-name>
<url-pattern>/login</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>SPNEGO</auth-method>
<realm-name>Tomcat Host Manager Application</realm-name>
</login-config>
-->
<!-- Enable FORM authentication -->
<!--security-constraint>
<web-resource-collection>
<web-resource-name>HTMLHostManager and HostManager commands</web-resource-name>
<url-pattern>/login</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint -->
<!-- login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/formLogin</form-login-page>
<form-error-page>/formLoginError</form-error-page>
</form-login-config>
<realm-name>Tomcat Host Manager Application</realm-name>
</login-config -->
Hope this helps anyone going through a similar setup.
