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

RE: Getting SASL working





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