Bug 1455440 - Add information about LDAP server, which we failed connect to, to ease problem investigation
Summary: Add information about LDAP server, which we failed connect to, to ease proble...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-extension-aaa-ldap
Version: 4.0.7
Hardware: Unspecified
OS: Unspecified
medium
urgent
Target Milestone: ovirt-4.3.2
: 4.3.0
Assignee: Ondra Machacek
QA Contact: Petr Matyáš
URL:
Whiteboard:
Depends On:
Blocks: 1520566
TreeView+ depends on / blocked
 
Reported: 2017-05-25 07:42 UTC by Roman Hodain
Modified: 2020-06-11 13:53 UTC (History)
11 users (show)

Fixed In Version: ovirt-engine-extension-aaa-ldap-1.3.9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-08 12:35:33 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1072 0 None None None 2019-05-08 12:35:39 UTC
oVirt gerrit 98064 0 None MERGED core: Print address of failed connection 2021-02-05 15:33:30 UTC

Description Roman Hodain 2017-05-25 07:42:20 UTC
Description of problem:

When the domain controller certificate is expired. An error message is displayed, but it is not understandable for a normal user without the understanding of the technology.

Version-Release number of selected component (if applicable):
RHV 4.0

How reproducible:
100%

Steps to Reproduce:
1. Configure AD with expired certificate.

Actual results:

server_error: The connection reader was unable to successfully complete TLS negotiation: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Sun May 14 12:08:55 CEST 2017 caused by java.security.cert.CertificateExpiredException: NotAfter: Sun May 14 12:08:55 CEST 2017

Expected results:

An error message with would provide more information
    - What exactly is expired
    - Where it is expired (What AD,IPA, ...)
    - How to fix it (a hint. The user should get some uderstanding who to contact)
    - Java exception, but only as an optional. May be workt the diplaythe exception only in a roll down menu. Should be hidden by default.

Additional info:
This is just an example, but the overall Errors coming from AAA-ldap should be readable and understandable without deeper technical knowledge.

Comment 1 Martin Perina 2017-05-25 14:44:28 UTC
(In reply to Roman Hodain from comment #0)
> Description of problem:
> 
> When the domain controller certificate is expired. An error message is
> displayed, but it is not understandable for a normal user without the
> understanding of the technology.

Well, aaa-ldap is advanced component, so we don't expect 'normal users' to understand it :-)

> 
> Version-Release number of selected component (if applicable):
> RHV 4.0
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. Configure AD with expired certificate.
> 
> Actual results:
> 
> server_error: The connection reader was unable to successfully complete TLS
> negotiation: javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateExpiredException: NotAfter: Sun May 14
> 12:08:55 CEST 2017 caused by java.security.cert.CertificateExpiredException:
> NotAfter: Sun May 14 12:08:55 CEST 2017
> 
> Expected results:
> 
> An error message with would provide more information
>     - What exactly is expired

Right we need to add server FQDN to know to which server we wasn't able to establish encrypted connection.

>     - Where it is expired (What AD,IPA, ...)

Should be identifiable by FQDN

>     - How to fix it (a hint. The user should get some uderstanding who to
> contact)

This is completely out of scope of error message. We can improve documentation how to replace expired certificate, but we can only refer to concrete LDAP product documentation how to get updated certificate.

>     - Java exception, but only as an optional. May be workt the diplaythe
> exception only in a roll down menu. Should be hidden by default.

What menu? Exceptions, especially stacktraces should be visible only in logs, do you see them somewhere in UI?

> 
> Additional info:
> This is just an example, but the overall Errors coming from AAA-ldap should
> be readable and understandable without deeper technical knowledge.

It's RHV administrator task to handle such errors, not RHV user's task. If admin was able to configure aaa-ldap he just need to know something about LDAP and this integration, this will never be 'one click and no worry' operation.

Comment 2 Yaniv Kaul 2017-05-25 18:51:50 UTC
(In reply to Martin Perina from comment #1)

> 
> Well, aaa-ldap is advanced component, so we don't expect 'normal users' to
> understand it :-)
> 


> >     - Java exception, but only as an optional. May be workt the diplaythe
> > exception only in a roll down menu. Should be hidden by default.
> 
> What menu? Exceptions, especially stacktraces should be visible only in
> logs, do you see them somewhere in UI?

What happens when users try to authenticate?

Comment 3 Martin Perina 2017-05-25 20:19:55 UTC
(In reply to Yaniv Kaul from comment #2)
> (In reply to Martin Perina from comment #1)
> 
> > 
> > Well, aaa-ldap is advanced component, so we don't expect 'normal users' to
> > understand it :-)
> > 
> 
> 
> > >     - Java exception, but only as an optional. May be workt the diplaythe
> > > exception only in a roll down menu. Should be hidden by default.
> > 
> > What menu? Exceptions, especially stacktraces should be visible only in
> > logs, do you see them somewhere in UI?
> 
> What happens when users try to authenticate?

Ondro, could you please test what is the exact error that user sees when he tries to login to LDAP which certificate is expired?

Comment 4 Martin Perina 2017-11-22 12:32:26 UTC
Hard to setup AD to make this issue reproducible, we will take a look during 4.3 cycle and backport when ready

Comment 6 Yaniv Kaul 2018-02-28 08:01:59 UTC
(In reply to Martin Perina from comment #4)
> Hard to setup AD to make this issue reproducible, we will take a look during
> 4.3 cycle and backport when ready

QE can do it easily, I assume?

Comment 7 Gonza 2018-04-03 08:20:32 UTC
(In reply to Yaniv Kaul from comment #6)
> (In reply to Martin Perina from comment #4)
> > Hard to setup AD to make this issue reproducible, we will take a look during
> > 4.3 cycle and backport when ready
> 
> QE can do it easily, I assume?

I don't believe we could easily do this with our existing LDAP instances.
We would require to create a new instance with expired certificates which will also require maintenance.

Comment 8 Yaniv Kaul 2018-04-03 09:53:02 UTC
(In reply to Gonza from comment #7)
> (In reply to Yaniv Kaul from comment #6)
> > (In reply to Martin Perina from comment #4)
> > > Hard to setup AD to make this issue reproducible, we will take a look during
> > > 4.3 cycle and backport when ready
> > 
> > QE can do it easily, I assume?
> 
> I don't believe we could easily do this with our existing LDAP instances.
> We would require to create a new instance with expired certificates which
> will also require maintenance.

Just bump the date on the host?

Comment 9 Martin Perina 2018-04-03 10:20:30 UTC
(In reply to Yaniv Kaul from comment #8)
> (In reply to Gonza from comment #7)
> > (In reply to Yaniv Kaul from comment #6)
> > > (In reply to Martin Perina from comment #4)
> > > > Hard to setup AD to make this issue reproducible, we will take a look during
> > > > 4.3 cycle and backport when ready
> > > 
> > > QE can do it easily, I assume?
> > 
> > I don't believe we could easily do this with our existing LDAP instances.
> > We would require to create a new instance with expired certificates which
> > will also require maintenance.
> 
> Just bump the date on the host?

Not that easy, you need to have 2 hosts in AD domain, 1st one with correct certificate and 2nd one with expired certificate. And that's the hard part, Ondra tried several times, but he was not able to get into that status.

Comment 13 Martin Perina 2019-01-22 11:40:55 UTC
We are going to log LDAP server FQDN/IP to which we tried to connect to when such low level error appeared. That should help tp understand the issue, but we are going to perform error translation, we will just display the error we received from the server.

Comment 15 Martin Perina 2019-02-27 07:42:37 UTC
Changing title according to the fix description in Comment 13

Comment 17 Petr Matyáš 2019-03-07 09:17:47 UTC
Verified on ovirt-engine-extension-aaa-ldap-1.3.9-1.el7ev.noarch

Comment 19 errata-xmlrpc 2019-05-08 12:35:33 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/RHEA-2019:1072


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