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
Samba Winbind reports this group as:
Whereas sssd-ad reports:
We also we have the commercial QAS AD Linux solution and it also reports:
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
1003 Domain Users
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):
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.
design_review: => 0
mark: no => 0
review: True => 0
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.
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:
If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.
Thank you for understanding. We apologize for all inconvenience.
to comment on this ticket.