authentication problem
Hi I use openldap to do authentication on RHEL 6 machines. The problem I'm having is that 2 users doesn't get authenticated. When I do a getent passwd for these users it is as if they doesn't exist but a ldapsearch -x shows them. I would appreciate it if someone can point me int the right direction. attachment: chris.vcf
Re: PAM authentication and PPolicy issues
2012/6/19 Francesco Belli francesco.be...@vegaspace.com: Hi Everybody, I'm have some RHEL6 machines that use an LDAP server to authenticate. I need to introduce in the server some checks on passwords using PPolicy. PPolicy works fine, the problem is that to use pwdCheckQuality and pwdInHistory I need to save passwords in clear text in the LDAP server. I did a search to find out if there is a way to let PAM to use clear text password to authenticate but it seems that it sends SHA hashes, so authentication fails. Do you have any suggestion? Do man pam_ldap and search for pam_password parameter. Clément.
Re: authentication problem
having is that 2 users doesn't get authenticated. When I do a getent passwd for these users it is as if they doesn't exist but a ldapsearch -x shows them. Sounds as though an attribute type is missing from the users' entries; are they of objectClass `posixAccount' ? Maybe show us the LDIF of one of the bad entries? -JP
Re: PAM authentication and PPolicy issues
2012/6/20 Francesco Belli francesco.be...@vegaspace.com: Hi Clement, I already used pam_password directive, I set it to cleartext, but this parameter is used for password change and not for authentication. As man pam_ldap says Specifies the password change protocol to use, so not the authentication method. Now my situation is that I have some users in the LDAP server that they have a SHA hash in the userPassword field, and they are correctly authenticated, others that have a clear text password and cannot be authenticated via PAM. Password scheme used in LDAP directory do not prevent any application to authenticate to LDAP. Dig into logs to see what is the real reason of your problem. Clément.
Re: authentication problem
On 20/06/2012 09:55, Jan-Piet Mens wrote:
having is that 2 users doesn't get authenticated. When I do a getent
passwd for these users it is as if they doesn't exist but a ldapsearch
-x shows them.
Sounds as though an attribute type is missing from the users' entries;
are they of objectClass `posixAccount' ? Maybe show us the LDIF of one
of the bad entries?
-JP
The LDIF for these users looks exactly ass all the other users.
dn: uid=izak,ou=People,dc=flamengro,dc=com
uid: izak
cn: Izak Veldsman
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}Something
shadowLastChange: 15264
shadowMin: 0
shadowMax: 9
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 504
gidNumber: 100
homeDirectory: /home/izak
gecos: Izak Veldsman
dn: uid=bertus,ou=People,dc=flamengro,dc=com
uid: bertus
cn: Bertus Smit
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}Something
shadowLastChange: 15260
shadowMin: 0
shadowMax: 9
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 100
homeDirectory: /home/bertus
gecos: Bertus Smit
What happens when I run getent passwd on the server .
getent passwd izak
izak:*:504:100:Izak Veldsman:/home/izak:/bin/bash
getent passwd bertus
bertus:*:500:100:Bertus Smit:/home/bertus:/bin/bash
On one client nothing for these specific users, the other users work fine.
attachment: chris.vcf
Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle
On Sat, Jun 16, 2012 at 02:31:31PM -0400, Patrick Hemmer wrote: Server certs are used by the client to verify the remote server is who it says it is. Client certs are used by the server to verify the client is allowed to talk to it. There is a very big difference between the two. The server doesnt care one bit if the CN of a client cert doesnt match the reverse DNS lookup of the IP the connection came from. All it cares is that the cert presented by the client is signed by a recognized CA. As such if you dont restrict the CAs that OpenLDAP will recognize for client certificates, any john-doe server with a certificate could connect (at which point client certs become useless). There is a good point here, and I think it may require some new config items to address it. Slapd needs to know about at least three CAs. In many cases they are the same actual CA, but the functions of each are distinct: 1) The CA that signed slapd's own server certificate. The CA certificate for this one should be supplied to clients as part of the TLS setup. 2) The CA that signed the server certificate of any replication supplier, so that TLS connections to that supplier can be verified. 3) The CA that signed the authentication certificates used by clients when they make ldap connections to slapd. This is used to verify the client certificates. At present, (1) and (3) are both configured using TLSCACertificateFile or TLSCACertificatePath. (2) is configured in the syncrepl clause, with fallback to ldap.conf or by setting the LDAPTLS_CACERT environment variable when starting slapd, as in this case slapd is acting as a client. The issue of CA *chains* is separate, and in all cases above it should be valid to use a file containing however many certificates there are in the chain. I think we need a way to configure each of the 3 cases separately. Case (1) is adequately covered by the existing config variables. Case (2) is covered by the tls_cacert options in the syncrepl clause, which allows for the possibility of each remote supplier having a certificate signed by a different CA. Case (3) seems to need new config items. Looking at the TLS section of slapd.conf(5) I think it would be necessary to duplicate all the TLS* items as TLSClient* items (except for TLSVerifyClient itself, which should perhaps be renamed as TLSClientVerify to fit the naming scheme) Comments? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: authentication problem
On one client nothing for these specific users, the other users work fine. Have you compared whether `ldap.conf' used by NSS for the two clients are identical? Is there some special filter configured in one of them? -JP
RE: Binding to openldap fails
Hello together, Just to stay updated. I tried to connect using the distinguished name cn=username,ou=Users,dc=domain,dc=my . I have changed the DN to uid=username,ou=Users,dc=domain,dc=my and login works. Yet I am confused because I have set index on cn as well as uid attribute (or is uid not an attribute but an element)? Below is an ldif of the user bjoern # bjoern, Users, domain.my dn: uid=bjoern,ou=Users,dc=domain,dc=my objectClass: account objectClass: posixAccount objectClass: sambaSamAccount cn: bjoern uid: bjoern uidNumber: some number homeDirectory: some path loginShell: /bin/bash gecos: bjoern description: User account sambaSID: some SID displayName: bjoern sambaNTPassword: some hash sambaPasswordHistory: sambaPwdLastSet: 1338641123 sambaAcctFlags: [U ] gidNumber: some group id userPassword:: some password Thank you for your support. Bjoern -Original Message- From: openldap-technical-boun...@openldap.org [mailto:openldap- technical-boun...@openldap.org] On Behalf Of Bjoern Wuest Sent: Monday, June 18, 2012 10:14 AM To: openldap-technical@openldap.org Subject: RE: Binding to openldap fails On Sun, 17 Jun 2012, Bjoern Wuest wrote: ... However, setting up the mail system (dovecot + postfix) I encountered a problem new to me. When I try to bind as a normal user (here: bjoern) to LDAP it fails with wrong credentials. I can assure that I did not mistyped the password (tried multiple times). Login to the Linux system and samba with same credentials (i.e. bjoern and his password) works. Here is the part of syslog I expect to be the cause: Jun 17 19:36:45 server slapd[23241]: dnPrettyNormal: cn=bjoern,ou=Users,dc=domain,dc=my, cn=bjoern,ou=users,dc=domain,dc=my Jun 17 19:36:45 server slapd[23241]: conn=1003 op=0 BIND dn=cn=bjoern,ou=Users,dc=domain,dc=my method=128 Jun 17 19:36:45 server slapd[23241]: do_bind: version=3 dn=cn=bjoern,ou=Users,dc=domain,dc=my method=128 Jun 17 19:36:45 server slapd[23241]: Jun 17 19:36:45 server slapd[23241]: == hdb_bind: dn: cn=bjoern,ou=Users,dc=domain,dc=my Jun 17 19:36:45 server slapd[23241]: bdb_dn2entry(cn=bjoern,ou=users,dc=domain,dc=my) Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: = hdb_dn2id(cn=bjoern,ou=users,dc=domain,dc=my) Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=9 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=10 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=11 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: = hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30987) In my experience, that sort of error from the DB library usually means a change to the indexing or schema was made without reindexing and/or dumping and reloading. If you're confident that's not the case here (how confident?), then have you compared that log output to the log output of a successful login? Philip Guenther Dear Philip, thank you for pointing me to the index files. I have recreated all the indexes but without effect. Here are the indexes I have defined: index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index sambaGroupType eq index sambaSIDList eq index default sub and here are the index files created: -rw-rw 1 openldap openldap16384 Jun 18 10:01 cn.bdb -rw-rw 1 openldap openldap24576 Jun 18 10:01 __db.001 -rw-rw 1 openldap openldap 1236992 Jun 18 10:01 __db.002 -rw-rw 1 openldap openldap 20979712 Jun 18 10:01 __db.003 -rw-rw 1 openldap openldap 163840 Jun 18 10:01 __db.004 -rw-rw 1 openldap openldap 1294336 Jun 18 10:01 __db.005 -rw-rw 1 openldap openldap32768 Jun 18 10:01 __db.006 -rw-rw 1 openldap openldap 194 Mai 20 08:55 DB_CONFIG -rw-rw 1 openldap openldap16384 Jun 18 10:01 displayName.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:00 dn2id.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:01 gidNumber.bdb -rw-rw 1 openldap openldap32768 Jun 18 10:00 id2entry.bdb -rw-rw 1 openldap openldap 10485760 Jun 18 10:01 log.01 -rw-rw 1 openldap openldap 8192 Jun 18 10:01 memberUid.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:01 objectClass.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:01 sambaDomainName.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:01
Re: Replication and acl: moddn operation problem.
On 05/29/2012 07:25 PM, Nick Milas wrote: On 29/5/2012 9:01 Ïμ, Konstantin Menshikov wrote: somebody? anybody? I would say: if you can use test servers with 2.4.31 and BDB = 4.6.21, then you could try to reproduce by doing some experiments (moving to branch visible by consumer binddn, moving to branch not visible by consumer) and report results with excerpts from the logs. Nick Hi. I try use openldap-server-2.4.31 and db47-4.7.25.4 on FreeBSD 8.2-RELEASE-p4. Configufation master and slave attached. Log fragments also attached. I try full replication of o=company, but with the help ACL limit access of replication binddn only ou=dev,o=company branch. Testing plan: move cn=cacti,ou=groups,ou=corp,o=company to cn=cacti,ou=groups,ou=dev,o=company. move group back from dev to corp. Result: moving to visible branch (dev): ok. moving from visible branch to unvisible: error, cn=cacti,ou=groups,ou=dev,o=company still exist on slave! You wrote: My tests (with v2.4.31 on both provider and consumer) show that syncrepl (refreshAndPersist) works correctly when replicating based on ACL restrictions. OpenLDAP consumer deletes correctly an entry from a branch when the entry is moved to another, invisible by the consumer binddn, branch, and it re-creates it correctly when it is moved back to a visible (based on ACL) branch. Please, show your replication setup at which it works correctly. I fount, that if to add ACL #access to dn.subtree=o=company attrs=entry # by dn.exact=uid=replica,ou=users,o=company read moving to unvisible branch working correctly! That side effect can be? What level of access allows this ACL? -- Konstantin Menshikov ee slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/corba.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/sudo.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/spamassassin.schema include /usr/local/etc/openldap/schema/openssh-lpk.schema include /usr/local/etc/openldap/schema/asterisk.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile/var/run/openldap/slapd.args loglevelsync stats # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_hdb #moduleload back_ldap #moduleload back_perl sizelimit 5000 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base= by * read # access to dn.base=cn=Subschema by * read access to dn.subtree=ou=users,o=company attrs=userPassword by anonymous auth access to dn.base=o=company by dn.exact=uid=replica,ou=users,o=company read access to dn.subtree=ou=dev,o=company by dn.exact=uid=replica,ou=users,o=company read #access to dn.subtree=o=company attrs=entry # by dn.exact=uid=replica,ou=users,o=company read #access to dn= by * read #access to dn=cn=Subschema by * read # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., access to * by * read) # # rootdn can always read and write EVERYTHING! # Enable TLS TLSCACertificatePath /etc/ssl/certs TLSCertificateFile /etc/ssl/certs/ro.devel.ldap.hostcomm.ru.crt TLSCertificateKeyFile /etc/ssl/private/ro.devel.ldap.hostcomm.ru.key # Here, ssf=128 tells OpenLDAP to require 128-bit encryption for all connections, both search and update. security ssf=128 require bind LDAPv3 ### # BDB database definitions ### databasehdb suffix o=company rootdn cn=ldapadm,o=company rootpw password directory /var/db/openldap-data/o=company overlay syncprov index mailLocalAddress pres,eq index
Re: Binding to openldap fails
Hi, Your *RDN *for that object is *uid=bjoern,ou=Users,dc=domain,dc=my*, which is single valued. Either configure dovecot use uid attribute as username and not cn, either change the RDN to cn=bjoern... or look into multiple values RDNs. Use this a reference: http://www.zytrax.com/books/ldap/apa/dn-rdn.html Regards, Andrei On 20.06.2012 14:31, Bjoern Wuest wrote: Hello together, Just to stay updated. I tried to connect using the distinguished name cn=username,ou=Users,dc=domain,dc=my . I have changed the DN to uid=username,ou=Users,dc=domain,dc=my and login works. Yet I am confused because I have set index on cn as well as uid attribute (or is uid not an attribute but an element)? Below is an ldif of the user bjoern # bjoern, Users, domain.my dn: uid=bjoern,ou=Users,dc=domain,dc=my objectClass: account objectClass: posixAccount objectClass: sambaSamAccount cn: bjoern uid: bjoern uidNumber: some number homeDirectory: some path loginShell: /bin/bash gecos: bjoern description: User account sambaSID: some SID displayName: bjoern sambaNTPassword: some hash sambaPasswordHistory: sambaPwdLastSet: 1338641123 sambaAcctFlags: [U ] gidNumber: some group id userPassword:: some password Thank you for your support. Bjoern -Original Message- From: openldap-technical-boun...@openldap.org [mailto:openldap- technical-boun...@openldap.org] On Behalf Of Bjoern Wuest Sent: Monday, June 18, 2012 10:14 AM To: openldap-technical@openldap.org Subject: RE: Binding to openldap fails On Sun, 17 Jun 2012, Bjoern Wuest wrote: ... However, setting up the mail system (dovecot + postfix) I encountered a problem new to me. When I try to bind as a normal user (here: bjoern) to LDAP it fails with wrong credentials. I can assure that I did not mistyped the password (tried multiple times). Login to the Linux system and samba with same credentials (i.e. bjoern and his password) works. Here is the part of syslog I expect to be the cause: Jun 17 19:36:45 server slapd[23241]: dnPrettyNormal: cn=bjoern,ou=Users,dc=domain,dc=my, cn=bjoern,ou=users,dc=domain,dc=my Jun 17 19:36:45 server slapd[23241]: conn=1003 op=0 BIND dn=cn=bjoern,ou=Users,dc=domain,dc=my method=128 Jun 17 19:36:45 server slapd[23241]: do_bind: version=3 dn=cn=bjoern,ou=Users,dc=domain,dc=my method=128 Jun 17 19:36:45 server slapd[23241]: Jun 17 19:36:45 server slapd[23241]: == hdb_bind: dn: cn=bjoern,ou=Users,dc=domain,dc=my Jun 17 19:36:45 server slapd[23241]: bdb_dn2entry(cn=bjoern,ou=users,dc=domain,dc=my) Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: = hdb_dn2id(cn=bjoern,ou=users,dc=domain,dc=my) Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=9 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=10 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: daemon: epoll: listen=11 active_threads=0 tvp=zero Jun 17 19:36:45 server slapd[23241]: = hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30987) In my experience, that sort of error from the DB library usually means a change to the indexing or schema was made without reindexing and/or dumping and reloading. If you're confident that's not the case here (how confident?), then have you compared that log output to the log output of a successful login? Philip Guenther Dear Philip, thank you for pointing me to the index files. I have recreated all the indexes but without effect. Here are the indexes I have defined: index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index sambaGroupType eq index sambaSIDList eq index default sub and here are the index files created: -rw-rw 1 openldap openldap16384 Jun 18 10:01 cn.bdb -rw-rw 1 openldap openldap24576 Jun 18 10:01 __db.001 -rw-rw 1 openldap openldap 1236992 Jun 18 10:01 __db.002 -rw-rw 1 openldap openldap 20979712 Jun 18 10:01 __db.003 -rw-rw 1 openldap openldap 163840 Jun 18 10:01 __db.004 -rw-rw 1 openldap openldap 1294336 Jun 18 10:01 __db.005 -rw-rw 1 openldap openldap32768 Jun 18 10:01 __db.006 -rw-rw 1 openldap openldap 194 Mai 20 08:55 DB_CONFIG -rw-rw 1 openldap openldap16384 Jun 18 10:01 displayName.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:00 dn2id.bdb -rw-rw 1 openldap openldap 8192 Jun 18 10:01 gidNumber.bdb -rw-rw 1 openldap openldap32768 Jun 18 10:00 id2entry.bdb -rw-rw 1 openldap openldap 10485760 Jun 18 10:01 log.01 -rw-rw 1 openldap openldap 8192 Jun 18
Sun(oracle) directory server to openldap
Hi I wonder if someone has already migrated from a Sun DSEE to openldap and establishment of a replication from SUN DSEE to openldap. thanks in advance Regards -- *Stanislas LEVEAU** *Rectorat de Caen 168, rue Caponière B.P. 6184 14061 CAEN Cedex Direction des Systèmes d'Information de l'Académie de Caen Département des infrastructures stanislas.lev...@ac-caen.fr Tel : 02.31.30.17.86
Re: Sun(oracle) directory server to openldap
Hi Stanislas, Sun DSEE replication protocol is proprietary and thus interoperating with any other LDAP directory server. I'm sure there are several people who have migrated from Sun DSEE to OpenLDAP (and the biggest hurdles are schema and aci) , although in my part of the industry I hear more about those who migrate to OpenDJ (initially started by Sun as OpenDS to replace Sun DSEE). Cordialement, Ludovic -- Ludovic Poitou ForgeRock - Product Manager for OpenDJ. http://forgerock.com http://ludopoitou.wordpress.com On Wednesday, June 20, 2012 at 14:45 , Stanislas LEVEAU wrote: Hi I wonder if someone has already migrated from a Sun DSEE to openldap and establishment of a replication from SUN DSEE to openldap. thanks in advance Regards -- Stanislas LEVEAU Stanislas LEVEAU Rectorat de Caen 168, rue Caponière B.P. 6184 14061 CAEN Cedex Direction des Systèmes d'Information de l'Académie de Caen Département des infrastructures stanislas.lev...@ac-caen.fr (mailto:stanislas.lev...@ac-caen.fr) Tel : 02.31.30.17.86
Re: PAM authentication and PPolicy issues
Sent: Wed Jun 20 2012 04:36:03 GMT-0400 (EDT) From: Clément OUDOT clem.ou...@gmail.com To: Francesco Belli francesco.be...@vegaspace.com openldap-technical@openldap.org Subject: Re: PAM authentication and PPolicy issues 2012/6/20 Francesco Bellifrancesco.be...@vegaspace.com: Hi Clement, I already used pam_password directive, I set it to cleartext, but this parameter is used for password change and not for authentication. As man pam_ldap says Specifies the password change protocol to use, so not the authentication method. Now my situation is that I have some users in the LDAP server that they have a SHA hash in the userPassword field, and they are correctly authenticated, others that have a clear text password and cannot be authenticated via PAM. Password scheme used in LDAP directory do not prevent any application to authenticate to LDAP. Dig into logs to see what is the real reason of your problem. Clément. In addition, it is not true that the password must be stored in cleartext for pwdCheckQuality and pwdInHistory to work. Storing passwords in cleartext is bad. -Patrick
Re: Sun(oracle) directory server to openldap
Hi Ludovic Thanks for your answer but in my architecture, openldap already exist and i'm obliged to work with . regards Stan Le 20/06/2012 15:07, Ludovic Poitou a écrit : Hi Stanislas, Sun DSEE replication protocol is proprietary and thus interoperating with any other LDAP directory server. I'm sure there are several people who have migrated from Sun DSEE to OpenLDAP (and the biggest hurdles are schema and aci) , although in my part of the industry I hear more about those who migrate to OpenDJ (initially started by Sun as OpenDS to replace Sun DSEE). Cordialement, Ludovic -- Ludovic Poitou ForgeRock - Product Manager for OpenDJ. http://forgerock.com http://ludopoitou.wordpress.com On Wednesday, June 20, 2012 at 14:45 , Stanislas LEVEAU wrote: Hi I wonder if someone has already migrated from a Sun DSEE to openldap and establishment of a replication from SUN DSEE to openldap. thanks in advance Regards -- *Stanislas LEVEAU** *Rectorat de Caen 168, rue Caponière B.P. 6184 14061 CAEN Cedex Direction des Systèmes d'Information de l'Académie de Caen Département des infrastructures stanislas.lev...@ac-caen.fr mailto:stanislas.lev...@ac-caen.fr Tel : 02.31.30.17.86 -- *Stanislas LEVEAU** *Rectorat de Caen 168, rue Caponière B.P. 6184 14061 CAEN Cedex Direction des Systèmes d'Information de l'Académie de Caen Département des infrastructures stanislas.lev...@ac-caen.fr Tel : 02.31.30.17.86
Re: PAM authentication and PPolicy issues
2012/6/20 Patrick Hemmer openl...@stormcloud9.net: Sent: Wed Jun 20 2012 04:36:03 GMT-0400 (EDT) From: Clément OUDOT clem.ou...@gmail.com To: Francesco Belli francesco.be...@vegaspace.com openldap-technical@openldap.org Subject: Re: PAM authentication and PPolicy issues 2012/6/20 Francesco Belli francesco.be...@vegaspace.com: Hi Clement, I already used pam_password directive, I set it to cleartext, but this parameter is used for password change and not for authentication. As man pam_ldap says Specifies the password change protocol to use, so not the authentication method. Now my situation is that I have some users in the LDAP server that they have a SHA hash in the userPassword field, and they are correctly authenticated, others that have a clear text password and cannot be authenticated via PAM. Password scheme used in LDAP directory do not prevent any application to authenticate to LDAP. Dig into logs to see what is the real reason of your problem. Clément. In addition, it is not true that the password must be stored in cleartext for pwdCheckQuality and pwdInHistory to work. Storing passwords in cleartext is bad. They can be stored hashed, but they must be sent as clear text in the modification operation so that OpenLDAP can check the quality (min size for example). The ppolicy overlay is then able to hash them when storing accepted password in database. Clément.
RE: PAM authentication and PPolicy issues
Sorry Patric, Maybe the reference that I have is wrong, I'm using the book Mastering OpenLDAP by Matt Butcher that in chapter 6 at pag 323 says if you store password in plain text in the directory then the policy overlay can be configured to maintain a password history. Now I'm using http://www.openldap.org/software/man.cgi?query=slapo-ppolicyapropos=0sektion=5manpath=OpenLDAP+2.3-Releaseformat=html as reference for ppolicy. My authentication error was a trivial problem on an objectClass: posixAccount. Now I'm testing with SHA stored passwords the pwdInHistory directive. Thanks for the suggestions, Regards Francesco From: openldap-technical-boun...@openldap.org [mailto:openldap-technical-boun...@openldap.org] On Behalf Of Patrick Hemmer Sent: 20 June 2012 14:17 To: openldap-technical@openldap.org Subject: Re: PAM authentication and PPolicy issues Sent: Wed Jun 20 2012 04:36:03 GMT-0400 (EDT) From: Clément OUDOT clem.ou...@gmail.commailto:clem.ou...@gmail.com To: Francesco Belli francesco.be...@vegaspace.commailto:francesco.be...@vegaspace.com openldap-technical@openldap.orgmailto:openldap-technical@openldap.org Subject: Re: PAM authentication and PPolicy issues 2012/6/20 Francesco Belli francesco.be...@vegaspace.commailto:francesco.be...@vegaspace.com: Hi Clement, I already used pam_password directive, I set it to cleartext, but this parameter is used for password change and not for authentication. As man pam_ldap says Specifies the password change protocol to use, so not the authentication method. Now my situation is that I have some users in the LDAP server that they have a SHA hash in the userPassword field, and they are correctly authenticated, others that have a clear text password and cannot be authenticated via PAM. Password scheme used in LDAP directory do not prevent any application to authenticate to LDAP. Dig into logs to see what is the real reason of your problem. Clément. In addition, it is not true that the password must be stored in cleartext for pwdCheckQuality and pwdInHistory to work. Storing passwords in cleartext is bad. -Patrick
Re: ACLs being ignored with rwm/relay
On 6/20/12 1:08 PM, Tim Watts wrote: Hi, Sorry - can't figure this out - would welcome any ideas :) Think of your rootdn as God, ACLs do not apply. Even if they did, write access implies read (iirc) signature.asc Description: OpenPGP digital signature
Re: ACLs being ignored with rwm/relay
--On Wednesday, June 20, 2012 6:08 PM +0100 Tim Watts t...@dionic.net wrote: Hi, Sorry - can't figure this out - would welcome any ideas :) The slapd.conf below contains an ACL: Your ACLs are only set in the HDB backend section. Have you tried adding ACLs to the relay DB? --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
Re: Sun(oracle) directory server to openldap
Clément OUDOT wrote: 2012/6/20 Stanislas LEVEAU stanislas.lev...@ac-caen.fr mailto:stanislas.lev...@ac-caen.fr Hi I wonder if someone has already migrated from a Sun DSEE to openldap and establishment of a replication from SUN DSEE to openldap. Hi, we have done a lot of migration ot this kind. We published some documentation about it: http://www.linid.org/projects/openldap-manager/wiki/MigrationSunOracle You have to study the data, the schema, the plugins... As said by Ludovic, you will not be able to use the built-in synchronization mechanism, but you can use LSC project to synchronize some data. Pretty sure that LSC would be the easiest route at the moment. There are stubs in the syncrepl consumer code for replicating from a SunDS style retro changelog, but that code was left incomplete due to lack of demand/interest. As I recall, it could only operate in polling mode (i.e. refreshOnly) but it's been a while since I looked at that aspect. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: ACLs being ignored with rwm/relay
--On Wednesday, June 20, 2012 1:20 PM -0400 Frank Swasey frank.swa...@uvm.edu wrote: On 6/20/12 1:08 PM, Tim Watts wrote: Hi, Sorry - can't figure this out - would welcome any ideas :) Think of your rootdn as God, ACLs do not apply. Even if they did, write access implies read (iirc) I think his search example was bad. He said he was unauthed. :P --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
Re: ACLs being ignored with rwm/relay
On 20/06/12 18:21, Quanah Gibson-Mount wrote: --On Wednesday, June 20, 2012 6:08 PM +0100 Tim Watts t...@dionic.net wrote: Hi, Sorry - can't figure this out - would welcome any ideas :) The slapd.conf below contains an ACL: Your ACLs are only set in the HDB backend section. Have you tried adding ACLs to the relay DB? Hi Quanah, I was thinking it might be something like that - but I could not work out the scope of the ACLs - they looked global to me. So do I have to duplicate the ACLs just after the database relay section? ## # Virtual maps # # map ou=staff,dc=cch to dc=dighum # databaserelay suffix ou=staff,dc=cch,dc=kcl,dc=ac,dc=uk relay dc=dighum,dc=kcl,dc=ac,dc=uk overlay rwm rwm-suffixmassage dc=dighum,dc=kcl,dc=ac,dc=uk ACL section duplicated ### If so, that makes sense - my bad for assuming the ACL section was a global section by itself... Cheers Tim -- Tim Watts Personal Blog: http://www.dionic.net/tim/
Re: ACLs being ignored with rwm/relay
--On Wednesday, June 20, 2012 7:08 PM +0100 Tim Watts t...@dionic.net wrote: On 20/06/12 18:21, Quanah Gibson-Mount wrote: --On Wednesday, June 20, 2012 6:08 PM +0100 Tim Watts t...@dionic.net wrote: Hi, Sorry - can't figure this out - would welcome any ideas :) The slapd.conf below contains an ACL: Your ACLs are only set in the HDB backend section. Have you tried adding ACLs to the relay DB? Hi Quanah, I was thinking it might be something like that - but I could not work out the scope of the ACLs - they looked global to me. So do I have to duplicate the ACLs just after the database relay section? Correct. ACLs are only global if they appear before any backend database definitions. --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
Re: Uniqueness constraint over multiple attributes
On 06/20/2012 06:43 PM, Michael Ströder wrote: Jan Beerden wrote: Is there a way to have a unique constraint over multiple attributes? We have different attributes for the primary email address of a person, and for additional aliases, and we'd like to enforce global uniqueness in such a way that the primary email address for one person can not be used as an email alias for another person. The slapo-unique manpage doesn't make this very clear. You can simply specify multiple attrs. Example for old syntax: unique_attributes uid uidNumber Based on LDAP URLs: unique_uri ldap:///o=myorg?uid,uidNumber?sub?(objectClass=*) IIRC there's a bug with filters in unique_uri. Ciao, Michael. We already tried that. We are trying to prevent user1 to have an email alias that is the same as user2's primary email address. With this it only make sure that an email address can exist only once in the email attribute and that an alias can exist only once in the alias attribute. What we would like is that a certain value (email address) has to be unique across both the email and the alias attribute. Regards Jan Beerden jan.beer...@fks.be fks bvba - Formal and Knowledge Systems http://www.fks.be/ Schampbergstraat 32 Tel: ++32-(0)11-21 49 11 B-3511 Kuringen Fax: ++32-(0)11-22 04 19
Re: Uniqueness constraint over multiple attributes
Jan, please follow-up on the mailing list (Cc:-ed) so others can answer and learn as well. Jan Beerden wrote: We already tried that. We are trying to prevent user1 to have an email alias that is the same as user2's primary email address. [..] What we would like is that a certain value (email address) has to be unique across both the email and the alias attribute. Uniqueness is only per attribute. So this is not possible. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: ACLs being ignored with rwm/relay
On 20/06/12 19:20, Quanah Gibson-Mount wrote: --On Wednesday, June 20, 2012 7:08 PM +0100 Tim Watts t...@dionic.net wrote: On 20/06/12 18:21, Quanah Gibson-Mount wrote: --On Wednesday, June 20, 2012 6:08 PM +0100 Tim Watts t...@dionic.net wrote: Hi, Sorry - can't figure this out - would welcome any ideas :) The slapd.conf below contains an ACL: Your ACLs are only set in the HDB backend section. Have you tried adding ACLs to the relay DB? Hi Quanah, I was thinking it might be something like that - but I could not work out the scope of the ACLs - they looked global to me. So do I have to duplicate the ACLs just after the database relay section? Correct. ACLs are only global if they appear before any backend database definitions. Awesome! - Thanks for that explanation... As it happens, I would like some global ACLs and maybe a minor override for the relay section. I'll try some of that out on my test server :) Cheers! Tim -- Tim Watts Personal Blog: http://www.dionic.net/tim/
Re: Uniqueness constraint over multiple attributes
On Wed, Jun 20, 2012 at 06:43:22PM +0200, Michael Ströder wrote: Jan Beerden wrote: Is there a way to have a unique constraint over multiple attributes? We have different attributes for the primary email address of a person, and for additional aliases, and we'd like to enforce global uniqueness in such a way that the primary email address for one person can not be used as an email alias for another person. The slapo-unique manpage doesn't make this very clear. You can simply specify multiple attrs. unique_uri ldap:///o=myorg?uid,uidNumber?sub?(objectClass=*) That will not have the effect that is required in this case. Each attribute listed in the unique_uri is enforced separately, so in the example above, all uid values would be unique, and all uidNumber values would be unique, but it would be quite possible to have a uid in one entry the same as the uidNumber in a different one. To achieve what Jan wants, I would consider requiring the primary email address to also be listed as one of the aliases. A uniqueness constraint like this would then protect against one entry hijacking the address of another: overlay unique unique_uri ldap:///o=myorg?primaryMail,aliasMail?sub?(objectClass=mailUser) The requirement for the primaryMail value to also appear as an aliasMail value could be enforced using the constraint overlay with the 'set' mechanism, something like: overlay constraint constraint_attribute primaryMail,aliasMail set this/primaryMail this/aliasMail restrict=ldap:///o=myorg??sub?(objectClass=mailUser) Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: authentication problem
On Wed, Jun 20, 2012 at 11:08:27AM +0200, Chris wrote: What happens when I run getent passwd on the server . getent passwd izak izak:*:504:100:Izak Veldsman:/home/izak:/bin/bash getent passwd bertus bertus:*:500:100:Bertus Smit:/home/bertus:/bin/bash On one client nothing for these specific users, the other users work fine. It may be that they are 'negatively cached' in nscd. Try this on the problem client: service nscd restart getent passwd izak Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: PAM authentication and PPolicy issues
On Wed, Jun 20, 2012 at 01:44:05PM +, Francesco Belli wrote: Now I’m using http:// www.openldap.org/software/man.cgi?query=slapo-ppolicyapropos=0sektion=5 manpath=OpenLDAP+2.3-Releaseformat=html as reference for ppolicy. My The 2.3 release series is very old now. You should be using 2.4 and the 2.4 manuals: http://www.openldap.org/software/man.cgi I’m testing with SHA stored passwords the pwdInHistory directive. SHA is much better than plaintext, but best practice is to use a salted hash - SSHA in this case. The use of salt frustrates attempts to build a dictionary to invert stolen password records. If LinkedIn had used salt in their password hashes they would now be in less trouble as a result of the recent disclosure... https://community.qualys.com/blogs/securitylabs/2012/06/08/lessons-learned-from-cracking-2-million-linkedin-passwords Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: adding schema to master
On Mon, Jun 18, 2012 at 01:41:46PM +0200, Stefano Zanmarchi wrote: our master slapd (openldap 2.4.26 on RHEL 5.6) has just one slave, same version, not easily modifiable since not directly under our control. We need to have some more attributes in the master and don't need them to be replicated to the slave. Can I safely add a new schema in the slapd.conf of the master, without doing anything to the slave? You can, but it is risky. If one of the new attributes gets passed to the slave by mistake it will cause a replication error that may be hard to recover from. If you decide to do this, you should use filters (and possibly ACLs too) to make sure that your new attributes do not reach the slave. If using a new auxiliary objectclass to permit the new attributes, you may also want to filter it out of the objectclass attribute in data passed to the slave. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Uniqueness constraint over multiple attributes
On 06/20/2012 09:35 PM, Andrew Findlay wrote: Jan Beerden wrote: Is there a way to have a unique constraint over multiple attributes? We have different attributes for the primary email address of a person, and for additional aliases, and we'd like to enforce global uniqueness in such a way that the primary email address for one person can not be used as an email alias for another person. The slapo-unique manpage doesn't make this very clear. To achieve what Jan wants, I would consider requiring the primary email address to also be listed as one of the aliases. A uniqueness constraint like this would then protect against one entry hijacking the address of another: overlay unique unique_uri ldap:///o=myorg?primaryMail,aliasMail?sub?(objectClass=mailUser) The requirement for the primaryMail value to also appear as an aliasMail value could be enforced using the constraint overlay with the 'set' mechanism, something like: overlay constraint constraint_attribute primaryMail,aliasMail set this/primaryMail this/aliasMail restrict=ldap:///o=myorg??sub?(objectClass=mailUser) Thanks! This does exactly what we wanted. Regards Jan Beerden jan.beer...@fks.be fks bvba - Formal and Knowledge Systems http://www.fks.be/ Schampbergstraat 32 Tel: ++32-(0)11-21 49 11 B-3511 Kuringen Fax: ++32-(0)11-22 04 19
Re: ACLs being ignored with rwm/relay
Hi, Wonderful - the slapd.conf (see end) with a slight re-arrangement, works! ldapsearch -H ldap://localhost/ -D cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk -b dc=cch,dc=kcl,dc=ac,dc=uk does not return userPassword attributes (the -D is convenience, no auth is performed). However, ldapsearch -H ldapi:/// -D cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk -b dc=cch,dc=kcl,dc=ac,dc=uk Does return userPassword - which is what I want. The UNIX domain socket is protected under a root directory mode 700 so only root can connect this way - ie, local root use has full unauthenticated access to ldap which is what I want, so that scripts may easily be run to maintain the LDAP database. Thanks again for your help :) Cheers, Tim ### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile/var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel-1 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb moduleload back_relay moduleload rwm # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 allow bind_anon_cred bind_anon_dn update_anon backend hdb #backendother overlay rwm rwm-rewriteEngine on ### # ACLs # access to attrs=userPassword,shadowLastChange by peername.path=/var/run/slapd/ldapi write by dn=cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk write by anonymous auth by self write by * none access to dn.base= by * read access to * by peername.path=/var/run/slapd/ldapi write by dn=cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk write by self write by * read ### # Virtual maps # # map ou=staff,dc=cch to dc=dighum # databaserelay suffix ou=staff,dc=cch,dc=kcl,dc=ac,dc=uk relay dc=dighum,dc=kcl,dc=ac,dc=uk overlay rwm rwm-suffixmassage dc=dighum,dc=kcl,dc=ac,dc=uk # # map ou=external,dc=cch to dc=dighum # #databaserelay #suffix ou=external,dc=cch,dc=kcl,dc=ac,dc=uk #relay dc=dighum,dc=kcl,dc=ac,dc=uk #overlay rwm #rwm-suffixmassage dc=dighum,dc=kcl,dc=ac,dc=uk # # map ou=student,dc=cch to dc=dighum # #databaserelay #suffix ou=student,dc=cch,dc=kcl,dc=ac,dc=uk #relay dc=dighum,dc=kcl,dc=ac,dc=uk #overlay rwm #rwm-suffixmassage dc=dighum,dc=kcl,dc=ac,dc=uk # # map ou=project,dc=cch to dc=dighum # #databaserelay #suffix ou=project,dc=cch,dc=kcl,dc=ac,dc=uk #relay dc=dighum,dc=kcl,dc=ac,dc=uk #overlay rwm #rwm-suffixmassage dc=dighum,dc=kcl,dc=ac,dc=uk # # map dc=cch to dc=dighum # databaserelay suffix dc=cch,dc=kcl,dc=ac,dc=uk relay dc=dighum,dc=kcl,dc=ac,dc=uk overlay rwm rwm-suffixmassage dc=dighum,dc=kcl,dc=ac,dc=uk ### # Specific Directives for database dighum # databasehdb suffix dc=dighum,dc=kcl,dc=ac,dc=uk rootdn cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk rootpw e1NTSEF9TnkzOUx6aGZCRnQvOUIwQzZOeFIvcGtVcXRQWkZObXI= directory /var/lib/ldap dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq lastmod on checkpoint 512 30 ### # Specific Directives for database #2, of type 'other' (can be @BACKEND@ too): #databaseother #suffix dc=debian,dc=org -- Tim Watts Personal Blog: http://www.dionic.net/tim/
Re: Uniqueness constraint over multiple attributes
El 20/06/12 14:38, Jan Beerden escribió: On 06/20/2012 06:43 PM, Michael Ströder wrote: Jan Beerden wrote: Is there a way to have a unique constraint over multiple attributes? We have different attributes for the primary email address of a person, and for additional aliases, and we'd like to enforce global uniqueness in such a way that the primary email address for one person can not be used as an email alias for another person. The slapo-unique manpage doesn't make this very clear. You can simply specify multiple attrs. Example for old syntax: unique_attributes uid uidNumber Based on LDAP URLs: unique_uri ldap:///o=myorg?uid,uidNumber?sub?(objectClass=*) IIRC there's a bug with filters in unique_uri. Ciao, Michael. We already tried that. We are trying to prevent user1 to have an email alias that is the same as user2's primary email address. With this it only make sure that an email address can exist only once in the email attribute and that an alias can exist only once in the alias attribute. What we would like is that a certain value (email address) has to be unique across both the email and the alias attribute. Regards Jan Beerden jan.beer...@fks.be fks bvba - Formal and Knowledge Systems http://www.fks.be/ Schampbergstraat 32 Tel: ++32-(0)11-21 49 11 B-3511 Kuringen Fax: ++32-(0)11-22 04 19 try this: ldap:///ou=Users,ou=Accounts,o=myorg?uid,uidNumber,mail?sub?(objectClass=inetOrgPerson) regards hhuntercu
Re: Replication and acl: moddn operation problem.
On 20/6/2012 3:10 μμ, Konstantin Menshikov wrote:
Please, show your replication setup at which it works correctly.
OK, here is an example test setup:
DN: ou=TestBranch1,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: TestBranch1
DN: dc=hostx,ou=TestBranch1,dc=example,dc=com
objectClass: dNSDomain2
objectClass: domainRelatedObject
associatedDomain: hostx.example.com
cNAMERecord: www.example.com
dc: hostx
DN: ou=TestBranch2,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: TestBranch2
ACLs (over-simplistic, devised to illustrate the case):
{0}to dn.sub=ou=TestBranch1,dc=example,dc=comby
dn.exact=uid=dnsauth,ou=system,dc=example,dc=com writeby * none
{1}to dn.sub=ou=TestBranch2,dc=example,dc=com by * none
Consumer setup:
syncrepl rid=444
provider=ldaps://vdev.example.com
type=refreshAndPersist
tls_reqcert=never
retry=60 +
searchbase=dc=example,dc=com
schemachecking=off
bindmethod=simple
binddn=uid=dnsauth,ou=System,dc=example,dc=com
credentials=secret
Initial State: dc=hostx,ou=TestBranch1,dc=example,dc=com exists on both
provider and consumer.
Action1: Manager moves (on the provider) dc=hostx from
ou=TestBranch1,dc=example,dc=com to
dc=hostx,ou=TestBranch2,dc=example,dc=com where consumer has no visibility.
Result: Entry is removed from the consumer
Action2: Manager moves back dc=hostx from
ou=TestBranch2,dc=example,dc=com to
dc=hostx,ou=TestBranch1,dc=example,dc=com where consumer has visibility.
Result: Entry is added back to the consumer
On the provider:
Jun 21 00:24:59 vdev slapd[2212]: slap_queue_csn: queing 0x41046300
20120620212459.398242Z#00#000#00
Jun 21 00:24:59 vdev slapd[2212]: slap_graduate_commit_csn: removing
0x1e4b94b0 20120620212459.398242Z#00#000#00
Jun 21 00:24:59 vdev slapd[2212]: slap_queue_csn: queing 0x4351e750
20120620212459.506829Z#00#000#00
Jun 21 00:24:59 vdev slapd[2212]: syncprov_sendresp:
cookie=rid=444,csn=20120620212459.506829Z#00#000#00
Jun 21 00:24:59 vdev slapd[2212]: slap_graduate_commit_csn: removing
0x1e003b10 20120620212459.506829Z#00#000#00
Jun 21 00:25:27 vdev slapd[2212]: slap_queue_csn: queing 0x4251c300
20120620212527.418467Z#00#000#00
Jun 21 00:25:27 vdev slapd[2212]: syncprov_sendresp:
cookie=rid=444,csn=20120620212527.418467Z#00#000#00
Jun 21 00:25:27 vdev slapd[2212]: slap_graduate_commit_csn: removing
0x1e46d620 20120620212527.418467Z#00#000#00
Jun 21 00:25:27 vdev slapd[2212]: slap_queue_csn: queing 0x41046750
20120620212527.515237Z#00#000#00
Jun 21 00:25:27 vdev slapd[2212]: slap_graduate_commit_csn: removing
0x1e46d5c0 20120620212527.515237Z#00#000#00
On the consumer:
Jun 21 00:24:59 dnslab slapd[20628]: do_syncrep2: rid=444
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Jun 21 00:24:59 dnslab slapd[20628]: do_syncrep2: rid=444 NEW_COOKIE:
rid=444,csn=20120620212459.398242Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: slap_queue_csn: queing 0xc2746a0
20120620212459.398242Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: slap_graduate_commit_csn: removing
0xc28ba90 20120620212459.398242Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: do_syncrep2: rid=444
cookie=rid=444,csn=20120620212459.506829Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_message_to_entry: rid=444
DN: dc=hostx,ou=TestBranch1,dc=example,dc=com, UUID:
6bd53150-9abf-4c83-9d23-9a706b042e07
Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE)
Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444 be_search (0)
Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444
dc=hostx,ou=TestBranch1,dc=example,dc=com
Jun 21 00:24:59 dnslab slapd[20628]: slap_queue_csn: queing 0xc47e150
20120620212459.506829Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: slap_graduate_commit_csn: removing
0xc28ba90 20120620212459.506829Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444 be_delete
dc=hostx,ou=TestBranch1,dc=example,dc=com (0)
Jun 21 00:24:59 dnslab slapd[20628]: slap_queue_csn: queing 0xc47e150
20120620212459.506829Z#00#000#00
Jun 21 00:24:59 dnslab slapd[20628]: slap_graduate_commit_csn: removing
0xc46f320 20120620212459.506829Z#00#000#00
Jun 21 00:25:27 dnslab slapd[20628]: do_syncrep2: rid=444
cookie=rid=444,csn=20120620212527.418467Z#00#000#00
Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_message_to_entry: rid=444
DN: dc=hostx,ou=TestBranch1,dc=example,dc=com, UUID:
bfd9ef4e-e299-445b-b0db-ffafbd8f3804
Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444 be_search (0)
Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444
dc=hostx,ou=TestBranch1,dc=example,dc=com
Jun 21 00:25:27
