SSSD / sssd

#3445 only primary group fetched
Closed: Invalid Opened by yodamoppet.

Closed: Invalid
Reopen Issue

Authentication and primary group working fine. When I do "id [username]" only the primary group of user is fetched.

This led me to issue #1280 "only primary group returned". His solution was to add "ldap_schema = rfc2307bis" and "ldap_group_member = uniqueMember", however I already have those in my sssd.conf.

I should add that this was/is working fine with pam authentication, but I'm trying to migrate everything over to sssd.

[sssd]
config_file_version = 2
services = nss, pam
domains = default

[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd

[pam]

[domain/default]
ldap_tls_reqcert = never
auth_provider = ldap
ldap_schema = rfc2307bis
krb5_realm = redacted
ldap_search_base = redacted
ldap_group_member = uniqueMember
id_provider = ldap
ldap_id_use_start_tls = False
chpass_provider = ldap
ldap_uri = redacted
ldap_chpass_uri = redacted
krb5_kdcip = redacted
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_access_filter = (&(object)(object))

Can you send an example how an LDAP group object looks like on your LDAP server. This would help to find out which options are needed. When editing the output please make sure that it is still clear if the group member are given by name or by LDAP DN.

Metadata Update from @sbose:
- Custom field cc adjusted to sbose

Sure. Could you provide the command to do this from the client side?

 
ldapsearch -x -H ldap_uri -b ldap_search_base cn=group_name

where you replace ldap_uri adn ldap_search_base with your setting from sssd.conf

Here is the result after subbing in my ldap_uri, ldap_search_base, and one of our group names. I have subbed in server and group names in this output to anonymize.

I believe the apple tags are because my organization uses an apple openldap server for authentication. However, this has never been a problem in the past using pam to authenticate our linux boxes against it.

extended LDIF

LDAPv3

base with scope subtree

filter: cn=lab

requesting: ALL

lab, groups, server1.server.example.com

dn: cn=lab,cn=groups,dc=server1,dc=server,dc=example,dc=com
memberUid: user1
memberUid: user2
memberUid: user3
memberUid: user4
memberUid: user5
memberUid: user6
memberUid: user7
apple-group-memberguid: A4B6ECA5-1FD6-4974-8DBA-3F38460D8E6E
apple-group-memberguid: A2FED9A5-090C-4B4A-8B53-10619DAC06E4
apple-group-memberguid: 37D4132B-1D68-425E-AA57-692A652E9C6C
apple-group-memberguid: 7F7E3B9C-ABB2-409F-BD9E-8714925D4B15
apple-group-memberguid: 84F5E1AC-149F-46C8-A867-20D0CC34DA78
apple-group-memberguid: 4F232FC0-67A4-4BFC-879D-6A678F3835F7
apple-group-memberguid: CEA23835-85BF-4B61-8E9A-950CC7615A03
cn: lab
apple-generateduid: 8F69FD57-6F8E-43A7-B294-B61D7D958598
apple-group-realname: lab
objectClass: top
objectClass: posixGroup
objectClass: extensibleObject
objectClass: apple-group
gidNumber: 5030

search result

search: 2
result: 0 Success

numResponses: 2

numEntries: 1
Edited by yodamoppet

Thank you for the data.

'memberUid: user7' means that you have a RFC2307 based schema where the group members are referenced by their name. With RFC2307bis you would see a DN in the member attribute like e.g. 'member: uid=user7,cn=groups,dc=server1,dc=server,dc=example,dc=com'.

So please do not use 'ldap_schema = rfc2307bis' but 'ldap_schema = rfc2307', remove the 'ldap_group_member = uniqueMember' and try again.

Thank you for the information -- it seems that you have solved this!

Yes, this works by changing "ldap_schema = rfc2307bis" to "ldap_schema = rfc2307" and removing "ldap_group_member = uniqueMember". Is there a reference that outlines the schema formats that I could have used to determine this?

In the interest of completeness and for anyone else experiencing a similar issue, I also had to clear the sssd cache (rm -f /var/lib/sss/db/cache_default.ldb ) and restart sssd after each configuration change.

Well, you should know in advance with schema is used by your LDAP server. As to where they are defined, check corresponding RFCs: RFC 2307 and RFC 2307bis.

Since the ticket was solved with a configuration change, I'm going to close it.

Metadata Update from @jhrozek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

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/4472

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.
Metadata
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.