Univention Bugzilla – Bug 52760
Updating username with just a change in the name's case not possible
Last modified: 2022-06-08 16:50:26 CEST
This may be related to https://forge.univention.org/bugzilla/show_bug.cgi?id=41711. When a username e.g. "my.name" is updated by only changing some letters case within the name e.g. to "My.NaMe", the rename process fails with the following error message: "Das LDAP-Objekt konnte nicht gespeichert werden: Der Benutzername wird bereits als Benutzername oder als Gruppenname verwendet <My.NaMe>" A temporary object gets created and blocks other usually working rename strategies e.g. my.name > my.name2 > My.NaMe while being valid: dn=My.NaMe,cn=uid,cn=temporary, cn=univention,$(ucr get ldap/base)
*** Bug 33725 has been marked as a duplicate of this bug. ***
*** Bug 28230 has been marked as a duplicate of this bug. ***
*** Bug 48181 has been marked as a duplicate of this bug. ***
(In reply to Florian Best from comment #3) > *** Bug 48181 has been marked as a duplicate of this bug. *** > UCS 4.3-2 Errata 305 > > It's not possible to "rename" a username from e.g. mixed-case to lowercase: > > uid: Michael.Grandjean -> michael.grandjean > > The attempt will result in this notification: > "The LDAP object could not be saved: The username is already in use as > username or as groupname michael.grandjean" > > In most cases the "uid" attribute is case-insensitive, but there are reasons > why we want to change the casing: > - Bugs in our and in other software products that are case-sensitive > - Querying the group attribute "uniqueMember" or "memberUid" - there the > "uid" is (part of) the value and those ldap queries *are* case sensitive > (e.g. memberUid="uid=Michael.Grandjean" != memberUid="uid=michael.grandjean")
We had a very long support debug session, because during the ucs-school-purge-expired-users cronjob in @school, we have discrepancies in group memberships afterwards. Unfortunately the groups where the users are still in, are untouched, so nothing to see in directory-logger.log or listener.log. Bug we could reproduce it, when we had a clue, what the cause could be: udm users/user create --position="cn=users,$(ucr get ldap/base)" --set firstname=univentiontest4benutzer --set lastname=tester --set username=univentiontest4 --set password=univention4UCS Object created: uid=univentiontest4,cn=users,dc=schein,dc=ig udm groups/group modify --dn 'cn=lehrer-sun,cn=groups,ou=SUN,dc=schein,dc=ig' --append users='uid=UNIVENTIONTEST4,cn=users,dc=schein,dc=ig' Object modified: cn=lehrer-sun,cn=groups,ou=SUN,dc=schein,dc=ig root@ucs-master:~/univention-support# udm users/user remove --dn uid=univentiontest4,cn=users,dc=schein,dc=ig No such attribute Afterwards: univention-ldapsearch -LLL cn=lehrer-sun |grep -i univentiontest4 memberUid: UNIVENTIONTEST4 uniqueMember: uid=UNIVENTIONTEST4,cn=users,dc=schein,dc=ig
There are two different issues here. 1) renaming of users 2) group member handling Regarding 1) * Why change the case of a username? Those should be handled case insensitively everywhere. The comparison function is defined in LDAP as "caseIgnoreMatch". What is the use case that requires renaming a user by changing only the case? * The temporary lock object should have been removed. You have probably done that renaming repeatedly in quick succession. Usually that strategy works: ----------------------------------------------------------------------------- root@schoola1:~# udm users/user modify --dn uid=demo_student,cn=schueler,cn=users,ou=DEMOSCHOOL,dc=uni1,dc=dtr --set username=demo_student2 Object modified: uid=demo_student2,cn=schueler,cn=users,ou=DEMOSCHOOL,dc=uni1,dc=dtr root@schoola1:~# udm users/user modify --dn uid=demo_student2,cn=schueler,cn=users,ou=DEMOSCHOOL,dc=uni1,dc=dtr --set username=Demo_Student Object modified: uid=Demo_Student,cn=schueler,cn=users,ou=DEMOSCHOOL,dc=uni1,dc=dtr ----------------------------------------------------------------------------- Regarding 2) This does actually look like a bug in UDM. When adding users as members it does not check if that user actually exists or for uid uniqueness or anything: ----------------------------------------------------------------------------- root@schoola1:~# udm groups/group modify --dn cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr --append users=uid=foo,cn=bar,cn=baz,ou=DEMOSCHOOL,dc=uni1,dc=dtr root@schoola1:~# udm groups/group modify --dn cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr --append users=uid=foo,cn=bar,cn=baz Object modified: cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr root@schoola1:~# univention-ldapsearch -LLL cn=DEMOSCHOOL-Democlass | grep -i foo uniqueMember: uid=foo,cn=bar,cn=baz,ou=DEMOSCHOOL,dc=uni1,dc=dtr uniqueMember: uid=foo,cn=bar,cn=baz memberUid: foo ----------------------------------------------------------------------------- IMHO that is OK, as you shuold know what you are doing, when using UDM and handling DNs. Bug the error happens when removing a member. The DN comparison should be case insensitive. ----------------------------------------------------------------------------- root@schoola1:~# udm groups/group modify --dn cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr --remove users=uid=FOO,cn=bar,cn=baz WARNING: cannot remove uid=FOO,cn=bar,cn=baz from users, value does not exist No modification: cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr root@schoola1:~# udm groups/group modify --dn cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr --remove users=uid=foo,cn=bar,cn=baz Object modified: cn=DEMOSCHOOL-Democlass,cn=klassen,cn=schueler,cn=groups,ou=DEMOSCHOOL,dc=uni1,dc=dtr ----------------------------------------------------------------------------- There is already a bug report for this: Bug 54183. === So IMHO what is left to discuss here is: * Why change the case of a username? What is the use case and what relevancy does it have?
(In reply to Daniel Tröder from comment #7) > There are two different issues here. > 1) renaming of users > 2) group member handling > > Regarding 1) > > * Why change the case of a username? > Those should be handled case insensitively everywhere. > The comparison function is defined in LDAP as "caseIgnoreMatch". > What is the use case that requires renaming a user by changing only the > case? The customer wants it and it it's only for a better looking username. I think UDM should support that OOTB. > * The temporary lock object should have been removed. You have probably done > that renaming repeatedly in quick succession. Usually that strategy works: The strategy has a small risk compared to a one-time operation: It invokes listener modules twice. We had race conditions in listener modules or S4-Connector in the past. it reduces risk for ping pongs and unnecessary "move" operations. I compared both variants and both deliver the same result (e.g. changed DN, uid, krb5PrincipalName and unchanged homeDirectory, cn. The changes required to support this is very small: diff --git management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py index 2a642c4007..7a316c4cf6 100644 --- management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py +++ management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py @@ -1677,7 +1677,7 @@ class object(univention.admin.handlers.simpleLdap): if self['primaryGroup'] and not self.lo.getAttr(self['primaryGroup'], 'sambaSID'): raise univention.admin.uexceptions.primaryGroupWithoutSamba(self['primaryGroup']) - if not self.exists() or self.hasChanged('username'): + if not self.exists() or self.hasChanged('username') and self['username'].lower() != self.oldinfo['username'].lower(): check_prohibited_username(self.lo, self['username']) # get lock for username > Regarding 2) > > This does actually look like a bug in UDM. When adding users as members it > does not check if that user actually exists or for uid uniqueness or > anything: > > > IMHO that is OK, as you should know what you are doing, when using UDM and > handling DNs. Yes, this behavior is required for the S4/AD Connector as they (used to?) are putting users into groups before creating them. > But the error happens when removing a member. The DN comparison should be > case insensitive. Yep. > There is already a bug report for this: Bug #54183. Hm, that bug has different symptoms. I think this is Bug #43286.
MR https://git.knut.univention.de/univention/ucs/-/merge_requests/309 fixes the change of case for: users/user: username groups/group: name, mailAddress computers/*: name mail/lists: mailAddress mail/folder: mailPrimaryAddress
See comment #9. Fixed in: univention-directory-manager-modules.yaml 398937482933 | Bug #52760: allow case changes without triggering locking mechanism univention-directory-manager-modules (15.0.11-41) b3ad87adae18 | refactor[mailPrimaryAddress]: lowercase in common _ldap_pre_ready() 398937482933 | Bug #52760: allow case changes without triggering locking mechanism
Successfully tested the following cases using udm modify command: For every case the respective attribute was changed by - only changing the case of one or more letters. - also changing the attribute so that before.lower() != after.lower() users/user → username users/user → mailPrimaryAddress. (is always lowercase) groups/group → name groups/group → mailAddress computers/linux, computers/windows → name
<https://errata.software-univention.de/#/?erratum=5.0x335>