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
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 ]
