Bug 1254257 - [AAA][KerbLDAP] engine-manage-domains add fails with "No user in Directory was found" for active directory domain
[AAA][KerbLDAP] engine-manage-domains add fails with "No user in Directory wa...
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.5.3
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Alon Bar-Lev
Ondra Machacek
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-17 10:02 EDT by marek.bednarczyk
Modified: 2016-02-10 14:03 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-04 07:09:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description marek.bednarczyk 2015-08-17 10:02:40 EDT
Description of problem:
I can not add my corporate domain to RHEVM.

Version-Release number of selected component (if applicable):
RHEL 6.6
RHEVM 3.5.1

How reproducible:
100%

Steps to Reproduce:
engine-manage-domains add --add-permissions --domain=[ad name] --provider=ad --user=[user]



Actual results:
No user in Directory was found for [user]@[ad name]. Trying next LDAP server in list
[...]
No user in Directory was found for [user]@[ad name]. Trying next LDAP server in list


Expected results:
No errors. AD added to rhev.

Additional info:
No /var/log/ovirt-engine/ovirt-manage-domains.log created. No idea where to look for debug information.
Comment 1 marek.bednarczyk 2015-08-18 09:32:42 EDT
I need to know when work on the case will start.
Comment 2 Oved Ourfali 2015-08-24 02:14:10 EDT
Martin - can you take a look?
Comment 3 Oved Ourfali 2015-08-24 02:15:04 EDT
Marek - I suggest to work with the new generic-ldap provider.
CC-ing also Alon to instruct on that.
Comment 4 Alon Bar-Lev 2015-08-24 02:20:29 EDT
engine-manage-domain is depreciated in 3.5.

In 3.5 we introduced a new LDAP provider[1][2], it is superset of the previous implementation, highlights includes:
 * Better response times.
 * Simplicity, Use of LDAP protocol only - kerberos is no longer needed.
 * More LDAP implementations are supported.
 * Flexible configuration, can be customized on site to support special setups.
 * Supportability, better logs and feedbacks to enable remote support.
 * Variety of fallback policies, examples: srvrecord, failover, round-robin and more.
 * Active Directory: supports multiple domain in forest.

Some references[1][2].

If you already used the engine-manage-domain before upgrade, we provide a migration utility[3] to help you via the process.

[1] http://www.ovirt.org/Features/AAA
[2] https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0
[3] https://github.com/machacekondra/ovirt-engine-kerbldap-migration/releases
Comment 5 Ondra Machacek 2015-08-24 02:37:45 EDT
The reason you didn't see any log in '/var/log/ovirt-engine/ovirt-manage-domains.log' is that you have to use --log-file=... param it's not created by default now.
Comment 6 Martin Perina 2015-08-25 03:59:53 EDT
Could you please rerun engine-manage-domains with --log-file and --log-level options As Ondra suggested and attach produced log file?

engine-manage-domains add --add-permissions --domain=[ad name] --provider=ad --user=[user] --log-file=[file] --log-level=FINEST
Comment 7 marek.bednarczyk 2015-08-25 04:19:47 EDT
Here are the results, I replaced FINEST (Invalid log level value: 'FINEST') with DEBUG.

# engine-manage-domains add --add-permissions --domain=[ad name] --provider=ad --user=[user] --log-level=DEBUG --log-file=/var/log/ovirt-engine/ovirt-manage-domains.log     Enter password:
No user in Directory was found for [user]@[ad name]. Trying next LDAP server in list
[...]
No user in Directory was found for [user]@[ad name]. Trying next LDAP server in list
Failure while testing domain [ad name]. Details: No user information was found for user

# cat /var/log/ovirt-engine/ovirt-manage-domains.log
2015-08-25 10:09:08,576 INFO  [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Creating kerberos configuration for domain(s): [ad name]
2015-08-25 10:09:08,578 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.KrbConfCreator] loaded template kr5.conf file krb5.conf.template
2015-08-25 10:09:08,584 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.KrbConfCreator] setting default_tkt_enctypes
2015-08-25 10:09:08,585 INFO  [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Successfully created kerberos configuration for domain(s): [ad name]
2015-08-25 10:09:08,585 INFO  [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Testing kerberos configuration for domain: [ad name]
2015-08-25 10:09:10,508 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.KerberosConfigCheck] Check authentication finished successfully
2015-08-25 10:09:13,764 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.JndiAction] User guid is:
2015-08-25 10:09:13,764 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.JndiAction] URI is: LDAP://[ldap server #1]:389
2015-08-25 10:09:13,764 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.JndiAction] Complete query path is: LDAP://[ldap server #1]:389/DC=[sub sub dom],DC=[sub dom],DC=[dom]
[...]
2015-08-25 10:09:55,054 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.JndiAction] User guid is:
2015-08-25 10:09:55,054 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.JndiAction] URI is: LDAP://[ldap server #14]:389
2015-08-25 10:09:55,054 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.JndiAction] Complete query path is: LDAP://[ldap server #14]:389/DC=[sub sub dom],DC=[sub dom],DC=[dom]
2015-08-25 10:09:55,056 ERROR [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Failure while testing domain [ad name]. Details: No user information was found for user
Comment 8 Martin Perina 2015-08-25 05:15:51 EDT
Hi

please take a look at inline replies:


(In reply to marek.bednarczyk from comment #7)
> Here are the results, I replaced FINEST (Invalid log level value: 'FINEST')
> with DEBUG.

I'm sorry about that, I forgot that in engine-manage-domains we still use old log4j log level names


> 
> # engine-manage-domains add --add-permissions --domain=[ad name]
> --provider=ad --user=[user] --log-level=DEBUG
> --log-file=/var/log/ovirt-engine/ovirt-manage-domains.log     Enter password:
> No user in Directory was found for [user]@[ad name]. Trying next LDAP server
> in list
> [...]
> No user in Directory was found for [user]@[ad name]. Trying next LDAP server
> in list
> Failure while testing domain [ad name]. Details: No user information was
> found for user
> 
> # cat /var/log/ovirt-engine/ovirt-manage-domains.log
> 2015-08-25 10:09:08,576 INFO 
> [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Creating
> kerberos configuration for domain(s): [ad name]
> 2015-08-25 10:09:08,578 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> KrbConfCreator] loaded template kr5.conf file krb5.conf.template
> 2015-08-25 10:09:08,584 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> KrbConfCreator] setting default_tkt_enctypes
> 2015-08-25 10:09:08,585 INFO 
> [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Successfully
> created kerberos configuration for domain(s): [ad name]
> 2015-08-25 10:09:08,585 INFO 
> [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Testing
> kerberos configuration for domain: [ad name]
> 2015-08-25 10:09:10,508 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> KerberosConfigCheck] Check authentication finished successfully
> 2015-08-25 10:09:13,764 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> JndiAction] User guid is:

Is there anything or user guid is empty?

> 2015-08-25 10:09:13,764 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> JndiAction] URI is: LDAP://[ldap server #1]:389
> 2015-08-25 10:09:13,764 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> JndiAction] Complete query path is: LDAP://[ldap server #1]:389/DC=[sub sub
> dom],DC=[sub dom],DC=[dom]

Is LDAP URI correct?

> [...]
> 2015-08-25 10:09:55,054 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> JndiAction] User guid is:

Is there anything or user guid is empty?

> 2015-08-25 10:09:55,054 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> JndiAction] URI is: LDAP://[ldap server #14]:389
> 2015-08-25 10:09:55,054 DEBUG
> [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> JndiAction] Complete query path is: LDAP://[ldap server #14]:389/DC=[sub sub
> dom],DC=[sub dom],DC=[dom]

Is LDAP URI correct?

> 2015-08-25 10:09:55,056 ERROR
> [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Failure while
> testing domain [ad name]. Details: No user information was found for user


Basically the above errors mean that we were not able to find out information about the user you entered on command line using LDAP search. The search is one of the below searches depending on your username:

 (&(sAMAccountType=805306368)(userPrincipalName=[user]@[ad name]))

 (&(sAMAccountType=805306368)(sAMAccountName=[user]))

So are you sure that your user exists and it has privileges to search LDAP tree?
Comment 9 marek.bednarczyk 2015-08-25 06:18:33 EDT
(In reply to Martin Perina from comment #8)
> > 2015-08-25 10:09:13,764 DEBUG
> > [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> > JndiAction] User guid is:
> 
> Is there anything or user guid is empty?

Yes, user guid is empty.

> 
> > 2015-08-25 10:09:13,764 DEBUG
> > [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> > JndiAction] URI is: LDAP://[ldap server #1]:389
> > 2015-08-25 10:09:13,764 DEBUG
> > [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.utils.kerberos.
> > JndiAction] Complete query path is: LDAP://[ldap server #1]:389/DC=[sub sub
> > dom],DC=[sub dom],DC=[dom]
> 
> Is LDAP URI correct?

Yes, I just replaced real names with these in square brackets.

> > 2015-08-25 10:09:55,056 ERROR
> > [org.ovirt.engine.extensions.aaa.builtin.tools.ManageDomains] Failure while
> > testing domain [ad name]. Details: No user information was found for user
> 
> 
> Basically the above errors mean that we were not able to find out
> information about the user you entered on command line using LDAP search.
> The search is one of the below searches depending on your username:
> 
>  (&(sAMAccountType=805306368)(userPrincipalName=[user]@[ad name]))
> 
>  (&(sAMAccountType=805306368)(sAMAccountName=[user]))
> 
> So are you sure that your user exists and it has privileges to search LDAP
> tree?

Yes, I can do ldapsearch authenticating with the same account I use for engine-manage-domains.
Comment 10 Martin Perina 2015-08-26 07:07:56 EDT
If I understand correctly, this is a new RHEVM installation and not an upgrade, right?

If so, are you willing to use aaa-ldap extension instead of engine-manage-domains? engine-manage-domains is deprecated in RHEVM 3.5+ and if you want to upgrade to RHEVM 4, you will need to migrate to aaa-ldap anyway. And at the moment I would need to deeply investigate your AD environment to find out the issue.

So if you agree, could you please do following:

1. Install package ovirt-engine-extension-aaa-ldap on the same machine as RHEVM

2. Take a look at /usr/share/doc/ovirt-engine-extension-aaa-ldap-1.0.2/README and configure aaa-ldap using the README file

Please let me know if you have any issues with aaa-ldap configuration.

Thanks
Comment 11 Alon Bar-Lev 2015-09-03 10:20:02 EDT
Hello Merek,

Have you tried to use ovirt-engine-extension-aaa-ldap?

If you have any issue, please contact me directly.

Thanks,
Alon
Comment 12 marek.bednarczyk 2015-09-04 07:08:26 EDT
Fortunately I managed to add RHEV 3.5 manager on the basis of engine-manage-domains. Thus I am not going to dig the aaa-ldap way as it looks more complicated from my point of view.
Comment 13 Alon Bar-Lev 2015-09-04 07:18:04 EDT
(In reply to marek.bednarczyk from comment #12)
> Fortunately I managed to add RHEV 3.5 manager on the basis of
> engine-manage-domains. Thus I am not going to dig the aaa-ldap way as it
> looks more complicated from my point of view.

this is not the correct solution, no support will be provided for this configuration in 3.5, I strongly suggest you migrate to the new provider ASAP.

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