Univention Bugzilla – Bug 55117
Samba/AD doesn't handle multiple spaces properly -> objects cannot be found
Last modified: 2023-08-15 15:23:05 CEST
Samba/AD doesn't handle multiple spaces properly which causes situations where objects cannot be found. Technically you can see with tdbdump that multiple spaces get compressed to a single space in the indices in sam.ldb. Since the indices are required to map an attibute to a an objectGUID and then to use that GUID to retrieve the actual object, this can have very strange effects. One of then is, that the S4-Connector doesn't find the object and then adds a second one -- with the same sAMAcccountName. No fun in revovering that. `samba-tool dbcheck --reindex` can help, but may also hide the evil twin if there is one.
Comparison between MS Active Directory (2012 in my VM) and Samba/AD (4.16): Samba finds the "Domain Admins" object when I search like this: univention-s4search "cn= Domain Admins" or even: univention-ldapsearch -b "CN = Domain Admins,CN=Groups,DC=ucs50domain , DC = net" That looks like a bug in Samba, AD doesn't behave like that: ldbsearch -H ldap://10.200.8.200 -U Administrator%Univention.3 "CN=Domain Admins" 1.1 -> no match Well, partly... This works against AD (2012): ldbsearch -H ldap://10.200.8.200 -U Administrator%Univention.3 -b "CN=Domain Admins ,CN=Users,DC=w2k12addomain , DC= net" but this doesn't: ldbsearch -H ldap://10.200.8.200 -U Administrator%Univention.3 -b "CN=Domain Admins ,CN=Users,DC=w2k12addomain , DC= net"
FYI: Apart from Samba, also OpenLDAP seems to have some peculiar behavior: root@primary20:~# ldapsearch -o ldif-wrap=no -ZZ -D cn=primary20,cn=dc,cn=computers,dc=ucs50domain,dc=net -y /etc/machine.secret -LLL -b 'cn=" Domain Admins ",cn = groups,dc=ucs50domain,dc= net' gidnumber dn: cn=Domain Admins,cn=groups,dc=ucs50domain,dc=net gidNumber: 5000 Now for the theory: It seems to be normal that spaces at the beginning and end of attributes and values get stripped if they are not escaped: see e.g. https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ldap/distinguished-names "The following table lists reserved characters that cannot be used in an attribute value without being escaped." * "space or # character at the beginning of a string" * "space character at the end of a string" Testing with python-ldap shows that it's space preserving in RDN values: >>> ldap.dn.dn2str(ldap.dn.str2dn('cn= Domain Admins ,cn = groups,dc=ucs50domain,dc= net')) 'cn=Domain Admins,cn=groups,dc=ucs50domain,dc=net' >>> ldap.dn.dn2str(ldap.dn.str2dn('cn=" Domain Admins ",cn = groups,dc=ucs50domain,dc= net')) 'cn=\\ Domain Admins \\ ,cn=groups,dc=ucs50domain,dc=net'
Is this something that should be reported upstream?
Actually Julia pointed out that there is some confusion here (on my side) between 1. standard behavior of the LDAP IA5 matching rule, which treats repeated (and leading/trailing) spaces as single spaces 2. the S4-Connector (apparently?) circumventing this duplicate check in Samba/AD, probably by using high privilege LDAP controls (e.g. the provision control, but also others) We were not able to reproduce this in a fairly quick test today (test VM) but since the above mentioned LDAP controls seem to be used in UCS@school setups only (from reading the code), it could be that specifically those are affected by this. From this first analysis I guess it's more a thing that we need to avoid in the S4-Connector.
We've attached two more support tickets both from school customers. It looks like something triggers this issue or it is a coincidence.