Skip to main content
Skip table of contents

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:

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

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

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

  1. recover from PS the “/princ” parameter value (e.g.: HTTP/shib-aerolocal.veridium-dev.com )

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

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

CODE 
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

  1. Navigate to Settings / Identity Provider / Configuration/ Authentication

Kerberos.png

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

3. Click on Save in the right side of the screen:

kerberos save.png

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

  1. Change the Authentication Flow to SPNEGO, Veridium Journey and click on Save:

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.

  1. Configuration for Internet Explorer and Microsoft Edge:

    1. Open Internet options and navigate to Security → Local Intranet

    2. Click on Sites then Advanced and add the Shibboleth URL

    3. Click on Custom Level button and make sure to have Automatic logon only in Intranet zone enabled under User Authentication → Logon

    4. Navigate to Advanced and activate Enable Integrated Windows Authentication under Security

    5. Save the configuration

Google Chrome or Microsoft Edge

Local testing configuration

  1. Right click on the Chrome shortcut and select properties

    • Under target add the following at the end of the line:

      1. --auth-server-whitelist="SHIB_URL" --auth-negotiate-delegate-whitelist="SHIB_URL"

      2. Where SHIB_URL is Shibboleth’s FQDN

      3. Update blow command for example:

        CODE 
        Example 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"

      4. Save the configuration

Global configuration

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

  1. Create the following keys:

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

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.

BASH 
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

CODE 
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

      CODE 
      JAVA_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"/>
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close