2

I have a machine setup to authenticate users with an LDAP directory using sssd+nss+pam.

At the current state any user in the directory is able to login by ssh, or with su in between user accounts, but it seems they are not able to retrieve their own uid and gid neither the ones from the rest of users.

Only root is able to resolve everything without issues, i guess this might come from a sssd.conf misconfiguration but i can't find out what could be causing this.

Behaviour observed as root:

[root@frontend ~]# ll /home/
total 0
drwx------. 2 chao    staff   83 Oct 25 22:57 chao
drwx------. 2 wshake  staff   99 Oct 26 12:45 wshake
[root@frontend ~]# id wshake
uid=10101(wshake) gid=10001(staff) groups=10001(staff)
[root@frontend ~]# id chao
uid=10103(chao) gid=10001(staff) groups=10001(staff)
[root@frontend ~]# getent passwd wshake
wshake:*:10101:10001:wshake:/home/wshake:/bin/bash

I can login with ssh or su as any of the users but they won't see their uid/gid names themselves with getent passwd myuid neither:

[root@frontend ~]# su - wshake
Last login: Fri Oct 26 14:08:23 CEST 2018 on pts/1
/usr/bin/id: cannot find name for user ID 10101
/usr/bin/id: cannot find name for group ID 10001
/usr/bin/id: cannot find name for user ID 10101
[I have no name!@frontend ~]$ id
uid=10101 gid=10001 groups=10001 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[I have no name!@frontend ~]$ id wshake
id: wshake: no such user
[I have no name!@frontend ~]$ getent passwd wshake
[I have no name!@frontend ~]$ su chao
Password:
/usr/bin/id: cannot find name for group ID 10001
/usr/bin/id: cannot find name for user ID 10103
[I have no name!@frontend wshake]$ id
uid=10103 gid=10001 groups=10001 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[I have no name!@frontend wshake]$ getent passwd chao
[I have no name!@frontend wshake]$

The /etc/sssd/sssd.config i'm using:

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

[domain/LDAP]
debug_level = 7
enumerate = True
cache_credentials = false
ldap_schema = rfc2307
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap

ldap_uri = ldaps://frontend
ldap_tls_reqcert = never
ldap_search_base = dc=test,dc=cluster
ldap_default_bind_dn = cn=Manager,dc=test,dc=cluster
ldap_default_authtok_type = password
ldap_default_authtok = testpass
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/openldap/certs/cert.crt

ldap_access_filter = (&(objectclass=posixAccount))
ldap_chpass_uri = ldaps://frontend

ldap_user_object_class = posixAccount
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_name = cn
ldap_group_object_class = posixGroup
ldap_group_gid_number = gidNumber

[nss]
debug_level = 7
override_homedir = /home/%u
override_shell = /bin/bash

Anybody has a hint of what to look at?

karamaz0v
  • 21
  • 1
  • 2
  • I suspect there's something wrong with permissions of the Unix domain socket used sssd listens on. – Michael Ströder Oct 27 '18 at 09:18
  • 1
    Finally found out the issue, it was indeed a permissions thing but with `/etc/nsswitch.conf`, it was set as `600`, changing to world readable `644` made everything work fine – karamaz0v Oct 28 '18 at 23:07
  • I'm having the same issue, but my `/etc/nsswitch.conf` is also world readable. How else might I debug this? – Ben Davis Nov 19 '19 at 19:45

0 Answers0