CentOS 5.2 with OpenLDAP 2.3.27, nss_ldap_253.13, using TLS, i686 and x86_64.
If a user with an expired password (shadowLastChange + shadowMax < current day) logs in to a system where ldap.conf points first to a consumer-only LDAP server, the password change operation (exop) proceeds and fails with:
LDAP password information update failed: Referral
If I comment out "ssl start_tls", the referral to the master is followed and the password change operation succeeds. I've found references to problems with earlier releases of pam_ldap when referrals were not properly followed when using TLS, and these are supposed to be fixed; apparently not in my case. Can anyone hit me with the clue stick?
Steve ---------------------------------------------------------------------------- Steve Thompson E-mail: smt AT vgersoft DOT com Voyager Software LLC Web: http://www DOT vgersoft DOT com 39 Smugglers Path VSW Support: support AT vgersoft DOT com Ithaca, NY 14850 "186,300 miles per second: it's not just a good idea, it's the law" ----------------------------------------------------------------------------
On Fri, 2008-10-31 at 16:32 -0400, Steve Thompson wrote:
CentOS 5.2 with OpenLDAP 2.3.27, nss_ldap_253.13, using TLS, i686 and x86_64.
LDAP password information update failed: Referral
If I comment out "ssl start_tls", the referral to the master is followed and the password change operation succeeds. I've found references to problems with earlier releases of pam_ldap when referrals were not properly followed when using TLS, and these are supposed to be fixed; apparently not in my case. Can anyone hit me with the clue stick?
Does the common name in the certificate or the x509 v3 extensions match the hostname used in the referral in your slapd.conf? Is the certificate issued by the ldap server you are being referred to signed by a trusted CA? Following referrals using start_tls works just fine for me.
On Fri, 31 Oct 2008, Scott McClanahan wrote:
On Fri, 2008-10-31 at 16:32 -0400, Steve Thompson wrote:
CentOS 5.2 with OpenLDAP 2.3.27, nss_ldap_253.13, using TLS, i686 and x86_64.
LDAP password information update failed: Referral
If I comment out "ssl start_tls", the referral to the master is followed and the password change operation succeeds. I've found references to problems with earlier releases of pam_ldap when referrals were not properly followed when using TLS, and these are supposed to be fixed; apparently not in my case. Can anyone hit me with the clue stick?
Does the common name in the certificate or the x509 v3 extensions match the hostname used in the referral in your slapd.conf? Is the certificate issued by the ldap server you are being referred to signed by a trusted CA?
Yes to both.
Steve ---------------------------------------------------------------------------- Steve Thompson E-mail: smt AT vgersoft DOT com Voyager Software LLC Web: http://www DOT vgersoft DOT com 39 Smugglers Path VSW Support: support AT vgersoft DOT com Ithaca, NY 14850 "186,300 miles per second: it's not just a good idea, it's the law" ----------------------------------------------------------------------------
Hi,
On Fri, Oct 31, 2008 at 18:32, Steve Thompson smt@vgersoft.com wrote:
Does the common name in the certificate or the x509 v3 extensions match the hostname used in the referral in your slapd.conf? Is the certificate issued by the ldap server you are being referred to signed by a trusted CA?
Yes to both.
Are you sure?
What is the output of this command on your slave LDAP server? # grep ^updateref /etc/openldap/slapd.conf
What is the output of this command on both of them, master and slave? # openssl x509 -text -in $(grep -i ^tlscertificatefile /etc/openldap/slapd.conf | awk '{print$2}') | grep Subject:
What is the issuer of each certificate? # openssl x509 -text -in $(grep -i ^tlscertificatefile /etc/openldap/slapd.conf | awk '{print$2}') | grep Issuer:
Could you also send the /etc/ldap.conf of the client where you are trying to change the password? You can strip the commented and blank lines: # grep -v -e ^# -e ^$ /etc/ldap.conf
Using SSL on OpenLDAP is really tricky, I've been through it recently and the configuration is not easy at all... If you send that info it might be easier to track down the problem.
Filipe
On Fri, 31 Oct 2008, Filipe Brandenburger wrote:
Hi Felipe; many thanks for your reply.
# grep ^updateref /etc/openldap/slapd.conf
updateref ldaps://ldap1.cbe.cornell.edu
# openssl x509 -text -in $(grep -i ^tlscertificatefile /etc/openldap/slapd.conf | awk '{print$2}') | grep Subject:
master (line continuations added): Subject: C=US, ST=New York, O=Cornell School of Chemical and \ Biomolecular Engineering/emailAddress=certs@cbe.cornell.edu, \ CN=ldap1.cbe.cornell.edu
slave: Subject: C=US, ST=New York, O=Cornell School of Chemical and \ Biomolecular Engineering/emailAddress=certs@cbe.cornell.edu, \ CN=asimov.cbe.cornell.edu
What is the issuer of each certificate?
Same on master and all slaves: Issuer: O=Cornell School of Chemical and Biomolecular Engineering, L=Ithaca, ST=New York, C=US, CN=cbe.cornell.edu/emailAddress=certs@cbe.cornell.edu
Could you also send the /etc/ldap.conf of the client where you are trying to change the password?
host asimov.cbe.cornell.edu referrals yes base dc=cbe,dc=cornell,dc=edu ldap_version 3 binddn cn=kelvin.cbe.cornell.edu,ou=Binddn,dc=cbe,dc=cornell,dc=edu bindpw XXXXXXXXX timelimit 120 bind_timelimit 5 bind_policy soft idle_timelimit 3600 pam_password exop nss_base_passwd ou=People,dc=cbe,dc=cornell,dc=edu?one nss_base_shadow ou=People,dc=cbe,dc=cornell,dc=edu?one nss_base_group ou=Group,dc=cbe,dc=cornell,dc=edu?one nss_base_hosts ou=Hosts,dc=cbe,dc=cornell,dc=edu?one nss_base_services ou=Services,dc=cbe,dc=cornell,dc=edu?one nss_base_networks ou=Networks,dc=cbe,dc=cornell,dc=edu?one nss_base_protocols ou=Protocols,dc=cbe,dc=cornell,dc=edu?one nss_base_rpc ou=Rpc,dc=cbe,dc=cornell,dc=edu?one nss_base_ethers ou=Ethers,dc=cbe,dc=cornell,dc=edu?one nss_base_netmasks ou=Networks,dc=cbe,dc=cornell,dc=edu?ne nss_base_bootparams ou=Ethers,dc=cbe,dc=cornell,dc=edu?one nss_base_aliases ou=Aliases,dc=cbe,dc=cornell,dc=edu?one nss_base_netgroup ou=Netgroup,dc=cbe,dc=cornell,dc=edu?one ssl start_tls tls_checkpeer yes tls_cacertdir /etc/openldap/cacerts tls_ciphers TLSv1
-Steve
Hi Steve,
On Sat, Nov 1, 2008 at 09:30, Steve Thompson smt@vgersoft.com wrote:
# grep ^updateref /etc/openldap/slapd.conf
updateref ldaps://ldap1.cbe.cornell.edu
If you are using "ssl start_tsl" you have to use ldap:// and not ldaps:// in your referrals, otherwise LDAP client will try to open a TLS session inside the connection which is already a SSL session. If you change that in your configuration file, it should work fine.
Alternatively you could use ldaps:// on the clients instead, by using "ssl on" or "uri ldaps://..." instead of "host ...".
HTH, Filipe
On Sat, 1 Nov 2008, Filipe Brandenburger wrote:
If you are using "ssl start_tsl" you have to use ldap:// and not ldaps:// in your referrals, otherwise LDAP client will try to open a TLS session inside the connection which is already a SSL session. If you change that in your configuration file, it should work fine.
Thank you very much Filipe; you are a star. Of course it works now. I have been doing this long enough that I should have seen that; sometimes the cause is so obvious that you look right past it at other details. Having made such a noob mistake, I'm surprised that more things didn't work.
Steve
Hi,
On Sat, Nov 1, 2008 at 15:42, Steve Thompson smt@vgersoft.com wrote:
Thank you very much Filipe
No problem!
LDAP with SSL is really tricky, as I said I implemented it some months ago, and I'm sure I went through the same issues you are going now.
One thing I did in my setup was to configure the clients to query both LDAP servers. To do that, I created a "star" certificate, like CN=*.cbe.cornell.edu in your case, and then I created a new entry in DNS doing round-robin between both IPs. Queries get split to both servers, and if there is an update that falls on the slave, the referral to the master by its own name will take care of doing the update properly. The star certificate makes sure that connections using any name (the RR or the master's name in case of updates) will match the certificate.
HTH, Filipe
-
Filipe Brandenburger -
Scott McClanahan -
Steve Thompson