Univention Bugzilla – Bug 36052
S4-Connector overwrites custom userPrincipalName value of accounts initially created in Samba
Last modified: 2020-07-03 20:54:46 CEST
If one wants to configure Kerberos authentication (+ SSO) with third party services there are at least the following steps necessary: 1. create a user 2. add SPN (Service Prinicipal Name) to this user 3. export keytab for this SPN 4. Use this keytab for the third party service With Samba 4 the command to add a SPN is: > samba-tool spn add service/host.example.lan username alternatively with the realm: > samba-tool spn add service/host.example.lan@EXAMPLE.COM username This actually adds a SPN: > univention-s4search CN=username servicePrincipalName > [...] > servicePrincipalName: hdfs/host.example.lan@EXAMPLE.LAN > servicePrincipalName: hdfs/host.example.lan > [...] But kerberos authentication fails nevertheless: > kinit -kt exported.keytab > service/host.example.lan@EXAMPLE.LAN > kinit: Client not found in Kerberos database while getting initial credentials A workaround is to additionally change the value of 'userPrincipalName' to 'hdfs/host.example.lan@EXAMPLE.LAN' using ldbedit. MS AD seems to do this automatically when adding a SPN.
Created attachment 6146 [details] Script to workaround bug Small script to automate this fix. Just use this script as EDITOR in ldbedit f.e. ldbedit #!DANGER!# -e /root/spn_rewrite.pl -S -H ldapi:///var/lib/samba/private/ldap_priv/ldapi '(cn=cdhkrb_*)' to modify all users beginning with "cdhkrb_"
* The SPN is for getting a AS ticket: ========================================================================== root@master50:~# kinit -S "DNS/$(hostname -f)" user1 user1@AR40I1.QA's Password: root@master50:~# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: user1@AR40I1.QA Issued Expires Principal Oct 6 17:30:15 2014 Oct 7 03:30:14 2014 DNS/master50.ar40i1.qa@AR40I1.QA =========================================================================== * Note that there is also "samba-tool user upn". * According to MS docs it's the responsibility of the service installer to create the desired SPNs http://msdn.microsoft.com/en-us/library/ms677949%28v=vs.85%29.aspx
> * The SPN is for getting a AS ticket: This should read: The SPN is for getting a Client-to-server ticket from the AS which it uses to connect to the Service Server identified by the SPN.
Don't think this is "resolved" and I'm really a little bit pissed in trying to explain this again and again and a.... Let's assume we use a "real" MS-AD instead of this AD-look-a-like and let's a assume we are using a software which created the required SPNs automatically for you. Then the real AD would change the UPN in the LDIF-Export the software would be able to use the SPN to get a ticket and everything is working like a charm. Now let's assume we use a samba4-AD instead. The Software is doing *exactly* the same. The user-accounts are created, the spn created and so on, but the samba4-AD isn't changing the UPN to the SPN@REALM, instead it keeps using the USER@REALM-format. The Software is unable to create a SPN-ticket because kerberos is unable to find the SPN in the database. So if UCS/Samba4 should be a valid replacement for Microsoft Active Directory, it should handle SPN as it's done in Active Directory. P.S.: Please repeat your tests with SPN not UPN!
Ok, details about this can be found at Ticket# 2014092621000165, especially posting 30.09.2014 12:14:03 and 06.10.2014 10:35:04. We should first check if this issue is caused by some behavior of the S4-Connector or if it is a Samba code related issue (or a combination).
Created attachment 8074 [details] create_user_with_special_UPN.sh I guess the attached script reproduces the issue and it looks like the reported difference in the behaviour of UCS/Samba and native AD is not caused by Samba but by the S4-Connector. When I stop it before running the test, the userPrincipalName is set just like specified in the ldapmodify / ldapadd. But when you then start the S4-Connector again, the userPrincipalName (UPN) gets overwritten by the default one. It can be set again to the desired value by running samba-tool user upn set "$USER" "$PRINC" after some time (to avoid a race condition with the S4-Connector, see script). About the confusion of this bug report: I was just confused by the reference to "servicePrincipalName" (SPN) in this report, because the servicePrincipalName is not involved in this (and the S4-Connector doesn't change it). Notice that the usage of kinit is like this: kinit [-S <SPN>] <UPN> i.e., kinit argument <UPN> is the subject getting the ticket while <SPN> is the object that he wants a ticket for. Usually one doesn't specify the SPN, because the kerberized client tools fetch the corresponding service ticket automatically. So it is a fact that you have to specify the actual UPN as *argument* to kinit, and not the SPN. That's not the bug here. Only after digging though the details and files attached to the ticket again at length I was in a position to understand that this bug report asks about having a special *userPrincipalName*.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.