SPNEGO/Kerberos Authentication Flow
This article provides the step by step configuration of SPNEGO SAML authentication flow.
Create Kerberos keytab file
Connect to the Windows Domain controller and create a Kerberos service account (new user account) in the Active directory.
Please use “Active Directory Users and Computers” and create the new user under de.local Users
The service account does not require any other group except for the default one.
The service account requires to have a non expiring password set.
Identify the service principal name that should be used in the keytab. Kerberos uses DNS for this, so a dns query would provide the answer:
nslookup <<identity provider domain>> // e.g. shib.dev1.veridium-dev.com or develop.veridium-dev.com
Create a Kerberos keytab file
If the service was already used in a different service, the previous SPN should be cleared. Run the following commands to verify and delete any mapped SPN.
setspn -L *serviceaccount* # provides back the current registered SPN
setspn -D <<spn retrieved from previous command>> *serviceaccount*
Open a PowerShell console as Administrator, run it on folder (e.g: Desktop) and create the keytab file by adapting this command.
ktpass /out veridium.keytab /princ HTTP/**veridiumservername.domain.com**@DOMAIN.LOCAL `
/pass *keytab_pwd* /mapuser *serviceaccount*@DOMAIN.LOCAL `
/ptype KRB5_NT_PRINCIPAL +DumpSalt /crypto *crypto_options*
**veridiumservername.domain.com** - should be the DNS name of the server hosting the Shibboleth server (for example: shib-poc.veridium-dev.com). Attention! for AWS hosted servers, the veridiumservername.domain.com must be the dns name of the nlb.
DOMAIN.LOCAL - MUST be in upper case and should reflect your Active Directory domain name (for example: DEV.LOCAL)
keytab_pwd - This is required to complete the command but is not needed for configuration in Shibboleth. This needs to match the password of user from AD
*serviceaccount*@DOMAIN.LOCAL - This is the user account created in the previous step in domain\username format (for example: spnego@DEV.LOCAL)
*crypto_options* - configure what cryptography algorithms to be used when validating the tokens on the SP side. common values are All, AES256-SHA1.
After running the command,
recover from PS the “/princ” parameter value (e.g.: HTTP/shib-aerolocal.veridium-dev.com )
a file named veridium.keytab will be created in the current directory (e.g.Desktop) of the PowerShell console and copy the file to clipboard. It will be later uploaded on Admin Dashboard
Repeat this process for any additional AD forests that you have
More information about ktpass may be found here https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass .
Here is an example used to create an AES256-SHA1 only keytab for dev1 environment
ktpass /out dev1.keytab /princ HTTP/dev1-public-nlb-5c8ef4d6cb4ccdff.elb.eu-central-1.amazonaws.com@DEV.LOCAL /pass Testing123# /mapuser spnego@DEV.LOCAL /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1
Configure the SPNEGO on Veridium Manager
Navigate to Settings / Connectors / SAML / SPNEGO
![](../../__attachments/3554673625/image-20220104-124804.png?inst-v=ffa2d127-74f7-4a38-ac00-bc62b4eb8eb4)
2. Enable SPNEGO authentication and click on New. Upload the Keytab generated and edit the Service Principal used to generate it and click on Add
![](../../__attachments/3554673625/image-20220104-124914.png?inst-v=ffa2d127-74f7-4a38-ac00-bc62b4eb8eb4)
3. Click on Save in the right side of the screen:
![](../../__attachments/3554673625/image-20220104-124945.png?inst-v=ffa2d127-74f7-4a38-ac00-bc62b4eb8eb4)
4. Navigate to Applications and select the SAML application for which SPNEGO will be used. Click on the Edit button on the right side of the application name
![](../../__attachments/3554673625/image-20220104-125134.png?inst-v=ffa2d127-74f7-4a38-ac00-bc62b4eb8eb4)
Change the Authentication Flow to SPNEGO, Veridium Journey and click on Save:
![](../../__attachments/3554673625/image-20220104-125249.png?inst-v=ffa2d127-74f7-4a38-ac00-bc62b4eb8eb4)
Enable SPNEGO on end-users devices
SPNEGO relies on the HTTP Negociate authentication scheme (WWW-Authenticate: Negociate) and requires that the browsers are aware of this configuration.
This may be enabled for most devices that are aware of Kerberos authentication like Windows, Linux, Mac OS, ChromeOS, iOS or Android devices.
Windows
If the machine is domain joined, it automatically receives a kerberos token during the login session. It is also possible to obtain a kerberos token for a machine outside of domain as long as it has connection to the KDC. Use klist get upn
Use klist for validate and obtain new kerberos tickets: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist
Internet Explorer
To be able to use SPNEGO connect to a Windows node that is connected to the domain used.
Configuration for Internet Explorer and Microsoft Edge:
Open Internet options and navigate to Security → Local Intranet
Click on Sites then Advanced and add the Shibboleth URL
Click on Custom Level button and make sure to have Automatic logon only in Intranet zone enabled under User Authentication → Logon
Navigate to Advanced and activate Enable Integrated Windows Authentication under Security
Save the configuration
Google Chrome or Microsoft Edge
Local testing configuration
Right click on the Chrome shortcut and select properties
Under target add the following at the end of the line:
--auth-server-whitelist="SHIB_URL" --auth-negotiate-delegate-whitelist="SHIB_URL"
Where SHIB_URL is Shibboleth’s FQDN
Update blow command for example:
CODEExample 1: "C:\Program Files\Google\Chrome\Application\chrome.exe" --auth-server-whitelist="shib.develop.veridium-dev.com" --auth-negotiate-delegate-whitelist="shib.develop.veridium-dev.com"
Save the configuration
Global configuration
Open regedit and navigate to
for Google Chrome Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
for Microsoft Edge Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge
Create the following keys:
AuthNegotiateDelegateAllowlist(https://chromeenterprise.google/policies/#AuthNegotiateDelegateAllowlist ), type String, value FQDN of the IDP (e.g. develop.veridium-dev.com)
AuthServerAllowlist (https://chromeenterprise.google/policies/#AuthServerAllowlist ), type String, value FQDN of the IDP (e.g. develop.veridium-dev.com)
AmbientAuthenticationInPrivateModesEnabled (optional) (https://chromeenterprise.google/policies/?policy=AmbientAuthenticationInPrivateModesEnabled ), type integer, value 3 (enables Kerberos SSO for all browser instances, nomal, guest or incognito).
Restart the browser or reload policies from chrome://policy.
If ADFS is used as an IDP, you must run (from a PowerShell window) Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Mozilla/5.0') on the ADFS server to allow the proper UserAgents for Windows Integrated Authentication and enable Windows Authentication under Authentication Methods in Intranet section in ADFS administration console:
![](../../__attachments/3554673625/image-20220506-131709.png?inst-v=ffa2d127-74f7-4a38-ac00-bc62b4eb8eb4)
Mozilla Firefox
Open Mozilla Firefox and access about:config
Search for and modify the entry named network.negotiate-auth.trusted-uris by entering the name of the IDP.
Mac OS
If the machine is domain joined, it automatically receives a kerberos token during the login session. It is also possible to obtain a kerberos token for a machine outside of domain as long as it has connection to the KDC.
You can use kinit
to obtain the krbtgt ticket for a domain user and klist -a
to verify if the ticket was received properly. To clear a token use kdestroy
command.
kinit -r 12h -f -p -l 12h user@DOMAIN.LOCAL
Google Chorme
Run the following commands to setup the allowed server lists to grant access to kerberos tickets
defaults write com.google.Chrome AuthServerAllowlist "shib.dev1.veridium-dev.com,*.veridium-dev.com"
defaults write com.google.Chrome AuthNegotiateDelegateAllowlist "shib.dev1.veridium-dev.com,*.veridium-dev.com"
Restart chrome or reload policies from chrome://policy
.
Mozilla Firefox
Open Mozilla Firefox and access about:config
Search for and modify the entry named network.negotiate-auth.trusted-uris by entering the name of the IDP.
Troubleshooting and Debugging
Kerberos SSO is not triggered even if the ticket is available on the machine.
Verify the encryption type of the kerberos ticket and inspect if the configured keytab has support for the specified encryption type. The encryption type is not negotiated when the Kerberos ticket is obtained and may be related with the default configuration. Make sure that proper encryption types are configured globally or per account.
Kerberos ticket is not created on the machine
Verify that SPNEGO was enabled correctly for the application you are trying to access. When the SPNEGO configuration is in place an error page for SPNEGO not available should be spotted briefly during authentication flow.
Verify the DNS resolved name of the IDP and the Keytab SPN. The SPN should be for the same resolved name, otherwise KDC would not provide a ticket for during DNS validation.
How to enable tracing logs on Veridium Server
Setting kerberos and spnego on debug via JAVA options from tomcat configuration. Append the following lines to
/opt/veridiumid/tomcat/bin/setenv.sh
CODEJAVA_OPTS="$JAVA_OPTS -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true -Dsun.security.jgss.debug=true"
Increase log levels for Shibboleth SPNEGO by adding the following lines in
/opt/veridiumid/shibboleth-idp/conf/logback.xml
CODE<logger name="com.veridium.integrations.shibboleth.spnego" level="TRACE"/> <logger name="net.shibboleth.idp.authn.spnego" level="TRACE"/>