Menu
▾
▴
#4657 Impossible to save an LDAP entry when real name is not pure ASCII
It seems that the bug #2494 is back. With 1.770 and locale FR.utf-8, it is no more possible to save an LDAP entry when the user Real Name contains an accent. We always get:
Failed to modify user in LDAP database : gecos: value #0 invalid per syntax
Tying to change via the LDAP browser lead to the same message
(Webmin 1.770, ubuntu server 12.04, local FR.utf-8)
I'm not sure if there's much Webmin can do about this - your LDAP server is rejecting the UTF-8 encoded real name.
Well, I suspect this was previously adressed, because some of the problematic entries were entered with Webmin, so something may have been broken.
Anyway, as it is not advisable to modify the LDAP schema for somtehing as basic as the GECOS, I can suggest two solutions:
1) Decoupling the Gecos from the Real Name,
2) Apply to the real name a processing that insert in the gecos the closest us-ascii string from the real name. I think the Text::unidecode module would perfectly do the job.
I prefer 2) over 1) of course :)
Ok, it looks like option 2 is the way to go, since the LDAP schema for Unix users only supports ascii characters :-( Interesting, Webmin already tries to do this via some badly written code that matches specific accented characters.
In your case, what specific accented characters does the user you are editing have in his real name?
E a-cute "é" that is widely used in French for firstnames as in "Rémi", "André". It is the utf8 code C3 A9. When striped down to us-ascii it should be a simple "e".
Thanks. Also, in your original comment you said that this happened when editing a user. Did the user already have a real name with an "é" that was stored in LDAP?
Yes they had they already had the real name with the accent. I can dump the LDAP record tomorrow if this can help.
Yes, I'd like to see what was actually in the LDAP database before Webmin tried to re-save it. Because it LDAP is rejecting an accented character, how did it get in there in the first place!?
This is a typical entry that exposes the problem. It was created some years ago with Webmin (i can't find the version). sensitive fields are obfuscated oc, and base64 encoded fields (givenName and cn) are decoded.
dn: uid=rXXXXX ,ou=Personnel,ou=People,dc=zzzzzzzzzzzzzz,dc=fr
objectClass: sambaSamAccount
objectClass: shadowAccount
objectClass: posixAccount
objectClass: inetOrgPerson
sambaDomainName: ZZZZZZZZZZZZZ
sambaHomeDrive: M:
sambaKickoffTime: 1893452400
sambaPrimaryGroupSID: S-1-ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
sambaSID: S-ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
shadowWarning: 10
shadowInactive: 10
shadowMin: 1
shadowMax: DDDDD
homeDirectory: /home/rXXXXX
loginShell: /bin/false
gidNumber: 513
uid: rXXXXX
cn:: "Rémi XXXXX "
uidNumber: DDDDD
sn: XXXXX
givenName:: "Rémi"
mail: remi.XXXXX @ZZZZZZZZZZZZZZZ.fr
sambaLogonScript: logonscr.cmd
sambaAcctFlags: [XU ]
sambaLMPassword: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
sambaNTPassword: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
sambaPwdLastSet: 1193044491
shadowExpire: DDDDD
shadowLastChange: DDDDD
description: ZZZZZZZZZZZ
telephoneNumber: +33 ZZZZZZZZZZZZZZZZZ
gecos: Remi XXXXX
Ok, I see now - it is just the gecos field that has this problem.
The next Webmin release will fix this properly.