I am having trouble getting multi-master syncrepl to sync when using "bindmethod=sasl" and "saslmech=gssapi". I achieved success when I tried "bindmethod=simple", so at least I know it has been narrowed down to a sasl/gssapi authentication problem (incorrect/missing sasl AuthzRegexp or perhaps an incorrect/missing slapd ACL?).
My syncrepl config is as follows (do I need to specify an authcid/authzid or is this id automatically obtained from gssapi?):
olcMirrorMode: TRUE olcSyncRepl: rid=001 provider=ldap://or-dc1-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="cn=config" olcSyncRepl: rid=002 provider=ldap://or-dc2-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="cn=config"
# Syncprov overlay dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
olcMirrorMode: TRUE olcSyncRepl: rid=003 provider=ldap://or-dc1-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="dc=example,dc=corp" olcSyncRepl: rid=004 provider=ldap://or-dc2-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="dc=example,dc=corp"
# Syncprov overlay dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
My access control:
olcAccess: to attrs=userPassword,shadowLastChange by dn="uid=ldap-admin,ou=people,dc=example,dc=corp" write by dn="uid=ldap/or-dc1-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by dn="uid=ldap/or-dc2-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by anonymous auth by self write by * none olcAccess: to dn.subtree="ou=krb5,dc=example,dc=corp" by dn="cn=kdc-srv,ou=krb5,dc=example,dc=corp" read by dn="cn=adm-srv,ou=krb5,dc=example,dc=corp" write by * none olcAccess: to * by dn="uid=ldap-admin,ou=people,dc=example,dc=corp" write by dn="uid=ldap/or-dc1-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by dn="uid=ldap/or-dc2-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by peername.ip="192.168.0.0%255.255.255.0" read
My sasl AuthzRegexp:
olcAuthzRegexp: uid=([^,]+),cn=example.corp,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=corp
I know sasl/gssapi are working since ldapwhoami on or-dc1-db returns:
SASL/GSSAPI authentication started SASL username: ldap/or-dc1-db.example.corp@EXAMPLE.CORP SASL SSF: 56 SASL data security layer installed. dn:uid=ldap/or-dc1-db.example.corp,ou=people,dc=example,dc=corp
ldapwhoami on or-dc2-db returns:
SASL/GSSAPI authentication started SASL username: ldap/or-dc2-db.example.corp@EXAMPLE.CORP SASL SSF: 56 SASL data security layer installed. dn:uid=ldap/or-dc2-db.example.corp,ou=people,dc=example,dc=corp
I get the following /var/log/syslog errors on or-dc1-db:
OR-DC1-DB slapd[5446]: slap_client_connect: URI=ldap://or-dc2-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC1-DB slapd[5446]: do_syncrepl: rid=004 rc -2 retrying OR-DC1-DB slapd[5446]: slap_client_connect: URI=ldap://or-dc2-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC1-DB slapd[5446]: do_syncrepl: rid=002 rc -2 retrying
/var/log/syslog errors on or-dc2-db:
OR-DC2-DB slapd[5455]: slap_client_connect: URI=ldap://or-dc1-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC2-DB slapd[5455]: do_syncrepl: rid=003 rc -2 retrying OR-DC2-DB slapd[5455]: slap_client_connect: URI=ldap://or-dc1-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC2-DB slapd[5455]: do_syncrepl: rid=001 rc -2 retrying
--On Wednesday, March 07, 2012 8:30 PM -0500 travis.bean@assuretech.net wrote:
I am having trouble getting multi-master syncrepl to sync when using "bindmethod=sasl" and "saslmech=gssapi". I achieved success when I tried "bindmethod=simple", so at least I know it has been narrowed down to a sasl/gssapi authentication problem (incorrect/missing sasl AuthzRegexp or perhaps an incorrect/missing slapd ACL?).
Does the slapd process have a KRB5TICKET environment variable defined? Does the slapd process have the "kstart" utility keeping said ticket constantly alive?
Those are usually the two main failing points.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
What value do I set the KRB5TICKET environment variable to? In all the documentation I have reviewed, I am not aware of the existence of a KRB5TICKET environment variable. Do you mean KRB5_KTNAME?
On Debian Linux, I set KRB5_KTNAME with the following:
sed -i "s|#export KRB5_KTNAME=/etc/krb5.keytab|export \ KRB5_KTNAME=/etc/ldap/ldap.keytab|" /etc/default/slapd
K5start is started with the following:
k5start -b -u ldap/${FQDN}@$KRB_REALM -f /etc/ldap/ldap.keytab \ -K 10 -l 24h -k /tmp/krb5cc_0 -o openldap
--On Wednesday, March 07, 2012 8:30 PM -0500 travis.bean@assuretech.net wrote:
I am having trouble getting multi-master syncrepl to sync when using "bindmethod=sasl" and "saslmech=gssapi". I achieved success when I tried "bindmethod=simple", so at least I know it has been narrowed down
to a
sasl/gssapi authentication problem (incorrect/missing sasl AuthzRegexp or perhaps an incorrect/missing slapd ACL?).
Does the slapd process have a KRB5TICKET environment variable defined? Does the slapd process have the "kstart" utility keeping said ticket constantly alive?
Those are usually the two main failing points.
--Quanah
--On Wednesday, March 07, 2012 10:10 PM -0800 "Travis L. Bean" travis.bean@assuretech.net wrote:
What value do I set the KRB5TICKET environment variable to? In all the documentation I have reviewed, I am not aware of the existence of a KRB5TICKET environment variable. Do you mean KRB5_KTNAME?
On Debian Linux, I set KRB5_KTNAME with the following:
sed -i "s|#export KRB5_KTNAME=/etc/krb5.keytab|export \ KRB5_KTNAME=/etc/ldap/ldap.keytab|" /etc/default/slapd
K5start is started with the following:
k5start -b -u ldap/${FQDN}@$KRB_REALM -f /etc/ldap/ldap.keytab \ -K 10 -l 24h -k /tmp/krb5cc_0 -o openldap
You may want to read over:
http://www.openldap.org/lists/openldap-software/200608/msg00294.html
You need to point slapd to the ticket *cache* not the keytab. slapd itself won't obtain a ticket, that's the purpose of k5start. I realize the variable I was thinking of is KRB5CCNAME. ;)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org