Description of problem: If I log into an IdM client machine I *sometimes* get a uid in lowercase (test) and sometimes in mixed case (Test) If I create a user with a mixed case id in AD and the use a winsync process to sync that account to IdM, the dataset within IdM should be consistent. Version-Release number of selected component (if applicable): How reproducible: If I create a user with a mixed case id in AD and the use a winsync process to sync that account to IdM, the dataset within IdM should be consistent. But if the user was created in lower case then sometimes it returns the uid in lowercase and sometime in mixed case. Steps to Reproduce: 1. 2. 3. Actual results: id should not return mixed case Expected results: Additional info:
Created attachment 1651811 [details] screenshot from webui
case_sensitive = False is working. But customer wants to know the actual reason.
Ming, thanks for the reproducer, I was also able to see the same behavior. If the AD entry contains a samAccountName with mixed case, the dn (with uid=...,cn=users,cn=accounts,$BASEDN) on IdM side will also be mixed-case, but the uid attribute is lowercase. When the entry DN is built on IdM side, the code is using samAccountName to create uid and DN. 1. The samAccountName is read using the method extract_username_from_entry() defined in 389-ds-base/ldap/servers/plugins/replication/windows_protocol_util.c: static char * extract_username_from_entry(Slapi_Entry *e) { char *uid = NULL; uid = slapi_entry_attr_get_charptr(e, "samAccountName"); return uid; } This method does not lowercase the value. Using this value, the entry DN is created in map_entry_dn_inbound_ext() defined in the same file: username = extract_username_from_entry(e); <<<<<<<<<<<<<< mixed case value from samAccountName [...] new_dn_string = slapi_create_dn_string("uid=\"%s\",%s%s", username, container_str, suffix); 2. Strangely, the same samAccountName value is used to build the uid attribute but the code seems to lowercase the value. I did not check where this normalization is done. Re-assigning this issue to 389-ds as the repl plugin should use a consistent case in the uid attribute and in the dn uid=...,cn=users,cn=accounts,$BASEDN when creating a new entry.
I can not reproduce this behavior with DS alone. If I add an entry with mixed case on AD it is replicated (via winsync replication) with that same case to DS: On AD: dn: CN=Mark T. Reynolds,CN=Users,DC=ad,DC=test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Mark T. Reynolds sn: Reynolds givenName: Mark initials: T distinguishedName: CN=Mark T. Reynolds,CN=Users,DC=ad,DC=test displayName: Mark T. Reynolds name: Mark T. Reynolds sAMAccountName: Mareynol ... On DS dn: uid=Mareynol,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetOrgPerson objectclass: ntUser uid: Mareynol sn: Reynolds givenName: Mark initials: T cn: Mark T. Reynolds ntUserDomainId: Mareynol ... Looking at the DS code we do not do any kind of normalizing of values in replication. We write it how AD sends it to us. If something is changing the case it's not Directory Server doing it. If it only happens with IPA then this is a probably an issue on their side. Actually, I thought IPA didn't even use winsync? Can someone confirm if this is occurring with a Winsync Replication Agreement (on DS), and not some other IPA plugin?
It was reported against IPA which has a winsync plugin which extends the DS plugin. winsync is not recommended these days but it is still an option. So I think you did reproduce it. The IPA code I think later will modify uid to lower case, leaving the DN and uid values with different values. IPA converts the uid to lower-case, saves the value and then uses it generate the principal. https://github.com/freeipa/freeipa/blob/master/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync.c#L317 This seems to be what we're seeing.
(In reply to Rob Crittenden from comment #26) > It was reported against IPA which has a winsync plugin which extends the DS > plugin. So does IPA call some of DS's winsync functions? > winsync is not recommended these days but it is still an option. > > So I think you did reproduce it. The IPA code I think later will modify uid > to lower case, leaving the DN and uid values with different values. > > IPA converts the uid to lower-case, saves the value and then uses it > generate the principal. > > https://github.com/freeipa/freeipa/blob/master/daemons/ipa-slapi-plugins/ipa- > winsync/ipa-winsync.c#L317 > > This seems to be what we're seeing. I guess I'm confused about this :-) Do you want DS's winsync code to lowercase the uid and DN values that comes from AD?
(In reply to mreynolds from comment #27) > (In reply to Rob Crittenden from comment #26) > > It was reported against IPA which has a winsync plugin which extends the DS > > plugin. > > So does IPA call some of DS's winsync functions? > > > winsync is not recommended these days but it is still an option. > > > > So I think you did reproduce it. The IPA code I think later will modify uid > > to lower case, leaving the DN and uid values with different values. > > > > IPA converts the uid to lower-case, saves the value and then uses it > > generate the principal. > > > > https://github.com/freeipa/freeipa/blob/master/daemons/ipa-slapi-plugins/ipa- > > winsync/ipa-winsync.c#L317 > > > > This seems to be what we're seeing. > > > I guess I'm confused about this :-) Do you want DS's winsync code to > lowercase the uid and DN values that comes from AD? The more I think about this, the more I don't like it. DS should not be mangling values that come from the client(AD). This could cause issues for customers who want the correct/expected case. If IPA is already doing the lowercasing of the UID attribute, then IPA can just do a modrdn to adjust the DN to lowercase. I don't think this should be "fixed" on the DS side since DS is behaving correctly.
(In reply to mreynolds from comment #28) > > (In reply to mreynolds from comment #27) > > (In reply to Rob Crittenden from comment #26) > > > It was reported against IPA which has a winsync plugin which extends the DS > > > plugin. > > > > So does IPA call some of DS's winsync functions? > > > > > winsync is not recommended these days but it is still an option. > > > > > > So I think you did reproduce it. The IPA code I think later will modify uid > > > to lower case, leaving the DN and uid values with different values. > > > > > > IPA converts the uid to lower-case, saves the value and then uses it > > > generate the principal. > > > > > > https://github.com/freeipa/freeipa/blob/master/daemons/ipa-slapi-plugins/ipa- > > > winsync/ipa-winsync.c#L317 > > > > > > This seems to be what we're seeing. > > > > > > I guess I'm confused about this :-) Do you want DS's winsync code to > > lowercase the uid and DN values that comes from AD? > > The more I think about this, the more I don't like it. DS should not be > mangling values that come from the client(AD). This could cause issues for > customers who want the correct/expected case. If IPA is already doing the > lowercasing of the UID attribute, then IPA can just do a modrdn to adjust > the DN to lowercase. I don't think this should be "fixed" on the DS side > since DS is behaving correctly. So at ipa-winsync.c#L325 do something like this: char *dn = slapi_entry_get_dn(ds_entry); slapi_entry_set_dn(ds_entry, str_tolower(dn));
Moving bug back to IPA as this should be fixed in that code, and I provided the code to make it work...
RHEL 7.9 is already near the end of a Development Phase and development is being wrapped up. This bug is moved to RHEL 8 for proper evaluation and planning.