Bug 1199445 - 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: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.2
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On: 1060325
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-06 10:26 UTC by Jakub Hrozek
Modified: 2020-05-04 10:46 UTC (History)
16 users (show)

Fixed In Version: sssd-1.13.0-0.1.alpha.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1060325
Environment:
Last Closed: 2015-11-19 11:36:02 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github SSSD sssd issues 3634 None None None 2020-05-04 10:46:07 UTC
Red Hat Product Errata RHSA-2015:2355 normal SHIPPED_LIVE Low: sssd security, bug fix, and enhancement update 2015-11-19 10:27:42 UTC

Description Jakub Hrozek 2015-03-06 10:26:33 UTC
+++ This bug was initially created as a clone of 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

--- Additional comment from Lukas Slebodnik on 2014-01-31 15:48:42 EST ---

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.

--- Additional comment from Jakub Hrozek on 2014-01-31 17:50:29 EST ---

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

--- Additional comment from Colin Simpson on 2014-01-31 18:54:28 EST ---

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.

--- Additional comment from Dmitri Pal on 2014-02-01 14:15:49 EST ---

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

--- Additional comment from Sumit Bose on 2014-02-03 03:32:07 EST ---

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.

--- Additional comment from Colin Simpson on 2014-02-03 06:24:09 EST ---

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.

--- Additional comment from Lukas Slebodnik on 2015-02-27 08:26:02 EST ---

(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?

--- Additional comment from Colin Simpson on 2015-02-27 13:39:40 EST ---

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?

--- Additional comment from Lukas Slebodnik on 2015-02-27 13:44:13 EST ---

(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?

--- Additional comment from Sumit Bose on 2015-03-02 06:32:58 EST ---

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.

--- Additional comment from Lukas Slebodnik on 2015-03-02 06:37:47 EST ---

(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.

--- Additional comment from Jakub Hrozek on 2015-03-02 07:12:51 EST ---

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2593

Comment 2 Martin Kosek 2015-04-24 11:35:59 UTC
Fixed upstream:

master: adb148603344a42d6edffdda0786a10af715dacb

Comment 4 Nirupama Karandikar 2015-10-13 09:25:17 UTC
Tested with sssd-1.13.0-39.el7.x86_64

1. Install older version sssd-1.12.2-58.el7.x86_64.

2. Setup sssd.conf as follows, set "ldap_id_mapping = False"

ad_domain = rootdc.com
krb5_realm = ROOTDC.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

in sssd.conf

3. Create adgrp1 group in AD as shown below :

# ldapsearch -x -D "cn=administrator,cn=Users,dc=rootdc,dc=com" -w Secret123 -b "dc=rootdc,dc=com" -h 10.65.207.10 cn="adgrp Test" sAMAccountName
# extended LDIF
#
# LDAPv3
# base <dc=rootdc,dc=com> with scope subtree
# filter: cn=adgrp Test
# requesting: sAMAccountName 
#

# adgrp Test, Builtin, rootdc.com
dn: CN=adgrp Test,CN=Builtin,DC=rootdc,DC=com
sAMAccountName: adgrpTest

4. Check for group lookup. Group lookup is not working as expected.

# getent group "adgrp test"@rootdc.com
adgrp test@rootdc.com:*:1294601115:aduser1@rootdc.com

# getent group adgrpTest@rootdc.com - do not work.

5. Update sssd to sssd-1.13.0-39.el7.x86_64

Re-check for the group lookup.

# getent group adgrpTest@rootdc.com
adgrptest@rootdc.com:*:1294601115:aduser1@rootdc.com

# getent group "adgrp test"@rootdc.com - do not work as expected.

Comment 5 errata-xmlrpc 2015-11-19 11:36:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2355.html


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