Resolving groups with memberOf only
BlackLotus opened this issue · 8 comments
I couldn't find a fitting issue or documentation. Hope I'm not overlooking something basic.
Problem is when I do
getent group foo
sssd tries to search for cn=foo in ou=users,....
Our ldap doesn't supply the information this way, but using memberOf.
ldap_user_member_of is set correctly, but I don't know how to force sssd to use this as the base for group mapping.
In theory we can find a group foo through a search in ou=user,dc=... memberOf=foo,ou=groups,...
If we want to list the groups of a user we can do a search in ou=users,... looking for 'uid=foobar' + (using ldapsearch)
Is there a way to configure sssd to work like this as well? Again sorry if this is an obvious problem
Hi,
can you share your current /etc/sssd/sssd.conf?
bye,
Sumit
[sssd]
config_file_version = 2
services = nss, pam
domains = default
#debug_level = 8
[domain/default]
cache_credentials = false
debug_level = 7
enumerate = false
#ldap_id_mapping = true
id_provider = ldap
auth_provider = ldap
#chpass_provider = ldap
ldap_uri = ldaps://openldap.example.com
ldap_search_base = ou=users,dc=example,dc=com
ldap_default_bind_dn = cn=binduser,ou=security,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = pw
ldap_user_member_of = memberOf
ldap_group_member = uniqueMember
override_shell = /bin/bash
Replaced my domain.
Hi,
you have ldap_search_base = ou=users,dc=example,dc=com which means all searches will use ou=users,dc=example,dc=com as a base. But your group objects are in ou=groups,... according to your memberOf attribute.
So, either you change ldap_search_base
ldap_search_base = dc=example,dc=com
or you have to add
ldap_group_search_base = ou=groups,dc=example,dc=com
I would recommend the first.
Additionally, since uniqueMember is typically using a DN syntax I assume you have to set
ldap_scheme = rfc2307bis
HTH
bye,
Sumit
The groups itself are not searchable. Only the memberOf attribute is shown.
So I tried every of the combination above (even before opening the ticket). Good to know that the problem seems to lie in the configuration of our ldap server and not me...
So I guess I can't configure sssd to search ou=users for memberOf to do the lookup right?
Hi,
one of the reasons you have to read the group object is to get the GID of the group.
bye,
Sumit
Oh... our ldap is... special. AFAIK we don't have GIDs in our ldap...
I asked for permissions to search for groups and this is what it looks like
[root@login001 ~]# ldapsearch -D "cn=binduser,ou=security,dc=example,dc=com" -y "/root/ldapsearch/password.txt" -H "ldaps://openldap.example.com:636" -b "ou=groups,dc=example,dc=com" -W "cn=somegroup"
# extended LDIF
#
# LDAPv3
# base <ou=groups,dc=example,dc=de> with scope subtree
# filter: cn=somegroup
# requesting: ALL
#
# somegroup, groups, example.com
dn: cn=somegroup,ou=groups,dc=example,dc=com
member: uid=nobody
member: uid=blacklotus,ou=users,dc=example,dc=com
objectClass: groupOfNames
objectClass: exampleAccessControl
cn: somegroup
rubReadAllow: cn=binduser,ou=security,dc=example,dc=com
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Edit: working on a solution to add the GIDs to the ldap
Hi,
do your LDAP user's have a uidNumber attribute or similar? Does getent passwd username show a user entry or does it fail as well?
bye,
Sumit
Sorry for the delayed answer - thought I already answered you
getent passwd username works of course. The main problem right now seems to be that our ldap is missing GIDs.