10:14 a.m.
Hi,
I'm running a pair of OpenLDAP servers on a network which primarily uses
kerberos for authentication. The two servers replicate data (via a
simple syncrepl master-slave setup). Right now, they're using simple
authentication. I'd like to move them to using kerberos authentication.
I've successfully gotten them to the point where the kerberos
authentication (appears) to succeed. However, replication doesn't
happen with the mysterious error "findbase failed! 32". I have found no
mention of this error, other than a couple of permissions-related
errors. I double-checked my permissions, so it's not that.
I've copied relevant portions of my slapd.conf below and would be happy
to provide more if required. I also have a syslog excerpt below.
Does anyone know what I should be looking at next or have an example of
a functional setup similar to what I've described?
Thanks,
Steve
Functioning syncrepl config:
syncrepl rid=1
provider=ldap://ldap1.pressers.name/
type=refreshAndPersist
retry="60 30 300 +"
searchbase="dc=pressers,dc=name"i
bindmethod=simple
binddn="cn=repl,dc=pressers,dc=name"
credentials="SOMEPASSWORD"
Config which fails mysteriously:
syncrepl rid=1
provider=ldap://ldap1.pressers.name/
type=refreshAndPersist
retry="60 30 300 +"
searchbase="dc=pressers,dc=name"i
bindmethod=sasl
saslmech=gssap
Finally, an excerpt for syslog on the master when the client attempts to
connect:
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 fd=18 ACCEPT from
IP=10.0.0.3:57149 (IP=0.0.0.0:389)
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=0 BIND dn="" method=163
Sep 30 13:11:09 hawking slapd[1620]: GSSAPI server step 1
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=0 RESULT tag=97 err=14
text=SASL(0): successful result:
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=1 BIND dn="" method=163
Sep 30 13:11:09 hawking slapd[1620]: GSSAPI server step 2
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=1 RESULT tag=97 err=14
text=SASL(0): successful result:
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND dn="" method=163
Sep 30 13:11:09 hawking slapd[1620]: GSSAPI server step 3
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
authcid="ldap/mordor.pressers.name"
authzid="ldap/mordor.pressers.name"
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI
sasl_ssf=56 ssf=56
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 RESULT tag=97 err=0
text=
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=3 SRCH
base="dc=pressers,dc=name" scope=2 deref=0 filter="(objectClass=*)"
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=3 SRCH attr=* +
Sep 30 13:11:09 hawking slapd[1620]: findbase failed! 32
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=3 SEARCH RESULT
tag=101 err=32 nentries=0 text=
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=4 UNBIND
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 fd=18 closed
10:22 a.m.
--On Tuesday, September 30, 2014 2:14 PM -0400 Steven Presser
<steve(a)pressers.name> wrote:
Hi,
I'm running a pair of OpenLDAP servers on a network which primarily uses
kerberos for authentication. The two servers replicate data (via a
simple syncrepl master-slave setup). Right now, they're using simple
authentication. I'd like to move them to using kerberos authentication.
I've successfully gotten them to the point where the kerberos
authentication (appears) to succeed. However, replication doesn't happen
with the mysterious error "findbase failed! 32". I have found no mention
of this error, other than a couple of permissions-related errors. I
double-checked my permissions, so it's not that.
I've copied relevant portions of my slapd.conf below and would be happy
to provide more if required. I also have a syslog excerpt below.
Does anyone know what I should be looking at next or have an example of a
functional setup similar to what I've described?
It doesn't look like you've set up SASL regexp's correctly or you didn't
define your ACLs correctly for the SASL bind ID:
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
authcid="ldap/mordor.pressers.name"
authzid="ldap/mordor.pressers.name"
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI
sasl_ssf=56 ssf=56
As you can see, your replication DN was:
binddn="cn=repl,dc=pressers,dc=name"
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:30 a.m.
No; That bind DN is used only in simple authentication. I am
maintaining them as separate accounts, for the time being. One of my
ACLs is:
access to *
by dn.exact="cn=repl,dc=pressers,dc=name" read
by dn.exact="uid=ldap/mordor.pressers.name,
cn=pressers.name,cn=gssapi,cn=auth" read
by * break
Which I think ought to cover the permissions required pretty well. As
you can see, they have identical permissions.
Also, I just noticed an error introduced by copy-paste in my last
email. In both configs there is a floating "i" on the searchbase line.
That "i" belongs at the end of "GSSAP" on the saslmech line.
Thanks,
Steve
On 09/30/2014 01:22 PM, Quanah Gibson-Mount wrote:
--On Tuesday, September 30, 2014 2:14 PM -0400 Steven Presser
<steve(a)pressers.name> wrote:
> Hi,
>
> I'm running a pair of OpenLDAP servers on a network which primarily uses
> kerberos for authentication. The two servers replicate data (via a
> simple syncrepl master-slave setup). Right now, they're using simple
> authentication. I'd like to move them to using kerberos authentication.
>
> I've successfully gotten them to the point where the kerberos
> authentication (appears) to succeed. However, replication doesn't
> happen
> with the mysterious error "findbase failed! 32". I have found no
> mention
> of this error, other than a couple of permissions-related errors. I
> double-checked my permissions, so it's not that.
>
> I've copied relevant portions of my slapd.conf below and would be happy
> to provide more if required. I also have a syslog excerpt below.
>
> Does anyone know what I should be looking at next or have an example
> of a
> functional setup similar to what I've described?
It doesn't look like you've set up SASL regexp's correctly or you
didn't define your ACLs correctly for the SASL bind ID:
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
authcid="ldap/mordor.pressers.name"
authzid="ldap/mordor.pressers.name"
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI
sasl_ssf=56 ssf=56
As you can see, your replication DN was:
binddn="cn=repl,dc=pressers,dc=name"
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:59 a.m.
--On Tuesday, September 30, 2014 2:30 PM -0400 Steven Presser
<steve(a)pressers.name> wrote:
No; That bind DN is used only in simple authentication. I am
maintaining
them as separate accounts, for the time being. One of my ACLs is:
access to *
by dn.exact="cn=repl,dc=pressers,dc=name" read
by dn.exact="uid=ldap/mordor.pressers.name,
cn=pressers.name,cn=gssapi,cn=auth" read
by * break
Which I think ought to cover the permissions required pretty well. As you
can see, they have identical permissions.
Also, I just noticed an error introduced by copy-paste in my last email.
In both configs there is a floating "i" on the searchbase line. That
"i"
belongs at the end of "GSSAP" on the saslmech line.
Ok, well, without having your full configs available (minus passwords), one
can only make guesses. ;)
I would start with binding as that ID using ldapwhoami, then move on to
ldapsearch, etc, and verify all of that works as expected.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:30 a.m.
No; That bind DN is used only in simple authentication. I am
maintaining them as separate accounts, for the time being. One of my
ACLs is:
access to *
by dn.exact="cn=repl,dc=pressers,dc=name" read
by dn.exact="uid=ldap/mordor.pressers.name,
cn=pressers.name,cn=gssapi,cn=auth" read
by * break
Which I think ought to cover the permissions required pretty well. As
you can see, they have identical permissions.
Also, I just noticed an error introduced by copy-paste in my last
email. In both configs there is a floating "i" on the searchbase line.
That "i" belongs at the end of "GSSAP" on the saslmech line.
Thanks,
Steve
On 09/30/2014 01:22 PM, Quanah Gibson-Mount wrote:
--On Tuesday, September 30, 2014 2:14 PM -0400 Steven Presser
<steve(a)pressers.name> wrote:
> Hi,
>
> I'm running a pair of OpenLDAP servers on a network which primarily uses
> kerberos for authentication. The two servers replicate data (via a
> simple syncrepl master-slave setup). Right now, they're using simple
> authentication. I'd like to move them to using kerberos authentication.
>
> I've successfully gotten them to the point where the kerberos
> authentication (appears) to succeed. However, replication doesn't
> happen
> with the mysterious error "findbase failed! 32". I have found no
> mention
> of this error, other than a couple of permissions-related errors. I
> double-checked my permissions, so it's not that.
>
> I've copied relevant portions of my slapd.conf below and would be happy
> to provide more if required. I also have a syslog excerpt below.
>
> Does anyone know what I should be looking at next or have an example
> of a
> functional setup similar to what I've described?
It doesn't look like you've set up SASL regexp's correctly or you
didn't define your ACLs correctly for the SASL bind ID:
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
authcid="ldap/mordor.pressers.name"
authzid="ldap/mordor.pressers.name"
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI
sasl_ssf=56 ssf=56
As you can see, your replication DN was:
binddn="cn=repl,dc=pressers,dc=name"
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11:09 a.m.
On 09/30/14 13:14 -0400, Steven Presser wrote:
I'm running a pair of OpenLDAP servers on a network which
primarily
uses kerberos for authentication. The two servers replicate data (via
a simple syncrepl master-slave setup). Right now, they're using
simple authentication. I'd like to move them to using kerberos
authentication.
Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI
sasl_ssf=56 ssf=56
On 09/30/14 13:30 -0400, Steven Presser wrote:
No; That bind DN is used only in simple authentication. I am
maintaining them as separate accounts, for the time being. One of my
ACLs is:
access to *
by dn.exact="cn=repl,dc=pressers,dc=name" read
by dn.exact="uid=ldap/mordor.pressers.name,
cn=pressers.name,cn=gssapi,cn=auth" read
Your line here does not match the identity from your logs.
--
Dan White
11:13 a.m.
Dan,
Good catch! That did the trick! (This is what I get for reading the
format out of the docs instead of the logs... And not double-checking)
Thanks a bunch,
Steve
On 09/30/2014 02:09 PM, Dan White wrote:
On 09/30/14 13:14 -0400, Steven Presser wrote:
> I'm running a pair of OpenLDAP servers on a network which primarily
> uses kerberos for authentication. The two servers replicate data
> (via a simple syncrepl master-slave setup). Right now, they're using
> simple authentication. I'd like to move them to using kerberos
> authentication.
> Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND
> dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI
> sasl_ssf=56 ssf=56
On 09/30/14 13:30 -0400, Steven Presser wrote:
> No; That bind DN is used only in simple authentication. I am
> maintaining them as separate accounts, for the time being. One of my
> ACLs is:
>
> access to *
> by dn.exact="cn=repl,dc=pressers,dc=name" read
> by dn.exact="uid=ldap/mordor.pressers.name,
> cn=pressers.name,cn=gssapi,cn=auth" read
Your line here does not match the identity from your logs.
3100
days inactive
3100
days old
openldap-technical@openldap.org
6 comments
3 participants
participants (3)
-
Dan White -
Quanah Gibson-Mount -
Steven Presser