Bug 783127 - LDAP authenticates against domain URI instead of LDAP Server URI from SRV records
Summary: LDAP authenticates against domain URI instead of LDAP Server URI from SRV rec...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.1
Assignee: Oved Ourfali
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-19 13:27 UTC by Vaclav Ehrlich
Modified: 2016-10-04 04:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-09 08:05:16 UTC
oVirt Team: ---


Attachments (Terms of Use)
ovirt-engine log (31.46 KB, text/plain)
2012-01-19 13:27 UTC, Vaclav Ehrlich
no flags Details
capture of DNS traffic of: engine-manage-domains -action=validate (1.68 KB, application/x-pcap)
2012-01-19 15:05 UTC, David Jaša
no flags Details
capture of DNS traffic when Admin Portal loads (1.28 KB, application/x-pcap)
2012-01-19 15:06 UTC, David Jaša
no flags Details
capture of DNS traffic when user tries to authenticate in Admin Portal (2.79 KB, application/x-pcap)
2012-01-19 15:09 UTC, David Jaša
no flags Details
capture of DNS traffic when ovirt-engine/jboss-as start (3.89 KB, application/x-pcap)
2012-01-24 14:01 UTC, David Jaša
no flags Details
capture of DNS traffic: rhevm start to display of webadmin page (18.71 KB, application/x-pcap)
2012-01-25 17:48 UTC, David Jaša
no flags Details

Description Vaclav Ehrlich 2012-01-19 13:27:54 UTC
Created attachment 556270 [details]
ovirt-engine log

Description of problem:
User could not be authenticated, because oVirt wants to connect to bad LDAP URI. 

Version-Release number of selected component (if applicable):
ovirt-engine-3.0.0_0001-1.2.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1.Install and set up oVirt
2.Start jboss-as (if is not running)
3.Open browser, connect to ovirt management page and try to log in with proper credentials
  
Actual results:
User is not log in, because ldap URI for authenticate is not valid

Expected results:
User is log in into system

Additional info:

[root@ovirt ~]# engine-manage-domains -action=validate
Domain spice.lab.eng.brq.redhat.com is valid.
Manage Domains completed successfully

[root@ovirt ~]# engine-manage-domains -action=list
Domain: spice.lab.eng.brq.redhat.com
	User name: vdcadmin.ENG.BRQ.REDHAT.COM
	This domain is a remote domain.
Manage Domains completed successfully

[root@ovirt ~]# host -t SRV _ldap._tcp.spice.lab.eng.brq.redhat.com
_ldap._tcp.spice.lab.eng.brq.redhat.com has SRV record 0 0 389 ad.spice.lab.eng.brq.redhat.com.

Comment 1 David Jaša 2012-01-19 15:05:55 UTC
Created attachment 556297 [details]
capture of DNS traffic of: engine-manage-domains -action=validate

Comment 2 David Jaša 2012-01-19 15:06:41 UTC
Created attachment 556298 [details]
capture of DNS traffic when Admin Portal loads

Comment 3 David Jaša 2012-01-19 15:09:39 UTC
Created attachment 556299 [details]
capture of DNS traffic when user tries to authenticate in Admin Portal

These three captures were taken on oVirt machine. They show that domain is configured correctly (as engine-manage-domains -action=validate shows) but then engine tries to reach ldap on itself, which results in USER_FAILED_TO_AUTHENTICATE_CONNECTION_ERROR presented to user.

Comment 4 Oved Ourfali 2012-01-22 07:47:03 UTC
Does it reproduce also after restarting the ovirt engine?

The reason of using URI is once we don't find the LDAP SRV record.
I see that it exists, but when the engine started he couldn't find it.

In case it indeed reproduces upon startup, the DNS traffic upon startup can help us understand the problem.

Comment 5 Oved Ourfali 2012-01-22 10:07:43 UTC
Proposed commit: http://gerrit.ovirt.org/#change,1184

Comment 7 David Jaša 2012-01-24 14:01:11 UTC
Created attachment 557243 [details]
capture of DNS traffic when ovirt-engine/jboss-as start

I hope that this comment doesn't come too late...

(In reply to comment #4)
> Does it reproduce also after restarting the ovirt engine?
> 

Yes, it does.

> The reason of using URI is once we don't find the LDAP SRV record.
> I see that it exists, but when the engine started he couldn't find it.
> 
> In case it indeed reproduces upon startup, the DNS traffic upon startup can
> help us understand the problem.

Attached. Note that ovirt does _not_ ask for SRV records, it just goes through series of trial-and-error with A and PTR records. You can see also another domain whose configuration looks almost the same but authentication against it works:

Domain: rhev.lab.eng.brq.redhat.com
	User name: vdcadmin.ENG.BRQ.REDHAT.COM
	This domain is a remote domain.

Comment 8 David Jaša 2012-01-24 14:13:14 UTC
Note that A record for the rhev.lab.<...> domain points to IP of AD so oVirt assumes the AD is not there. This is not the case with spice.lab.<...> domain so when oVirt does not ask for SRV record of _ldap._tcp.spice.<...>, it's clear that it has no clue where the AD server is.

This is a clear blocker if not fixed by previous commit IMO.

Comment 9 David Jaša 2012-01-25 17:48:24 UTC
Created attachment 557496 [details]
capture of DNS traffic: rhevm start to display of webadmin page

Comment 10 David Jaša 2012-01-25 17:50:52 UTC
RHEV-M unlike oVirt employs no guesswork and asks correctly for _ldap._tcp.<domain> SRV record.

Oved, could you have a quick look if your commit indeed fixes the issue or guide me to verify it?

Comment 11 Oved Ourfali 2012-01-26 06:54:34 UTC
The commit should fix the issue.
The problem was a class loading issue with classes used to do the DNS queries.
The commit adds these classes to the correct jboss module.

Comment 12 David Jaša 2012-01-30 11:38:58 UTC
Confirmed on my setup, doing the source modifications manually (module.xml was not yet updated in -3.0.0_0001-1.3.fc16.x86_64), the setup started working for me.

Comment 13 Itamar Heim 2012-08-09 08:05:16 UTC
closing ON_QA bugs as oVirt 3.1 was released:
http://www.ovirt.org/get-ovirt/


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