Kerberos/SPNEGO allows users to sign in to applications automatically using their Windows domain account, without entering their username and password again. When integrated with SAP Identity Authentication Service (IAS), it provides a seamless Single Sign-On (SSO) experience for domain-joined users.
This guide explains how to configure Active Directory, generate the required keytab file, configure SAP IAS, and verify the Kerberos authentication.
Part 1 – Active Directory Configuration
Step 1 — Create a new service account
Open Active Directory Users and Computers (run dsa.msc or access it from Server Manager). Navigate to your domain → Users container. Right-click → New → User.
Fill in the user details. Use a clear, descriptive name that identifies this as a Kerberos service account:
- Full name: Kerberos Test IAS
- User logon name: KerberosTestIAS@pslab.gscbrsle.local
Step 2 — Set password
On the next wizard screen, set a strong password and configure the option: Password never expires
Note: Service accounts must not have expiring passwords. An expired password silently invalidates the keytab and breaks all Kerberos authentication.
Click Next and review the confirmation summary, then click Finish.
Step 3 — Enable AES encryption flags
Open the account Properties → Account tab in the Account options list, enable both AES flags:
- This account supports Kerberos AES 128-bit encryption
- This account supports Kerberos AES 256-bit encryption
Note: Microsoft is progressively deprecating RC4. If AES flags are not enabled, Kerberos will silently break when RC4 is fully disabled.
Step 4 — Copy the userPrincipalName from Attribute Editor
Go to the Attribute Editor tab. Locate userPrincipalName and copy its value. This value is the key source used in AES key derivation — it must be correct.
Value in this example: KerberosTestIAS@pslab.gscbrsle.local
Note: An incorrect or empty UPN is the #1 cause of Kerberos failures after AES is enforced. Verify this value carefully before generating the keytab.
Step 5 — Register the Service Principal Name (SPN)
Before setting the SPN, run an nslookup on your IAS tenant URL to find the exact canonical hostname and any aliases that clients may resolve:
nslookup <ias_tenant>.accounts.ondemand.com
In the Attribute Editor, double-click servicePrincipalName and add an entry for each hostname returned by nslookup (the canonical Name and all Aliases) using the format:
HTTP/<canonical_name>
HTTP/<alias>
Note: The browser uses whichever hostname DNS resolves to request the Kerberos ticket. Registering both the alias and the canonical name ensures the ticket request succeeds regardless of which hostname the client resolves.
Step 6 — Perform a dummy password reset
After enabling AES encryption (or any encryption/UPN change), you must reset the service account password even to the same current value. This forces Active Directory to regenerate the cryptographic key material using the new AES algorithms.
Right-click the service account → Reset Password. Enter the current password and click OK.
Part 2 — Verifying the Kerberos Ticket Cache
Before generating the keytab, verify the Kerberos infrastructure is working correctly on the Windows Server (or any domain-joined client) using the klist command.
Step 1 — View cached tickets with klist
Open an elevated Command Prompt and run:
klist
You should see the generated tickets for your domain, confirming AES is active.
Step 2 — Purge the ticket cache after any AD change
After any change in Active Directory (password reset, SPN update, UPN change, encryption flags), always purge the client ticket cache:
klist purge
Note: Old tickets remain valid until they expire. Always purge after AD changes, then re-test, otherwise stale tickets mask the real state.
Step 3 — Simulate a service ticket request for IAS
To confirm the SPN is correctly registered and the Domain Controller can issue a ticket for your IAS tenant, run:
klist get HTTP/<IAS_TENANT>.accounts.ondemand.com
This confirms Kerberos can successfully issue a service ticket for IAS. If this command fails, the SPN is not registered or the AD account is misconfigured.
Part 3 — Generating the Keytab File
The keytab (key table) is a file containing the cryptographic keys that allow SAP IAS to decrypt Kerberos tokens without connecting to Active Directory at runtime. It is derived from the service account’s UPN, realm, and password.
Step 1 — Run ktpass on the Windows Server
Open an elevated Command Prompt and run:
ktpass /princ <userPrincipalName>@<REALM_UPPERCASE>
/pass <service_account_password>
/crypto all
/ptype KRB5_NT_principal
/out .keytab
Concrete example from our lab:
ktpass /princ KerberosTestIAS@PSLAB.GSCBRSLE.LOCAL
/pass YourSecureP@ssword
/crypto all
/ptype KRB5_NT_principal
/out .keytab
The command generates a list of all keys. The relevant entries are:
- (AES256-SHA1): used when AES 256-bit encryption is active.
- (AES128-SHA1): used when AES 128-bit encryption is active.
- (RC4-HMAC): although supported by IAS, will be deprecated by Microsoft.
Note: The realm (/princ …@REALM) must be in UPPERCASE — this is an RFC 4120 requirement. Regenerate the keytab whenever the service account password or UPN changes.
Part 4 — SAP IAS Configuration
With the keytab ready, configure SPNEGO in the IAS admin console. This is done in two steps: first configure the realm/key at tenant level, then enable SPNEGO on the target application.
Step 1 — Configure SPNEGO at tenant level
Log in to the IAS Admin Console and navigate to:
Applications & Resources → Tenant Settings → SPNEGO
Click Add and fill in:
- Realm: The Active Directory domain in uppercase — e.g., PSLAB.GSCBRSLE.LOCAL
- Key Type: The encryption algorithm — must match what was configured in AD (e.g., AES256-CTS-HMAC-SHA1-96)
- Key: The corresponding key value generated by ktpass in Part 3
- Allowed IP Ranges: Optional — restrict SPNEGO to specific subnets (e.g., corporate network only)
SAP IAS supports the following key types:
Step 2 — Enable SPNEGO Authentication on the application
Navigate to Applications & Resources → Applications. Select the application you want to use with SPNEGO. Go to Authentication and Access tab and enable SPNEGO Authentication.
Step 3 — Test the end-to-end login
From a domain-joined browser configured for Integrated Windows Authentication, navigate to the IAS-protected application. The user should be authenticated silently with no credential prompt.
In this lab, the User Profile page of SAP IAS was used as the test. The result after successful SPNEGO authentication:
Key Takeaways
- SAP IAS only decrypts — if the token never arrives or is malformed, the issue is in AD or the browser, not IAS.
- Always enable AES flags — RC4 is being deprecated by Microsoft. Enable AES 128 + 256 to future-proof the configuration.
- Run nslookup first — register ALL hostnames (canonical + aliases) returned by nslookup as SPNs.
- Dummy password reset is mandatory — any encryption/UPN change requires a password reset to regenerate key material.
- Purge client tickets after AD changes — klist purge forces fresh ticket acquisition and avoids stale-ticket confusion.
- Use klist get to test — klist get HTTP/<IAS_hostname> confirms the SPN is correctly registered end-to-end.
- The keytab is static — regenerate and re-import into IAS whenever the service account password or UPN changes.
- IAS does not support NTLM — NTLMSSP and NEGOEXT tokens are rejected. Ensure the browser sends a proper Kerberos token.
References:
- SAP Help Portal — Configure Kerberos Authentication
- Microsoft Docs — Kerberos Authentication Overview
- RFC 4120 — The Kerberos Network Authentication Service (V5)
- RFC 4559 — SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
Useful KBAs:
- 2958786 – Kerberos Authentication fails with Could not decrypt the encrypted data error
- 3760970 – SPNEGO authentication on IAS shows credentials popup
- 2958806 – Kerberos Authentication fails with Unsupported encryption SPNEGO token type error
- 2726591 – Supported number of realm or domain for Kerberos/SPNEGO in IAS
#SAPCHANNEL