#2593 Does sssd-ad use the most suitable attribute for group name?
Closed: Fixed None Opened 5 years ago by jhrozek.

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

Fields changed

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

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata