Everything is setup on RHEL 6.4 with Openldap 2.4.
I have one provider and one consumer. StartTLS has been enabled and everything is working as intended. My only problem arises here - When a user is setup with a password and he tries to change his password on a consumer pointing client, I get a passwd: Authentication token manipulation error. This message is misleading since the password is in fact changed on the provider ( I have the olcUpdateRef directive setup). This creates a situation where the user can login to consumer pointed boxes with his old password and provider pointed boxes with his new password. If the user tries to change his password for the second time on consumer pointed boxes, I get Password change failed. Server message: unwilling to verify old password passwd: Authentication token manipulation error which understandably is because the password in the actual LDAP db is different from what is being supplied and being accepted by the client. What is going on here? Why isn’t the password not getting updated properly in the consumer?
Here are some of the relevant snippets of configs - For Syncrepl in olcDatabase={2}bdb.ldif on consumer
###For Replication
olcSyncrepl: rid=100
provider="ldap://server.com
type=refreshAndPersist
retry="60 30 300 +"
searchbase=“dc=ex,dc=example,dc=com"
bindmethod=simple
binddn="cn=Manager,dc=ex,dc=example,dc=com"
credentials=secret
starttls=yes
tls_cacert=/etc/pki/CA/cacert.pem
tls_cert=/etc/pki/tls/certs/cert.pem
tls_key=/etc/pki/tls/certs/key.pem
olcUpdateRef: ldap://server.com
ACL on provider -
lcAccess: to attrs=userPassword
by self write
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by anonymous auth
by * none
olcAccess: to *
by self write
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by users read
olcAccess: to attrs=entry
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by * read
Let me know if any more configs are needed and I will post them. Any help is appreciated.
Siddharth Choure Senior Systems Engineer
Anyone? Siddharth Choure Senior Systems Engineer
On 11/22/13, 4:15 PM, "Choure, Sidd" schoure@apartments.com wrote:
Everything is setup on RHEL 6.4 with Openldap 2.4.
I have one provider and one consumer. StartTLS has been enabled and everything is working as intended. My only problem arises here - When a user is setup with a password and he tries to change his password on a consumer pointing client, I get a passwd: Authentication token manipulation error. This message is misleading since the password is in fact changed on the provider ( I have the olcUpdateRef directive setup). This creates a situation where the user can login to consumer pointed boxes with his old password and provider pointed boxes with his new password. If the user tries to change his password for the second time on consumer pointed boxes, I get Password change failed. Server message: unwilling to verify old password passwd: Authentication token manipulation error which understandably is because the password in the actual LDAP db is different from what is being supplied and being accepted by the client. What is going on here? Why isn¹t the password not getting updated properly in the consumer?
Here are some of the relevant snippets of configs - For Syncrepl in olcDatabase={2}bdb.ldif on consumer
###For Replication
olcSyncrepl: rid=100
provider="ldap://server.com
type=refreshAndPersist
retry="60 30 300 +"
searchbase=³dc=ex,dc=example,dc=com"
bindmethod=simple
binddn="cn=Manager,dc=ex,dc=example,dc=com"
credentials=secret
starttls=yes
tls_cacert=/etc/pki/CA/cacert.pem
tls_cert=/etc/pki/tls/certs/cert.pem
tls_key=/etc/pki/tls/certs/key.pem
olcUpdateRef: ldap://server.com
ACL on provider -
lcAccess: to attrs=userPassword
by self write by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by anonymous auth by * noneolcAccess: to *
by self write by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by users readolcAccess: to attrs=entry
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by * readLet me know if any more configs are needed and I will post them. Any help is appreciated.
Siddharth Choure Senior Systems Engineer
--On Sunday, November 24, 2013 9:52 PM +0000 "Choure, Sidd" schoure@apartments.com wrote:
Anyone?
What version of OpenLDAP 2.4? The ancient broken one shipped by RedHat, or a current sane one? I also note you're using back-bdb, which is quite ancient being phased out.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Here is the version info - slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Apr 22 2013 05:03:41) $ mockbuild@x86-007.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4. 23/openldap-2.4.23/build-servers/servers/slapd.
There are few practical implementation documents for the new cn=config version of openldap and the ones available all use the bdb database. What can I do about this password issue? Am I missing come ACL or option that needs to be added?
Siddharth Choure Senior Systems Engineer
On 11/24/13, 6:46 PM, "Quanah Gibson-Mount" quanah@zimbra.com wrote:
--On Sunday, November 24, 2013 9:52 PM +0000 "Choure, Sidd" schoure@apartments.com wrote:
Anyone?
What version of OpenLDAP 2.4? The ancient broken one shipped by RedHat, or a current sane one? I also note you're using back-bdb, which is quite ancient being phased out.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
Choure, Sidd wrote:
Here is the version info - slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Apr 22 2013 05:03:41) $ mockbuild@x86-007.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4. 23/openldap-2.4.23/build-servers/servers/slapd.
There are few practical implementation documents for the new cn=config version of openldap and the ones available all use the bdb database.
Examples use whatever was convenient for the document author at the time. They're obviously not the only choice, nor are they necessarily the best or recommended choice. Learn to think for yourself instead of blindly copy/pasting other peoples' examples.
The back-bdb code is not particularly *old*, contrary to what Quanah implied. But BerkeleyDB is definitely *obsolete*, and with the license change in 6.0.20, it is no longer legal for use in open source LDAP servers. (But given its obsolescence, the license issue is somewhat irrelevant.)
What can I do about this password issue? Am I missing come ACL or option that needs to be added?
Siddharth Choure Senior Systems Engineer
So you don¹t have a solution?
Siddharth Choure Senior Systems Engineer
On 11/25/13, 8:52 AM, "Howard Chu" hyc@symas.com wrote:
Choure, Sidd wrote:
Here is the version info - slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Apr 22 2013 05:03:41) $
mockbuild@x86-007.build.bos.redhat.com:/builddir/build/BUILD/openldap-2. 4. 23/openldap-2.4.23/build-servers/servers/slapd.
There are few practical implementation documents for the new cn=config version of openldap and the ones available all use the bdb database.
Examples use whatever was convenient for the document author at the time. They're obviously not the only choice, nor are they necessarily the best or recommended choice. Learn to think for yourself instead of blindly copy/pasting other peoples' examples.
The back-bdb code is not particularly *old*, contrary to what Quanah implied. But BerkeleyDB is definitely *obsolete*, and with the license change in 6.0.20, it is no longer legal for use in open source LDAP servers. (But given its obsolescence, the license issue is somewhat irrelevant.)
What can I do about this password issue? Am I missing come ACL or option that needs to be added?
Siddharth Choure Senior Systems Engineer
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Choure, Sidd wrote:
So you don¹t have a solution?
The Project only supports current releases, the current release is 2.4.38. Since you're running Red Hat's old build of 2.4.23, which was released over 3 years ago, you should contact them for support.
Siddharth Choure Senior Systems Engineer
On 11/25/13, 8:52 AM, "Howard Chu" hyc@symas.com wrote:
Choure, Sidd wrote:
Here is the version info - slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Apr 22 2013 05:03:41) $
mockbuild@x86-007.build.bos.redhat.com:/builddir/build/BUILD/openldap-2. 4. 23/openldap-2.4.23/build-servers/servers/slapd.
There are few practical implementation documents for the new cn=config version of openldap and the ones available all use the bdb database.
Examples use whatever was convenient for the document author at the time. They're obviously not the only choice, nor are they necessarily the best or recommended choice. Learn to think for yourself instead of blindly copy/pasting other peoples' examples.
The back-bdb code is not particularly *old*, contrary to what Quanah implied. But BerkeleyDB is definitely *obsolete*, and with the license change in 6.0.20, it is no longer legal for use in open source LDAP servers. (But given its obsolescence, the license issue is somewhat irrelevant.)
What can I do about this password issue? Am I missing come ACL or option that needs to be added?
--On Monday, November 25, 2013 7:03 AM -0800 Howard Chu hyc@symas.com wrote:
Choure, Sidd wrote:
So you don¹t have a solution?
The Project only supports current releases, the current release is 2.4.38. Since you're running Red Hat's old build of 2.4.23, which was released over 3 years ago, you should contact them for support.
You could also download something a little more current:
http://ltb-project.org/wiki/download#openldap
if you can't build out OpenLDAP yourself. I strongly advise you read the changes made to releases since 2.4.23 as well.
http://www.openldap.org/software/release/changes.html
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Choure, Sidd -
Howard Chu -
Quanah Gibson-Mount