Hi Matt, On Sunday, October 14, 2012 11:46:36 AM Matthew Drobnak wrote:
Daniel,
So here's the problem - it looks like OpenLDAP on SuSE is not configured to use the default system ca_bundle.pem file.
I added this line:
TLS_CACERT /etc/ssl/ca-bundle.pem
to /etc/openldap/ldap.conf,
and re-ran the script, and it works perfectly.
Good catch! LDAP & TLS is always fun :(
So, of course, I made the config settings match between the script, and the production.rb file. Something is a bit different however, as it does not work with API auth still:
My little helper script seems to different in the relevant part. At least I helped a bit so far .... The TLS vs. SSL handling in my helper script is pretty simplified compared to the LDAP implementation in OBS.
obs01:/srv/www/obs/api/log # /root/obs-ldap.rb Bingo: uid=mdrobnak,ou=People,dc=appnexus,dc=com obs01:/srv/www/obs/api/log # head -n 10 /root/obs-ldap.rb #!/usr/bin/ruby require 'ldap'
LOGIN = "mdrobnak"
LDAP_SEARCH_ATTR = "uid" LDAP_SERVERS = "ldap.local.appnexus.net" LDAP_PORT = 389
LDAP_START_TLS = true LDAP_SSL = :on
So this two option might work for my helper script .. but not for OBS. Those are XOR in OBS... :(
obs01:/srv/www/obs/api/log # grep LDAP ../config/environments/production.rb LDAP_MODE = :on # LDAP Servers separated by ':'. LDAP_SERVERS = "ldap.local.appnexus.net" # If you're using LDAP_AUTHENTICATE=:ldap then you should ensure that
LDAP_SSL = :on
Since you are using TLS: turn LDAP_SSL := off
# Use StartTLS extension of LDAP LDAP_START_TLS = :on
... and keep this LDAP_START_TLS = :on. This hopefully should do the trick for you. With your current configuration OBS would only try to do plain-SSL chatting on Port 389 which is going to fail since your TLS configured LDAP is expecting TLS handshake. Still I really wonder why the exception when all this goes fail is completely silenced in the logs ... But we should definitly introduce a sanity check that warns you having LDAP_SSL and LDAP_START_TLS activated at the same time ... which is usually not what you want. (TLS will turn the initial plain connection into an encrypted one after the TLS handshake thingy ...)
# LDAP port defaults to 636 for ldaps and 389 for ldap and ldap with StartTLS LDAP_PORT=389 LDAP_REFERRALS = :off # Max number of times to attempt to contact the LDAP servers LDAP_MAX_ATTEMPTS = 10 LDAP_SEARCH_BASE = "dc=appnexus,dc=com" # Sam Account Name is the login name for LDAP LDAP_SEARCH_ATTR = "uid" LDAP_NAME_ATTR="cn" LDAP_MAIL_ATTR="mail"
Not related so far .. . but maybe this comes next. Make sure all your users in your LDAP tree have this MAIL attribute set ... if not they will also fail to login. HTH BR Daniel
[INFO |# 7455] Processing MainController#index (for 68.67.167.97 at 2012-10-14 15:44:19) [GET] [DEBUG|# 7455] Validate XML request: #ActionController::Request:0x7f145fa0df50 [DEBUG|# 7455] no schema found, skipping validation for controllermainmethodgettyperequestactionindex [DEBUG|# 7455] AUTH: ["Basic", "REDACTED"] [DEBUG|# 7455] Using LDAP to find mdrobnak [DEBUG|# 7455] Looking for mdrobnak using ldap [DEBUG|# 7455] Cache read: ldap_cache_userpasswd:mdrobnak [DEBUG|# 7455] Cache read: ldap_cache_userpasswd:mdrobnak ({:raw=>true}) [DEBUG|# 7455] Connecting to ldap.local.appnexus.net as 'uid=cmcvalidation,ou=Pseudousers,dc=appnexus,dc=com' [DEBUG|# 7455] mdrobnak not found in LDAP. [DEBUG|# 7455] User not found with LDAP, falling back to database [DEBUG|# 7455] User Load (0.4ms) SELECT * FROM `users` WHERE (login = 'mdrobnak') LIMIT 1 [DEBUG|# 7455] SQL (0.1ms) BEGIN [DEBUG|# 7455] User Load (0.2ms) SELECT `users`.id FROM `users` WHERE (`users`.`login` = 'mdrobnak' AND `users`.id <> 3) LIMIT 1 [DEBUG|# 7455] Error - skipping to create user [DEBUG|# 7455] User Update (0.3ms) UPDATE `users` SET `login_failure_count` = 5, `updated_at` = '2012-10-14 15:44:19' WHERE `id` = 3 [DEBUG|# 7455] SQL (2.5ms) COMMIT
Apologies for the delay in getting this information; it's been quite hectic last week at work.
Thanks for everyone's help so far.
-Matt
On 10/11/2012 03:02 AM, Daniel Gollub wrote:
Hi Matt,
On Wednesday, October 10, 2012 05:40:29 PM Matthew Drobnak wrote:
Ok, so the root of this is:
SSL Cert issues. As you suspected. We have our own root CA, but I thought I did this right:
obs01:/etc/ssl/certs # ls -l /usr/share/ca-certificates/mozilla/AppNex*
[...]
obs01:/etc/ssl/certs # And I did a update-ca-certificates, and it was in the list...So I have no idea what's still broken.
FYI, if I turn off SSL, it does work.
You might want to use the little helper script and run it like this:
strace -o ruby-ldap-ssl.trace -f -e file -s1024 ruby ldap.rb
And check which files in /etc/ssl/certs/ the openssl library tries to access. I could imagine that there might be a hash symlink inside /etc/ssl/certs/ missing - e.g. /etc/ssl/certs/$HASH.0 -> toyourCAorCert.crt or so.
Note: also make sure that the SSL server cert matches with the provided domain you have configured for your LDAP. And the server cert is not expired and such stuff ... otherwise the ldap connection willl fail also - due to "untrusted" SSL cert.
Best Regards, Daniel
-Matt
-- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: gollub@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537