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

Re: Slave/Replica server authentication/authorization question



I agree, acls have usually been the problem for us. The only other thing i can
think of to try is to run a slapindex -f /location/of/slapd.conf to make sure
the indexing is upto date.

Lee

Quoting Quanah Gibson-Mount <quanah@stanford.edu>:

> Why are you using openldap-2.2.4? 2.2.5 is the latest 2.2 release.
> 
> Also, not being able to bind is generally a sign of bad ACL's.
> 
> --Quanah
> 
> --On Wednesday, February 25, 2004 10:01 AM -0600 "Aaron M. Hirsch" 
> <Aaron.Hirsch@atosorigin.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I have a master server and a slave/replica server.  All the
> > information that is popluated in the master server is in the
> > slave/replica server.  Changes performed on the master server are
> > propogated out properly to the slava/replica server.  I've verified
> > this through the use of the ldapbrowser tool.  The problem is that if
> > I point a ldap client to the slave/replica server for authentication
> > it fails.  Yup, I get err=49 when attempting to bind to the
> > slave/replica server.
> >
> > openldap 2.2.4, openssl-0.9.7c, cyrus-sasl-2.1.17 and db-4.2.52 are
> > the packages used, which are the same on the master server.
> >
> > Here is the slapd.conf from the slave/replica server:
> >
> > bash-2.05# cat slapd.conf
> >#
> ># See slapd.conf(5) for details on configuration options.
> ># This file should NOT be world readable.
> >#
> > include         /opt/ldap/etc/openldap/schema/core.schema
> > include         /opt/ldap/etc/openldap/schema/cosine.schema
> > include         /opt/ldap/etc/openldap/schema/inetorgperson.schema
> > include         /opt/ldap/etc/openldap/schema/nis.schema
> > include         /opt/ldap/etc/openldap/schema/misc.schema
> > include         /opt/ldap/etc/openldap/schema/solaris.schema
> >
> > allow bind_v2 bind_anon_dn
> > loglevel        296
> > pidfile         /opt/ldap/var/run/slapd.pid
> > argsfile        /opt/ldap/var/run/slapd.args
> >
> > TLSCipherSuite          HIGH:MEDIUM
> > TLSCertificateFile      /opt/ldap/etc/openldap/slapd-cert.pem
> > TLSCertificateKeyFile   /opt/ldap/etc/openldap/slapd-key.pem
> >
> > database        bdb
> > readonly        off
> > suffix          "dc=cellnet,dc=com"
> > rootdn          "cn=replica,dc=cellnet,dc=com"
> > updatedn        "cn=replica,dc=cellnet,dc=com"
> > updateref       https://konldap1.cellnet.com/ldap/ldap_config.pl
> > rootpw          {SSHA}5vb4Mp3BltJOBhnwCecA6FGN1zECY7Wp
> > directory       /var/lib/ldap
> > mode            0700
> >
> > index objectClass                       eq,pres
> > index ou,cn,mail,surname,givenname      eq,pres,sub
> > index uidNumber,gidNumber,loginShell    eq,pres
> > index uid,memberUid                     eq,pres,sub
> > index nisMapName,nisMapEntry            eq,pres,sub
> > index nisNetgroupTriple                 pres
> >
> > I'm looking online now, but not finding any answers.  The master
> > server is a RH 3.0 Linux server and the slave/replica is a Sun Solaris
> > 9 machine.
> >
> > Does anyone have any insight into why authorization/authentication
> > works on the master but not the slave/replica?
> >
> > I did have the same ACL's on the slave/replica as the master but that
> > didn't work either.
> >
> > - --
> > Aaron M. Hirsch
> > Atos Origin - Cellnet
> > 11146 Thompson Ave.
> > Lenexa, KS 66219
> > Work:(913) 312-4717
> > Fax:(913) 312-4701
> > Mobile:(913) 284-9094
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.3 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> >
> > iD8DBQFAPMbMgBD+XyMGAPwRAiJUAJ9dR1fCMnVcGvF1Eva3VL60DjxBYwCghSCg
> > Db7xJtEi+qqHYcqhABIQI4Q=
> > =tAif
> > -----END PGP SIGNATURE-----
> >
> 
> 
> 
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITSS/TSS/Computing Systems
> ITSS/TSS/Infrastructure Operations
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>