Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1357832

Summary: LDAP authentication failures are not reported in an understandable way down the stack
Product: Red Hat Satellite 6 Reporter: Daniele <dconsoli>
Component: Users & RolesAssignee: Dominik Hlavac Duran <dhlavacd>
Status: CLOSED ERRATA QA Contact: Omkar Khatavkar <okhatavk>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2.0CC: aperotti, bkearney, cwelton, dhlavacd, mhulan, okhatavk, satellite6-bugs, tscherf, tstrachota
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-16 18:54:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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:

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: 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?

- 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 from this bug

Comment 5 2017-05-31 10:13:47 UTC
Upstream bug assigned to

Comment 8 2017-07-31 16:12:35 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue 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.