4

I have been able to setup 389 LDAP server and SSSD client authentication. However, whenever I login using ldap user after each login it displays the error 

ttt@dsl's password: 
Last login: Thu Dec  6 12:52:06 2012
id: cannot find name for group ID 6006

I tried with multiple different users and multiple types. I am using Centos 6 on both server and client side. getent shadow does not return ldap users and this feature request have been denied by Redhat.https://bugzilla.redhat.com/show_bug.cgi?id=751291.

Or shall I switch back to nss_ldap/pam_ldap, but I may not get password caching that sssd provides.

Update:

root@dsl etc]# cat /etc/sssd/sssd.conf 
[domain/default]
ldap_tls_reqcert = never
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = dc=ma,dc=net
#krb5_realm = EXAMPLE.COM
#krb5_server = kerberos.example.com
ldap_group_member = uniquemember
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://ldap.ma.net
ldap_tls_cacertdir = /etc/openldap/cacerts
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
enumerate = false
[sssd]
services = nss, pam
config_file_version = 2

#domains = LDAP
domains = 
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
[sudo]

[autofs]

[ssh]

[root@dsl etc]#

After login as user I can successfully execute id command, still wondering why it always says no such group.

[root@ldap02 ~]# ssh ttt@dsl
ttt@dsl's password: 
Last login: Thu Dec  6 13:18:16 2012 from 10.2.3.69
id: cannot find name for group ID 6006
[ttt@dsl ~]$ id ttt
uid=6006(ttt) gid=6006 groups=6006

Also

[root@dsl ~]# groups ttt
ttt : groups: cannot find name for group ID 6006
6006
[root@dsl ~]# groups ttt
chandank
  • 857
  • 4
  • 15
  • 31

2 Answers2

3

Finally I was able to resolve it. This article helped me a lot.

Here is what I did. On SSSD side everything was configured fine, however, I did not configure the LDAP side. In order to Unix users (posix users) to work properly, we have to create posix groups and assign appropriate values.

For for each user, apart from assigning posix group ID and User ID, you need to attach them to a posix group as well. You can add this from 389 admin console as well. While creating group just click on the "posix group" section. Or from command prompt use this article

Abhijeet Kasurde
  • 1,009
chandank
  • 857
  • 4
  • 15
  • 31
0

My case had the same symptons, but the cause was more convoluted. I followed this guide, that suggest configuiring LDAP access controls To make sure that no-one can read the (encrypted) passwords from the LDAP server, but still allowing users to edit some of their own select attributes (such as own password and photo), by importing the following LDIF:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=cn,givenName,sn,userPassword,shadowLastChange,mail,loginShell,photo by self write by anonymous auth by dn.base="cn=Manager,dc=example,dc=org" write by * none
olcAccess: {1}to * by self read by dn.base="cn=Manager,dc=example,dc=org" write by * read

When sssd search the group ID in LDAP, it makes an anonymous search request using the following filter (extracted from sssd logs, v. 1.16.5):

(&(memberuid=test)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))

This search request needs read acces to cn attribute, but the anonymous only have auth access, so the search fails and sssd cannot know the group ID. The same happens with the loginShell attribute in a different search request, so the logged LDAP users have the defalult shell (that happens to be csh instead of bash). The fix was set read acces (instead of auth) to cn and loginShell attributes in the LDAP database (just remove them from the first attrs line):

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=givenName,sn,userPassword,shadowLastChange,mail,photo by self write by anonymous auth by dn.base="cn=Manager,dc=example,dc=org" write by * none
olcAccess: {1}to * by self read by dn.base="cn=Manager,dc=example,dc=org" write by * read

Maybe others attributes (such as givenName) should also be removed from the firs attr line.

Sergio Llorente
  • 101