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.conf i 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
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.conf i 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
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.conf i
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
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.conf i
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
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.conf i
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
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.
--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
"unknown CA" suggests you examine the TLS_CACERT directive. Perhaps it points to something that the user running slapd isn't permitted to read? (Alternately, verify that you're running ldapwhoami under the same conditions as slapd, in terms of uid, chroot, etc.)
Look around with that, maybe drill down to a truss/strace (look for open() or open64() or something like that on the TLS_CACERT file) if things still aren't working.
On Tue, 23 Jan 2007, 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.
--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
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
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-----
OK, a couple long shots (I don't really believe these, but they should be quick to try and since you're not working anyway they shouldn't hurt)...
Do TLSCACertificateFile and/or TLSCACertificatePath match TLS_CACERT and/or TLS_CACERTDIR? Can you make them that way?
Can you verify somehow that the ldap.conf you expect to be read is indeed being read? That there's no ~/.ldaprc in the way?
"TLS_REQCERT never" should set the library to its most liberal; it's somewhat surprising that it's still complaining about CA in that case.
On Wed, 24 Jan 2007, Stephen Agar wrote:
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
I'm going to try these things shortly.
Quick question on how back-meta works, does it use the configuration in ldap.conf to do the backend proxying to the external LDAP server? My slapd.conf has a self signed ca/cert and stuff, but I have no visibility into the configuration of the external LDAP server that I have configured in the meta stanza in my slapd.conf. Do I need their cacert.pem file? Does the one I use in slapd.conf need to match the one on the external server? Does the one in my ldap.conf need to match theirs? Do I need to configure something in the "meta" stanza in my slapd.conf to tell it not to verify the external servers certificate?
The thing that confuses me the most if the fact that ldapwhoami works over ldaps:// to that external server, but the meta piece in my slapd.conf won't work over ldaps, only over straight ldap.
--stephen
On 1/24/07, Aaron Richton richton@nbcs.rutgers.edu wrote:
OK, a couple long shots (I don't really believe these, but they should be quick to try and since you're not working anyway they shouldn't hurt)...
Do TLSCACertificateFile and/or TLSCACertificatePath match TLS_CACERT and/or TLS_CACERTDIR? Can you make them that way?
Can you verify somehow that the ldap.conf you expect to be read is indeed being read? That there's no ~/.ldaprc in the way?
"TLS_REQCERT never" should set the library to its most liberal; it's somewhat surprising that it's still complaining about CA in that case.
On Wed, 24 Jan 2007, Stephen Agar wrote:
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
openldap-software@openldap.org
-
Aaron Richton -
Alex Samad -
Stephen Agar