Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1060325
Description of problem: When using sssd-ad in RFC2307 mode i.e. ldap_id_mapping = False The group name is taken from what appears to be the "cn" attribute in AD? This is absolutely correct as per RFC2307. However this is perhaps not correct when using AD, or at least less desirable. Other solutions and Microsoft's own tools appear to use "sAMAccountName". To take an example, we have a group name "Local IT" (note the space) but it's "Group name (pre-Windows 2000)" in the Users and Computers GUI we have set as "LocalIT" (no space). This seems to set in AD: dn: CN=Local IT,OU=Groups,OU=eame,DC=csl,DC=corp cn: Local IT distinguishedName: CN=Local IT,OU=Groups,OU=eame,DC=csl,DC=corp displayName: Local IT name: Local IT sAMAccountName: LocalIT Samba Winbind reports this group as: localit:*:2006 Whereas sssd-ad reports: local it:*:2006 We also we have the commercial QAS AD Linux solution and it also reports: LocalIT:VAS:2006 Interestingly Microsoft's own tools for identity mapping in NFS via AD RFC2307 attributes (Windows 2012R2) also report the non-spaced version: PS C:\Windows\system32> Get-NfsMappedIdentity -AccountType Group GroupIdentifier GroupName --------------- --------- 1003 Domain Users 2006 LocalIT Not sure if the preferred attribute to use with Unix for group names is documented (by MS) anywhere, I couldn't find it. But sssd-ad appears to be different from others including MS. For interop, I'd have thought SSSD should be the same as MS uses (i.e will potentially make it harder for an SSSD-AD system to work with an MS NFS server). The only reason I guess (and a pure guess) use SamAccountname is that windows groups often have spaces in them, and this can (especially in the past) be problematic in Unix (e.g. Allowgroups in sshd_config until recently couldn't use them). Maybe the thought is you can workaround this by setting a non-spaced version in "Group name (pre-Windows 2000)" and leave the group name displayed in Windows with the spaces. Maybe you guys have more information on this? Not sure if there would be a similar issue for usernames, not sure which attribute you use for that. RFC2307 says uid but AD doesn't seem to have that, so I guess you use what everyone else uses and "SamAccountname"? Version-Release number of selected component (if applicable): sssd-1.11.3-1.fc20 How reproducible: Every time
This is the article that ab sent me that describes what samaccountname is - https://msdn.microsoft.com/en-us/library/ms677605%28v=vs.85%29.aspx
From the text it seems that name is not guaranteed to be unique? However, we can treat duplicate names as a directory error, just like we do with plain LDAP servers.
blockedby: => blocking: => changelog: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => mark: no => 0 review: True => 0 selected: => testsupdated: => 0
Bah, I confused group map and user map. For user maps, we already default to samaccount name, and then I agree with Sumit that samaccountname looks like a good choice for groups also.
1.13 sounds like a good target, given how early in the F-22 cycle we are.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.13 alpha
Sumit volunteered to do the change.
owner: somebody => sbose
patch: 0 => 1
resolution: => fixed status: new => closed
Metadata Update from @jhrozek: - Issue assigned to sbose - Issue set to the milestone: SSSD 1.13 alpha
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3634
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.