FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 02-22-2010, 04:48 AM
"Paul R. Ganci"
 
Default LDAP Server Access Problem

Hi All,

I am at my wits end. I have a LDAP server setup on a machine (the names
are changed to protect the innocent) example.mydomain.com running CentOS
5.4 and LDAP version 2.3.43-3. If I issue a ldapsearch command while
logged onto the LDAP server host I get a valid response back. For
example:

> ldapsearch -x -LLL -H ldaps://example.mydomain.com:636 "(uid=joker)"
> sn uid
dn: uid=joker,ou=People,dc=mydomain,dc=com
uid: joker
sn: Nicholson

Everything works as expected. However if I try the same command from a
remote machine remote.mydomain.com the command just hangs. I can not
find a log entry anywhere that indicates something is wrong. I have
checked the obvious things I can check. For example I know that port 636
is open:

> /etc/rc.d/init.d/iptables status | grep 636
110 ACCEPT tcp -- 0.0.0.0/0 208.139.195.124 state
NEW,ESTABLISHED tcp dpt:636
111 ACCEPT udp -- 0.0.0.0/0 208.139.195.124 state
NEW,ESTABLISHED udp dpt:636

I have enabled access via /etc/hosts.allow:
> cat /etc/hosts.allow | grep slapd
slapd: ALL

I can see the server running and listening on port 636:
> netstat -l | grep ldaps
tcp 0 0 *:ldaps *:* LISTEN
tcp 0 0 *:ldaps *:* LISTEN

> ps auxww | grep slapd
ldap 21865 0.0 0.2 467976 5860 ? Ssl 19:54
0:02 /usr/sbin/slapd -h ldap:/// ldaps:/// -u ldap

I am missing something very obvious. Can anyone offer any clues? Thanks.

--
Paul (ganci@nurdog.com)


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2010, 05:04 AM
Rajagopal Swaminathan
 
Default LDAP Server Access Problem

Greetings,

On Mon, Feb 22, 2010 at 11:18 AM, Paul R. Ganci <ganci@nurdog.com> wrote:

Hi All,


Everything works as expected. However if I try the same command from a

remote machine remote.mydomain.com the command just hangs.
Sorry if you have already checked it.

In you remote.mydomain.com, does /etc/hosts contain entry for LDAP server? IOW does the names resolve?


Are you able to do the query using IP addresses?

Any evidence/trace of the query packets travelling in the net (say using wireshark)? I usually go this way when confronted with such situation.

Is LDAP* configured to be query-able without any passwords. (I may not be too clear here though)


HTH

Regards,

Rajagopal


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2010, 05:23 AM
Craig White
 
Default LDAP Server Access Problem

On Sun, 2010-02-21 at 22:48 -0700, Paul R. Ganci wrote:
> Hi All,
>
> I am at my wits end. I have a LDAP server setup on a machine (the names
> are changed to protect the innocent) example.mydomain.com running CentOS
> 5.4 and LDAP version 2.3.43-3. If I issue a ldapsearch command while
> logged onto the LDAP server host I get a valid response back. For
> example:
>
> > ldapsearch -x -LLL -H ldaps://example.mydomain.com:636 "(uid=joker)"
> > sn uid
> dn: uid=joker,ou=People,dc=mydomain,dc=com
> uid: joker
> sn: Nicholson
>
> Everything works as expected. However if I try the same command from a
> remote machine remote.mydomain.com the command just hangs. I can not
> find a log entry anywhere that indicates something is wrong. I have
> checked the obvious things I can check. For example I know that port 636
> is open:
>
> > /etc/rc.d/init.d/iptables status | grep 636
> 110 ACCEPT tcp -- 0.0.0.0/0 208.139.195.124 state
> NEW,ESTABLISHED tcp dpt:636
> 111 ACCEPT udp -- 0.0.0.0/0 208.139.195.124 state
> NEW,ESTABLISHED udp dpt:636
>
> I have enabled access via /etc/hosts.allow:
> > cat /etc/hosts.allow | grep slapd
> slapd: ALL
>
> I can see the server running and listening on port 636:
> > netstat -l | grep ldaps
> tcp 0 0 *:ldaps *:* LISTEN
> tcp 0 0 *:ldaps *:* LISTEN
>
> > ps auxww | grep slapd
> ldap 21865 0.0 0.2 467976 5860 ? Ssl 19:54
> 0:02 /usr/sbin/slapd -h ldap:/// ldaps:/// -u ldap
>
> I am missing something very obvious. Can anyone offer any clues? Thanks.
----
ldap ssl is deprecated but should actually still work.

Do you actually have to specify the port number? I don't think so...

-H ldaps://example.mydomain.com
should be sufficient

The preferred method is TLS (via standard -h ldap://example.mydomain.com
uri notation)

Note that ldap 'client' applications like ldapsearch
use /etc/openldap/ldap.conf so I would suspect that the 'certificates'
used by the 2 machines are different.

add -d 256 (or even higher debug level) to the ldapsearch command for
debugging - I'm not going to hazard any actual guesses.

Craig


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2010, 12:47 PM
Dan Burkland
 
Default LDAP Server Access Problem

> -----Original Message-----
> From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On
> Behalf Of Craig White
> Sent: Monday, February 22, 2010 12:23 AM
> To: CentOS mailing list
> Subject: Re: [CentOS] LDAP Server Access Problem
>
> On Sun, 2010-02-21 at 22:48 -0700, Paul R. Ganci wrote:
> > Hi All,
> >
> > I am at my wits end. I have a LDAP server setup on a machine (the names
> > are changed to protect the innocent) example.mydomain.com running CentOS
> > 5.4 and LDAP version 2.3.43-3. If I issue a ldapsearch command while
> > logged onto the LDAP server host I get a valid response back. For
> > example:
> >
> > > ldapsearch -x -LLL -H ldaps://example.mydomain.com:636 "(uid=joker)"
> > > sn uid
> > dn: uid=joker,ou=People,dc=mydomain,dc=com
> > uid: joker
> > sn: Nicholson
> >
> > Everything works as expected. However if I try the same command from a
> > remote machine remote.mydomain.com the command just hangs. I can not
> > find a log entry anywhere that indicates something is wrong. I have
> > checked the obvious things I can check. For example I know that port 636
> > is open:
> >
> > > /etc/rc.d/init.d/iptables status | grep 636
> > 110 ACCEPT tcp -- 0.0.0.0/0 208.139.195.124 state
> > NEW,ESTABLISHED tcp dpt:636
> > 111 ACCEPT udp -- 0.0.0.0/0 208.139.195.124 state
> > NEW,ESTABLISHED udp dpt:636
> >
> > I have enabled access via /etc/hosts.allow:
> > > cat /etc/hosts.allow | grep slapd
> > slapd: ALL
> >
> > I can see the server running and listening on port 636:
> > > netstat -l | grep ldaps
> > tcp 0 0 *:ldaps *:* LISTEN
> > tcp 0 0 *:ldaps *:* LISTEN
> >
> > > ps auxww | grep slapd
> > ldap 21865 0.0 0.2 467976 5860 ? Ssl 19:54
> > 0:02 /usr/sbin/slapd -h ldap:/// ldaps:/// -u ldap
> >
> > I am missing something very obvious. Can anyone offer any clues? Thanks.
> ----
> ldap ssl is deprecated but should actually still work.
>
> Do you actually have to specify the port number? I don't think so...
>
> -H ldaps://example.mydomain.com
> should be sufficient
>
> The preferred method is TLS (via standard -h ldap://example.mydomain.com
> uri notation)
>
> Note that ldap 'client' applications like ldapsearch
> use /etc/openldap/ldap.conf so I would suspect that the 'certificates'
> used by the 2 machines are different.
>
> add -d 256 (or even higher debug level) to the ldapsearch command for
> debugging - I'm not going to hazard any actual guesses.
>
> Craig
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
-----------------------

I can confirm that indeed ldaps still works fine as I recently implemented such a setup on my network a few months ago (OpenLDAP). Make sure the clocks on both machines are in sync as that will cause problems with the certs for example if cert was generated "in the future". Also, what was your process in creating certificates for your LDAP infrastructure?
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2010, 02:44 PM
"Paul R. Ganci"
 
Default LDAP Server Access Problem

> >
> > Note that ldap 'client' applications like ldapsearch
> > use /etc/openldap/ldap.conf so I would suspect that the 'certificates'
> > used by the 2 machines are different.
>>
This might be the missing piece.

The certificates were generated from a signing request to CAcert.
However, while the certificate is installed on the server machine it is
not installed on the remote machine. I didn't think that was necessary
especially given that the certificate was generated explicitly for
example.mydomain.com. I can try this.

I do know that the CAcert root certificate is not accepted by LDAP as
coming from a valid certificate root authority. I manage to get around
this by explicitly adding CAcert's root certificate
to /etc/pki/tls/certs/ca-bundle.crt and adding that path to
the /etc/openldap/ldap.conf config. I will try installing the
certificate and then adding the path in /etc/openldap/ldap.conf. I
probably should have shown the /etc/openldap/ldap.conf file. For the
record here it is:

HOST example.mydomain.com
BASE dc=mydomain,dc=com
URI ldaps://example.mydomain.com:636/
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
TLS_CACERTDIR /etc/openldap/cacerts

Have to go to work now so will try later. Thanks.

> >
> > add -d 256 (or even higher debug level) to the ldapsearch command for
> > debugging - I'm not going to hazard any actual guesses.

Thanks for this suggestion ... should have thought of it myself.

--
Paul (ganci@nurdog.com)


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2010, 05:41 PM
Jay Leafey
 
Default LDAP Server Access Problem

Paul R. Ganci wrote:

Note that ldap 'client' applications like ldapsearch
use /etc/openldap/ldap.conf so I would suspect that the 'certificates'
used by the 2 machines are different.

This might be the missing piece.


The certificates were generated from a signing request to CAcert.
However, while the certificate is installed on the server machine it is
not installed on the remote machine. I didn't think that was necessary
especially given that the certificate was generated explicitly for
example.mydomain.com. I can try this.

I do know that the CAcert root certificate is not accepted by LDAP as
coming from a valid certificate root authority. I manage to get around
this by explicitly adding CAcert's root certificate
to /etc/pki/tls/certs/ca-bundle.crt and adding that path to
the /etc/openldap/ldap.conf config. I will try installing the
certificate and then adding the path in /etc/openldap/ldap.conf. I
probably should have shown the /etc/openldap/ldap.conf file. For the
record here it is:

HOST example.mydomain.com
BASE dc=mydomain,dc=com
URI ldaps://example.mydomain.com:636/
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
TLS_CACERTDIR /etc/openldap/cacerts

Have to go to work now so will try later. Thanks.


add -d 256 (or even higher debug level) to the ldapsearch command for
debugging - I'm not going to hazard any actual guesses.


Thanks for this suggestion ... should have thought of it myself.



It occurs to me that you can turn off certificate validation by setting
the TLS_REQCERT entry in either /etc/openldap/ldap.conf or
${HOME}/.ldaprc. Here's part of my .ldaprc:



TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt
TLS_REQCERT never


If you run ldapsearch in with "-d 1" you will see that it is indeed
using the server's certificate but is not checking it for validity. I
usually use this for testing purposes.


Also, you generally don't want to use both HOST and URI at the same
time. It can sometimes confuse issues.

--
Jay Leafey - Memphis, TN
jay.leafey@mindless.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2010, 11:24 PM
Craig White
 
Default LDAP Server Access Problem

On Mon, 2010-02-22 at 07:47 -0600, Dan Burkland wrote:

>
> I can confirm that indeed ldaps still works fine as I recently implemented such a setup on my network a few months ago (OpenLDAP).
----
doing a new setup using methodologies that have already been tagged as
deprecated seems to be a really bad idea. Even though it currently
works, you can be certain that at some point down the road, it will
cease to work... that is what deprecated means.

Craig


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2010, 12:57 PM
Dan Burkland
 
Default LDAP Server Access Problem

> -----Original Message-----
> From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On
> Behalf Of Craig White
> Sent: Monday, February 22, 2010 6:25 PM
> To: CentOS mailing list
> Subject: Re: [CentOS] LDAP Server Access Problem
>
> On Mon, 2010-02-22 at 07:47 -0600, Dan Burkland wrote:
>
> >
> > I can confirm that indeed ldaps still works fine as I recently
> implemented such a setup on my network a few months ago (OpenLDAP).
> ----
> doing a new setup using methodologies that have already been tagged as
> deprecated seems to be a really bad idea. Even though it currently
> works, you can be certain that at some point down the road, it will
> cease to work... that is what deprecated means.
>
> Craig
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

I am well aware of that, it was my first OpenLDAP setup Hopefully sooner rather than later I'll be able to migrate my systems to use TLS over 389 instead of SSL over 636.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-28-2010, 04:07 PM
"Paul R. Ganci"
 
Default LDAP Server Access Problem

On Sun, 2010-02-21 at 23:23 -0700, Craig White wrote:
> Note that ldap 'client' applications like ldapsearch
> use /etc/openldap/ldap.conf so I would suspect that the 'certificates'
> used by the 2 machines are different.

I thought I would follow up on this problem. I did finally get the
ldapsearch to function properly on the remote machine. However, I am
puzzled as to what I had to do to get it to work. I originally never
setup a certificate for the client as I did not think they were needed.
In my /etc/openldap/slapd.conf file I had to set up the LDAP server with
the following:

TLSVerifyClient never

I had the initial setup with

TLSVerifyClient allow

According to man slapd.conf:

TLSVerifyClient <level>
Specifies what checks to perform on client certificates in an incoming
TLS session, if any. The <level> can be specified as one of the
following keywords:

never This is the default. slapd will not ask the client for a
certificate.

allow The client certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certificate is
provided, it will be ignored and the session proceeds normally.

try The client certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certificate is
provided, the session is immediately terminated.

demand | hard | true
These keywords are all equivalent, for compatibility reasons.
The client certificate is requested. If no certificate is
provided, or a bad certificate is provided, the session is
immediately terminated.

Note that a valid client certificate is required in order to use
the SASL EXTERNAL authentication mechanism with a TLS session.
As such, a non-default TLSVerifyClient setting must be chosen to
enable SASL EXTERNAL authentication.

Note that according to the documentation the original setup should have
worked properly. Why doesn't "allow" work?

--
Paul (ganci@nurdog.com)


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-28-2010, 04:10 PM
"Paul R. Ganci"
 
Default LDAP Server Access Problem

On Mon, 2010-02-22 at 17:24 -0700, Craig White wrote:

> doing a new setup using methodologies that have already been tagged as
> deprecated seems to be a really bad idea. Even though it currently
> works, you can be certain that at some point down the road, it will
> cease to work... that is what deprecated means.

My LDAP server has been running for several years now and was initially
setup to use ldaps. Only recently I wanted to use it for remote
authentication which is how I ended up going down this path. It doesn't
take that much effort to fix the LDAP server to use TLS which I will do
as soon as I can get to it.
--
Paul (ganci@nurdog.com)


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 02:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org