Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1455440

Summary: Add information about LDAP server, which we failed connect to, to ease problem investigation
Product: Red Hat Enterprise Virtualization Manager Reporter: Roman Hodain <rhodain>
Component: ovirt-engine-extension-aaa-ldapAssignee: Ondra Machacek <omachace>
Status: CLOSED ERRATA QA Contact: Petr Matyáš <pmatyas>
Severity: urgent Docs Contact:
Priority: medium    
Version: 4.0.7CC: audgiri, grafuls, lleistne, lsurette, lsvaty, mgoldboi, mkalinin, mperina, omachace, Rhev-m-bugs, rhodain
Target Milestone: ovirt-4.3.2   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-extension-aaa-ldap-1.3.9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-08 12:35:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1520566    

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