SSO Setup for AD-Based Integrated Windows Authentication in SAS 9.4 VA

PrathmeshX — Thu, 05 Jun 2025 11:13:00 GMT

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>:

<!--

<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>

-->

<!--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.

topic SSO Setup for AD-Based Integrated Windows Authentication in SAS 9.4 VA in SAS Visual Analytics

SSO Setup for AD-Based Integrated Windows Authentication in SAS 9.4 VA