[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem with nss-ldap using GSSAPI



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.

1) 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.

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
#
# 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 ...)

4) 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





--
Wojtek Polcwiartek

------
tubIT
TU-Berlin
Web   : www.tubit.tu-berlin.de
Email : tubit@tu-berlin.de
Tel   : +49.30.314.28000