Bug 683267
Summary: | sssd 1.5.1-9 breaks AD authentication | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bojan Smojver <bojan> | ||||||
Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 14 | CC: | grajaiya, jhrozek, kbanerje, sbose, sgallagh, ssorce | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | sssd-1.5.4-1.fc14 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 683860 (view as bug list) | Environment: | |||||||
Last Closed: | 2011-03-28 19:28:17 UTC | Type: | --- | ||||||
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: | 683860, 688697 | ||||||||
Attachments: |
|
Can you try running the following command from your Linux client and tell me what you get? ldapsearch -x -W -D -H ldap://DC=srvr501.some.domainname.org \ cn=XXXXXXXX,ou="XXXXXXXXXXXXXXX",ou=XXXXXXXXXXXXXX,dc=some,dc=domainname,dc=org \ -b dc=some,dc=domainname,dc=org '(&(member=CN=Smojver\5c, Bojan,OU=XXXXXXXX,OU=XXXXXX,DC=some,DC=domainname,DC=org)(objectclass=group))' I want to see if this lookup is succeeding (obviously substitute the correct values for the OUs etc.) Can you also attach the log files of a successful authentication with 1.5.1-3 ? Sorry about the delay. Work stuff. Will try getting this to you tomorrow. Re-setting the NeedInfo flag Also, can you let us know which Active Directory server it is? 2003R2 or 2008? (In reply to comment #1) > Can you try running the following command from your Linux client and tell me > what you get? > > ldapsearch -x -W -D -H ldap://DC=srvr501.some.domainname.org \ > cn=XXXXXXXX,ou="XXXXXXXXXXXXXXX",ou=XXXXXXXXXXXXXX,dc=some,dc=domainname,dc=org > \ > -b dc=some,dc=domainname,dc=org > '(&(member=CN=Smojver\5c, > Bojan,OU=XXXXXXXX,OU=XXXXXX,DC=some,DC=domainname,DC=org)(objectclass=group))' > > I want to see if this lookup is succeeding (obviously substitute the correct > values for the OUs etc.) This won't work because the URL contains DC= (i.e. I get "ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)" with that in, obviously). Another problem with the query is that -D has to go just before the bind DN, of course. If I remove the DC= part from the URL, put the bind DN after -D, I get no results. Now, I copied the search filter from the bug report, so that is a problem in itself, because there is a newline after that backslash comma thing. It needs to be like this in order to work: '(&(member=CN=Smojver\5c, Bojan,OU= [..snip..]' So, _only_ if I actually ask like the above, I get a list of groups I belong to. Now, this is a _very_ large list. If I add -LLL to the query and pass it to wc -l, I get 18271 lines. Hope this answers your question. (In reply to comment #5) > Also, can you let us know which Active Directory server it is? 2003R2 or 2008? All of the ADs are 2003R2. Created attachment 483601 [details]
Logs of successful authentication with 1.5.1-3
Is there any chance that the user belongs to a group where the attribute 'msSFU30Name', which is used as the unix group name, is not set or empty ? After comparing both sets of logs I think both are showing a wrong behavior in sssd_default.log which might be caused by a missing 'msSFU30Name'. The reason that it worked in -3 is a bug that masked this error which is fix in -9. (In reply to comment #9) > Is there any chance that the user belongs to a group where the attribute > 'msSFU30Name', which is used as the unix group name, is not set or empty ? > > After comparing both sets of logs I think both are showing a wrong behavior in > sssd_default.log which might be caused by a missing 'msSFU30Name'. The reason > that it worked in -3 is a bug that masked this error which is fix in -9. I'll check and let you know. (In reply to comment #9) > Is there any chance that the user belongs to a group where the attribute > 'msSFU30Name', which is used as the unix group name, is not set or empty ? > > After comparing both sets of logs I think both are showing a wrong behavior in > sssd_default.log which might be caused by a missing 'msSFU30Name'. The reason > that it worked in -3 is a bug that masked this error which is fix in -9. The result of the above ldapsearch query does not contain "msSFU30Name" string. Ok, then please try to use a different attribute for the name of the group. Typical candidates are 'cn', 'name' or 'sAMAccountName'. Please check if one of these attributes can be found in your ldapsearch output. Please note that the attribute must only have a single value to be suitable for a group name. If you have decided which attribute to use please change 'ldap_group_name = msSFU30Name' to e.g. 'ldap_group_name = cn' in /etc/sssd/sssd.conf. Additionally please check if every group has the attribute 'msSFU30GidNumber' set. If not please use AD's user and group manager to set it to a numerical value. OK, will try that. Thank you for the pointers. To be honest, I just assumed our AD admins set things up in line with what regular examples show and that kinda worked, including before I switched to sssd. Obviously, these assumptions were not correct - my bad :-( One other detail, if it matters. The above ldap query doesn't yield anything for msSFU30Name. However, a query that asks for "msSFU30Name=bsmojver" does return stuff, among other things this: msSFU30UidNumber: <myrealuid> msSFU30GidNumber: <myrealgid> msSFU30LoginShell: /bin/bash msSFU30NisDomain: <myrealdomain> msSFU30HomeDirectory: /home/bsmojver msSFU30Name: bsmojver Query was: ldapsearch -h srvr501 -x -D '<theDN>' -W -b dc=some,dc=domainname,dc=org "msSFU30Name=bsmojver" Hmm, so these things _do_ exist, it's just that the query with '(&(member=CN=Smojver\5c, Bojan,OU= [..snip..]' doesn't yield desired stuff, I guess. The query with "msSFU30Name=bsmojver" returns your user object and here all needed attributes are available and msSFU30Name holds your user name. The query with "member=CN=Smojver\5c, Bojan" returns the groups you are a member of and here msSFU30Name, which should contains the name of the group, is empty so you must use a different attribute from the returned object as a group name. Right, I'll try that. Time for a silly question: Given that the user query returns my primary group gid, why is subsequent query for other group membeship considered fatal? What if a user really doesn't have any other groups? First you only know the gid and not the name of the primary group. Second, group memberships are important, e.g. they can allow or even more important deny access (although I think it makes more sense to only have groups that allow a specific access). I the case of sssd there is a access provider which can allow or deny access to the system, so it is important to know all about your group memberships. (In reply to comment #18) > First you only know the gid and not the name of the primary group. You won't find the name of the primary group using the '(&(member=CN=Smojver\5c, Bojan,OU= [..snip..]' query anyway. Grep of the result does not list the primary group I belong to at all. > Second, > group memberships are important, e.g. they can allow or even more important > deny access (although I think it makes more sense to only have groups that > allow a specific access). Hmm, never heard of access being denied using explicit group membership. It would kinda mean that everyone has access unless they are a member of some group. Seems like a strange way to do security. > I the case of sssd there is a access provider which can allow or deny access to > the system, so it is important to know all about your group memberships. Well, I can tell you that we have a lot of systems out there that don't run sssd (RHEL4/5), but instead use pam_krb5/nss_ldap to do all this and they recognise only the primary group and work just fine (i.e. when I run id on these machine, I get: "uid=<myrealid>(bsmojver) gid=<myrealgid>(<myprimarygroup>) groups=<myrealgid>(<myprimarygroup>)"). If what you are saying were true, then all of these systems need to be fixed, because they allow users to log in when they should not be able to (supplementary groups not found). I am a bit sceptical of that interpretation though. (In reply to comment #19) > I am a bit sceptical of that interpretation > though. Not to mention the fact that on any of the systems one can get supplementary group membership from locally defined groups too. In fact, on this particular system, which is my workstation, I belong a local wheel group (obviously) in addition to belonging to the primary group assigned to me by AD. (In reply to comment #19) > > Well, I can tell you that we have a lot of systems out there that don't run > sssd (RHEL4/5), but instead use pam_krb5/nss_ldap to do all this and they > recognise only the primary group and work just fine (i.e. when I run id on > these machine, I get: "uid=<myrealid>(bsmojver) > gid=<myrealgid>(<myprimarygroup>) groups=<myrealgid>(<myprimarygroup>)"). > > If what you are saying were true, then all of these systems need to be fixed, > because they allow users to log in when they should not be able to > (supplementary groups not found). I am a bit sceptical of that interpretation > though. Now I see your point. You explicitly do not want to have supplementary groups on the Linux client although the corresponding user in AD belongs to various other groups. I'm not sure if this is currently possible with sssd. I have to think about it. What I'm trying to point out is that in this particular AD setup (which was not done by me, I just have to use it): - supplementary groups don't exist - users were always able to log in without them More generally, I do not see why supplementary groups should be mandatory in any environment. If you get an empty set, that should be fine. Actually, in my environment, the argument may be a bit more subtle still. Just because I belong to a bunch of groups that are used in a Windows environment, doesn't mean they have any meaning in a Unix environment. These groups have not been "tagged" with attributes required for them to be Unix groups, so they should be simply ignored. Ergo, my supplementary Unix group membership is an empty set. I would not be surprised if other users actually did belong to some supplementary Unix groups. It's just that I don't. Ok, I think we are on the same page now. I'll discuss with the other sssd developers how to handle this use case. (In reply to comment #23) > Actually, in my environment, the argument may be a bit more subtle still. > > Just because I belong to a bunch of groups that are used in a Windows > environment, doesn't mean they have any meaning in a Unix environment. These > groups have not been "tagged" with attributes required for them to be Unix > groups, so they should be simply ignored. Ergo, my supplementary Unix group > membership is an empty set. > > I would not be surprised if other users actually did belong to some > supplementary Unix groups. It's just that I don't. I think we should support this situation with regard to supplementary groups. But I am a bit skeptical about the primary group, as that is a mandatory attribute for posix. I think we may add an option to allow a user to login if only the primary gid value is known but a group cannot be found. I wouldn't allow that by default though, sounds like a broken setup. (In reply to comment #25) > But I am a bit skeptical about the primary group, as that is a mandatory > attribute for posix. I think we may add an option to allow a user to login if > only the primary gid value is known but a group cannot be found. I wouldn't > allow that by default though, sounds like a broken setup. I am not sure which ldap query delivers the name of my primary group, but it is clearly there with 1.5.1-3. I can strace sssd and check, but I' pretty sure you guys already know from the source. So, primary group name is not missing in AD. It is just that the query in question doesn't deliver it (or any other group). One more detail: name of my primary group is not the same as the name of my user account, so it's not just copied from that somewhere. (In reply to comment #26) > I am not sure which ldap query delivers the name of my primary group This does: ldapsearch -h srvr501 -x -D '<theDN>' -W -b dc=some,dc=domainname,dc=org "msSFU30Name=<myprimarygroupname>" I can see whole bunch of "member: CN=<somebody>" stuff in the result, but not me. These are folks have this group as their supplementary group. Hope this helps. sssd-1.5.3-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/sssd-1.5.3-2.fc14 sssd-1.5.4-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/sssd-1.5.4-1.fc14 sssd-1.5.4-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 483062 [details] Requested sssd logs, with debug level set to 9 Description of problem: On upgrade to 1.5.1-9, AD authentication stops working. Reverting to 1.5.1-3 fixes the issue, using identical configuration files. Version-Release number of selected component (if applicable): 1.5.1-9 How reproducible: Always. Steps to Reproduce: 1. Upgrade sssd and sssd-client to 1.5.1-9 2. Attempt to login using one of the AD accounts. Actual results: Authentication fails. Expected results: Works with 1.5.1-3. Additional info: See attached logs.