Open BlackLotus opened 2 months ago
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.
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 inou=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