powered by Jive Software

LDAP UserAuth problem - not AD (Wildfire 2.5.0)

I can’‘t get Wildfire 2.5.0 to authenticate via my organization’'s LDAP server.

The problem is that SSL/TLS is required for the authentication (simple bind) step, but when I set the configuration parameter “sslEnabled” to true, it an exception is thrown (connection closed) during the handshake and the search never is completed. If I turn sslEnabled to false, then the search works fine, but the simple bind fails with the error: “Error 49: SSL/TLS is required”

The port is set to 389, because if I change it to 636 (which is allowed for the LDAP server), the connection times out. This may be due to

I am doing the testing using the Admin console log in, which was previously configured using the interal DB option with users and pw for admin accounts, one of which corresponds to an LDAP entry.

wildfire.xml relevant section:

System: Linux (Fredora Core 4)

Thanks for any help!

On the command line, can you perform a simple ldapwhoami using SSL? example commandline usage:

ldapwhoami -x -D uid=someuser,ou=authenticate,dc=purdue,dc=edu -W -H ldaps://dbm.i2a2.purdue.edu

/code

My guess is that will fail also, meaning something between you and the ldap server is blocking that port. Could be a firewall, or maybe iptables on either end.

Thanks for the help.

The suggestion that port 636 was blocked was correct (firewall to server). Opening communication over this port not only made the LDAP client command line tool functional, but also let the LDAP Auth work in Wildfire.

Although it is obvious in hindsight, the documentation from my LDAP server and Wildfire seems to suggest that using port 636 is optional, even for SSL communication to the LDAP server. For instance, LDAP clients can connect over port 389 and then user the StartTLS function to change to SSL for a simple bind. It was not clear from the documentation that doing this requires access over port 636. Clearly, it does.

Also, it is not clear from the Wildfire documentation that port 636 MUST be specified if sslEnabled is set to true. After all, some LDAP servers allow initial connection over port 389 then start TLS. Using port 389 and true for sslEnabled does not work in Wildfire, at least not with my LDAP server.

Agreed. I think it should be a feature request to get the SSL settings in LDAP a bit more “friendly”, as well as adding TLS support. How does this sound for proposed logic:

if port == null {

if useSSL == false {

port = 389

} else {

port = 689

}

}

/code

And I think adding TLS is a good feature to have (makes firewalling easier). I think if a user selects useSSL and useTLS at the same time (an illogical choice) useTLS should override. Even having a fallback wouldnt be terrible (if TLS fails, try SSL).

Both the port logic above and the fallback you suggest are good ideas.

Here are my 2 cent’'s worth on this topic:

I’'m not sure that requiring the port be null to have it autoselect on sslEnabled value is the most transparent approach, though. Would not 636 always beused with SSL and 389 without SSL? Clearly there is a reason to allow port reassignment (for non-standard port usage) in the config.xml file. Perhaps better logic would be (psuedo code)

if sslEnabled is null and port is null, then use port 636 with SSL

(arguably, this could be port 389 without SSL, but this is unsecure for simple bind with clear text passwords)

if sslEnabled is false with port null, use port 389

if sslEnabled is true with port null, use port 636

if port is 636 with sslEnabled is null, use SSL

if port is 389 with sslEnabled null, do not use SSL

if port is set to nonstandard value and sslEnabled is null, do not use SSL

otherwise, honor the sslEnabled and port settings.

In the docs, indicate the defaul if both parametes are not set;

that setting sslEnabled is needed to force to not use SSL;

that the port should be set only if a non-standard port is needed

I don’'t follow the logic that TLS makes firewalling easier, but support for TLS would be good as some setups may require it for their own reasons. .

Keep up the good work!

Your pesudo code is basicly the same thing I described, just making the default (if no port settings and no ssl settings) to use SSL. The problem with that is the “default” ldap connection is without SSL. Nearly every LDAP client expects you to explicitly select “use SSL”

Using TLS simplifies firewall rules since you dont have multiple ports. Its not a huge simplification, though.