If you do

getent group <groupname>

Does it return the list of users including the one for which you were trying to call 'id' on?

description: have authentication working with sssd on rhel 6.1 but when i do an "id <username>" only the primary group of any given user is returned. after looking at the wiki, i tried adding ldap_schema = rfc2307bis to the sssd.conf with the same results. also tried adding ldap_group_name = uniqueMember with no luck. if i do a "getent group" all the groups are returned. any ideas?

sssd-client-1.5.1-34.el6_1.3.x86_64[[BR]]

sssd-1.5.1-34.el6_1.3.x86_64

[sssd.conf][[BR]]
auth_provider=ldap[[BR]]

ldap_is_use_start_tls=false[[BR]]

chpass_provider=ldap[[BR]]

cache_credentials=true[[BR]]

krb5_realm=EXAMPLE.com[[BR]]

ldap_search_base= dc=domain,dc=com[[BR]]

debug_level=10[[BR]]

id_provider=ldap[[BR]]

ldap_uri=ldaps://server.domain.com[[BR]]

krb5_kdcip=kerberos.example.com[[BR]]

ldap_tls_cacertdir=/etc/openldap/cacerts[[BR]]

ldap_schema=rfc2307bis
enumerate=true => have authentication working with sssd on rhel 6.1 but when i do an "id <username>" only the primary group of any given user is returned. after looking at the wiki, i tried adding ldap_schema = rfc2307bis to the sssd.conf with the same results. also tried adding ldap_group_name = uniqueMember with no luck. if i do a "getent group" all the groups are returned. any ideas?

• sssd-client-1.5.1-34.el6_1.3.x86_64
• sssd-1.5.1-34.el6_1.3.x86_64

{{{[sssd.conf]}}}
{{{
auth_provider=ldap
ldap_is_use_start_tls=false
chpass_provider=ldap
cache_credentials=true
krb5_realm=EXAMPLE.com
ldap_search_base= dc=domain,dc=com
debug_level=10
id_provider=ldap
ldap_uri=ldaps://server.domain.com
krb5_kdcip=kerberos.example.com
ldap_tls_cacertdir=/etc/openldap/cacerts
ldap_schema=rfc2307bis
enumerate=true
}}}

no, it only returns the group name and id. for example, getent group sradm returns:

sradm:*:1000:

Could you add

debug_level = 6

To your sssd.conf file in the {{{[domain/<DOMAINNAME>]}}} section, restart SSSD and then run

getent group sradm

Then please attach {{{/var/log/sssd/sssd_<DOMAINNAME>.log}}} to this ticket (sanitized if necessary).

attachment
sanitized_sssd_log.txt

Log file attached.

Can you also paste a sanitized search result of one of the groups that actually contains users in your directory? A filter like (&(objectclass=posixGroup)(cn=group_name)) should yield the result..

Could you give me the exact command?

Replying to [comment:5 jhrozek]:

Can you also paste a sanitized search result of one of the groups that actually contains users in your directory? A filter like (&(objectclass=posixGroup)(cn=group_name)) should yield the result..

Replying to [comment:6 theonlyjason]:

Could you give me the exact command?

Replying to [comment:5 jhrozek]:

Can you also paste a sanitized search result of one of the groups that actually contains users in your directory? A filter like (&(objectclass=posixGroup)(cn=group_name)) should yield the result..

Sure, according to you sanitized logs and config, the command should look something like this:

ldapsearch -x -H ldap://server1.domain.com -b "dc=domain,dc=com" "(&(objectclass=posixGroup)(cn=sradm)(gidNumber=*))"

I'm specifically looking for a group entry that contains members, so please substitute "sradm" in the above filter for a name of a group that has members.

Thank you for the help with debugging this issue.

Replying to [comment:7 jhrozek]:

Replying to [comment:6 theonlyjason]:

Could you give me the exact command?

Replying to [comment:5 jhrozek]:

Can you also paste a sanitized search result of one of the groups that actually contains users in your directory? A filter like (&(objectclass=posixGroup)(cn=group_name)) should yield the result..

Sure, according to you sanitized logs and config, the command should look something like this:
{{{
ldapsearch -x -H ldap://server1.domain.com -b "dc=domain,dc=com" "(&(objectclass=posixGroup)(cn=sradm)(gidNumber=*))"
}}}

I'm specifically looking for a group entry that contains members, so please substitute "sradm" in the above filter for a name of a group that has members.

Thank you for the help with debugging this issue.

The group sradm actually does contain users. Here's the search result:

#extended LDIF
#
#LDAPv3
#base <dc=domain,dc=com> with scope subtree
#filter:  (&(objectclass=posixGroup)(cn=sradm)(gidNumber=*))
#requesting:  ALL
#

#sradm, People, domain.com
dn:  CN=sradm,ou=People,dc=domain,dc=com
cn:  sradm
ntUniqueId:  12935b3c4267...
objectClass:  posixGroup
objectClass:  top
objectClass:  groupofuniquenames
objectClass:  ntgroup
ntUserDomainId:  sradm
gidNumber:  1000
uniqueMember:  uid=user1,ou=People,dc=domain,dc=com
uniqueMember:  uid=user2,ou=People,dc=domain,dc=com
uniqueMember:  uid=user3,ou=People,dc=domain,dc=com
uniqueMember:  uid=user4,ou=People,dc=domain,dc=com
uniqueMember:  uid=user5,ou=People,dc=domain,dc=com
uniqueMember:  uid=user6,ou=People,dc=domain,dc=com
uniqueMember:  uid=user7,ou=People,dc=domain,dc=com
uniqueMember:  uid=user8,ou=People,dc=domain,dc=com

#search result
search:  2
result:  0 success

#numResponses:  2
#numEntries:  1

Ok, judging by that output, you DO need to make sure that your sssd.conf contains the following two lines:

ldap_schema = rfc2307bis
ldap_group_member = uniqueMember

It was unclear above if you tried both together. The log you sent us has only the schema change, which would correctly report "no members" because there were no attributes of type 'member', only 'uniqueMember', which it wasn't looking for.

Also, you need to do

rm -f /var/lib/sss/db/cache_default.ldb

and restart SSSD after making this change. Leftovers in the cache from the wrong config may be causing other issues.

Ok, after adding

ldap_schema = rfc2307bis
ldap_group_member = uniqueMember

to the sssd.conf, all group memberships are being returned correctly. Before, I was adding

ldap_group_name = uniqueMember

because that's what was suggested on the FAQ page of the Wiki. I'm guessing that was a typo and should be corrected.

Thanks so much for your help with resolving the issue. Is there good documentation or does anyone have any insight on how to get sudo working with sssd? I've added

sudoers:  sss

to /etc/nsswitch.conf and tried adding sudo to the services option of sssd.conf but sssd fails to startup with this option. Is it possible that I need to use a more recent version? Thanks again!

Replying to [comment:10 theonlyjason]:

Ok, after adding

{{{
ldap_schema = rfc2307bis
ldap_group_member = uniqueMember
}}}

to the sssd.conf, all group memberships are being returned correctly. Before, I was adding
{{{
ldap_group_name = uniqueMember
}}}
because that's what was suggested on the FAQ page of the Wiki. I'm guessing that was a typo and should be corrected.

Oh, right, that's definitely a typo. Thank you for catching that.

Thanks so much for your help with resolving the issue. Is there good documentation or does anyone have any insight on how to get sudo working with sssd?

I wrote a short blog post about the sudo/sssd integration:
http://jhrozek.livejournal.com/2065.html

I've added
{{{
sudoers: sss
}}}
to /etc/nsswitch.conf and tried adding sudo to the services option of sssd.conf but sssd fails to startup with this option. Is it possible that I need to use a more recent version? Thanks again!

Unfortunately, the sudo integration requires a patched sudo version that is only available in Fedora 17 right now. In theory, you could rebuild the Fedora source RPM sudo yourself, but obviously that would void any warranty :-)

This turned out to be a configuration issue and a bug in our documentation which is now closed.

Closing the ticket as worksforme.

resolution: => worksforme
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2322

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.