Hello I have an openldap server running slapd on 636 (LDAPS) . When I connect from a ldap browser , I am able to successfully browse the database. However when I try to connect from a linux client machine (Ubuntu Server 8.04) I am not able to connect to the ldaps. However regular ldap works fine.
The /etc/ldap.conf looks like this
ssl start_tls ssl on tls_checkpeer tes tls_cacertdir /etc/ldap/cacerts tls_cacertfile /etc/ldap/cacert/cacert.pem #server IP uri ldaps://30.0.0.2/ pam_password md5 base dc=example,dc=com
The /etc/ldap/ldap.conf file is like this
URI ldaps://30.0.0.2/ TLS_CACERTDIR /etc/ldap/cacerts TLS_CACERT /etc/ldap/cacerts/cacert.pem HOST 30.0.0.2 BASE dc=example,dc=com
The same configuration (with approprirate changes - replacing ldaps with ldap and so on) works fine for regular ldap. But the problem is the ldaps.
When ldaps client is enabled and I do a getent passed , the /var/log/auth.log looks like this
Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server... Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... Jul 7 23:57:47 host3 getent: nss_ldap: could not search LDAP server - Server is unavailable Jul 7 23:58:18 host3 getent: nss_ldap: reconnecting to LDAP server...
Please suggest where I could have gone wrong. Any suggestions would be really appreciated.
Thanks Sambuddho
On Tue, 2008-07-08 at 00:06 -0400, Sambuddho Chakravarty wrote:
Hello I have an openldap server running slapd on 636 (LDAPS) . When I connect from a ldap browser , I am able to successfully browse the database.
Can you be more specific about the software you are using? Not all graphical LDAP clients have SSL validation features (and if they do, in some cases they aren't enabled by default).
However when I try to connect from a linux client machine (Ubuntu Server 8.04) I am not able to connect to the ldaps. However regular ldap works fine.
So, assuming it is not a firewall problem, the most likely cause is certificate validation.
The /etc/ldap.conf looks like this
ssl start_tls ssl on
You shouldn't use both of these, only use 'ssl on' if you are using 'host', in the 'uri' case it won't really make a difference.
tls_checkpeer tes
"tes" ???
tls_cacertdir /etc/ldap/cacerts tls_cacertfile /etc/ldap/cacert/cacert.pem #server IP uri ldaps://30.0.0.2/
What is the subject CN on the certificate the server has?
pam_password md5 base dc=example,dc=com
The /etc/ldap/ldap.conf file is like this
URI ldaps://30.0.0.2/ TLS_CACERTDIR /etc/ldap/cacerts TLS_CACERT /etc/ldap/cacerts/cacert.pem HOST 30.0.0.2 BASE dc=example,dc=com
The same configuration (with approprirate changes - replacing ldaps with ldap and so on) works fine for regular ldap. But the problem is the ldaps.
So, what do you get if you try something like this:
$ openssl s_client -CAfile /etc/ldap/cacerts/cacert.pem -connect 30.0.0.2:636
Does the CN attribute in the server certificate you get back match the hostname in the URI?
When ldaps client is enabled and I do a getent passed , the /var/log/auth.log looks like this
Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server... Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... Jul 7 23:57:47 host3 getent: nss_ldap: could not search LDAP server - Server is unavailable Jul 7 23:58:18 host3 getent: nss_ldap: reconnecting to LDAP server...
For now, using the OpenLDAP client utilities (ldapsearch) to do the same connection may be an easier way to debug, but once it is working, you need to put the equivalent configuration in /etc/ldap.conf. So, with your current configuration, this would be the way to test with ldapsearch:
$ ldapsearch -x -H ldaps://30.0.0.2 -s base -b dc=example,dc=com namingContexts
However, and certificate-related aspects still need to be in the OpenLDAP library configuration file (/etc/ldap/ldap.conf, or ~/.ldaprc).
Please suggest where I could have gone wrong. Any suggestions would be really appreciated.
Hmm, if you were trying to get https working, you would be getting warnings from your browser, this really isn't rocket science, but nss_ldap can't show you warning dialogs, so you need to get the configuration right ...
Regards, Buchan
Buchan Milne wrote:
On Tue, 2008-07-08 at 00:06 -0400, Sambuddho Chakravarty wrote:
Please suggest where I could have gone wrong. Any suggestions would be really appreciated.
Hmm, if you were trying to get https working, you would be getting warnings from your browser, this really isn't rocket science, but nss_ldap can't show you warning dialogs, so you need to get the configuration right ...
You can also enable libldap debugging in nss_ldap's config file, which would provide detailed error messages for this situation.
We have openldap version(-2.2.13-7.4E) installed as master and slave (on two different systems) with replication configured between them.
When we try to a ldapmodify on the slave it returns the following message
#ldapmodify -x -hlocalhost -p389 -v -D'cn=Directory Manager, o=del.com' -w dgtyrh -f a
ldap_initialize( ldap://localhost:389 ) replace CurrentVersion: 2.0.txt1 modifying entry "cn=options-server-tr,ou=App-test,o=del.com" modify complete ldap_modify: Referral (10) referrals: ldap://100.115.23.156:389/cn=options-server-tr,ou=App-test,o=del.com
However the changes are not reflected.Browsing the internet,I found that ldapmodify doesn`t have the capability to chase referrals and but the openldap API allows to write clients that do the chasing. Is this statement valid for this version of openldap too?
Is chaining the other alernative for chasing referrals?
Cheers CG
Govind c wrote:
We have openldap version(-2.2.13-7.4E) installed as master and slave (on two different systems) with replication configured between them.
You definitely should upgrade.
ldap_modify: Referral (10) referrals: ldap://100.115.23.156:389/cn=options-server-tr,ou=App-test,o=del.com However the changes are not reflected.Browsing the internet,I found that ldapmodify doesn`t have the capability to chase referrals and but the openldap API allows to write clients that do the chasing. Is this statement valid for this version of openldap too?
Is chaining the other alernative for chasing referrals?
Yes, you probably should just use slapo-chain.
Ciao, Michael.
On Tuesday 08 July 2008 20:00:56 Govind c wrote:
We have openldap version(-2.2.13-7.4E) installed as master and slave (on two different systems) with replication configured between them.
When we try to a ldapmodify on the slave it returns the following message
#ldapmodify -x -hlocalhost -p389 -v -D'cn=Directory Manager, o=del.com' -w dgtyrh -f a
ldap_initialize( ldap://localhost:389 ) replace CurrentVersion: 2.0.txt1 modifying entry "cn=options-server-tr,ou=App-test,o=del.com" modify complete ldap_modify: Referral (10) referrals:
ldap://100.115.23.156:389/cn=options-server-tr,ou=App-test,o=del.com
So, why don't you retry the modification against 100.115.23.156? Or, since you know which is the master, why don't you always run changes against the master?
However the changes are not reflected.
The fact that you got a referral back does indicate that no changes were made on the LDAP server you tried to run the modifications against.
Browsing the internet,I found that ldapmodify doesn`t have the capability to chase referrals and but the openldap API allows to write clients that do the chasing.
Since ldapmodify is an administrative utility, the person using it is expected to be able to be in the position to determine the security impact of following the referral. Since ldapmodify is not in such a position, it intentionally will not follow referrals.
Is this statement valid for this version of openldap too?
Since it is quite possible for an LDAP server to return referrals to LDAP servers that are outside the security control of the administrator of the first LDAP server (see e.g. back-dnssrv), no, nothing has changed.
Is chaining the other alernative for chasing referrals?
Well, the real question is why you think you need anything besides what you have. The OpenLDAP utilities do no chase referrals (except anonymously in the case of ldapsearch), but most other tools that you would need to have chase referrals (e.g. pam_ldap) do. Since I can't see why you would need the OpenLDAP utilities to chase referrals (apply logic at layer 8 instead), I don't see why you have a problem.
But, yes, an alternative means (for clients that don't have the ability to chase referrals, be it due to insufficient control available to the user or lack of automatic referral chasing), for ensuring that changes sent to a slave arrive at the master is the use of the chain overlay.
Hello
On Tue, 2008-07-08 at 10:04 +0200, Buchan Milne wrote:
On Tue, 2008-07-08 at 00:06 -0400, Sambuddho Chakravarty wrote:
Hello I have an openldap server running slapd on 636 (LDAPS) . When I connect from a ldap browser , I am able to successfully browse the database.
Can you be more specific about the software you are using? Not all graphical LDAP clients have SSL validation features (and if they do, in some cases they aren't enabled by default).
It is called 'LDAP BROWSWER' . Website : www.iit.edu/~gawojar/ldap.
However when I try to connect from a linux client machine (Ubuntu Server 8.04) I am not able to connect to the ldaps. However regular ldap works fine.
So, assuming it is not a firewall problem, the most likely cause is certificate validation.
Alright.
The /etc/ldap.conf looks like this
ssl start_tls ssl on
You shouldn't use both of these, only use 'ssl on' if you are using 'host', in the 'uri' case it won't really make a difference.
tls_checkpeer tes
"tes" ???
Thats a typo. It was meant to be 'yes'.
tls_cacertdir /etc/ldap/cacerts tls_cacertfile /etc/ldap/cacert/cacert.pem #server IP uri ldaps://30.0.0.2/
What is the subject CN on the certificate the server has?
Subject CN is the servers's CN./ST/C/emailAddress/O/OU
pam_password md5 base dc=example,dc=com
The /etc/ldap/ldap.conf file is like this
URI ldaps://30.0.0.2/ TLS_CACERTDIR /etc/ldap/cacerts TLS_CACERT /etc/ldap/cacerts/cacert.pem HOST 30.0.0.2 BASE dc=example,dc=com
The same configuration (with approprirate changes - replacing ldaps with ldap and so on) works fine for regular ldap. But the problem is the ldaps.
So, what do you get if you try something like this:
$ openssl s_client -CAfile /etc/ldap/cacerts/cacert.pem -connect 30.0.0.2:636
Does the CN attribute in the server certificate you get back match the hostname in the URI?
No. I check this .
When ldaps client is enabled and I do a getent passed , the /var/log/auth.log looks like this
Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server... Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... Jul 7 23:57:47 host3 getent: nss_ldap: could not search LDAP server - Server is unavailable Jul 7 23:58:18 host3 getent: nss_ldap: reconnecting to LDAP server...
For now, using the OpenLDAP client utilities (ldapsearch) to do the same connection may be an easier way to debug, but once it is working, you need to put the equivalent configuration in /etc/ldap.conf. So, with your current configuration, this would be the way to test with ldapsearch:
$ ldapsearch -x -H ldaps://30.0.0.2 -s base -b dc=example,dc=com namingContexts
However, and certificate-related aspects still need to be in the OpenLDAP library configuration file (/etc/ldap/ldap.conf, or ~/.ldaprc).
Alright.
Please suggest where I could have gone wrong. Any suggestions would be really appreciated.
Hmm, if you were trying to get https working, you would be getting warnings from your browser, this really isn't rocket science, but nss_ldap can't show you warning dialogs, so you need to get the configuration right ...
Let me check with these options and get back to you.
Thanks Sambuddho
Regards, Buchan
On Tuesday 08 July 2008 19:05:05 Sambuddho Chakravarty wrote:
tls_cacertdir /etc/ldap/cacerts tls_cacertfile /etc/ldap/cacert/cacert.pem #server IP uri ldaps://30.0.0.2/
What is the subject CN on the certificate the server has?
Subject CN is the servers's CN./ST/C/emailAddress/O/OU
I was meaning, you should provide the actual value. If it is not 30.0.0.2, your certificate validation should work.
But, if you don't want help, don't post details that people need to help you.
So, what do you get if you try something like this:
$ openssl s_client -CAfile /etc/ldap/cacerts/cacert.pem -connect 30.0.0.2:636
Does the CN attribute in the server certificate you get back match the hostname in the URI?
No. I check this .
No it doesn't match? It does match? Why don't you provide the actual output? Or, don't you want help?
Hello
On Tue, 2008-07-08 at 10:04 +0200, Buchan Milne wrote:
On Tue, 2008-07-08 at 00:06 -0400, Sambuddho Chakravarty wrote:
Hello I have an openldap server running slapd on 636 (LDAPS) . When I connect from a ldap browser , I am able to successfully browse the database.
Can you be more specific about the software you are using? Not all graphical LDAP clients have SSL validation features (and if they do, in some cases they aren't enabled by default).
However when I try to connect from a linux client machine (Ubuntu Server 8.04) I am not able to connect to the ldaps. However regular ldap works fine.
So, assuming it is not a firewall problem, the most likely cause is certificate validation.
The /etc/ldap.conf looks like this
ssl start_tls ssl on
You shouldn't use both of these, only use 'ssl on' if you are using 'host', in the 'uri' case it won't really make a difference.
tls_checkpeer tes
"tes" ???
tls_cacertdir /etc/ldap/cacerts tls_cacertfile /etc/ldap/cacert/cacert.pem #server IP uri ldaps://30.0.0.2/
What is the subject CN on the certificate the server has?
The subject CN on the certificate is the IP address of the server (30.0.0.2); same as that in the HOST field.
pam_password md5 base dc=example,dc=com
The /etc/ldap/ldap.conf file is like this
URI ldaps://30.0.0.2/ TLS_CACERTDIR /etc/ldap/cacerts TLS_CACERT /etc/ldap/cacerts/cacert.pem HOST 30.0.0.2 BASE dc=example,dc=com
The same configuration (with approprirate changes - replacing ldaps with ldap and so on) works fine for regular ldap. But the problem is the ldaps.
So, what do you get if you try something like this:
$ openssl s_client -CAfile /etc/ldap/cacerts/cacert.pem -connect 30.0.0.2:636
Does the CN attribute in the server certificate you get back match the hostname in the URI?
The CN attribute is the server IP address.
When ldaps client is enabled and I do a getent passed , the /var/log/auth.log looks like this
Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server... Jul 7 23:57:46 host3 getent: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... Jul 7 23:57:47 host3 getent: nss_ldap: could not search LDAP server - Server is unavailable Jul 7 23:58:18 host3 getent: nss_ldap: reconnecting to LDAP server...
For now, using the OpenLDAP client utilities (ldapsearch) to do the same connection may be an easier way to debug, but once it is working, you need to put the equivalent configuration in /etc/ldap.conf. So, with your current configuration, this would be the way to test with ldapsearch:
$ ldapsearch -x -H ldaps://30.0.0.2 -s base -b dc=example,dc=com namingContexts
This results the following error : ldap_result: Can't contact LDAP server (-1)
However, and certificate-related aspects still need to be in the OpenLDAP library configuration file (/etc/ldap/ldap.conf, or ~/.ldaprc).
Please suggest where I could have gone wrong. Any suggestions would be really appreciated.
Hmm, if you were trying to get https working, you would be getting warnings from your browser, this really isn't rocket science, but nss_ldap can't show you warning dialogs, so you need to get the configuration right ...
Thanks Sambuddho
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Govind c -
Howard Chu -
Michael Ströder -
Sambuddho Chakravarty