Debugging the SAML Kerberos authentication

With UCS 4.3, it is possible to associate the SAML authentication with the Kerberos login. This means that users with a valid Kerberos ticket, for example after logging on to Windows or Linux, can log on to the identity provider without having to manual re-authenticate.

First, make sure that Single Sign-On is working in general. When clicking the Univention Management Console link on the UCS Portal, the URL should contain simplesamlphp when the login page is shown.

Therefore, the following tasks have to be done:

  • Change the UCR variable saml/idp/authsource from univention-ldap to univention-negotiate.
  • The web browsers must be configured to transfer the Kerberos ticket to the SAML identity provider.
    • Firefox: about:config β†’ add ucs-sso.$domainname to network.negotiate-auth.trusted-uris
    • Microsoft web browsers: Control Panel β†’ Internet Options β†’ Security β†’ Local Intranet β†’ Sites β†’ Advanced β†’ add ucs-sso.$domainname

If a different DNS name for ucs-sso.$domainname is used, it has to be replaced.

If the Kerberos authentication at the SAML identity provider doesn’t work, the following issues have to be checked:

  • Have UCR or Apache configurations been changed? It should look like the following output:
root@master501:~# univention-check-templates 2>&1 | egrep "(apache|saml)"
root@master501:~# 
  • Is the keytab generated and can a Kerberos ticket created? Otherwise the join scripts 91univention-saml.inst and if available 98univention-samba4-saml-kerberos.inst should be re-executed
root@master501:~# ktutil --keytab=/etc/simplesamlphp.keytab list
/etc/simplesamlphp.keytab:

Vno  Type                     Principal                                             Aliases
  1  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
  1  des3-cbc-sha1            HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
  1  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
  1  des-cbc-crc              HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
  1  des-cbc-md4              HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
  1  arcfour-hmac-md5         HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
  1  des-cbc-md5              HTTP/ucs-sso.deadlock50.intranet@DEADLOCK50.INTRANET  
root@master501:~# kinit -t /etc/simplesamlphp.keytab HTTP/ucs-sso.$(ucr get domainname)@$(ucr get kerberos/realm)
root@master501:~# 
  • The log files /var/log/apache2/* and /var/log/syslog should be checked.
  • Does the logged in user in Windows or Linux have a valid Kerberos Ticket for the UCS domain? Check with klist

You should also check the DNS entry for ucs-sso. This entry has to be an A-record and not an alias or CNAME entry:

dig ucs-sso.schein.qa
[..]
;; ANSWER SECTION:
ucs-sso.schein.qa.	900	IN	A	10.200.43.122
[..]

WRONG!:
;; ANSWER SECTION:
ucs-sso.schein.qa.	900	IN      CNAME   ucs-master.schein.qa.

If this is in a school scenario, the schoolslaves should be checked, if there exists the servicePrincipalName for ucs-sso.
samba-tool spn list "ucs-sso"
If the answer is:
User CN=ucs-sso,CN=Users,DC=schein,DC=qa has no servicePrincipalName
then it should be created:
samba-tool spn add "HTTP/ucs-sso.$(hostname -d)" "ucs-sso"
reboot client & click on the login-button, this should work now.

2 Likes
Mastodon