nntp2http.com
Posting
Suche
Optionen
Hilfe & Kontakt

Heimdal + OpenLDAP

Von: Friedemann Stoyan (devnull@swapon.de) [Profil]
Datum: 19.04.2009 14:57
Message-ID: <gsf73k$lf1$1@news.lab.swapon.de>
Newsgroup: de.comp.os.unix.misc
Geschätzte Leserschaft!

Nachdem Heimdal+NFS4 läuft, versuche ich mich an Heimdal+OpenLDAP
auf Debian/GNU-Linux (Lenny). Ziel soll sein keine Passwörter in
LDAP abzulegen und die Authorisierung an Kerberos auszulagern. Das
Setup ist angelehnt an:

http://www.openldap.org/doc/admin24/
/usr/share/doc/slapd/README.Debian.gz

Also 'libsasl2-modules-gssapi-heimdal' installiert und folgende
Konfiguration:

/etc/ldap/slapd.conf:
# Kerberos Configuration
sasl-host       kerberos.lab.swapon.de
sasl-realm      LAB.SWAPON.DE

# Mapping Kerberos Authentication Identities
authz-regexp
uid=([^,]*),cn=lab.swapon.de,cn=gssapi,cn=auth
ldap:///ou=people,dc=lab,dc=swapon,dcÞ??one?(&(uid=$1)(objectClass=person))

/etc/ldap/sasl2/slapd.conf:

keytab:         /etc/ldap/krb5.keytab
mech_list:      GSSAPI

Ja, 'keytab:' ist korrekt [1].

Leider funktioniert es nicht so, wie ich mir das vorgestellt habe.

* Kerberos Ticket besorgen und ein ldapsearch:

$ kinit
$ ldapsearch -H ldaps://ldap.lab.swapon.de/ -b 'dc=lab,dc=swapon,dcÞ'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)

Ein LDAP-Ticket habe ich erhalten:

$ klist
Credentials cache: KCM:1000
Principal: fsn@LAB.SWAPON.DE

Issued           Expires          Principal
Apr 19 14:31:19  Apr 20 00:31:18  krbtgt/LAB.SWAPON.DE@LAB.SWAPON.DE
Apr 19 14:31:48  Apr 20 00:31:18  ldap/ldap.lab.swapon.de@LAB.SWAPON.DE

Aus Serverseite sehe ich:

slapd[32712]: conn=5 fd ACCEPT from IP=[2001:6f8:12ec::]:58148 (IP=[2001:6f8:12ec::]:636)
slapd[32712]: conn=5 fd TLS established tls_ssf8 ssf8
slapd[32712]: conn=5 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
slapd[32712]: conn=5 op=0 SRCH attr=supportedSASLMechanisms
slapd[32712]: conn=5 op=0 SEARCH RESULT tag1 err=0 nentries=1 text
slapd[32712]: conn=5 op=1 BIND dn="" method3
slapd[32712]: SASL [conn=5] Failure: GSSAPI Error:  No credentials were supplied, or the
credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown)
slapd[32712]: conn=5 op=1 RESULT tag— err€ text=SASL(-1): generic failure: GSSAPI Error: 
No credentials were supplied, or the credentials were unavailable or inaccessible.
(unknown mech-code 0 for mech unknown)
slapd[32712]: conn=5 fd closed (connection lost)

Hier komme ich nicht so recht weiter. Wo ist der Showstopper?

An dieser Stelle eine andere Frage: Macht es überhaupt Sinn diesen
Ansatz weiter zu verfolgen? Ich habe einige Nicht-Kerberos
Applikationen. Wäre es nicht besser, den slapd per sasl einen
saslauthd befragen zu lassen, welcher dann seinerseits per Kerberos
authentisiert. Die Applikationen müsten dann nicht kerberisiert
sein, ich könnte aber trotzdem Kerberos nutzen. Meinungen dazu?


mfg Friedemann

[1]:
http://www.openldap.org/doc/admin24/appendix-common-errors.html#GSSAPI:%20gss_acquire_cred
:%20Miscellaneous%20failure;%20Permission%20denied;

[ Auf dieses Posting antworten ]