Quanah Gibson-Mount wrote:
--On Wednesday, February 21, 2007 11:52 PM +0100 Pierangelo Masarati ando@sys-net.it wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, February 21, 2007 2:39 PM -0800 Quanah Gibson-Mount quanah@stanford.edu wrote:
I'm trying to set up a very simply slapd that takes incoming requests locally, and forwards them on to a remote server using SASL/GSSAPI to get the information, so that a internal app that doesn't understand SASL/GSSAPI can get the information it needs.
Never mind, I forgot to load the core schema. duh. :P
The proxy was a bit too dumb ;)
Heh.
The problem I'm having now, is I can't get it to perform SASL/GSSAPI auth to the remote proxy.
If I have:
# /etc/ldap/slapd.conf -- LDAP proxy slapd configuration file. # $Id$ include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/krb5-kdc.schema include /etc/ldap/schema/suacct.schema # Global Options
modulepath /usr/lib/ldap moduleload back_ldap.la
readonly on access to * by * read
# LDAP Proxy Options
database ldap suffix "dc=stanford,dc=edu" uri "ldap://ldap-test1.stanford.edu" idassert-bind bindmethod=none
It correctly talks to the remote server with an anonymous bind. However, if I change things around:
idassert-bind bindmethod=sasl saslmech=gssapi realm=stanford.edu authcID=proxy credentials=proxy mode=self
I get:
ldapsearch -LLL -x -h localhost -b "dc=stanford,dc=edu" uid=quanah Inappropriate authentication (48)
The KRB5CCNAME is set in slapd's environment, so it has access to the ticket cache it needs to use to perform SASL/GSSAPI. It is not talking to the remote server at all.
Is there something here I'm missing?
I've also tried:
idassert-bind bindmethod=sasl saslmech=gssapi realm=stanford.edu authcID=service/mailrouter@stanford.edu
authzID=dn:cn=mailrouter,cn=service,cn=applications,dc=stanford,dc=edu
But then I get:
Authentication method not supported (7)
And again, it didn't talk to the remote server.
I have never tested back-ldap with GSSAPI; however, config parsing exploits the slap_bindconf() code that's used throughout slapd (e.g. in syncrepl), and the related SASL bind code was basically adapted from the same source, and it is known to work with other SASL mechs. I guess the devil is in the details, as usual. Can you debug it a little bit further, e.g. by running with -d "stats,args,trace", or even more?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------