Trying to enable SSL Authentication - Apache2 to eDir LDAP

Have a SLES 11 sp2 server running Apache 2.2.12. Up to now we have been using plain text LDAP authentication to our eDirectory server and that has worked fine. Want to enable SSL but am getting Apache error screen upon attempting to enable SSL authentication. I know the exported server certificate is good because am using the same cert in some Sonicwall firewalls to enable SSL LDAP authentication for VPN to the same eDir server. Here is the code in our “ldap-login.conf” file (included in our httpd.conf file for Apache).

The way these lines are now, it works plain text. When I uncomment lines #2 & #13 and comment out line #14, that is when it stops working. Is there something I need that is missing? Thanks!

  1. Following line may be needed for LDAPS

  2. LDAPTrustedGlobalCert CA_DER /root/certs/dgw-edir.der

  3. <Directory “/srv/www/htdocs/”>
  4. Options Indexes FollowSymLinks
  5. AllowOverride None
  6. Order allow,deny
  7. Allow from All
  8. AuthName “Protected”
  9. AuthType Basic
  10. AuthBasicAuthoritative off
  11. AuthBasicProvider ldap
  12. AuthzLDAPAuthoritative on
  13. AuthLDAPURL ldaps://10.0.0.1:636/o=dgww?cn?sub

  14. AuthLDAPURL ldap://10.0.0.1:389/o=dgww?cn?sub
  15. Require valid-user

Hi donahueit,

Is there something I need that is missing?

It might be interesting to see what’s in Apache’s error log when you try to access the resource.

Can you access that ldaps URI when using i.e. “ldapsearch” from the command line?

Regards,
Jens

jmozdzen wrote:
[color=blue]

It might be interesting to see what’s in Apache’s error log when you try
to access the resource.[/color]

No need to access the resource as there should be some LDAP-related [info]
entries in /var/log/apache2/error_log (default error log file unless
changed) when Apache is (re)started.

HTH.

Simon
SUSE Knowledge Partner

Good point - checking the error log. Here is what it records as I attempt to authenticate via Apache:

[Thu Nov 14 16:01:57 2013] [warn] RSA server certificate CommonName (CN) OakWebAcc.donahue.com' does NOT match server name!? [Thu Nov 14 16:01:57 2013] [warn] RSA server certificate CommonName (CN) OakWebAcc.donahue.com’ does NOT match server name!?
[Thu Nov 14 16:01:57 2013] [notice] Apache/2.2.12 (Linux/SUSE) PHP/5.2.14 with Suhosin-Patch mod_ssl/2.2.12 OpenSSL/0.9.8j-fips configured – resuming normal operations
[Thu Nov 14 16:03:07 2013] [warn] [client 10.0.0.64] [27070] auth_ldap authenticate: user don authentication failed; URI / [LDAP: ldap_simple_bind_s() failed][Can’t contact LDAP server]
[Thu Nov 14 16:03:07 2013] [crit] [client 10.0.0.64] configuration error: couldn’t check user. No user file?: /
[Thu Nov 14 16:03:24 2013] [notice] caught SIGTERM, shutting down

OakWebAcc is the host name for the WebAccess server running Apache. The eDirectory (LDAP) server host name is OakMaster. Now, all I did was perform a simple export of the CA server certificate from the OakMaster server (which is, in fact, the CA for eDirectory). And, using this certificate I was able to import it into our Sonicwall firewalls and then successfully perform secure LDAP (636) authentication to the OakMaster server. But, Apache apparently doesn’t like this certificate. By the way, this Apache server is using it’s own, self-signed certificate which allows it to support https. Do I need to export a different kind of certificate from OakMaster in this case? Thanks!

Don

Hi Don,

[QUOTE=donahueit;17484]Good point - checking the error log. Here is what it records as I attempt to authenticate via Apache:

[Thu Nov 14 16:01:57 2013] [warn] RSA server certificate CommonName (CN) OakWebAcc.donahue.com' does NOT match server name!? [Thu Nov 14 16:01:57 2013] [warn] RSA server certificate CommonName (CN) OakWebAcc.donahue.com’ does NOT match server name!?
[Thu Nov 14 16:01:57 2013] [notice] Apache/2.2.12 (Linux/SUSE) PHP/5.2.14 with Suhosin-Patch mod_ssl/2.2.12 OpenSSL/0.9.8j-fips configured – resuming normal operations
[Thu Nov 14 16:03:07 2013] [warn] [client 10.0.0.64] [27070] auth_ldap authenticate: user don authentication failed; URI / [LDAP: ldap_simple_bind_s() failed][Can’t contact LDAP server]
[Thu Nov 14 16:03:07 2013] [crit] [client 10.0.0.64] configuration error: couldn’t check user. No user file?: /
[Thu Nov 14 16:03:24 2013] [notice] caught SIGTERM, shutting down

OakWebAcc is the host name for the WebAccess server running Apache. The eDirectory (LDAP) server host name is OakMaster. Now, all I did was perform a simple export of the CA server certificate from the OakMaster server (which is, in fact, the CA for eDirectory). And, using this certificate I was able to import it into our Sonicwall firewalls and then successfully perform secure LDAP (636) authentication to the OakMaster server. But, Apache apparently doesn’t like this certificate. By the way, this Apache server is using it’s own, self-signed certificate which allows it to support https. Do I need to export a different kind of certificate from OakMaster in this case? Thanks!

Don[/QUOTE]

though only classified as “warn”, the IMO more important message is about not being able to contact the LDAP server you configured. Have you run a manual query to that LDAP server from your web server, i.e. via “ldapsearch”, to confirm accessibility?

Regards,
Jens

[QUOTE=jmozdzen;17487]Hi Don,

though only classified as “warn”, the IMO more important message is about not being able to contact the LDAP server you configured. Have you run a manual query to that LDAP server from your web server, i.e. via “ldapsearch”, to confirm accessibility?

Regards,
Jens[/QUOTE]

Hi Jens,

ldapsearch does work at port 389 but does not work at 636, which is what I was expecting. When I use port 636, it says “can’t contact server”. But, as I indicated in my earlier post, the exported certificate I am using is working fine with our Sonicwall firewalls so the server is indeed responding on port 636 in that case. Thanks.

Don

Hi Don,

[QUOTE=donahueit;17504]Hi Jens,

ldapsearch does work at port 389 but does not work at 636, which is what I was expecting. When I use port 636, it says “can’t contact server”. But, as I indicated in my earlier post, the exported certificate I am using is working fine with our Sonicwall firewalls so the server is indeed responding on port 636 in that case. Thanks.

Don[/QUOTE]

I’m not as convinced (yet) as you are: Both httpd and ldapsearch (AKA “a generic LDAP client”) report they cannot reach the LDAP server - I’m thinking along the lines of a blocking firewall in between the server in question and the LDAP server, or similar, and am trying to rule that out. (I’ve just learned by testing that ldapsearch will actually report the same if it i.e. can connect to the LDAP server, but is unable to established the protocol - so use “-d1” for details, see below).

Is the firewall you mentioned (or any other filtering device) in the network path between the LDAP server and the httpd server?

Can you run “telnet 636” from the server in question? If it reports “connection refused” or the connect times out, although slapd is listening on 636, then you might want to check the “network path” between the two servers for intercepting firewalls, including “iptables” on both servers. (And as you reported that your firewall system can connect to your LDAP server on port 636, yes the LDAP server should be listening :slight_smile: ).

Also, if you run ldapsearch with debugging even at the lowest level (-d1), you should see if the client actually could establish an IP socket connection and fails during TLS/SSL negotiation, too.

If both servers are in the same IP subnet, without intercepting machines in between, the above are a bit “overkill”, of course.

Regards,
Jens

Hi Jens,

I double checked firewall settings on the LDAP server and port 636 is open. Then I tested telnet to port 636 from the source (webaccess) server and I get connection - same for port 389 (which works fine anyway for LDAP authentication). So, I don’t know, I am thinking it is more of an issue with the source server and the certificate it has to use for port 636 to work for authentication. These systems are on the same subnet - there is no firewall device sitting between them. Thanks.

Don

[QUOTE=jmozdzen;17509]Hi Don,

I’m not as convinced (yet) as you are: Both httpd and ldapsearch (AKA “a generic LDAP client”) report they cannot reach the LDAP server - I’m thinking along the lines of a blocking firewall in between the server in question and the LDAP server, or similar, and am trying to rule that out. (I’ve just learned by testing that ldapsearch will actually report the same if it i.e. can connect to the LDAP server, but is unable to established the protocol - so use “-d1” for details, see below).

Is the firewall you mentioned (or any other filtering device) in the network path between the LDAP server and the httpd server?

Can you run “telnet 636” from the server in question? If it reports “connection refused” or the connect times out, although slapd is listening on 636, then you might want to check the “network path” between the two servers for intercepting firewalls, including “iptables” on both servers. (And as you reported that your firewall system can connect to your LDAP server on port 636, yes the LDAP server should be listening :slight_smile: ).

Also, if you run ldapsearch with debugging even at the lowest level (-d1), you should see if the client actually could establish an IP socket connection and fails during TLS/SSL negotiation, too.

If both servers are in the same IP subnet, without intercepting machines in between, the above are a bit “overkill”, of course.

Regards,
Jens[/QUOTE]

Hi Don,

[QUOTE=donahueit;17531]Hi Jens,

I double checked firewall settings on the LDAP server and port 636 is open. Then I tested telnet to port 636 from the source (webaccess) server and I get connection - same for port 389 (which works fine anyway for LDAP authentication). So, I don’t know, I am thinking it is more of an issue with the source server and the certificate it has to use for port 636 to work for authentication. These systems are on the same subnet - there is no firewall device sitting between them. Thanks.

Don[/QUOTE]

I’m convinced :wink:

I had a look at the mod_ldap docs (http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#ldaptrustedglobalcert), the section on LDAPGlobalTrustedCert. It says:

You’ve set it globally, have you tried setting it per directory per LDAPTrustedClientCert?

Regards,
Jens

[QUOTE=jmozdzen;17532]Hi Don,

I’m convinced :wink:

I had a look at the mod_ldap docs (http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#ldaptrustedglobalcert), the section on LDAPGlobalTrustedCert. It says:

You’ve set it globally, have you tried setting it per directory per LDAPTrustedClientCert?

Regards,
Jens[/QUOTE]

I also noticed that information about needing to use LDAPGlobalTrustedCert in a Novell environment (but does that also hold true when the LDAP server is not really “Novell” but is SLES 11 running OES?). Do you think it could have something to do with file properties of the .der file? I just copied it into this directory - /root/certs and it shows up as:

-rw-r–r-- 1 root root … dgw-edir.der

Thanks,
Don

Hi Don,

from your first post it looks to me like you’re doing it “the Novell way” - using LDAPGlobalTrustedCert at the global level. Have you ever tried LDAPTrustedClientCert at the directory level instead, as the docs suggest in case of problems?
And I believe mod_ldap docs is not about the server, but about the client-side libs, where you’re using openldap from what I can tell. Either way - if one way doesn’t work, try the other way.

[QUOTE=donahueit;17535]Do you think it could have something to do with file properties of the .der file? I just copied it into this directory - /root/certs and it shows up as:

-rw-r–r-- 1 root root … dgw-edir.der[/QUOTE]

I don’t see a problem with the der file, but the directories’ permissions (/root, /root/cert) might be restricting access once httpd has switched user to “wwwrun”. The certificate itself needs no specific protection, so you may put it in any public place. It’s just the private key part that is, hm, private :wink: , and needs specific protection. I cannot tell for sure if httpd will open the file while still running as root, so it’d do no harm to make sure wwwrun can access that file.

Regards,
Jens

[QUOTE=donahueit;17445]Have a SLES 11 sp2 server running Apache 2.2.12. Up to now we have been using plain text LDAP authentication to our eDirectory server and that has worked fine. Want to enable SSL but am getting Apache error screen upon attempting to enable SSL authentication. I know the exported server certificate is good because am using the same cert in some Sonicwall firewalls to enable SSL LDAP authentication for VPN to the same eDir server. Here is the code in our “ldap-login.conf” file (included in our httpd.conf file for Apache).

The way these lines are now, it works plain text. When I uncomment lines #2 & #13 and comment out line #14, that is when it stops working. Is there something I need that is missing? Thanks!

  1. Following line may be needed for LDAPS

  2. LDAPTrustedGlobalCert CA_DER /root/certs/dgw-edir.der

  3. <Directory “/srv/www/htdocs/”>
  4. Options Indexes FollowSymLinks
  5. AllowOverride None
  6. Order allow,deny
  7. Allow from All
  8. AuthName “Protected”
  9. AuthType Basic
  10. AuthBasicAuthoritative off
  11. AuthBasicProvider ldap
  12. AuthzLDAPAuthoritative on
  13. AuthLDAPURL ldaps://10.0.0.1:636/o=dgww?cn?sub

  14. AuthLDAPURL ldap://10.0.0.1:389/o=dgww?cn?sub
  15. Require valid-user
  16. [/QUOTE]

Hi!
I have exactly the same problem.
LDAP logs answer a TLS Negotiation failure. But the cert is running ok betwen ldap client and ldap server.
Looks like we need to put something else to accept the LDAP server TLS cert by default.

How about both of you give a read. At SUSECon a week ago Lawrence Kearney
gave a great presentation on integrating Apache httpd with LDAP (eDir,
OpenLDAP, microsoft active directory (MAD), etc.) and while there were a
lot of slides on the caveats/hassles on the MAD side the basic
configuration looks pretty good. I have not tried his steps yet, but
included are some great tips for troubleshooting.

https://event.susecon.com/connect/sessionDetail.ww?SESSION_ID=1350

https://event.susecon.com/connect/fileDownload/session/D3E6DCEE55EA4582B153666043EBBAD7/TT1350_Mejia-TT1350.pdf

Specifically look for the ldapsearch example that lets you use an SSL
certificate using an environment variable when calling ldapsearch. Also
look at the various configuration options such as ‘LDAPTrustedMode’ which
he set to SSL and which may help.

Finally, while I do not remember if he called it out explicitly, it
probably makes the most sense to export your Trusted Root certificate vs.
the Public Key certificate from the Key Material Object (KMO, aka
certificate object in eDirectory). This is he same object as the
‘Self-Signed Certificate’ on the Certificate Authority (CA).


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

donahueit,
You’re on the right track, but I’d make a couple of adjustments.

1- Do use your eDir CA trusted root cert, consider using the “LDAPVerifyServerCert OFF” global directive so Apache doesn’t try to resolve the cert signing chain as it would a globally published cert, such as from Verisign or Go Daddy for example.

2- Convert your “dgw-edir.der” certificate (assuming this is your eDir trusted root cert) from the “.der” format to a “pem” formatted cert. The .der file should work with the Novell LDAP SDK being present, but just eliminate the possibly of something being wrong in this stack by using a cert format all OpenLDAP stacks will understand. www.sslshopper.com can handle this for you easily (specifically, http://www.sslshopper.com/ssl-certificate-tools.html ). It’s what I do and I usually use a .crt extension, but it really doesn’t matter :slight_smile:

3- To simplify your configuration consider using the “LDAPTrustedMode SSL” global directive and the “ldaps://” format in your “AuthLDAPURL” directive. TLS connections have different nuances and require more configuration effort and assessment to identify working configurations. Ensure SSL is working, simply, before implementing TLS if needed.

4- Lose the port specification in your AuthLDAPURL directive. Technically it should work but the directive understands ldap (unsecure and TLS secured) and ldaps on the standard ports of 389 and 636 respectively. Simple is better and only specify ports that are non-standard as best practice.

5- Lose the “AuthzLDAPAuthoritative on” directive as it’s on by default (again, simple is better). I include it in presentations for demonstrative purposes only. Basically with it on Apache will not fall back to other authentication criteria (like local databases or htaccess files) if LDAP auth fails.

6- Lose the “AuthBasicAuthoritative off” directive … if you’re only using LDAP authentication than the "“AuthzLDAPAuthoritative” directive has you covered

7- Use DSTrace in your eDir environment to see what’s being talked about at your eDir LDAP server :slight_smile:

8- Finally, if necessary use the ldapsearch util on the SLES server to test LDAP connections to the eDir backend. Ensure the “/etc/openldap/ldap.conf” file is configured with the same global SSL parameters. This file is used by LDAP clients on the server whereas the “/etc/ldap.conf” is used by the server and Apache, for example. Try using the “LDAPTLS_CACERT=” directive preceding the ldapsearch command line (but on the same command line seperated by a space) if you don’t want to modify the “/etc/openldap/ldap.conf” file.

This can be a busy tool to use but it’s the troubleshooting scalpel you’ll need to get accurate insight into what is or isn’t happening with your LDAP backend.

From what I’ve seen so far this should be enough to help get your basic configuration going. Do consider that once it is working consider there may be more to do. Can or should you use TLS instead of SSL ? Can you optimise the configuration further ? Can or should you implement more granular authorisation security (group membership or other attribute value validation) ?

Let us know how it goes and how we can help further … Have alot of fun :slight_smile:

– lawrence