Univention Bugzilla – Bug 50304
Support for custom sAMAccountName != uid
Last modified: 2022-02-24 15:48:42 CET
At the start of most UCS@school projects, the discussion about username length comes up right at the beginning. In UCS@school it is not recommended to use usernames longer than 15 characters. The reason is a combination of a historical limitation in MS domains for the sAMAccountName (max. 20 characters, see also bug #47222) and the exam mode in UCS@school (+5 characters for the -exams prefix). However, this is a problem for the users and will be negatively marked when starting UCS@school projects. A solution to this problem would be to synchronize UserPrincipalName & sAMAccountName independently in the S4 connector. The UserPrincipalName may be more than 20 characters long and could also solve the problem with regard to the standardization of user names towards username@domain in the future.
(In reply to Michel Smidt from comment #0) > In UCS@school it is not recommended to use usernames longer than 15 > characters. The reason is a combination of a historical limitation in MS > domains for the sAMAccountName (max. 20 characters, see also bug #47222) and > the exam mode in UCS@school (+5 characters for the -exams prefix). Just for completeness: - the exam prefix is "exam-" → 5 characters - the exam prefix can be customized via the UCR variable "ucsschool/ldap/default/userprefix/exam" and therefore also be set to a shorter prefix (at least 1 character which is also allowed to be used within a username)
(In reply to Sönke Schwardt-Krummrich from comment #1) > "ucsschool/ldap/default/userprefix/exam" and therefore also be set to a > shorter > prefix (at least 1 character which is also allowed to be used within a > username) In reality it probably must be 2 characters, as a username must start with a letter and to prevent possible account duplications the prefix should contain some special char, e.g. "e-".
In a quick test I cannot see that the S4-Connector needs adjustment. I think it's just that the UDM currently doesn't expose the krb5PrincipalName as an UDM property. In my test I created a user1 with udm, extracted the ldif with ldapsearch, modifies the ldif with "sed 's/user1/user2/g'" and replaced the krb5PrincipalName by: krb5PrincipalName: user2hasanexceptionallylongname@AR41I1.QA. Then I used ldapadd to create this object in OpenLDAP. The S4-connector faithfully synchonized the object, and I can use the userPrincipalName to obtain a Kerberos Ticket and to authenticate: ========================================================================== root@master10:~# kinit user2hasanexceptionallylongname@AR41I1.QA user2hasanexceptionallylongname@AR41I1.QA's Password: root@master10:~# smbclient -k "//$(hostname -f)/sysvol" -c ls . D 0 Mon Nov 23 18:08:36 2015 .. D 0 Mon Oct 7 09:40:25 2019 ar41i1.qa D 0 Mon Nov 23 18:08:38 2015 48135984 blocks of size 1024. 40447152 blocks available ==========================================================================
Created attachment 10197 [details] patch UDM (In reply to Arvid Requate from comment #3) > In a quick test I cannot see that the S4-Connector needs adjustment. I think > it's just that the UDM currently doesn't expose the krb5PrincipalName as an > UDM property. Patch attached. Not sure if we really want this.
The exam mode doesn't use UDM but it clones the LDAP attributes of a user. It could just not strip the krb5Principal at 20 characters but let the uid still be max. 20 chars.
After discussing this with Jürn I think I have now better understood the idea of this bug, so Comment 3 (and Comment 4) are probably obsolete. The idea seems to be to have in OpenLDAP: uid: school1-verylongusername krb5PrincipalName: school1-verylongusername@KERBEROS.REALM and in Samba/AD: sAMAccountName: school1-randomID1234 userPrincipalName: school1-verylongusername@KERBEROS.REALM If this is true, then we would need to have to implement a custom mapping function for sAMAccountName instead of our standard samaccountname_dn_mapping function.
In response to Arvid (and I hope not perceived as hijacking attempt to #49954 which is about the AD connector Microsoft says about the UPN Attribute: "By convention, this should map to the user email name." This becomes ever moreso a "forced" convention with Azure services that only work with RFC822 format user names and you end up having user to remember both a mail address and their UPN which both have a domain suffix. Source: https://docs.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname Copying Arvids example in Samba/AD I see it more like: sAMAccountName: school1-randomID1234 userPrincipalName: school1-verylongusername@kerberos.realm or: school1-verylongusername@myschool.tld - <suffix.kerberos.realm usually is often lower case in AD (it's case insensitive though, suffice to say that users do ask if they need to care about, so if all is lower case you get less questions) - kerberos.realm usually is the default before registering alternate suffixes in a forest - Once additional suffixes are registered in a forest, they can be applied on a per-user basis. While this issue is about UCS@School, #49954 is specific about the AD connector. The same applies technically also with the S4 connector when a service gets tied to S4 and users use the UPN when such mapping would helpful in making it fit for a use case and not only about UCS@School environments. Which is - if I understood Arvid correctly - is actually what he proposes about implementing a custom mapping function for sAMAccountName.