[Date Prev][Date Next]
Re: Problem with nss-ldap using GSSAPI
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.
Wojtek Polcwiartek wrote:
thank you for help offer! We spent already much time analysing this
1) Parts of our ldap.conf:
We do not need root access to ldap. We only read from it.
2) 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
3) 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
# base <ou=user,dc=tu-berlin,dc=de> with scope subtree
# filter: uid=SOME_USER
# requesting: ALL
# SOME_USER, user, tu-berlin.de
(... and so on ...)
4) Errorneous debug output of 'getent passwd'
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.
Thanks in advance!
Buchan Milne wrote:
On Wednesday, 30 December 2009 12:32:32 Wojtek Polcwiartek wrote:
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: >,
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.
Web : www.tubit.tu-berlin.de
Email : email@example.com
Tel : +49.30.314.28000