| Summary: | LDAP authentication failures are not reported in an understandable way down the stack | ||
|---|---|---|---|
| Product: | Red Hat Satellite 6 | Reporter: | Daniele <dconsoli> |
| Component: | Users & Roles | Assignee: | Dominik Hlavac Duran <dhlavacd> |
| Status: | CLOSED ERRATA | QA Contact: | Omkar Khatavkar <okhatavk> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2.0 | CC: | aperotti, bkearney, cwelton, dhlavacd, mhulan, okhatavk, satellite6-bugs, tscherf, tstrachota |
| Target Milestone: | 6.4.0 | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 1353215 | ||
Created redmine issue http://projects.theforeman.org/issues/17811 from this bug Upstream bug assigned to dhlavacd@redhat.com Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17811 has been resolved. *** Bug 1292058 has been marked as a duplicate of this bug. *** 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})
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 |
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)