Hi all,
last week I wrote to the list because I have a problem with overlay chain. Today I traced the problem. The configuration and the host are the same. OpenLDAP syncrepl runs fine over the weekend. But if I want to change a password nothing happens. I can't see any packet with tcpdump from the slave to the master. I traced slapd with loglevel=65535. The slave is openldap 2.4.21.
# Here the trace with no successfull passmod operation: ----------------------------------------------------- conn=1126 op=1 BIND dn="cn=ldapadmin,dc=camelot,dc=de" method=128 do_bind: version=3 dn="cn=ldapadmin,dc=camelot,dc=de" method=128 => bdb_entry_get: ndn: "cn=ldapadmin,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") => bdb_entry_get: found entry: "cn=ldapadmin,dc=camelot,dc=de" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=default,ou=policies,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=default,ou=policies,dc=camelot,dc=de") bdb_entry_get: found entry: "cn=default,ou=policies,dc=camelot,dc=de" bdb_entry_get: rc=0 ==> hdb_bind: dn: cn=ldapadmin,dc=camelot,dc=de bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") )
# Here the trace after I restart slapd with exactly the same config # and working passmod oepration: ------------------------------------------------------------------ conn=1000 op=1 BIND dn="cn=ldapadmin,dc=camelot,dc=de" method=128 do_bind: version=3 dn="cn=ldapadmin,dc=camelot,dc=de" method=128 => bdb_entry_get: ndn: "cn=ldapadmin,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") => hdb_dn2id("cn=ldapadmin,dc=camelot,dc=de") <= hdb_dn2id: got id=0x5 entry_decode: "" <= entry_decode() => bdb_entry_get: found entry: "cn=ldapadmin,dc=camelot,dc=de" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=default,ou=policies,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=default,ou=policies,dc=camelot,dc=de") => hdb_dn2id("ou=policies,dc=camelot,dc=de") <= hdb_dn2id: got id=0x9 => hdb_dn2id("cn=default,ou=policies,dc=camelot,dc=de") <= hdb_dn2id: got id=0xa entry_decode: "" <= entry_decode() => bdb_entry_get: found entry: "cn=default,ou=policies,dc=camelot,dc=de" bdb_entry_get: rc=0 ==> hdb_bind: dn: cn=ldapadmin,dc=camelot,dc=de bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de")
When the passmod operation is successfull there are hdb_dn2id entries in the trace. When the passmod operation ist not successfull the entries doesn't exist. What happens, that I must restart the slapd? The configuration is the same and all other things works fine. Only the write operations to the master hangs. If I make a passmod without TLS everything works fine and I can change the password after I restarted the slapd on the slave. Then I can change the passwords the wholy day. Tomorrow I'll must restart slapd on the slave because the passmod operation is not successfull.
Any ideas?
regards Ralf Zimmermann
--
.''`. Ralf Zimmermann : :' : SIEGNETZ.IT GmbH `. `' Schneppenkauten 1a `- 57076 Siegen
Tel.: +49 271 68193 13 Fax.: +49 271 68193 29
Amtsgericht Siegen HRB4838 Geschaeftsfuehrer: Oliver Seitz Sitz der Gesellschaft ist Siegen
Hi all,
last week I wrote to the list because I have a problem with overlay chain. Today I traced the problem. The configuration and the host are the same. OpenLDAP syncrepl runs fine over the weekend. But if I want to change a password nothing happens. I can't see any packet with tcpdump from the slave to the master. I traced slapd with loglevel=65535. The slave is openldap 2.4.21.
# Here the trace with no successfull passmod operation:
conn=1126 op=1 BIND dn="cn=ldapadmin,dc=camelot,dc=de" method=128 do_bind: version=3 dn="cn=ldapadmin,dc=camelot,dc=de" method=128 => bdb_entry_get: ndn: "cn=ldapadmin,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") => bdb_entry_get: found entry: "cn=ldapadmin,dc=camelot,dc=de" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=default,ou=policies,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=default,ou=policies,dc=camelot,dc=de") bdb_entry_get: found entry: "cn=default,ou=policies,dc=camelot,dc=de" bdb_entry_get: rc=0 ==> hdb_bind: dn: cn=ldapadmin,dc=camelot,dc=de bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") )
# Here the trace after I restart slapd with exactly the same config
# and working passmod oepration:
conn=1000 op=1 BIND dn="cn=ldapadmin,dc=camelot,dc=de" method=128 do_bind: version=3 dn="cn=ldapadmin,dc=camelot,dc=de" method=128 => bdb_entry_get: ndn: "cn=ldapadmin,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") => hdb_dn2id("cn=ldapadmin,dc=camelot,dc=de") <= hdb_dn2id: got id=0x5 entry_decode: "" <= entry_decode() => bdb_entry_get: found entry: "cn=ldapadmin,dc=camelot,dc=de" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=default,ou=policies,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=default,ou=policies,dc=camelot,dc=de") => hdb_dn2id("ou=policies,dc=camelot,dc=de") <= hdb_dn2id: got id=0x9 => hdb_dn2id("cn=default,ou=policies,dc=camelot,dc=de") <= hdb_dn2id: got id=0xa entry_decode: "" <= entry_decode() => bdb_entry_get: found entry: "cn=default,ou=policies,dc=camelot,dc=de" bdb_entry_get: rc=0 ==> hdb_bind: dn: cn=ldapadmin,dc=camelot,dc=de bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de")
When the passmod operation is successfull there are hdb_dn2id entries in the trace. When the passmod operation ist not successfull the entries doesn't exist. What happens, that I must restart the slapd? The configuration is the same and all other things works fine. Only the write operations to the master hangs. If I make a passmod without TLS everything works fine and I can change the password after I restarted the slapd on the slave. Then I can change the passwords the wholy day. Tomorrow I'll must restart slapd on the slave because the passmod operation is not successfull.
Any ideas?
You don't clearly state what your configuration is, so I can only guess. I presume you're using the ppolicy overlay. I set up a syncrepl producer/consumer with slapo-chain on the consumer and slapo-ppolicy on both servers, and I'm hitting the consumer with passmod requests that are chained to the producer, using TLS both client to consumer and in chaining. It seems to be working just fine, I had no failures after hundreds of operations. Would you mind sharing your configuration and an example passmod, in order to reproduce the issue? More details, e.g. about what TLS support you're using, and software versions would be helpful.
p.
Hi,
* masarati@aero.polimi.it masarati@aero.polimi.it [10.04.2010 07:19]:
You don't clearly state what your configuration is, so I can only guess. I presume you're using the ppolicy overlay. I set up a syncrepl producer/consumer with slapo-chain on the consumer and slapo-ppolicy on both servers, and I'm hitting the consumer with passmod requests that are chained to the producer, using TLS both client to consumer and in chaining. It seems to be working just fine, I had no failures after hundreds of operations. Would you mind sharing your configuration and an example passmod, in order to reproduce the issue? More details, e.g. about what TLS support you're using, and software versions would be helpful.
sorry for my uncleary description. The OpenLDAP Master is at time a self-compiled OpenLDAP 2.4.20 on a Sles11. The Slaves have different packages and are different distros. We use Ubuntu, Suse and Debian installations. The effect is always the same. In the morning the first extended passmod operation fails. We can't see a tcp packet on the outgoing interface on the slave. After the first fail all works fine. The whole day. There are working more than 500 User on the Samba Servers without problems. If we restart the slapd before the first extended passmod the operation is successfully. We have checked ntp, dns, routing, firewalls and so on without a result.
We define and undefine idletimeouts, TLSRandFile and so on. But without a result. In the morning before the User are working the first extended passmod over overlay chain and TLS fails. If we disable TLS always works fine.
I would like to know where the problem is. At the first time we searched at the virtual systems but the problem exists also on physical machines.
Here our configure command: --------------------------- ./configure --with-tls --with-cyrus-sasl --enable-overlays --enable-modules \ --enable-rewrite --enable-wrapper --enable-dynamic --enable-ldap
We use openssl support.
Here the OpenLDAP 2.4.20 Master configuration: ---------------------------------------------- include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/samba3.schema include /usr/local/etc/openldap/schema/kerberos.schema include /usr/local/etc/openldap/schema/siegnetz.schema
pidfile /usr/local/var/run/slapd/slapd.pid
argsfile /usr/local/var/run/slapd/slapd.args
#loglevel trace args filter stats parse loglevel sync #loglevel conns
authz-policy all
moduleload back_hdb moduleload accesslog moduleload syncprov moduleload smbk5pwd
sizelimit unlimited idletimeout 300 writetimeout 300
defaultsearchbase dc=camelot,dc=de
TLSCertificateFile /usr/local/etc/openldap/certs/cert.pem TLSCertificateKeyFile /usr/local/etc/openldap/certs/key.pem TLSCACertificateFile /usr/local/etc/openldap/certs/cacert.pem TLSVerifyClient demand
authz-regexp "uid=rzimmermann,cn=gssapi,cn=auth" "cn=ldapadmin,dc=camelot,dc=de" authz-regexp "email=r.zimmermann@siegnetz.de,cn=r.zimmermann@siegnetz.de,ou=EDV,o=Siegnetz,l=Siegen,st=NRW,c=DE" "cn=ldapadmin,dc=camelot,dc=de"
tool-threads 1 threads 16
limits dn.exact="cn=replicator,dc=camelot,dc=de" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=backupadmin,dc=camelot,dc=de" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
<snip> ACLS </snip>
backend hdb database config rootdn cn=config rootpw {SSHA}xxxxxxx security ssf=128
access to dn="olcDatabase={2}hdb,cn=config" attrs=olcReadOnly by ssf=128 dn.exact="cn=backupadmin,dc=camelot,dc=de" write by break
access to dn="olcDatabase={3}hdb,cn=config" attrs=olcReadOnly by ssf=128 dn.exact="cn=backupadmin,dc=camelot,dc=de" write by break
database monitor rootdn "cn=monitoring,cn=monitor" rootpw {SSHA}xxxxxx security ssf=128
database hdb suffix "cn=logs" cachesize 10000 rootdn "cn=logs" rootpw {SSHA}xxxxxx directory /var/lib/ldaplogs/data security ssf=128 dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_data_dir /var/lib/ldaplogs/data dbconfig set_lg_dir /var/lib/ldaplogs/logs dbconfig set_lk_max_objects 2000 dbconfig set_lk_max_locks 2000 dbconfig set_lk_max_lockers 2000 checkpoint 1024 5 index default eq index objectClass,entryCSN,entryUUID eq index reqEnd,reqResult,reqStart,reqMod eq overlay syncprov syncprov-reloadhint TRUE syncprov-nopresent TRUE
database hdb suffix "dc=camelot,dc=de" cachesize 50000 idlcachesize 150000 security ssf=128 rootdn "cn=masteradmin,dc=camelot,dc=de" rootpw {SSHA}xxxxxx directory "/var/lib/ldap/data" dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_data_dir /var/lib/ldap/data dbconfig set_lg_dir /var/lib/ldap/logs dbconfig set_lk_max_objects 2000 dbconfig set_lk_max_locks 2000 dbconfig set_lk_max_lockers 2000 index default eq index objectClass,entryCSN,entryUUID eq index memberUid,gidNumber,displayName,mail,uidNumber,homeDirectory,loginShell,employeeNumber eq index sambaDomainName,sambaPrimaryGroupSID,sambaGroupType,sambaSIDList eq index krbPrincipalName eq index cn,sn,uid pres,eq,approx,sub index sambaSID eq,sub index associatedDomain,rfc822MailMember eq index snitMailQuota,snitMailSizeMax,snitAccountStatus,snitTransportServer,snitDynamicGroupMember eq lastmod on checkpoint 1024 5 overlay accesslog logdb "cn=logs" logsuccess TRUE logops writes logpurge 07+00:00 01+00:00 logold (objectClass=*)
overlay syncprov syncprov-checkpoint 100 1
overlay valsort valsort-attr memberUid dc=camelot,dc=de alpha-ascend valsort-attr member dc=camelot,dc=de alpha-ascend valsort-attr snitGroupMemberMailAddress dc=camelot,dc=de alpha-ascend
overlay dynlist dynlist-attrset groupOfNames labeledURI member
overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=camelot,dc=de"
overlay refint refint_attributes member manager owner seeAlso refint_nothing "cn=dummyuser,dc=camelot,dc=de"
overlay unique unique_uri ldap:///?mail?sub? unique_uri ldap:///?uid?sub? unique_uri ldap:///?uidNumber?sub? unique_uri ldap:///?employeeNumber?sub? unique_uri ldap:///?sambaSID?sub? unique_uri ldap:///?snitPrimaryMailAddress?sub?
overlay smbk5pwd
Here the configuration of a OpenLDAP 2.4.21 Slave(Samba): ---------------------------------------------------------
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/samba3.schema include /usr/local/etc/openldap/schema/kerberos.schema include /usr/local/etc/openldap/schema/siegnetz.schema
referral ldap://master.camelot.de
pidfile /usr/local/var/run/slapd/slapd.pid
argsfile /usr/local/var/run/slapd/slapd.args
authz-policy all
#loglevel sync stats loglevel sync
moduleload back_hdb moduleload accesslog moduleload syncprov moduleload back_ldap moduleload dynlist moduleload ppolicy moduleload unique
sizelimit unlimited
idletimeout 300 writetimeout 300 conn_max_pending 256
defaultsearchbase dc=camelot,dc=de
TLSCertificateFile /usr/local/etc/openldap/certs/cert.pem TLSCertificateKeyFile /usr/local/etc/openldap/certs/key.pem TLSCACertificateFile /usr/local/etc/openldap/certs/cacert.pem TLSVerifyClient demand
tool-threads 2 threads 16
overlay chain chain-uri ldap://master.camelot.de chain-tls start tls_reqcert="demand" tls_cert="/usr/local/etc/openldap/certs/cert.pem" tls_key="/usr/local/etc/openldap/certs/key.pem" tls_cacert="/usr/local/etc/openldap/certs/cacert.pem" chain-idassert-bind bindmethod=simple binddn="cn=sambaadmin,dc=camelot,dc=de" credentials="xxxxxx" mode="self" flags=non-prescriptive chain-rebind-as-user TRUE chain-return-error TRUE chain-conn-ttl 600 chain-idle-timeout 300 chain-protocol-version 3
limits dn.exact="cn=replicator,dc=camelot,dc=de" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=sambaadmin,dc=camelot,dc=de" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
<snip> ACLS </snip>
backend hdb database monitor rootdn "cn=monitoring,cn=monitor" rootpw {SSHA}xxxxxx security ssf=128
database config rootdn cn=config rootpw {SSHA}xxxxxx security ssf=128
database hdb suffix "dc=camelot,dc=de" cachesize 50000 idlcachesize 150000 security ssf=128 rootdn "cn=masteradmin,dc=camelot,dc=de" rootpw {SSHA}xxxxxxx directory /var/lib/ldap/data readonly FALSE checkpoint 1024 5 dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_data_dir /var/lib/ldap/data dbconfig set_lg_dir /var/lib/ldap/logs dbconfig set_lk_max_objects 2000 dbconfig set_lk_max_locks 2000 dbconfig set_lk_max_lockers 2000 dbConfig set_flags DB_LOG_AUTOREMOVE index default eq index objectClass,entryCSN,entryUUID eq index memberUid,gidNumber,uidNumber,mail,homeDirectory,loginShell,displayName,employeeNumber eq index sambaDomainName,sambaGroupType,sambaSIDList,sambaPrimaryGroupSID eq index sambaSID eq,sub index krbPrincipalName eq index cn,sn,uid pres,eq,approx,sub index associatedDomain,rfc822MailMember eq index snitMailQuota,snitMailSizeMax,snitAccountStatus,snitTransportServer eq index snitPrimaryMailAddress,snitRecipientRestrictedMailAddress,snitSenderRestrictedMailAddress,snitDynamicGroupMember eq syncrepl rid=001 provider=ldap://master.camelot.de uri=ldap://master.camelot.de searchbase="dc=camelot,dc=de" type=refreshandpersist interval=00:00:00:10 retry="10 6 30 6 60 +" bindmethod=simple binddn="cn=replicator,dc=camelot,dc=de" credentials="xxxxxx" schemachecking=on attrs="*,+" filter="(objectClass=*)" scope=sub logbase="cn=logs" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog starttls=critical tls_cert=/usr/local/etc/openldap/certs/cert.pem tls_key=/usr/local/etc/openldap/certs/key.pem tls_cacert=/usr/local/etc/openldap/certs/cacert.pem updateref ldap://master.camelot.de
overlay valsort valsort-attr memberUid dc=camelot,dc=de alpha-ascend valsort-attr member dc=camelot,dc=de alpha-ascend valsort-attr snitGroupMemberMailAddress dc=camelot,dc=de alpha-ascend
overlay dynlist dynlist-attrset groupOfNames labeledURI member
overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=camelot,dc=de"
Regards Ralf Zimmermann
--
.''`. Ralf Zimmermann : :' : SIEGNETZ.IT GmbH `. `' Schneppenkauten 1a `- 57076 Siegen
Tel.: +49 271 68193 13 Fax.: +49 271 68193 29
Amtsgericht Siegen HRB4838 Geschaeftsfuehrer: Oliver Seitz Sitz der Gesellschaft ist Siegen
openldap-technical@openldap.org
-
masarati＠aero.polimi.it -
Ralf Zimmermann