Bug 1357832 - LDAP authentication failures are not reported in an understandable way down the stack
Summary: LDAP authentication failures are not reported in an understandable way down t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Users & Roles
Version: 6.2.0
Hardware: All
OS: Linux
medium
medium vote
Target Milestone: 6.4.0
Assignee: Dominik Hlavac Duran
QA Contact: Omkar Khatavkar
URL:
Whiteboard:
: 1292058 (view as bug list)
Depends On:
Blocks: 1353215
TreeView+ depends on / blocked
 
Reported: 2016-07-19 10:35 UTC by Daniele
Modified: 2019-11-05 23:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-16 18:54:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 17811 None None None 2016-12-21 09:50:24 UTC
Red Hat Bugzilla 1292058 None CLOSED Traceback when LDAP authentication password is incorrect 2019-09-27 15:05:42 UTC

Internal Links: 1292058

Description Daniele 2016-07-19 10:35:10 UTC
Description of problem:
I'm not entirely sure this should be open against Hammer, because the issue exists independently from the component that tries to authenticate.

LDAP authentication failures are ofter reported as failures in other components of the stack, making it hard to spot and work on.

i.e. :

2016-06-10 16:52:08 [I] Completed 500 Internal Server Error in 116ms (Views: 0.4ms | ActiveRecord: 0.9ms)
2016-06-10 16:52:08 [D] With body: {"displayMessage":"SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A","errors":["SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A"]}

500 internal server error is misleading, if the ssl issue is on ldaps connection. Only with debug things are a little bit better:

2016-06-10 16:52:08 [I] Processing by Katello::Api::V2::PingController#index as application/json;version=2
2016-06-10 16:52:08 [I]   Parameters: {"api_version"=>"v2", "ping"=>{}}
2016-06-10 16:52:08 [D]   User Load (0.6ms)  SELECT "users".* FROM "users" WHERE "users"."lower_login" = 'tugnusatapi' LIMIT 1
2016-06-10 16:52:08 [D]   AuthSource Load (0.4ms)  SELECT "auth_sources".* FROM "auth_sources" WHERE "auth_sources"."id" = 4 LIMIT 1
2016-06-10 16:52:08 [D] LDAP-Auth with User tugnusatapi
2016-06-10 16:52:08 [E] OpenSSL::SSL::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1132:in `connect'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1132:in `wrap_with_ssl'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1169:in `setup_encryption'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1116:in `initialize'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:634:in `new'
--
/usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler/thread_handler.rb:140:in `accept_and_process_next_request'
/usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler/thread_handler.rb:108:in `main_loop'
/usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler.rb:441:in `block (3 levels) in start_threads'
/opt/rh/ruby193/root/usr/share/gems/gems/logging-1.8.1/lib/logging/diagnostic_context.rb:323:in `call'
/opt/rh/ruby193/root/usr/share/gems/gems/logging-1.8.1/lib/logging/diagnostic_context.rb:323:in `block in create_with_logging_context'

So, while the problem was not with the Satellite, but with the Oracle LDAP server it was trying to authenticate against, it took a very long time to figure out due to the poor error reported.

Version-Release number of selected component (if applicable):
Satellite 6.2

How reproducible:
100%

Steps to Reproduce:
1. Perform an action (through Hammer, for example) that would trigger a SSL handshake
2. Have the server drop the connection
3. Inspect the error reported by the tool used (Hammer, for example)

Actual results:
Unuseful error message such as

2016-06-10 16:52:08 [I] Completed 500 Internal Server Error in 116ms (Views: 0.4ms | ActiveRecord: 0.9ms)

Expected results:
More useful error message, that points out the target LDAP server has dropped the connection or had problems completing the request.

Additional info:
During a SSL handshake steps to establish connection to Oracle LDAP server, the server suddenly drops the TCP connection. To see that, let apply filter:

tcp.stream eq 18

to  test_ldap-cycle-error-ldap03_20160713_14.55.21.pcap and notice:

- client (the Sat server here) sent "Client Hello" handshake
- server (the LDAP server) replied with "Server Hello", "Certificate", "Server Key Exchange" and "Server Hello Done"
- client sent "Client Key Exchange", "Change Cipher Spec" and "Encrypted Handshake message"
- server abruptly terminated the connection by sending FIN packet

See Oracle LDAP logs from the same time in #133.

These failures happen _sometimes_ (with approx. 3% probability) only - see other TCP streams in the flow.

Can you please explain me why?

Background:
- client is a ruby script (see #128) using openSSL client
- server is Oracle LDAP server (a pool of servers behind a proxy)
- these unexpected connection drops cause authentication issues to Satellite6 (user auths against the external LDAP server and that connection sometimes fail)

Comment 2 Tomas Strachota 2016-12-21 09:50:22 UTC
Created redmine issue http://projects.theforeman.org/issues/17811 from this bug

Comment 5 pm-sat@redhat.com 2017-05-31 10:13:47 UTC
Upstream bug assigned to dhlavacd@redhat.com

Comment 8 pm-sat@redhat.com 2017-07-31 16:12:35 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17811 has been resolved.

Comment 9 Bryan Kearney 2017-08-11 14:12:08 UTC
*** Bug 1292058 has been marked as a duplicate of this bug. ***

Comment 17 Omkar Khatavkar 2018-09-06 13:16:22 UTC
Verified = 6.4.x Snap 
Status = Passed 
Comments = The fix is working as an error message get disapled on console. 

ERF77-8207 [Foreman::LdapException]: Error while connecting to '${LDAP HOST/IP}' LDAP server at '${LDAP HOST/IP}' during authentication ([Net::LDAP::Error]: Permission denied - connect(2) for ${LDAP_HOST:PORT})

Comment 18 Bryan Kearney 2018-10-16 18:54:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2927


Note You need to log in before you can comment on or make changes to this bug.