Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060325 - Does sssd-ad use the most suitable attribute for group name?
Summary: Does sssd-ad use the most suitable attribute for group name?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 22
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1199445
TreeView+ depends on / blocked
 
Reported: 2014-01-31 19:26 UTC by Colin.Simpson
Modified: 2015-05-15 15:14 UTC (History)
10 users (show)

Fixed In Version: sssd-1.12.4-6.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1199445 (view as bug list)
Environment:
Last Closed: 2015-05-11 19:01:38 UTC


Attachments (Terms of Use)

Description Colin.Simpson 2014-01-31 19:26:22 UTC
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

Comment 1 Lukas Slebodnik 2014-01-31 20:48:42 UTC
You mentioned you are using package sssd-ad in RFC2307 mode and 
ldap_id_mapping = False

I would like to acknowledge few information. Do you have id_provider=ldap
and ldap_schema = rfc2307 in your configuration file?

id_provider ldap is generic provider and therefore you can see this behaviour with AD, but it is easy to change it.

From man page sssd-ldap
       ldap_group_name (string)
           The LDAP attribute that corresponds to the group name.

           Default: cn

ldap_group_name = sAMAccountName
I hope it helps you.

Comment 2 Jakub Hrozek 2014-01-31 22:50:29 UTC
Colin,

I think you're simply looking for either using:

id_provider=ad
ldap_id_mapping = False

or

id_provider=ldap
ldap_schema=ad

I would recommend using id_provider=ad

Comment 3 Colin.Simpson 2014-01-31 23:54:28 UTC
I'm not sure you are quite getting what I'm saying. I have:

id_provider = ad
access_provider = ad
ldap_id_mapping = False

I'm suggesting that I think, **by default**, the ad provider maybe using the wrong (or at least a less desirable) attribute from AD for the group name (when using POSIX aka RFC2307 attributes i.e ldap_id_mapping = false).

I fully realise I can fudge the issue (maybe by having to use the ldap id_provider) but my point is that the default attribute used (probably cn) ,for the group name, using the pure ad provider is maybe less desirable than using the sAMAccountName. 

I'm willing to be shown this is wrong, but my evidence for this is in the original report.

Comment 4 Dmitri Pal 2014-02-01 19:15:49 UTC
Colin,

Please try ldap_group_name setting as suggested in comment #2. Does it work for you?
You might be correct that in some cases it might be more desirable to have this value set however it would be a change of the behaviour. We do not take backward compatibility lightly so we do not change default behaviour unless there is no way to solve the problem without it.

In this specific case I suggest that we for now:
a) Add a note into id_provider man page that if the user selects "ad" as a provider he might consider changing ldap_group_name attribute too.
b) We need to check authconfig/realmd how they configure SSSD in case of AD and may be have ldap_group_name set explicitly to the sAMAccountName.

Thanks
Dmitri

Comment 5 Sumit Bose 2014-02-03 08:32:07 UTC
The default attribute for the group name in the AD provider is 'name' which differs from sAMAccountName if the pre-2000 name is set explicitly.

While one might argue which name is the right one I see your point in the sense that we are inconsistent here with respect to the user name which takes sAMAccounName as a default. So if the pre-2000 name is set explicitly for a user and a group, the name is respected for the user but not for the group.

Given this I think we should consider to change the default in the next major release.

Additionally we might want to add different default values for different schema versions to the man page.

Comment 6 Colin.Simpson 2014-02-03 11:24:09 UTC
Setting, 

ldap_group_name = sAMAccountName
 
,does indeed cause cause sssd-ad to replicate the behaviour of other systems. 

I guess my other question is do MS have a document of the preferred attributes for RFC2307 style data from AD? I can't see one. Except, in the case, by observation of their own ID mapping used with the NFS server in Windows server.

Comment 7 Lukas Slebodnik 2015-02-27 13:26:02 UTC
(In reply to Colin Simpson from comment #6)
> Setting, 
> 
> ldap_group_name = sAMAccountName
>  
> ,does indeed cause cause sssd-ad to replicate the behaviour of other
> systems. 

Do you have any other issue?
Can we close this ticket?

Comment 8 Colin.Simpson 2015-02-27 18:39:40 UTC
Well I have a workaround but as per comment #5, "Given this I think we should consider to change the default in the next major release". I guess this ticket was tracking this, to change this default?

Comment 9 Lukas Slebodnik 2015-02-27 18:44:13 UTC
(In reply to Sumit Bose from comment #5)
> The default attribute for the group name in the AD provider is 'name' which
> differs from sAMAccountName if the pre-2000 name is set explicitly.
> 
> While one might argue which name is the right one I see your point in the
> sense that we are inconsistent here with respect to the user name which
> takes sAMAccounName as a default. So if the pre-2000 name is set explicitly
> for a user and a group, the name is respected for the user but not for the
> group.
> 
> Given this I think we should consider to change the default in the next
> major release.
> 
> Additionally we might want to add different default values for different
> schema versions to the man page.

Do we want to change default in sssd-1.12 or sssd-1.13?
or what do we want to do with this ticket?

Comment 10 Sumit Bose 2015-03-02 11:32:58 UTC
I still think it would be a good idea to switch to 'samAccountName' for 1.13. Besides consistency with the name for the user object I found the following in the MSFT docs for LDAP attributes:

samAccountName (https://msdn.microsoft.com/en-us/library/ms679635%28v=vs.85%29.aspx) is mandotory for 'user' and 'group' objectclasses via the 'Security-Principal' aux-class

name (https://msdn.microsoft.com/en-us/library/ms678697%28v=vs.85%29.aspx) is part of the 'top' class and _not_ mandatory for 'user' or 'group'.

Although I would expect that 'name' is always present because it is the generic rdn attribute it looks that 'samAccountName' would be the better choice.

If we want to change this, we should mention it at a prominent place because it might break setups which depend on the old behavior.

Comment 11 Lukas Slebodnik 2015-03-02 11:37:47 UTC
(In reply to Sumit Bose from comment #10)
> I still think it would be a good idea to switch to 'samAccountName' for
> 1.13. Besides consistency with the name for the user object I found the
> following in the MSFT docs for LDAP attributes:
> 
In this case, could you file an upstream ticket? So we will not forget.

After decision in upstream we can close this BZ or move to fedora 22.

Comment 12 Jakub Hrozek 2015-03-02 12:12:51 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2593

Comment 13 Jakub Hrozek 2015-04-17 11:37:39 UTC
Fixed upstream:
    master: adb148603344a42d6edffdda0786a10af715dacb

Comment 14 Fedora Update System 2015-05-08 13:33:12 UTC
sssd-1.12.4-6.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/sssd-1.12.4-6.fc22

Comment 15 Fedora Update System 2015-05-10 23:34:51 UTC
Package sssd-1.12.4-6.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.12.4-6.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7903/sssd-1.12.4-6.fc22
then log in and leave karma (feedback).

Comment 16 Fedora Update System 2015-05-11 19:01:38 UTC
sssd-1.12.4-6.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 richard.robson 2015-05-15 14:48:04 UTC
Just updated to Fedora22, and come across this change.  Is there an option to take it back to as before, you now can't have groupnames the same as usernames as AD doesn't allow duplicates.

Comment 18 Lukas Slebodnik 2015-05-15 14:55:37 UTC
(In reply to richard.robson from comment #17)
> Just updated to Fedora22, and come across this change.  Is there an option
> to take it back to as before, you now can't have groupnames the same as
> usernames as AD doesn't allow duplicates.

Sure; you can override default value.
Put "ldap_group_name = name" into domain section and restart sssd.

Could you provide minimal LDIF with problematic LDAP entries?
I would like to know where exactly is the problem.
because the patch for this BZ passed all AD related tests.

Comment 19 Sumit Bose 2015-05-15 15:00:27 UTC
Please set 'ldap_group_name = name' to get the old behavior.

Comment 20 Sumit Bose 2015-05-15 15:03:02 UTC
(In reply to Lukas Slebodnik from comment #18)
> (In reply to richard.robson from comment #17)
> > Just updated to Fedora22, and come across this change.  Is there an option
> > to take it back to as before, you now can't have groupnames the same as
> > usernames as AD doesn't allow duplicates.
> 
> Sure; you can override default value.
> Put "ldap_group_name = name" into domain section and restart sssd.
> 
> Could you provide minimal LDIF with problematic LDAP entries?
> I would like to know where exactly is the problem.
> because the patch for this BZ passed all AD related tests.

I guess the name was set explicitly to get around the uniqueness requirement AD has for samAccountName, i.e. by default there can be no user and group with the same name.

Comment 21 Lukas Slebodnik 2015-05-15 15:06:10 UTC
(In reply to Sumit Bose from comment #20)
> (In reply to Lukas Slebodnik from comment #18)
> > (In reply to richard.robson from comment #17)
> > > Just updated to Fedora22, and come across this change.  Is there an option
> > > to take it back to as before, you now can't have groupnames the same as
> > > usernames as AD doesn't allow duplicates.
> > 
> > Sure; you can override default value.
> > Put "ldap_group_name = name" into domain section and restart sssd.
> > 
> > Could you provide minimal LDIF with problematic LDAP entries?
> > I would like to know where exactly is the problem.
> > because the patch for this BZ passed all AD related tests.
> 
> I guess the name was set explicitly to get around the uniqueness requirement
> AD has for samAccountName, i.e. by default there can be no user and group
> with the same name.

ahh, 
I misread Richard's comment.

Comment 22 richard.robson 2015-05-15 15:14:25 UTC
Cheers, figured out the ldap_group_name = name just as you replied as well from a previous comment.  

The id_provider = ldap (with ldap_schema = rfc2307bis) setting also uses the name (or cn) attribute as well the service nslcd (tested to Fedora 21).  Older versions of Fedora (like 6) when configured for ldap against AD also use the name attribute.


Note You need to log in before you can comment on or make changes to this bug.