RE: Getting SASL working

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Thursday, December 30, 2004 2:02 PM -0600 Jonathan Reeder 
<jreeder@nscnet.com> wrote:

> ------- Jonathan Reeder's Reply -----------
>
> Thanks a bunch for the tip, I'm sure that would have caused me trouble in
> the future.  However, unfortunately, I'm still getting the same error
> after modifying my slapd.conf and restarting.
>
> I don't know if my slapd.conf would be helpful to anyone, but here it is:
>
> $ cat slapd.conf
> include         /usr/local/etc/openldap/schema/core.schema
>
> pidfile         /var/run/openldap/slapd.pid
> argsfile        /var/run/openldap/slapd.args
>
> # SASL stuff
> sasl-host <FQDN.of.this.host>
> sasl-realm <MYREALM.COM>
>
> # sasl-secprops  noplain,noanonymous,minssf=56
>
> # SSL/TLS stuff
> TLSCipherSuite          HIGH
> TLSCertificateFile      /usr/local/certs/host.cert
> TLSCertificateKeyFile   /usr/local/certs/host.key
> TLSCACertificateFile    /usr/local/certs/host.cert
>
> database        bdb
> suffix          "dc=<mydomain>,dc=com"
> # rootdn         "cn=Manager,dc=<mydomain>,dc=com"
> rootdn "uid=ldapadmin,cn=<MYREALM.COM>,cn=gssapi,cn=auth"
> directory       /var/db/openldap-data
> mode            0700
> # Indices to maintain
> index   objectClass     eq
>
> # ACLs (just to test)
> access to *
>         by * read

I think, but may be mistaken, that the rootdn must actually exist in your 
database.  I assume you don't actually have an entry called 
"uid=ldapadmin,cn=<MYREALM.COM>,cn=gssapi,cn=auth" in your database.

This really isn't the approach I would take with this, either.

You might find this page helpful:

<http://www.stanford.edu/services/directory/openldap/configuration/slapd-conf-replica.html>

For ldapadmins @ stanford, they belong to an ldapadmin group in the 
database:

tribes:~> ldsearch cn=ldapadmin
dn: cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu
objectClass: groupOfNames
cn: ldapAdmin
member: uid=quanah,cn=Accounts,dc=stanford,dc=edu
<.... other members ....>

That group has full read (supervisor has full write on the master, read on 
the replica):

access to *
   by 
dn.base="cn=replicator,cn=Service,cn=Applications,dc=stanford,dc=edu" 
sasl_ssf=56 write
   by group.base="cn=Supervisor,cn=Applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
   by group.base="cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
   by * break

Slurpd uses its own keytab & ticket for replication.  My rootdn actually is 
not used for anything, and is an empty placeholder entry:

tribes:/afs/ir/dev/directory/template/conf> ldsearch cn=manager
dn: cn=Manager,dc=stanford,dc=edu
objectClass: organizationalRole
cn: Manager

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin