Here are the changes I'd review:
1. After installing the CA cert, did you create a hash link? E.g.,
/usr/sbin/cacertdir_rehash /etc/openldap/cacerts
2. Make sure you know the difference between /etc/ldap.conf and /etc/openldap/ldap.conf. The former is used by nss_ldap, the latter by openldap clients.
3. Does /etc/ldap.conf have all the correct TLS entries, e.g.,
ssl start_tls tls_checkpeer yes tls_cacertdir /etc/openldap/cacerts
Additionally, I've had trouble using the "uri" directive in /etc/ldap.conf, esp. with encrypted connections. The "host" and "port" directives have worked better for me.
4. Does /etc/pam.d/system-auth have pam_ldap.so entries for auth, account, password, and session?
5. Are you running nscd? (I've found it indispensable when working with network auth.)
6. Review the changes to /etc/nsswitch.conf to make sure that the passwd, shadow, and group entries all query ldap.
Thanks a lot for this check-list (I recommend it for others in the future).
I had already checked most of the points, but I still played around with your ideas, without success
But, this remark:
I've never done ldaps to port 636, only TLS to port 389, so some of my comments may be slightly off-base in your situtation.
made me think of checking what should be the difference between a START_TLS on a plain ldap port and ldaps on the ssl port
In /etc/ldap.conf:
for ldap + START_TLS this is indeed
ssl start_tls
but for ldaps (my case) this should be: ssl on
Changing the value of 'ssl' to 'on' solved my problem! (and this explains why my ldapsearch queries were working: as you pointed out, /etc/ldap.conf is for the configuration of nss_ldap)
IMHO, the comments in /etc/ldap.conf could be a bit more explicit on the 'on' value:
... # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls #ssl on ...
Thanks a lot for your help!
Are you aware that SSL on port 636 is now considered deprecated in favor of START_TLS on port 389?
Are you aware that SSL on port 636 is now considered deprecated in favor of START_TLS on port 389?
No, I'm not (I actually thought that it was the other way round)
I found it practical to have a port (389 or equivalent) that I could authorize via iptables only on the local network., and another one (636 or equivalent) that could be accessed from outside.
What are the pro and cons of both approaches?
Comments more than welcome!
Are you aware that SSL on port 636 is now considered deprecated in favor of START_TLS on port 389?
No, I'm not (I actually thought that it was the other way round)
(...)
What are the pro and cons of both approaches?
Comments more than welcome
You can, as an example, consult the Wikipedia article on LDAP. It states:
---------------------------------------------------
StartTLS
The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). During TLS negotiation the server sends its X.509 certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though technically the server may use any identity information established at any lower level, typically the server will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways: 1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and 2) the LDAPS connection must be closed upon TLS closure.
LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defined. The use of LDAPS is deprecated, and modern software should only use StartTLS .
http://en.wikipedia.org/wiki/LDAP
---------------------------------------------------
A quick search will provide plenty of articles about the subject.
A quick search will provide plenty of articles about the subject.
Thanks, I had actually thought of using a search engine (as somebody put it, part of the fun with configuring OpenLDAP is that you definitely have to).
What I cannot find (yet) is whether there is a way to require StartTLS only for external connections and allow it plain on the local network?
The reason why I (think I) need both is that many third party apps on the server (PHP applications typically) do not easily manage StartTLS. Meanwhile, having two different ports make it easier to manage via iptables.
The reason why I (think I) need both is that many third party apps on the server (PHP applications typically) do not easily manage StartTLS. Meanwhile, having two different ports make it easier to manage via iptables.
You can also use StartTLS over the network and LDAPI (connection over Unix sockets, which are inherently secure) for apps running on the server. I use it, both with OpenLDAP and 389 Directory Server (a.k.a. Fedora DS, Red Hat DS).
You can also use StartTLS over the network and LDAPI (connection over Unix sockets, which are inherently secure) for apps running on the server. I use it, both with OpenLDAP and 389 Directory Server (a.k.a. Fedora DS, Red Hat DS).
Unfortunately, I have a whole LAN whose user/group/auth management is centralized with LDAP (each server having different apps). So I need plain LDAP access on the LAN.
On Thu, 7 Oct 2010, Mathieu Baudier wrote:
You can also use StartTLS over the network and LDAPI (connection over Unix sockets, which are inherently secure) for apps running on the server. I use it, both with OpenLDAP and 389 Directory Server (a.k.a. Fedora DS, Red Hat DS).
Unfortunately, I have a whole LAN whose user/group/auth management is centralized with LDAP (each server having different apps). So I need plain LDAP access on the LAN.
One possible solution is to have the main LDAP server addressable only via STARTTLS and a non-SSL, read-only slave on a different host that's visible only to your LAN.
Read up on the "syncrepl" directive for use in slapd.conf.
The slave could even exist in a VM hosted on the main LDAP server, since it's a very lightweight service.
One possible solution is to have the main LDAP server addressable only via STARTTLS and a non-SSL, read-only slave on a different host that's visible only to your LAN.
Very interesting. It would also address some concerns I had with all these third-party LDAP plugins having (potential) write access to the repo.
Thanks a lot for the idea!
Hello Please I want help in centos server I can ping the gateway or my eth1 ip address but i cant browse from my server could you help me with the codes the codes that will enable network cause i've already configure my iptables and it's showing me that everything is ok. Please help Thank you.
Date: Wed, 6 Oct 2010 22:27:08 +0100 From: miguelmedalha@sapo.pt To: mbaudier@argeo.org CC: centos@centos.org Subject: Re: [CentOS] LDAP authentication on a remote server (via ldaps://) [SOLVED]
Are you aware that SSL on port 636 is now considered deprecated in favor of START_TLS on port 389?
No, I'm not (I actually thought that it was the other way round)
(...)
What are the pro and cons of both approaches?
Comments more than welcome
You can, as an example, consult the Wikipedia article on LDAP. It states:
StartTLS
The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). During TLS negotiation the server sends its X.509 certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though technically the server may use any identity information established at any lower level, typically the server will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways: 1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and 2) the LDAPS connection must be closed upon TLS closure.
LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defined. The use of LDAPS is deprecated, and modern software should only use StartTLS .
http://en.wikipedia.org/wiki/LDAP
A quick search will provide plenty of articles about the subject.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, Oct 06, 2010 at 06:35:14PM +0200, Mathieu Baudier wrote:
IMHO, the comments in /etc/ldap.conf could be a bit more explicit on the 'on' value:
IMNSHO most docmentation on LDAP is laughable, and perhaps one of the main reasons Active Directory has become so much more popular. Say what you want about MS, but it does seem to me, that at least on the syadmin and user side that their documentation is usually quite good, at least since Windows 2000.
RH in particular has some really poor docs--as mentioned earlier, they didn't feel it necessary to mention that they'd broken SSL and TLS.
As the authors of the excellent ldap for rocket scientists page say.
"The bad news is that IOHO never has so much been written so incomprehensibly about a single topic with the possible exceptions of BIND."
(That page is at http://www.zytrax.com/books/ldap/)
Might as well spam my own page while at it. :)
http://home.roadrunner.com/~computertaijutsu/ldap.html
Grouchily yours (and REALLY sick of the low quality of so much Linux documentation)
Scott Robbins wrote:
On Wed, Oct 06, 2010 at 06:35:14PM +0200, Mathieu Baudier wrote:
IMHO, the comments in /etc/ldap.conf could be a bit more explicit on the 'on' value:
IMNSHO most docmentation on LDAP is laughable, and perhaps one of the main reasons Active Directory has become so much more popular. Say what you want about MS, but it does seem to me, that at least on the syadmin and user side that their documentation is usually quite good, at least since Windows 2000.
<snip>
As the authors of the excellent ldap for rocket scientists page say.
"The bad news is that IOHO never has so much been written so incomprehensibly about a single topic with the possible exceptions of BIND."
(That page is at http://www.zytrax.com/books/ldap/)
<snip> Well, that's simply *not* true... says the guy who, 20-30 years ago, had to read IBM mainframe manuals....
mark "this postfix left blank"
Well, that's simply *not* true... says the guy who, 20-30 years ago, had to read IBM mainframe manuals....
I can attest to IBM manuals of that era. :-)
Few years back while working for a bank I came across one of the original manuals for the IBM 4702 Branch Controller. And I thought early eServer manuals were a tough slog. ;-)
-
Drew -
m.roth＠5-cent.us -
Mathieu Baudier -
Miguel Medalha -
Paul Heinlein -
Scott Robbins -
Smith Erick Marume-Bahizire