Bug 1060325
| Summary: | Does sssd-ad use the most suitable attribute for group name? | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Colin.Simpson | |
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 22 | CC: | abokovoy, Colin.Simpson, dpal, jhrozek, lslebodn, pbrezina, richard.robson, sbose, sgallagh, ssorce | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | sssd-1.12.4-6.fc22 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1199445 (view as bug list) | Environment: | ||
| Last Closed: | 2015-05-11 19:01:38 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1199445 | |||
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.
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 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. 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 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. 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. (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? 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? (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? 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. (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. Upstream ticket: https://fedorahosted.org/sssd/ticket/2593 Fixed upstream:
master: adb148603344a42d6edffdda0786a10af715dacb
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 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). 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. 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. (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. Please set 'ldap_group_name = name' to get the old behavior. (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. (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. 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. |
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