Hello,
we found the problem: it was wrong server-side configuration. The account, used for binding to ldap server, did not had enough rights to read the Gecos-Attribute. The Ldap-Server returned an answer (that is, why we could see it in Debug-mode), but it was not enough for NSS (without Gecos). NSS discarded the entry. Correcting the access list solved the problem. We just wanted to share our expirience.
Greetings,
Wojtek
Wojtek Polcwiartek wrote:
Hello,
thank you for help offer! We spent already much time analysing this problem.
- Parts of our ldap.conf:
URI ldap://SOME_HOST.tu-berlin.de use_sasl on sasl_mech gssapi sasl_authid SOME_USER@TU-BERLIN.DE krb5_ccname SOME_PATH
We do not need root access to ldap. We only read from it.
- Output of klist:
root@ANOTHER_HOST:/root# klist SOME_PATH Ticket cache: FILE:SOME_PATH Default principal: SOME_USER@TU-BERLIN.DE
Valid starting Expires Service principal 01/06/10 09:45:54 01/06/10 19:45:54 krbtgt/TU-BERLIN.DE@TU-BERLIN.DE renew until 01/07/10 0return 9:45:54
- Output of ldapsearch (in shell of root: KRB5CCNAME=SOME_PATH)
root@ANOTHER_HOST:/root# ldapsearch -h SOME_HOST.tu-berlin.de -Y gssapi -b ou=user,dc=tu-berlin,dc=de uid=SOME_USER
SASL/GSSAPI authentication started SASL username: SOME_USER@TU-BERLIN.DE SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <ou=user,dc=tu-berlin,dc=de> with scope subtree # filter: uid=SOME_USER # requesting: ALL #
# SOME_USER, user, tu-berlin.de dn: uid=SOME_USER,ou=user,dc=tu-berlin,dc=de objectClass: top (... and so on ...)
- Errorneous debug output of 'getent passwd'
http://paste-it.net/public/e7c590c/
Suspicious error you can see on the lines 85 and 144. In the lines 315-336 you can see correct, but encoded, output. This action will not produce any passwd line.
Any ideas? Thanks in advance!
Wojtek
Buchan Milne wrote:
On Wednesday, 30 December 2009 12:32:32 Wojtek Polcwiartek wrote:
Hello,
we use ldap as name source in our system (libnss-ldap). Until now we used anonymous bind with LDAP and it worked fine. Now we want to switch to GSSAPI (MIT Krb5), but getting names ('getent passwd <name>') does not work: no result is returned/printed. Strange is that, when we run the query in debug-mode (debug 7 in /etc/ldap.conf), you can see the correct result in the debug part (in "hexes") but at the end no result is printed . The only error message we could see is: res_errno: 14, res_error: <SASL(0): successful result: >, res_matched: <>
Can you provide your /etc/ldap.conf (or, at least the relevant parts, such as host/uri, use_sasl, rootuse_sasl, krb5_ccname etc.), as well as output from a relevant klist command.
Querying LDAP with ldapsearch still works fine.
With GSSAPI? Can you provide an example (including the output)?
Do You have any idea how to get closer to the source of the problem? We use Ubuntu Karmic as client (repo package) and Solaris10 (with OpenLdap 2.4.16) as server.
I have no problems on Mandriva (e.g. 2010.0), and with sudo 1.7.x, even sudo now supports GSSAPI for sudo rules in LDAP.
Regards, Buchan