Bug 47222 - (usernamelengthlimit) Make it configurable to use usernames longer than 20 characters
(usernamelengthlimit)
Make it configurable to use usernames longer than 20 characters
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: HTTP-API (Kelvin)
UCS@school 4.4
Other All
: P5 normal with 2 votes (vote)
: UCS@school 4.4 v2-errata
Assigned To: Daniel Tröder
Jürn Brodersen
https://docs.microsoft.com/en-us/wind...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-06-20 22:11 CEST by Michel Smidt
Modified: 2023-07-13 18:12 CEST (History)
8 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019032121000971, 2019032621000891
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Smidt 2018-06-20 22:11:13 CEST
Currently it is not possible to use usernames longer than 20 characters in UCS@school. Historically that made sense because on the microsoft side it was a long time a problem for windows clients to handle longer usernames.
At least for windows 10 which I tested it seems no problem any more and microsoft seems to recommend 20 characters only for backward compatibility reasons (see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10) )

The second reason why I propose to change this limitation is the product path of UCS@school to a sole cloud solution with no access of windows clients.

For this reasons I would recommend to make it even possible to increase the limit at least in the HTTP-API (/usr/lib/pymodules/python2.7/ucsschool/importer/configuration.py) for good reasons. If than a customer decide by extra UCR-Variable that he/she would like to increase the limit he/she must be aware of the potencial consequence (which I think are fairly reasonable)
Comment 1 Michel Smidt 2018-10-10 16:37:47 CEST
Tested login (uid/sAMAccountName) and Kerberos tickets (with klist) with multiple Windows versions.

Windows 7
- login + klist possible with max. 20 charatcters
Windows 8.1 & Windows 10
- creation of user (UMC/OpenLDAP) only possible with 241 characters
- login + klist possible with 241 charatcters
Comment 2 Daniel Tröder univentionstaff 2018-10-10 17:22:06 CEST
Great.
Please also test with MacOS X.
Comment 3 Michel Smidt 2019-04-23 10:57:14 CEST
As discussed I set the version to UCS 4.4. Please comment on this bug should it be a problem for you as a customer that the functionality is planned for UCS@school 4.4 only.
Comment 4 Daniel Tröder univentionstaff 2019-04-23 16:39:49 CEST
[4.4] d9a9f46ae Bug #47222: allow usernames longer than 20 characters
[4.4] b4240d7f0 Bug #47222: test long usernames
[4.4] b739eeb57 Bug #47222: changelogs, advisory
[4.4] d820db2ec Bug #47222: advisory update

ucs-school-import (17.0.6-5)
Comment 5 Daniel Tröder univentionstaff 2019-04-30 10:25:01 CEST
Create UCRV on DC master that as the maximum username length for both import and UMC modules.
Comment 6 Jürn Brodersen univentionstaff 2019-04-30 12:31:56 CEST
Some more infos for this:

Samba accepts a "sAMAccountName" longer than 20 characters. This is what we are doing here.
-> Login works under Win10 and Win8.1 but not in Win7 not even when using the userPrincipalName (UPN) (e.g.: ...@my.domain) as the login name, it complains about a buffer that's to short :)

-> The exam mode works

-> RSAT are working, but the sAMAccountName can only be changed after shortened to 20 characters (which is possible within RSAT) :)

-> Some windows api calls seem to shorten the sAMAccountName, e.g. the task manager only shows the first 20 characters

->-> this also seems to break italks display name lookup and the umc only shows the shortened sAMAccountName.

->-> Besides some optical problems with long usernames, I didn't notice any other problems within windows.



As an alternative the sAMAccountName and the UPN do not need to be the same. E.g "userPrincipalName = sam.IhaveAreallyLongSurname@my.domain" and "sAMAccountName = si2"
-> Login works under win7 as well (using either "my\si2" or "sam.IhaveAreallyLongSurname@my.domain"). In the default settings the long account name only works if the UPN is used for login.

-> italk shows the sAMAccountName as the username, but the display name lookup works again.

-> Some programs might not expect the sAMAccountName to differ from the UPN

->-> The s4connector doesn't seem to like that and throws some tracebacks

-> It is possible to set a gpo which makes it possible to login using the long username without having to type in the @my.domain part:
https://support.microsoft.com/de-de/help/2908796/using-gpos-to-change-default-logon-domain-name-in-the-logon-screen
the domain in the gpo needs to be set to "my.domain" (no @), the dot seems to force an UPN login. This works from win7 upwards.




While ensuring that the sAMAccountName is not longer than 20 character feels less hacky, using a long sAMAccountName seems to be working fine and doesn't need any extra work from the ucs side.
Comment 7 Arvid Requate univentionstaff 2019-04-30 19:07:27 CEST
I think we cannot support this officially, because the MS docs say that the samaccountname (aka "Pre Windows-2000 Logon Name") "must be 20 characters or less to support earlier clients". If this would be an RFC, nobody would say, "Ok, it says must, but I don't have that use case".

Assume two situations:

1. A customer decides to use third party program XYZ and that doesn't work with logon names > 20 chars.

2. A customer decides to use an AD-Connector to pump users into some other Actoive Directory domain.


That's where he would hit a brick wall. Active Directory enforces so called "SAM rules", as explained here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc961578(v=technet.10) .

You can quickly test this by spinning up e.g. a W2k8R2 Windows AD DC and running samba-tool against it to create a user with more than 20 chracters:

root@master10:~# samba-tool user create -H ldap://10.200.8.126/ DevelopmentMSSQLSVC01 Univention.1 -U Administrator%Univention.2
ERROR(ldb): Failed to add user 'DevelopmentMSSQLSVC01':  - LDAP error 80 LDAP_OTHER -  <00000523: SysErr: DSID-031A123E, problem 22 (Invalid argument), data 0
> <>

If you reduce the name length by one it works:

root@master10:~# samba-tool user create -H ldap://10.200.8.126/ DevelopmentMSSQLSVCx Univention.1 -U Administrator%Univention.2
User 'DevelopmentMSSQLSVCx' created successfully


OTOH I just checked again with Jürn that, on a UCS Samba/AD you can create  users with longer names (e.g. with samba-tool), and a Windows client joined into the domain also can show those objects properly (up to the limits of the GUI) in the "Active Directory Users and Computers" tool. A trivial change (e.g. street address) doesn't cause this to break.

I think, before activating this technically, we need to establish a decision if and under which conditions we can support this in the product. At least something will have to be added to the UCS@school documentation.
Comment 8 Daniel Tröder univentionstaff 2019-05-03 10:48:28 CEST
Previously commited code in the 4.4 branch (see comment4) was reverted:

[4.4] d1aabefd7 Revert "Bug #47222: allow usernames longer than 20 characters"
[4.4] a0fff7454 Revert "Bug #47222: test long usernames"
[4.4] 342ad036f Bug #47222: changelogs and revert advisory (b739eeb573, d820db2eca)
[4.4] 2d86fddff Bug #47222: update advisory

ucs-school-import (17.0.6-10)
ucs-test-ucsschool (6.0.0-49)
Comment 9 Daniel Tröder univentionstaff 2019-05-06 15:02:25 CEST
Readded previous commits and improved code and tests:

[4.4] 86667da39 Bug #47222: allow usernames longer than 20 characters
[4.4] 03bb494fe Bug #47222: test long usernames
[4.4] c17a4f189 Bug #47222: changelogs, advisory
[4.4] ac7df3a36 Bug #47222: advisory update
[4.4] 5652a1b3e Bug #47222: add UCRV ucsschool/username/max_length to set limit for UMC as well as import
[4.4] b8d1a450f Bug #47222: cleanup
[4.4] fb3b3b4d8 Bug #47222: improve wording
[4.4] 168d588b6 Bug #47222: fix typo
[4.4] 1931dfa5b Bug #47222: improve tests
[4.4] 828ec500e Bug #47222: changelogs
[4.4] 0a19eb24e Bug #47222: advisories

ucs-school-lib (12.1.1-6)
ucs-school-import (17.0.6-11)
ucs-school-umc-wizards (11.0.0-5)
ucs-test-ucsschool (6.0.0-50)
Comment 11 Daniel Tröder univentionstaff 2019-05-07 16:27:18 CEST
Thanks for fixes!

[4.4] 0583e5bfc Bug #47222: fix missing comma
[4.4] 0bcf7907c Bug #47222: Max username length always includes the exam prefix
[4.4] 3cbaa2e19 Bug #47222: fix translation
[4.4] c9d2341f9 Bug #47222: adjust wording

The default username length is not set anymore in the default import configuration file. Instead it is calculated from the UCRV ucsschool/username/max_length. The maximum length of a students username is also now always calculated. Both the default and the students values are explicitly set in the import configuration, so they end up in the logfile.

[4.4] 34c848ddd Bug #47222: always calculate username_max_length for default and student
[4.4] 42d25619f Bug #47222: handle username_max_length changes
[4.4] 1ebbcc4b0 Bug #47222: improve documentation
[4.4] c673892a1 Bug #47222: advisory update

ucs-school-import (17.0.6-13)
ucs-test-ucsschool (6.0.0-51)
Comment 12 Jürn Brodersen univentionstaff 2019-05-08 11:53:44 CEST
What I tested:
ucrv ucsschool/username/max_length default is 20 -> OK
wizard respects ucrv ucsschool/username/max_length -> OK
username->max_length->default -> works for all roles -> OK
username->max_length->student -> overrides default -> OK
username->max_length->* -> can't be bigger than ucrv ucsschool/username/max_length -> OK

Doku -> OK
YAML -> OK

-> Verified
Comment 13 Sönke Schwardt-Krummrich univentionstaff 2019-05-08 22:26:29 CEST
UCS@school 4.4 v2 has been released.

https://docs.software-univention.de/changelog-ucsschool-4.4v2-de.html

If this error occurs again, please clone this bug.