Bug 683267 - sssd 1.5.1-9 breaks AD authentication
sssd 1.5.1-9 breaks AD authentication
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
14
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 683860 688697
  Show dependency treegraph
 
Reported: 2011-03-08 18:05 EST by Bojan Smojver
Modified: 2011-03-28 15:28 EDT (History)
6 users (show)

See Also:
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 15:28:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Requested sssd logs, with debug level set to 9 (10.59 KB, application/x-bzip2)
2011-03-08 18:05 EST, Bojan Smojver
no flags Details
Logs of successful authentication with 1.5.1-3 (8.60 KB, application/x-bzip2)
2011-03-10 18:26 EST, Bojan Smojver
no flags Details

  None (edit)
Description Bojan Smojver 2011-03-08 18:05:08 EST
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.
Comment 1 Stephen Gallagher 2011-03-09 12:12:41 EST
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.)
Comment 2 Sumit Bose 2011-03-09 15:32:02 EST
Can you also attach the log files of a successful authentication with 1.5.1-3 ?
Comment 3 Bojan Smojver 2011-03-10 08:03:05 EST
Sorry about the delay. Work stuff. Will try getting this to you tomorrow.
Comment 4 Stephen Gallagher 2011-03-10 08:05:26 EST
Re-setting the NeedInfo flag
Comment 5 Stephen Gallagher 2011-03-10 08:35:46 EST
Also, can you let us know which Active Directory server it is? 2003R2 or 2008?
Comment 6 Bojan Smojver 2011-03-10 17:51:56 EST
(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.
Comment 7 Bojan Smojver 2011-03-10 17:57:31 EST
(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.
Comment 8 Bojan Smojver 2011-03-10 18:26:03 EST
Created attachment 483601 [details]
Logs of successful authentication with 1.5.1-3
Comment 9 Sumit Bose 2011-03-11 08:29:07 EST
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.
Comment 10 Bojan Smojver 2011-03-11 09:31:58 EST
(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.
Comment 11 Bojan Smojver 2011-03-11 18:21:06 EST
(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.
Comment 12 Sumit Bose 2011-03-12 03:55:53 EST
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.
Comment 13 Bojan Smojver 2011-03-12 05:27:45 EST
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 :-(
Comment 14 Bojan Smojver 2011-03-12 05:48:22 EST
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.
Comment 15 Sumit Bose 2011-03-12 07:09:57 EST
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.
Comment 16 Bojan Smojver 2011-03-12 07:19:24 EST
Right, I'll try that.
Comment 17 Bojan Smojver 2011-03-12 08:36:03 EST
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?
Comment 18 Sumit Bose 2011-03-12 09:44:28 EST
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.
Comment 19 Bojan Smojver 2011-03-12 16:11:56 EST
(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.
Comment 20 Bojan Smojver 2011-03-12 16:21:02 EST
(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.
Comment 21 Sumit Bose 2011-03-12 17:36:21 EST
(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.
Comment 22 Bojan Smojver 2011-03-12 18:12:46 EST
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.
Comment 23 Bojan Smojver 2011-03-12 18:51:59 EST
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.
Comment 24 Sumit Bose 2011-03-13 13:35:04 EDT
Ok, I think we are on the same page now. I'll discuss with the other sssd developers how to handle this use case.
Comment 25 Simo Sorce 2011-03-13 14:38:38 EDT
(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.
Comment 26 Bojan Smojver 2011-03-13 15:23:56 EDT
(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).
Comment 27 Bojan Smojver 2011-03-13 15:26:42 EDT
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.
Comment 28 Bojan Smojver 2011-03-13 18:26:15 EDT
(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.
Comment 29 Fedora Update System 2011-03-17 13:12:09 EDT
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
Comment 30 Fedora Update System 2011-03-24 15:47:09 EDT
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
Comment 31 Fedora Update System 2011-03-28 15:28:12 EDT
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.

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