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
  • 847
  • 3
  • 14
  • 31
  • 1
    Your question is missing the following ingredients: full `sssd.conf`, relevant logfile entries and a mention of whether there even is a group with GID 6006 or not and whether your LDAP user is part of it or not. – daff Dec 06 '12 at 22:19
  • updated the question. Many cases if I post a question I get the answer by myself by evening but I guess this question has to wait – chandank Dec 07 '12 at 01:25

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
  • 983
  • 9
  • 20
chandank
  • 847
  • 3
  • 14
  • 31
  • Really? You wanted to do (PAM) authentication against an LDAP user database without even having a complete LDAP user database? :) – daff Dec 08 '12 at 00:04
  • 5
    Yes it may sound strange to you, but I guess for someone who has no idea about Ldap and how it handles the user management for Unix, it was really difficult. I never though a ldap server designed on/for Linux would keep Linux user mgm so cryptic for a new user. I understand your point as now I think that was a trivial approach but at the same time I know how a newbie feels when he/she does not find a single reference of this in whole Manual. – chandank Dec 08 '12 at 00:18
  • I wonder if you could help me with how I could manage certs of two LDAP servers (failover server) on the client side. I did copy both certs on cacertd dir pointed by sssd and ldap.conf but it does not seems to work. Does these certs need to be in some format ? – chandank Dec 08 '12 at 00:22
  • I think you should post a separate question about your certificate issues, should be fairly straightforward to answer. As for LDAP as a user database and authentication in general: of course it is difficult and non-trivial to get working, but there is much documentation and quite a few books out there that also teach the basics. The [Ubuntu Server Guide](https://help.ubuntu.com/12.04/serverguide/) contains useful information, as does the [Red Hat documentation](http://red.ht/SNSTI8). And although a bit dated now, [this book](http://bit.ly/jlimNj) also helped me a lot. – daff Dec 08 '12 at 15:49
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
  • 1