2.4.21 delta syncrepl : do_syncrep2: rid=000 (4096) Content Sync Refresh Required
Hello openldap-technical, new on the list, Arjan Filius is my Name. Having setup openldap 2.4.21, with one master, and six slaves/consumers in delta syncrepl configuration and testing an upgrade from an older openldap version. exporting (slapcat export-file), importing (slapadd -l `export-file`) on the (empty/pristine) master, and attaching empty/pristine slaves works just fine except for taking more than one hour to complete. To speed up migration i decided to import the export on master _and_ 6 slaves which finishes under 15 minutes. and now my problem starts. Starting the master and slaves results in a situation which doesn't go away and causes load on master, unneeded network traffic, all slaves/consumers complain with: 2010-07-06 07:00:58.797739500 do_syncrep2: rid=000 (4096) Content Sync Refresh Required 2010-07-06 07:00:58.801662500 do_syncrep2: rid=000 (4096) Content Sync Refresh Required 2010-07-06 07:00:58.804550500 do_syncrep2: rid=000 (4096) Content Sync Refresh Required at a fast rate. and the master complains about stale cookies (all slave connections ): 2010-07-06 07:08:44.470077500 conn=1003 op=40499239 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 2010-07-06 07:08:44.470079500 conn=1003 op=40499239 SEARCH RESULT tag=101 err=4096 nentries=0 text=sync cookie is stale 2010-07-06 07:08:44.470760500 conn=1003 op=40499240 SRCH base=dc=com scope=2 deref=0 filter=(objectClass=*) 2010-07-06 07:08:44.470762500 conn=1003 op=40499240 SRCH attr=* + 2010-07-06 07:08:44.470764500 conn=1003 op=40499240 SEARCH RESULT tag=101 err=0 nentries=0 text= 2010-07-06 07:08:44.471582500 conn=1003 op=40499241 SRCH base=cn=accesslog scope=2 deref=0 filter=((objectClass=auditWriteObject)(reqResult=0)) 2010-07-06 07:08:44.471585500 conn=1003 op=40499241 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 2010-07-06 07:08:44.471587500 conn=1003 op=40499241 SEARCH RESULT tag=101 err=4096 nentries=0 text=sync cookie is stale 2010-07-06 07:08:44.472298500 conn=1003 op=40499242 SRCH base=dc=com scope=2 deref=0 filter=(objectClass=*) 2010-07-06 07:08:44.472301500 conn=1003 op=40499242 SRCH attr=* + 2010-07-06 07:08:44.472302500 conn=1003 op=40499242 SEARCH RESULT tag=101 err=0 nentries=0 text= 2010-07-06 07:08:44.473006500 conn=1003 op=40499243 SRCH base=cn=accesslog scope=2 deref=0 filter=((objectClass=auditWriteObject)(reqResult=0)) 2010-07-06 07:08:44.473008500 conn=1003 op=40499243 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 2010-07-06 07:08:44.473010500 conn=1003 op=40499243 SEARCH RESULT tag=101 err=4096 nentries=0 text=sync cookie is stale The slave has a rid config of: syncrepl rid=4 provider=ldap://X.X.X.X:389 bindmethod=simple binddn=cn=X,dc=XXX,dc=com credentials= searchbase=dc=com logbase=cn=accesslog logfilter=((objectClass=auditWriteObject)(reqResult=0)) schemachecking=on type=refreshAndPersist retry=1 10 2 + sizelimit=unlimited timelimit=unlimited syncdata=accesslog Has anyone an idea what is/might be going on, and how to fix/prevent this? or how to migrate/replicate in a fast way? Regards, and thanks in advance. -- Arjan Filius mailto:iafil...@xs4all.nl
Re: 2.4.21 delta syncrepl : do_syncrep2: rid=000 (4096) Content Sync Refresh Required
On Tuesday, 6 July 2010 07:08:05 Arjan Filius wrote: Hello openldap-technical, new on the list, Arjan Filius is my Name. Having setup openldap 2.4.21, with one master, and six slaves/consumers in delta syncrepl configuration and testing an upgrade from an older openldap version. Please specify the version you are upgrading from, it *is* relevant. exporting (slapcat export-file), importing (slapadd -l `export-file`) on the (empty/pristine) master, and attaching empty/pristine slaves works just fine except for taking more than one hour to complete. Well, maybe you should consider appropriate tuning/changes to your import process to speed things up, rather than risk data integrity. You don't specify how large your database is, or any tuning etc., or other slapadd flags, so it is difficult to know if 1 hour is good or bad. E.g., using the -q flag to slapadd can speed things up significantly, setting 'tool-threads' in slapd.conf appropriately can too, and you should have database tuning (e.g. DB_CONFIG) in place. [...] Starting with different data on providers and consumers is sure to result in broken replication. Has anyone an idea what is/might be going on, and how to fix/prevent this? or how to migrate/replicate in a fast way? See above, but you provide no detail on what you have done to speed up your import, and this seems the original problem. Regards, Buchan
RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
Buchan, Thanks for the information.please see my responses inserted below. Al -Original Message- From: Buchan Milne [mailto:bgmi...@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org Cc: Licause, Al Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user I did not reply to your off-list mails, primarily because I was out of the office (at a data centre) all of Friday, and without internet access over the weekend. You could have sent those replies to your original thread to the list ... No problem. You were correct in stating that I posted to the wrong discussion and I therefore should have expected no further discussion. On Friday, 2 July 2010 20:09:15 Licause, Al wrote: I have installed and configured the ppolicy overlay software on a Red Hat V5.4 server along with the openldap server software and the following components: openldap-servers-2.3.43-3.el5 python-ldap-2.2.0-2.1 openldap-devel-2.3.43-3.el5 checkpassword-ldap-0.01-1.2.el5.rf mozldap-6.0.5-1.el5 openldap-2.3.43-3.el5 openldap-debuginfo-2.3.43-3.el5 openldap-servers-overlays-2.3.43-3.el5 nss_ldap-253-22.el5_4 openldap-clients-2.3.43-3.el5 PROBLEM: I have notice that when an ldap users' password expires, and pwdGraceAuthNLimit is set to a non-zero value...in my case it is set to 1 for testing purposes, the user is allowed to login one time. The next login forces a password change. On the first login, allowed via pwdGraceAuthNLimit, there is no announcement sent to the user telling them that the password has expired. You should actually get a prompt to change your password immediately. I'm not seeing that. If the number of permitted logins specified by pwdGraceAuthNLimit has not counted an equal number of attempted logins, the login is allowed with no warnings.When the number of attempts to login finally exceeds pwdGraceAuthNLimit, then and only then is the user prompted to change the password. BTW, if your PAM setup was correct, you should have seen warnings about expiry before this. Did you bother testing with a guaranteed-to-work tool, such as (with appropriate values to -D option) 'ldapwhoami -e ppolicy' ? I hadn't but having done so at your suggestion, and using -x since I am not using sasl, it yields the following: $ ldapwhoami -x ppolicy anonymous Result: Success (0) Pardon my ignorance, but I'm not sure of the significance of this test and what it would have shown with regard to the pwdGraceAuthNLimit warnings. Nor that they will have to change their password on the next login. I have to wonder if there is also a missing announcement that might tell the user how many more logins they are permitted given the value of pwdGraceAuthNLimit It was suggested that the problem may be in the pam configuration. I am using the following /etc/pam.d/system-auth file that is autogenerated by authconfig: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_ldap.so use_first_pass authrequired pam_deny.so account required pam_unix.so broken_shadow account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so This should be pam_deny.so, but is likely not the cause of your problems. I tried changing this entry to pam_deny.so and while it didn't force a warning to be printed, it also simply denied access to the user as it should have. passwordrequisite pam_cracklib.so try_first_pass retry=3 passwordsufficientpam_unix.so md5 shadow nis nullok try_first_pass use_authtok passwordsufficientpam_ldap.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so I am testing by logging into the client with ssh. I also have many of the pwd* values set fairly low for quick testing. This is the default policy in use: dn: cn=Standard,ou=Policies,dc=mydomain,dc=com objectClass: top objectClass: device objectClass: pwdPolicy cn: Standard pwdAttribute: userPassword pwdLockoutDuration: 15 pwdInHistory: 6 pwdCheckQuality: 0 pwdMinLength: 5 pwdAllowUserChange: TRUE pwdMustChange: TRUE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: FALSE pwdLockout: TRUE pwdReset: TRUE structuralObjectClass: device entryUUID:
Re: ldap_bind: Can't contact LDAP server (-1)
On Fri, 2 Jul 2010, Aldo wrote:
THE REQUIRED PORT 636 IS LISTENING.
[r...@ldapserver]# fuser -n tcp 636
636/tcp: 7027
[r...@ldapserver ~]# telnet localhost 636
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
Connection closed by foreign host.
Well, obviously the process is attached. But why is it dropping your
connection instantly? It should be sitting there, listening for input
data.
I'd:
0) check your libwrap configuration (/etc/hosts.{allow,deny}).
and if you don't find anything there,
1) restart slapd with excessive debugging (-d -1 or similar), telnet
localhost 636, see what's going on.
RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
This works from the test account:
$ ldapwhoami -x -D uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net -W
Enter LDAP Password:
dn:uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net
Result: Success (0)
It still doesn't tell me anything about the problems I have raised with
pwdGraceAuthNLimit.
The following have been removed from the /etc/ldap.conf:
rootpw {SSHA}RHVddPmANdnsYDuMzFlM/D4D7aAH1yYG
ppolicy_hash_cleartext
ppolicy_use_lockout
The ldap server has been restarted.
Still no notification when the users password expires and pwdGraceAuthNLimit is
greater
than zero.
Al
-Original Message-
From: Buchan Milne [mailto:bgmi...@staff.telkomsa.net]
Sent: Tuesday, July 06, 2010 9:06 AM
To: Licause, Al
Cc: openldap-technical@openldap.org
Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to
user
On Tuesday, 6 July 2010 13:24:51 Licause, Al wrote:
Buchan,
Thanks for the information.please see my responses inserted below.
Al
-Original Message-
From: Buchan Milne [mailto:bgmi...@staff.telkomsa.net]
Sent: Monday, July 05, 2010 4:56 AM
To: openldap-technical@openldap.org
Cc: Licause, Al
Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning
to user
I did not reply to your off-list mails, primarily because I was out of
the office (at a data centre) all of Friday, and without internet access
over the weekend. You could have sent those replies to your original
thread to the list ...
No problem. You were correct in stating that I posted to the wrong
discussion and I therefore should have expected no further discussion.
On Friday, 2 July 2010 20:09:15 Licause, Al wrote:
I have installed and configured the ppolicy overlay software on a Red Hat
V5.4 server along with the openldap server software and the following
components:
openldap-servers-2.3.43-3.el5
python-ldap-2.2.0-2.1
openldap-devel-2.3.43-3.el5
checkpassword-ldap-0.01-1.2.el5.rf
mozldap-6.0.5-1.el5
openldap-2.3.43-3.el5
openldap-debuginfo-2.3.43-3.el5
openldap-servers-overlays-2.3.43-3.el5
nss_ldap-253-22.el5_4
openldap-clients-2.3.43-3.el5
PROBLEM:
I have notice that when an ldap users' password expires, and
pwdGraceAuthNLimit is set to a non-zero value...in my case it is set to
1 for testing purposes, the user is allowed to login one time. The
next login forces a password change.
On the first login, allowed via pwdGraceAuthNLimit, there is no
announcement sent to the user telling them that the password has
expired.
You should actually get a prompt to change your password immediately.
I'm not seeing that. If the number of permitted logins specified by
pwdGraceAuthNLimit has not counted an equal number of attempted logins,
the login is allowed with no warnings.When the number of attempts to
login finally exceeds pwdGraceAuthNLimit, then and only then is the user
prompted to change the password.
BTW, if your PAM setup was correct, you should have seen warnings about
expiry before this.
Did you bother testing with a guaranteed-to-work tool, such as (with
appropriate values to -D option) 'ldapwhoami -e ppolicy' ?
I hadn't but having done so at your suggestion, and using -x since I am not
using sasl, it yields the following:
$ ldapwhoami -x ppolicy
anonymous
Result: Success (0)
Please see the man page. You need to provide a DN and password (e.g.
ldapwhoami -x -D uid=xxx. -W .), but if you aren't familiar enough
with the tools, please read the man pages.
Pardon my ignorance, but I'm not sure of the significance of this test and
what it would have shown with regard to the pwdGraceAuthNLimit warnings.
Well, you have to use the test correctly.
Nor that they will have to change their password on the next login.
I have to wonder if there is also a missing announcement that might tell
the user how many more logins they are permitted given the value of
pwdGraceAuthNLimit
It was suggested that the problem may be in the pam configuration.
I am using the following /etc/pam.d/system-auth file that is
autogenerated by authconfig:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired pam_env.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid = 500 quiet
authsufficientpam_ldap.so use_first_pass
authrequired pam_deny.so
account required pam_unix.so broken_shadow
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
This should be pam_deny.so, but is likely not the cause of your problems.
I tried changing this entry to pam_deny.so and while it didn't force a
warning to be
Re: nssov overlay socket and chrooted software
b...@bitrate.net wrote: hi- i'm using the nssov overlay, which is hard coded (i believe?) to present it's socket at /var/run/nslcd/socket. this presents a problem for software (in this particular case, postfix) that is chrooted and can't see the socket. can i configure the overlay to create multiple sockets (sort of along the same lines as rsyslog, for example)? No, currently there is no support for configuring the socket path, or multiple sockets. Patches to add this feature are welcome. -- -- 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: How to modify a single attribute from multiple list of attributes
Thanks to everyone who replied. In my searching, I hadn't found any examples of modifying an attribute that had multiple values. the following ldif did exactly what I needed: dn: cn=config,o=dhcp changetype: modify delete: dhcpStatements dhcpStatements: log-facility local7 - add: dhcpStatements dhcpStatements: log-facility local3 I was stuck on trying to use 'replace' rather then 'delete + add' and I couldn't find an ldif syntax that worked. Thanks again! Tom Leach On 07/02/2010 04:24 PM, Tom Leach wrote: How do I modify/delete a single attribute from the directory when I have multiple attributes of the same name. For example, given the following ldif: dn: cn=config,o=dhcp cn: config objectClass: top objectClass: dhcpService objectClass: dhcpOptions dhcpPrimaryDN: cn=server1,o=dhcp dhcpStatements: default-lease-time 600 dhcpStatements: max-lease-time 1200 dhcpStatements: ddns-update-style none dhcpStatements: boot-unknown-clients on dhcpStatements: log-facility local7 How would I modify just one of the dhcpStatements: attributes, for example, change 'dhcpStatements: log-facility local7' to 'dhcpStatements: log-facility local3'? I've tried an ldif with: dn: cn=config,o=dhcp changetype: modify replace: dhcpStatements log-facility local7 dhcpStatements: log-facility local3 But that just gave me an error: ldapmodify: Undefined attribute type (17) additional info: dhcpStatements log-facility local7: AttributeDescription contains inappropriate characters. I've also tried: dn: cn=config,o=dhcp changetype: modify replace: dhcpStatements dhcpStatements: log-facility local3 But that just gave me an error: replace modify: dhcpStatements replace dhcpStatements: log-facility local3 modifying entry cn=config,o=dhcp modify complete ldapmodify: Undefined attribute type (17) additional info: modify: attribute type undefined I can use 'delete: dhcpStatements' but that deletes all of the dhcpStatements and then I have to add all of them back with the modification to the one that's needed. So, what ldapmodify/ldif syntax is needed to specify which of multiple attributes should be modified? Thanks! Tom Leach
Re: How to modify a single attribute from multiple list of attributes
Tom Leach wrote: Thanks to everyone who replied. In my searching, I hadn't found any examples of modifying an attribute that had multiple values. See Example 6 in RFC 2849. the following ldif did exactly what I needed: dn: cn=config,o=dhcp changetype: modify delete: dhcpStatements dhcpStatements: log-facility local7 - add: dhcpStatements dhcpStatements: log-facility local3 Note that this only works if the attribute type in question is declared with an EQUALITY matching rule (which is defined for dhcpStatements). Ciao, Michael.
Question about password storage.
Hi everyone. I just read this information. 14.4. Password Storage LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead. slapd(8) supports a variety of storage schemes for the administrator to choose from. If it is not typical to store passwords in LDAP in hashed form. Then how are you supposed to bind to LDAP without transmitting the clear text password across the network? I understand that SSL and Kerberos will fix this problem, but what if a user just wants to use plain LDAP? Would I need to dictate to a customer that they must use a hash alg. in the userPassword in this case? thanks
Re: Question about password storage.
On 7/6/10 11:44 PM, Bryan Boone wrote:
Hi everyone. I just read this information.
14.4. Password Storage
LDAP passwords are normally stored in the userPassword attribute. RFC4519
specifies that passwords are not stored in encrypted (or hashed) form.
*encrypted*. Not encrypted *or* hashed.
Encrypted is really different from Hashed. Encryption means you have a
way to decrypt the password. Hashing does not offer this possibility.
This allows a wide range of password-based authentication mechanisms, such as
DIGEST-MD5 to be used. This is also the most interoperable storage scheme.
However, it may be desirable to store a hash of password instead. slapd(8)
supports a variety of storage schemes for the administrator to choose from.
If it is not typical to store passwords in LDAP in hashed form.
All the existing ldap servers support hashed passwords. Usually, the
mechanism is stored in frm of the encrypted password like :
{MD5}XXX
or
{crypt}Y
Then how are you supposed to bind to LDAP without transmitting the clear
text password across the network?
Even if the password is hashed ( you still have to pass the password in
clear text ).
I understand that SSL and Kerberos will fix this problem, but what if a user
just wants to use plain LDAP?
Ask this user his bank account number and his password... There is no
reason for him to refuse to give you such information if he accepts the
idea that his password will be transmitted in clear.
Hey, it's not like if this is a unsafe planet where some bad bad people
are willing to use those information to spam or send scams. We are all
living in a peaceful and honest world... ;)
Would I need to dictate to a customer that they must use a hash alg. in the
userPassword in this case?
You just need to explain this customer the very basis of what is security.
Or may be point him to http://www.ietf.org/rfc/rfc4513.txt, 6.3.3.
Password-Related Security Considerations :
...The use of clear text passwords and other unprotected authentication
credentials is strongly discouraged over open networks when the
underlying transport service cannot guarantee confidentiality. LDAP
implementations SHOULD NOT by default support authentication methods
using clear text passwords and other unprotected authentication
credentials unless the data on the session is protected using TLS or
other data confidentiality and data integrity protection...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Question about password storage.
On 06/07/10 14:44 -0700, Bryan Boone wrote: Hi everyone. I just read this information. 14.4. Password Storage LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead. slapd(8) supports a variety of storage schemes for the administrator to choose from. If it is not typical to store passwords in LDAP in hashed form. Then how are you supposed to bind to LDAP without transmitting the clear text password across the network? I understand that SSL and Kerberos will fix this problem, but what if a user just wants to use plain LDAP? Would I need to dictate to a customer that they must use a hash alg. in the userPassword in this case? I believe your question is based on a misinterpretation of the above. Storing the password in clear text within the userPassword attribute opens up several SASL based authentication mechanisms which do not transmit the password over the network, such as with DIGEST-MD5 (See RFC 2831). Storing your password in a hashed form may restrict the ability of the server, or the SASL library, in making use of such mechanisms, and could allow, or even require, your users to transmit the password in clear text over the network. Assuming that you only allow SASL binds, you can implement a configuration option of 'sasl-secprops minssf=64' to require users to choose authentication mechanisms that provides a security layer of at least 64 bits (for example). See RFC 4422. Even when using such appropriate mechanisms to authenticate, it's still a good idea to protect the authentication handshake with TLS. -- Dan White
