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

Re: backend-meta usage



I appreciate everyone's advice, I have verified that as the same uid "user ldap", i CAN connect to the external LDAP server via "ldapwhoami over ldaps://" but when connecting to localhost and attempting to use the "meta" definition, it doesn't work.

I don't have a copy of the cacert on the external server, i just have a self signed setup on my own openldap box. Do I need to get a copy of their cacert.pem and configure that in my ldap.conf?

I haven't had a chance to look at the strace/truss output yet, but will post when I do.

--stephen

On 1/23/07, Alex Samad <alex@samad.com.au> wrote:
On Tue, Jan 23, 2007 at 03:10:06PM -0600, Stephen Agar wrote:
> thanks for the advice, ldapwhoami -H ldaps://directory.company.com
> -D"blahblahblah" succeeds.
>
> ldapwhoami -H ldaps://localhost -D"blahblahblah" fails when use via the meta
> db is attempted.
>
> in my slapd debug, i'm seeing the following:
>
> TLS certificate verification: Error, unable to get local issuer certificate
> TLS trace: SSL_connect:SSLv3 read server certificate A
> TLS trace: SSL_connect:SSLv3 read server certificate request A
> TLS trace: SSL_connect:SSLv3 read server done A
> TLS trace: SSL_connect:SSLv3 write client certificate A
> TLS trace: SSL_connect:SSLv3 write client key exchange A
> TLS trace: SSL_connect:SSLv3 write certificate verify A
> TLS trace: SSL_connect:SSLv3 write change cipher spec A
> TLS trace: SSL_connect:SSLv3 write finished A
> TLS trace: SSL_connect:SSLv3 flush data
> TLS trace: SSL3 alert read:fatal:unknown CA
> TLS trace: SSL_connect:failed in SSLv3 read finished A
>
> so it makes me think that it doesnt recognize the cert as being from a valid
> CA. i don't have access to the cert on the other server, and I have tried:
>
> TLS_REQCERT     allow (and also never)
>
> any thoughts? thanks so much for your help so far.
looks like it is trying to authenicate the certificate and because you don't
have the CA it is unable to.  Can you grab the ca for that cert or even place
the public in the list a known good key



>
> --stephen
>
>
> On 1/23/07, Aaron Richton <richton@nbcs.rutgers.edu> wrote:
> >
> >That looks like OK syntax. Get ldapwhoami(1) and similar working at the
> >command line directly. e.g.
> >
> >server$ ldapwhoami -H ldaps://directory.company.com/ [...]
> >
> >I suspect this will fail. (Often CA validation fails, for example.) Once
> >you have ldap.conf such that this works, the slapd.conf syntax you
> >mentioned should be OK. If you can get the command line to work as the
> >same user you're running slapd as, but slapd still fails, try turning up
> >slapd debugging.
> >
> >You can also try "tls propagate" or "tls start". See slapd-meta man page
> >for details.
> >
> >On Tue, 23 Jan 2007, Stephen Agar wrote:
> >
> >> one more followup question. i want the "meta" database on the external
> >> server contacted via tls/ssl.
> >> if I set:
> >>
> >> uri             "ldap://directory.company.com/ou=People,o=company,c=US"
> >>
> >> things work perfectly, however if i set:
> >>
> >> uri             "ldaps://directory.company.com/ou=People,o=company,c=US"
> >>
> >> i get "server is unavailable" when i do things like ldapwhoami. is there
> >> something i can configure in my ldap.conf to allow ldaps authentication
> >to
> >> the server defined in my "meta" stanza?
> >>
> >> --stephen
> >>
> >> On 1/22/07, Stephen Agar <seagar@gmail.com> wrote:
> >>>
> >>> wow....thanks a bunch, that worked perfectly.
> >>>
> >>> --stephen
> >>>
> >>> On 1/22/07, Aaron Richton <richton@nbcs.rutgers.edu > wrote:
> >>> >
> >>> > Try something more like:
> >>> >
> >>> > database        meta
> >>> > suffix          "ou=people,o=company,c=US"
> >>> > subordinate
> >>> >
> >>> > database        bdb
> >>> > suffix          "o=company,c=US"
> >>> >
> >>> > see if that does what you want...
> >>> >
> >>> > On Mon, 22 Jan 2007, Stephen Agar wrote:
> >>> >
> >>> > > I have an LDAP server with a base "o=company, c=us".  There is
> >another
> >>> >
> >>> > > server which controls "ou=people,o=company,c=us",  so in slapd.confi
> >>> > have
> >>> > > the following:
> >>> > >
> >>> > > database        bdb
> >>> > > suffix          "o=company,c=US"
> >>> > > rootdn          "cn=Manager,o=company,c=US"
> >>> > > rootpw          *******
> >>> > > directory       /usr/var/openldap-data
> >>> > > # Indices to maintain
> >>> > > index   objectClass     eq
> >>> > > index   ou,cn,uid       eq,pres,sub
> >>> > >
> >>> > > #meta test
> >>> > > database        meta
> >>> > > suffix          "ou=people,o=company,c=US"
> >>> > > uri
> >>> > "ldap://directory.company.com/ou=People,o=company,c=US"
> >>> > >
> >>> > >
> >>> > > When I try to start slapd, I get: /etc/openldap/slapd.conf: line
> >84:
> >>> > > <suffix> namingContext "o=company,c=US" already served by a
> >preceding
> >>> > bdb
> >>> > > database serving namingContext "o=company,c=US". Am I misusing
> >meta?
> >>> > Can I
> >>> > > not proxy binds/lookups to specific OUs to a secondary LDAP?  I
> >>> > understand
> >>> > > what the message is saying, but don't think I understand the proper
> >>> > use of
> >>> > > meta.
> >>> > >
> >>> > > For example, I have an ou=groups that contains "groupofnames" and
> >the
> >>> > > members of those groups are like
> >>> > "uid=123456,ou=people,o=company,c=us". So I
> >>> > > want ou = groups owned on my server, then the when specific members
> >>> > try to
> >>> > > bind, they are proxied to this external LDAP server that serves
> >>> > > ou=people,o=company,c=us and contains their uids and passwords.  Am
> >I
> >>> > going
> >>> > > about this the wrong way? Is there a way to accomplish what im
> >trying
> >>> > to do?
> >>> > >
> >>> > >
> >>> > > Thanks in advance...
> >>> > > --stephen
> >>> > >
> >>> >
> >>>
> >>>
> >>
> >


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFtpX6kZz88chpJ2MRAk+fAKCYrbulpIeT0387+AFUggHHNDiSugCeIIIf
J54Ft+00D6qaIPquQ5x8qP4=
=MW5+
-----END PGP SIGNATURE-----