8:50 p.m.
Greetings all,
I'm trying to figure out why Syncrepl is only syncing part of my provider's
database when I use GSSAPI to connect. Both my provider and consumer are on 2.4.40. Here
are all the steps I'm taking:
My provider is working fine, I've been using it for months now without any issues. I
added this to the provider:
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
structuralObjectClass: olcSyncProvConfig
entryUUID: b32ac160-29e6-1036-8d0a-07ef98fd592e
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20161019012544Z
olcSpSessionlog: 100
entryCSN: 20161024233803.817199Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161024233803Z
I also indexed entryCSN and entryUUID on the provider. I have olcAuthzRegexp setup on the
provider as well.
olcAuthzRegexp: {0}"uid=admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=admin,dc=harmonywave,dc=com"
olcAuthzRegexp: {1}"uid=ldap/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
olcAuthzRegexp: {2}"uid=syncprov,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=syncprov,dc=harmonywave,dc=com" #not using this.
olcAuthzRegexp: {3}"uid=.*\/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=admin,dc=harmonywave,dc=com"
olcAuthzRegexp:
{4}"uid=host\/([^.]*).harmonywave.com,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=$1+ipHostNumber=.*,ou=Hosts,dc=harmonywave,dc=com"
olcAuthzRegexp: {5}"uid=([^/]*),cn=harmonywave.com,cn=GSSAPI,cn=auth"
"uid=$1,ou=End Users,ou=People,dc=harmonywave,dc=com"
On the consumer I have slapd installed. The first thing I did was change the olcSuffix on
my database. I'm not sure if this is required or not.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=harmonywave,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=harmonywave,dc=com
Then I'm adding my ldap keytab for the consumer.
kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/consumer.harmonywave.com
consumer: ~# chown openldap:openldap /etc/ldap/ldap.keytab
consumer: ~# chmod 0640 /etc/ldap/ldap.keytab
I edited my /etc/default/slapd file and pointed the KRB5_KTNAME environment variable to
the new keytab then restarted slapd. Next I installed kstart and created a ticket cache.
consumer: ~# k5start -U -f /etc/ldap/ldap.keytab -K 10 -l 24h -k /tmp/krb5cc_108 -o
openldap -b
I can see the ldap service's keytab with klist.
consumer: ~# klist /tmp/krb5cc_108
Ticket cache: FILE:/tmp/krb5cc_108
Default principal: ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM
Valid starting Expires Service principal
10/28/2016 21:18:14 10/29/2016 07:18:14 krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM
renew until 10/29/2016 21:18:14
Then I add my olcSaslRealm
dn: cn=config
changetype: modify
add: olcSaslRealm
olcSaslRealm: HARMONYWAVE.COM
Here is what my database looks like right before I add olcSyncrepl:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootPW:: ...
olcDbCheckpoint: 512 30
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 9a091324-2e84-1036-8b7a-73db8891632a
creatorsName: cn=admin,cn=config
createTimestamp: 20161024222607Z
olcSuffix: dc=harmonywave,dc=com
olcRootDN: cn=admin,dc=harmonywave,dc=com
olcDbIndex: cn,uid eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: member,memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: uidNumber,gidNumber eq
entryCSN: 20161029033105.691204Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161029033105Z
then I add olcSyncrepl to the consumer.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=000
provider=ldap://provider.harmonywave.com
type=RefreshAndPersist
retry="30 10 1800 +"
searchbase="dc=harmonywave,dc=com"
bindmethod=sasl
saslmech=GSSAPI
starttls=critical
tls_cacert=/etc/ssl/certs/ca.harmonywave.com.pem
tls_reqcert=demand
After that I slapcat on the consumer and I only see about 1/3 of my data from the
provider. When I watch the log on the provider this is what I get:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 ACCEPT from IP=10.1.30.19:55992
(IP=0.0.0.0:389)
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 STARTTLS
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 RESULT oid= err=0 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS established tls_ssf=128
ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0
filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH attr=krbprincipalname
krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife
krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled
krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount
krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences
krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SEARCH RESULT tag=101 err=0
nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0
filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH attr=krbprincipalname
krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife
krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled
krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount
krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences
krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SEARCH RESULT tag=101 err=0
nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0
filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH attr=krbprincipalname
krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife
krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled
krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount
krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences
krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SEARCH RESULT tag=101 err=0
nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 RESULT tag=97 err=14 text=SASL(0):
successful result:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 RESULT tag=97 err=14 text=SASL(0):
successful result:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth"
mech=GSSAPI sasl_ssf=56 ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
The only thing I really notice from this is near the end of the file. It when it searches
the base with attributes "*+", but then immediately unbinds. I've seen
people stating that authzid is required, but when I don't provide it I still get a
partial sync, so I'm not sure about this. I've restored my consumer to a clean
install of slapd and repeated the above steps with minor variations several times but the
consumer always syncs the exact same amount of data and then seems to stop.
Any help to point me in the right direction would be appreciated.
Thanks,
Joshua Schaeffer
**
10:22 p.m.
On Fri, Oct 28, 2016 at 09:50:30PM -0600, Joshua Schaeffer wrote:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=harmonywave,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=harmonywave,dc=com
You may have done this - I didn't see it - but if you change the suffix
this way when there are existing entries in that database, and you don't
clear them out, you risk exposing yourself to issues such as
<https://bugs.debian.org/546368>;. If you change your suffix this way,
after you do it, consider initializing a new, empty database: stop
slapd, rm /var/lib/ldap/*, and start it again. I'm bringing this up
because it looks like you're using the Debian/Ubuntu package, which does
indeed add a couple of entries to the default database during setup.
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS established
tls_ssf=128 ssf=128
As I understand it, using Kerberos with OpenLDAP already gets you an
encrypted transport - I believe using TLS on top of that is redundant.
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth"
mech=GSSAPI sasl_ssf=56 ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text=
That looks fine, the GSSAPI bind seems to have succeeded.
So at this point, based on your ACLs above, I'd expect it to be able to
read all of your data (to * by * read), except for the userPassword and
shadowLastChange attributes.
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
Odd - I was expecting to see a RESULT line there. Not sure what that
means. I guess something goes wrong on the client and it aborts early?
It would be interesting to see logs from the syncrepl consumer, at
loglevel 'sync', when you bring it up with an empty database.
If you do an ldapsearch against the provider as anonymous, or doing a
GSSAPI bind using that sevice ticket, do you see all the data returned
that you expected?
If you want a decent example config to compare your work against, I
would suggest rjsystems' articles:
http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php
http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-consumer.php
It's a little dated, but not too badly. (For example, most or all of the
bugs he mentions have since been fixed; and the hdb backend is
deprecated now in favour of mdb.)
12:25 p.m.
On 10/28/2016 11:22 PM, Ryan Tandy wrote:
On Fri, Oct 28, 2016 at 09:50:30PM -0600, Joshua Schaeffer wrote:
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> replace: olcSuffix
> olcSuffix: dc=harmonywave,dc=com
> -
> replace: olcRootDN
> olcRootDN: cn=admin,dc=harmonywave,dc=com
You may have done this - I didn't see it - but if you change the suffix this way when
there are existing entries in that database, and you don't clear them out, you risk
exposing yourself to issues such as <https://bugs.debian.org/546368>;. If you change
your suffix this way, after you do it, consider initializing a new, empty database: stop
slapd, rm /var/lib/ldap/*, and start it again. I'm bringing this up because it looks
like you're using the Debian/Ubuntu package, which does indeed add a couple of entries
to the default database during setup.
Yes, I am using Debian's Jessie's package. So would it just be easier to not
change the olcSuffix to start with?
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS
established tls_ssf=128 ssf=128
As I understand it, using Kerberos with OpenLDAP already gets you an encrypted transport
- I believe using TLS on top of that is redundant.
Whenever I don't include the TLS portion I get a TLS confidentiality error on the
provider size. I'm assuming this is because of my olcSecurity: tls=128 on the
database.
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth"
mech=GSSAPI sasl_ssf=56 ssf=128
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text=
That looks fine, the GSSAPI bind seems to have succeeded.
So at this point, based on your ACLs above, I'd expect it to be able to read all of
your data (to * by * read), except for the userPassword and shadowLastChange attributes.
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
Odd - I was expecting to see a RESULT line there. Not sure what that means. I guess
something goes wrong on the client and it aborts early?
It would be interesting to see logs from the syncrepl consumer, at loglevel
'sync', when you bring it up with an empty database.
Okay, I'll turn that on and run through the process again.
If you do an ldapsearch against the provider as anonymous, or doing a GSSAPI bind using
that sevice ticket, do you see all the data returned that you expected?
If you want a decent example config to compare your work against, I would suggest
rjsystems' articles:
http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php
http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-consumer.php
It's a little dated, but not too badly. (For example, most or all of the bugs he
mentions have since been fixed; and the hdb backend is deprecated now in favour of mdb.)
I actually used that consumer guide as my main reference. I didn't look at the
provider as setting up the provider is pretty straightforward. I'll take a look at it
to see if I missed any steps.
2:45 a.m.
Am Fri, 28 Oct 2016 21:50:30 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
Greetings all,
I'm trying to figure out why Syncrepl is only syncing part of my
provider's database when I use GSSAPI to connect. Both my provider
and consumer are on 2.4.40. Here are all the steps I'm taking:
My provider is working fine, I've been using it for months now
without any issues. I added this to the provider:
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
structuralObjectClass: olcSyncProvConfig
entryUUID: b32ac160-29e6-1036-8d0a-07ef98fd592e
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20161019012544Z
olcSpSessionlog: 100
entryCSN: 20161024233803.817199Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161024233803Z
I also indexed entryCSN and entryUUID on the provider. I have
olcAuthzRegexp setup on the provider as well.
olcAuthzRegexp: {0}"uid=admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=admin,dc=harmonywave,dc=com" olcAuthzRegexp:
{1}"uid=ldap/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
olcAuthzRegexp:
{2}"uid=syncprov,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=syncprov,dc=harmonywave,dc=com" #not using this. olcAuthzRegexp:
{3}"uid=.*\/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=admin,dc=harmonywave,dc=com" olcAuthzRegexp:
{4}"uid=host\/([^.]*).harmonywave.com,cn=harmonywave.com,cn=GSSAPI,cn=auth"
"cn=$1+ipHostNumber=.*,ou=Hosts,dc=harmonywave,dc=com"
olcAuthzRegexp: {5}"uid=([^/]*),cn=harmonywave.com,cn=GSSAPI,cn=auth"
"uid=$1,ou=End Users,ou=People,dc=harmonywave,dc=com"
On the consumer I have slapd installed. The first thing I did was
change the olcSuffix on my database. I'm not sure if this is required
or not.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=harmonywave,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=harmonywave,dc=com
Then I'm adding my ldap keytab for the consumer.
kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/consumer.harmonywave.com
consumer: ~# chown openldap:openldap /etc/ldap/ldap.keytab
consumer: ~# chmod 0640 /etc/ldap/ldap.keytab
I edited my /etc/default/slapd file and pointed the KRB5_KTNAME
environment variable to the new keytab then restarted slapd. Next I
installed kstart and created a ticket cache.
consumer: ~# k5start -U -f /etc/ldap/ldap.keytab -K 10 -l 24h
-k /tmp/krb5cc_108 -o openldap -b
I can see the ldap service's keytab with klist.
consumer: ~# klist /tmp/krb5cc_108
Ticket cache: FILE:/tmp/krb5cc_108
Default principal: ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM
Valid starting Expires Service principal
10/28/2016 21:18:14 10/29/2016 07:18:14
krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM renew until 10/29/2016 21:18:14
Then I add my olcSaslRealm
dn: cn=config
changetype: modify
add: olcSaslRealm
olcSaslRealm: HARMONYWAVE.COM
Here is what my database looks like right before I add olcSyncrepl:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonym ous auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootPW:: ...
olcDbCheckpoint: 512 30
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 9a091324-2e84-1036-8b7a-73db8891632a
creatorsName: cn=admin,cn=config
createTimestamp: 20161024222607Z
olcSuffix: dc=harmonywave,dc=com
olcRootDN: cn=admin,dc=harmonywave,dc=com
olcDbIndex: cn,uid eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: member,memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: uidNumber,gidNumber eq
entryCSN: 20161029033105.691204Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161029033105Z
then I add olcSyncrepl to the consumer.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=000
provider=ldap://provider.harmonywave.com
type=RefreshAndPersist
retry="30 10 1800 +"
searchbase="dc=harmonywave,dc=com"
bindmethod=sasl
saslmech=GSSAPI
starttls=critical
tls_cacert=/etc/ssl/certs/ca.harmonywave.com.pem
tls_reqcert=demand
After that I slapcat on the consumer and I only see about 1/3 of my
data from the provider. When I watch the log on the provider this is
what I get:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 ACCEPT from
IP=10.1.30.19:55992 (IP=0.0.0.0:389) Oct 28 21:39:02 baneling
slapd[12540]: conn=4421 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 28
21:39:02 baneling slapd[12540]: conn=4421 op=0 STARTTLS Oct 28
21:39:02 baneling slapd[12540]: conn=4421 op=0 RESULT oid= err=0
text= Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS
established tls_ssf=128 ssf=128 Oct 28 21:39:02 baneling
slapd[12540]: conn=1005 op=43768 SRCH base="dc=harmonywave,dc=com"
scope=2 deref=0
filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH
attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey
krbmaxrenewableage krbmaxticketlife krbticketflags
krbprincipalexpiration krbticketpolicyreference krbUpEnabled
krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth
krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange
krbLastAdminUnlock krbExtraData krbObjectReferences
krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]:
conn=1005 op=43768 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct
28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0
filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH
attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey
krbmaxrenewableage krbmaxticketlife krbticketflags
krbprincipalexpiration krbticketpolicyreference krbUpEnabled
krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth
krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange
krbLastAdminUnlock krbExtraData krbObjectReferences
krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]:
conn=1005 op=43769 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct
28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0
filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH
attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey
krbmaxrenewableage krbmaxticketlife krbticketflags
krbprincipalexpiration krbticketpolicyreference krbUpEnabled
krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth
krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange
krbLastAdminUnlock krbExtraData krbObjectReferences
krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]:
conn=1005 op=43770 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct
28 21:39:02 baneling slapd[12540]: conn=4421 op=1 BIND dn=""
method=163 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1
RESULT tag=97 err=14 text=SASL(0): successful result: Oct 28 21:39:02
baneling slapd[12540]: conn=4421 op=2 BIND dn="" method=163 Oct 28
21:39:02 baneling slapd[12540]: conn=4421 op=2 RESULT tag=97 err=14
text=SASL(0): successful result: Oct 28 21:39:02 baneling
slapd[12540]: conn=4421 op=3 BIND dn="" method=163 Oct 28 21:39:02
baneling slapd[12540]: conn=4421 op=3 BIND
authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM" Oct 28
21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth"
mech=GSSAPI sasl_ssf=56 ssf=128 Oct 28 21:39:02 baneling
slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text= Oct 28
21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0
filter="(objectClass=*)"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND Oct 28
21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
The only thing I really notice from this is near the end of the file.
It when it searches the base with attributes "*+", but then
immediately unbinds. I've seen people stating that authzid is
required, but when I don't provide it I still get a partial sync, so
I'm not sure about this. I've restored my consumer to a clean install
of slapd and repeated the above steps with minor variations several
times but the consumer always syncs the exact same amount of data and
then seems to stop.
Any help to point me in the right direction would be appreciated.
Note that there is a hard coded limit to 500 operations. If you have
more than 500 entries, syncrepl only recieves a limited set of entries.
Read slapd-config(5) on limits.
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
12:16 p.m.
On 10/29/2016 03:45 AM, Dieter Klünter wrote:
Note that there is a hard coded limit to 500 operations. If you have
more than 500 entries, syncrepl only recieves a limited set of entries.
Read slapd-config(5) on limits.
-Dieter
I feel this is somewhat contradictory with the admin guide:
"The content of the syncrepl replica is defined using a search specification as its
result set. The consumer slapd will send search requests to the provider slapd according
to the search specification. The search specification
includessearchbase,scope,filter,attrs,attrsonly,sizelimit, andtimelimitparameters as in
the normal search specification. Thesearchbaseparameter has no default value and must
always be specified. Thescopedefaults tosub, thefilterdefaults
to(objectclass=*),attrsdefaults to"*,+"to replicate all user and operational
attributes, andattrsonlyis unset by default. Bothsizelimitandtimelimitdefault to
"unlimited", and only positive integers or "unlimited" may be
specified."
It specifies that the sizelimit and timelimit defaults to unlimited. I understand that you
are pointing out a hard limit on the provider side so it doesn't matter that the
search is unlimited from the consumer's side, it's just a first glance it seems
that the search will be unlimited.
Either way, I change both provider and consumer databases to unlimited and I'm still
not getting all the database entries from my provider.
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=harmonywave,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by self
write by anonymous auth by dn="cn=admin,dc=harmonywave,dc=com" write by *
none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=harmonywave,dc=com
olcRootPW:: e1NTSEF9dUhDcE1jUUJoWlpuc0twRHBNQkVCUGtmTFA5SC9EYUU=
olcDbCheckpoint: 512 30
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: caa04334-6857-1035-9fbb-dd6671002504
creatorsName: cn=admin,cn=config
createTimestamp: 20160215174631Z
olcSecurity: tls=128
olcDbIndex: cn,uid eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: krbPrincipalName eq,pres,sub
olcDbIndex: member,memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: sudoHost eq
olcDbIndex: sudoUser eq
olcDbIndex: uidNumber,gidNumber eq
olcSizeLimit: unlimited
olcTimeLimit: unlimited
entryCSN: 20161029184934.818117Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161029184934Z
2:16 a.m.
Am Sat, 29 Oct 2016 13:16:03 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
On 10/29/2016 03:45 AM, Dieter Klünter wrote:
>
> Note that there is a hard coded limit to 500 operations. If you have
> more than 500 entries, syncrepl only recieves a limited set of
> entries. Read slapd-config(5) on limits.
>
> -Dieter
>
I feel this is somewhat contradictory with the admin guide:
"The content of the syncrepl replica is defined using a search
specification as its result set. The consumer slapd will send search
requests to the provider slapd according to the search specification.
The search specification
includessearchbase,scope,filter,attrs,attrsonly,sizelimit,
andtimelimitparameters as in the normal search specification.
Thesearchbaseparameter has no default value and must always be
specified. Thescopedefaults tosub, thefilterdefaults
to(objectclass=*),attrsdefaults to"*,+"to replicate all user and
operational attributes, andattrsonlyis unset by default.
Bothsizelimitandtimelimitdefault to "unlimited", and only positive
integers or "unlimited" may be specified."
It specifies that the sizelimit and timelimit defaults to unlimited.
I understand that you are pointing out a hard limit on the provider
side so it doesn't matter that the search is unlimited from the
consumer's side, it's just a first glance it seems that the search
will be unlimited.
Either way, I change both provider and consumer databases to
unlimited and I'm still not getting all the database entries from my
provider.
[...]
It is a bit more complicated than that.
syncrepl is a client operation, which requires ldap client
configuration, specified in ldap.conf(5).
The sizelimit and timelimit, configuration parts defined in
slapd.conf(5), are global configuration parameters.
There is a database specific 'limits' parameter, which binds the
defined operation limitation to a Distinguished Name.
You realy should read that manual pages slapd.conf(5) and
slapd-config(5) on databasse limits and syncrepl limits.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
2344
days inactive
2345
days old
openldap-technical@openldap.org
5 comments
3 participants
participants (3)
-
Dieter Klünter -
Joshua Schaeffer -
Ryan Tandy