How do I properly configure SimpleSAMLphp to use LDAPS?

[jpio...@gmail.com]

I'm trying to set up SimpleSAMLphp for authentication to Google Apps.  I have everything working for LDAP but am having trouble with LDAPS.  We are using Windows with IIS for the SAML server.

What I've done so far:

• I've installed the CA and Intermediate CA certs into the Trusted Root Certificate store using the MMC tool.
• I've tested LDAPS connectivity through an LDAP tool called LDAPAdmin and confirmed that I can connect to my AD server for LDAPS searches.
• I've changed the authsources.php file so that 'hostname' => 'ldaps://myserver' and 'port' => 636

This is were I'm thinking I'm missing something.  Is there more to configure?

I'm not yet configuring the Google side of things, just testing connectivity to my Active Directory server for authentication.

What happens is:

• When I test the login page I'm getting this message:   Authentication error in source %AUTHSOURCE%. The reason was: %REASON%
• The log file shows this:
  Nov 08 10:30:17 simplesamlphp DEBUG [31d396a07f] Library - LDAP __construct(): Setup LDAP with host='ldaps://hidden.for.security', tls=false, debug=false, timeout=0, referrals=false
  Nov 08 10:30:17 simplesamlphp ERROR [31d396a07f] Library - LDAP bind(): Bind failed with DN 'useracct'; cause: 'Can't contact LDAP server' (0xffffffffffffffff); additional: 'error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate)'
• Using WireShark I get an Unknown CA error.  (This only happens for the SimplaSAMLphp connection and not LDAPAdmin testing.

I'm new to SimpleSAMLphp so I'm thinking I'm missing something somewhere that resulting in the failures.

John

[Tim van Dijen]

Your problem here is that php-ldap doesn't care about your Trusted Root Store... It will use it's own..
Now, I don't know how to fix this on Windows properly, but I do know how to turn off certificate checking completely:
Add an environment variable to your machine called 'TLS_REQCERT' value 'never' and restart php + webserver.

[Peter Schober]

* jpio...@gmail.com <jpio...@gmail.com> [2017-11-08 16:53]:
> - I've installed the CA and Intermediate CA certs into the Trusted Root

> Certificate store using the MMC tool.

If the SSL server is configured correctly (i.e., it will send the
server cert and the any intermediates in correct order) the SSL client
will only need to know the root CA (i.e., the one issuing the
intermediates).

> (0xffffffffffffffff); additional: 'error:14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed (unable to
> get local issuer certificate)'

> - Using WireShark I get an Unknown CA error. (This only happens for the

> SimplaSAMLphp connection and not LDAPAdmin testing.

No idea, but instead of what Tim suggtested (which results in
passwords and all other data being sent on the network in cleartext!)
I recommend you read up on that topic elsehwere.

It's not a SSP setting (AFAIK), it's PHP deployment-specific.
Since the documentation doesn't mention anything about this...
https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/ldap/docs/ldap.md
I wonder whether there should in fact be a configuration for this, or
at least a hint on how/where to configure this.

-peter

[Tim van Dijen]

Op donderdag 9 november 2017 14:10:04 UTC+1 schreef Peter Schober:

No idea, but instead of what Tim suggtested (which results in
passwords and all other data being sent on the network in cleartext!)
I recommend you read up on that topic elsehwere.

Thanks for the wakeup-call Peter!
I obviously meant TLS_CRLCHECK = never

[jpio...@gmail.com]

Thanks for the suggestions.  I have resolved the issue.  It was not easy as through days of Google searches I was not able to find an answer but enough “parts” to piece together the solution.

 

What I needed to do was this:

 

Under PHP 7.1 when using LDAP apparently older versions created a folder “c:\openldap\sysconf” which held the ldap.conf file.  I needed to create this folder and the configuration file.  I also needed to create a .PEM format copy of my intermediate and certificate authority certificates as a combined file and place it in the folder “c:\openldap\sysconf\certs”.   My ldap.conf file looks like this:

 

#--begin--

 

# Instruct client to NOT request a server's cert.

TLS_REQCERT allow

 

# Define location of CA cert

TLS_CACERT C:\openldap\sysconf\certs\cacert.pem

TLS_CACERTDIR C:\openldap\sysconf\certs

 

#--end—

 

 

Once I did this and restarted my web services both php ldaps requests worked and so did the SimplaSAMLphp requests.

[Peter Schober]

* jpio...@gmail.com <jpio...@gmail.com> [2017-11-09 18:13]:

> Thanks for the suggestions. I have resolved the issue. It was not
> easy as through days of Google searches I was not able to find an
> answer but enough “parts” to piece together the solution.

Thanks for getting back with how you got it to work. A few comments
below.

> I also needed to create a .PEM format copy of my intermediate and
> certificate authority certificates as a combined file

As I said before, if the SSL server was configured correctly (by also
sending any intermediate certs as part of the cert chain) the client
would only need to know/trust the root CA cert. (Otherwise you'd have
to closely coordinate the rollover of any intermediate CA certs with
all clients, that's just not practical.)

> TLS_REQCERT allow

The man page for ldap.conf
http://www.openldap.org/software/man.cgi?query=ldap.conf
says for 'allow':

"If no certificate is provided, the session proceeds normally.
If a bad certificate is provided, it will be ignored and the
session proceeds normally."

I doubt this is what anyone wants when they set up TLS?! The above
means the connection would be established successfully -- and your
passwords transmitted -- even if someone redirected your connection to
a different server (or port), and even if the server there has an
invalid or no certificate at all!

I.e., the only value for TLS_REQCERT that makes any sense is "demand",
IMNSHO.

> TLS_CACERT C:\openldap\sysconf\certs\cacert.pem
>
> TLS_CACERTDIR C:\openldap\sysconf\certs

You don't need both. Either specify a directory containing individual
CA certs your client should trust, or specify a single file with the
CA certs contatenated.

Just where that ldap.conf needs to go is the interesting part...

-peter

[jpio...@gmail.com]

The SSL server is configured correctly and all other methods of using LDAPS worked except for PHP.   I was just missing how PHP needed to be configured.

As for the TLS_REQCERT entry I suppose the better solution is to use TLS_REQCERT demand as you suggested.

The examples I found for TLS_CACERT and TLS_CACERTDIR were both filled so I thought they were both needed.  I suppose if I had multiple servers to authenticate from that used different certificate authorities then I'd use the TLS_CACERTDIR

[Peter Schober]

* jpio...@gmail.com <jpio...@gmail.com> [2017-11-09 20:51]:

> The SSL server is configured correctly and all other methods of
> using LDAPS worked except for PHP.

If you also have to configure the intermediate certificate(s) on the
client (in addition to the actual trust anchor) then I stand by my
assertion that the server is misconfigured (and I already provided one
reason why that's the case), but whatever.

> The examples I found for TLS_CACERT and TLS_CACERTDIR were both
> filled so I thought they were both needed.

Now you have the URL to the man page (I reckon those won't be
available on a MS-Windows build) and can decide based on the
authoritative documentation. Sadly the OpenLDAP man page says nothing
about where this has to go in MS-Windows systems, AFAICT, probably
because the OpenLDAP project only supplies source code, not
pre-compiled packages, themselfs.

> I suppose if I had multiple servers to authenticate from that used
> different certificate authorities then I'd use the TLS_CACERTDIR

Sometimes only TLS_CACERT will work, depending on the TLS
library/implementation used (as mentioned in the man page), otherwise
I agree that TLS_CACERTDIR is easier to work with.
In the case of a since trust anchor (one CA) the effort is identical
(provided the server sends the complete chain, minus the root CA cert
itself): Drop a single file (the CA root cert) with a singe cert into
a single location.

-peter