RHEV-M LDAP integration Logon VERY slow

Latest response

Hi,

I added our RHEV-M to our domain so that we can do domain logons... set my id up as administrator, but it takes like 5 minutes for me to logon.

We have a very large AD domain so I guess it is searching the whole thing, just wondered if I can point it to a OU with just the group of RHEV-M admins in it somehow?

Thanks
Bill

Responses

Hi Bill,
I am not an AD guy, but... I wonder if you could create a user in AD only has privilege to see a particular tree, if that would limit it's reach and thereby speed up the search. My own login is a bit slow and we have a very small AD environment.

Here is an example of folks wanting to use multiple forests (which leads me to believe you could configure a "sub-forest"?)
https://access.redhat.com/solutions/53477

After adding our RHEVM to AD, we executed the following query and found out that the (European) RHEVM was connecting to an Asian AD server:

psql -U postgres engine
select option_name, option_value from vdc_options where option_name like '%LdapS%';

After correcting this to a nearby AD server, lookups were much faster.

that sounds like a good idea! We've had that sort of problem before with AD... but I tried running
[root@UKwatRHEV-M ~]# psql -U postgres engine
psql: FATAL: Ident authentication failed for user "postgres"

sorry, i'm a real newbie to RHEV and haven't worked with postgres before - just looking at the format of the psql command postres is the user and engine is the database I guess. Any help would be appreciated as I can imagine that this is the problem and we do have a local DC we can use.

Thanks again

Does it help when you "su - postgres" before executing the query?

doh, yes it does... sort of I just get this for the output though, it doesn't actually tell me the server name!

engine=# select option_name, option_value from vdc_options where option_name like '%LdapS%';
option_name | option_value
-------------+--------------
LdapServers |
(1 row)

It looks like there is no ldap server configured. My output looks like:

LdapServers | <domain>:<fqdn1>;<domain>:<fqdn2> ....

I'm using an AD domain with RHEV 3.3 and I get the same result as Bill to the SQL query.

engine=# select option_name, option_value from vdc_options where option_name like
engine-# '%LdapS%';
 option_name | option_value 
-------------+--------------
 LdapServers | 
(1 row)

Hi, been very busy and only getting a chance to revisit this now - does anyone have any further ideas on how I can see what AD server I am using? It does log me in, so it obviously is finding a server... would like to try and get this moving as it looks like I may be getting some budget to finally run a pilot of RHEV in our engineering dept for real.

Thanks

You are likely using a number of AD servers. I believe will try to do an SRV lookup for ldap in your domain (I do not know this for certain, as I have never had a reason to reverse-engineer the process ;-)

You can look as well (here are some example methods - dig, probably the best)

nslookup -type=SRV _ldap._tcp.example.com
host -t SRV _ldap._tcp.example.com
dig SRV _kerberos._udp.example.com

EDIT: I also should mention... AD has a locality function which will attempt to direct you to the "nearest resource" - I believe it is referred to as NLA (Network Location Awareness).

http://technet.microsoft.com/en-us/library/cc787373%28v=ws.10%29.aspx

I'm also using MS-AD and also get,
engine=> select option_name, option_value from vdc_options where option_name like '%LdapS%';
option_name | option_value
-------------+--------------
LdapServers |
(1 row)

Using engine, I do get correct values:

-> engine-manage-domains list
Domain: your.domain
User name: SERVICE-ACCOUNT-NAME@YOUR.DOMAIN
Manage Domains completed successfully

You can validate the AD user account by,
-> engine-manage-domains validate

Print list of available commands using engine-manage-domain.
-> engine-manage-domains --help

Here you have an option to,
--ldap-servers=SERVERS
A comma delimited list of LDAP servers to be set to the domain.
Haven't been able to come any closer than that

Hi Siem Korteweg

Are you using MS-AD?

Sorry for the late reaction. Yes, we are using MS-AD.

If I remember correctly, the function i MS AD is called 'Sites and Services'. Here you can control logon servers by subnet as well as replication.
Otherwise perhaps try out using a comma delimited list of LDAP servers to see if that solves the problem.

Hi all, thanks for comments...
the

dig SRV _kerberos._udp.pbi.global.pvt

returned a long list of logon servers all over the world. It appeared to have gotten that from our local server

;; Query time: 3 msec
;; SERVER: 152.144.160.188#53(152.144.160.188)
;; WHEN: Tue Nov 25 08:34:01 2014
;; MSG SIZE  rcvd: 1887

which is in our office.

I thought I would try and add our local ldap server..

[root@UKwatRHEV-M ~]# engine-manage-domains edit --ldap-servers=152.144.160.188 --domain=pbi.global.pvt --user=auser@PBI.GLOBAL.PVT --provider=AD
Enter password:
Error: LDAP query Failed. Error in DNS configuration. Please verify the Engine host has a valid reverse DNS (PTR) record.
Failure while testing domain pbi.global.pvt. Details: No user information was found for user

which is probably true and if this is a requirement is really going to shoot everyone in the foot. I don't have control over our DNS... big company and all.. and they don't use Reverse DNS. No zones for us. They don' t feel it is necessary... I know... but totally out of my control and absolutely no way I am ever going to be able to influence it. Saying that, I was able to add the domain, and validate the domain etc without any problems, so maybe the second line No user information was found for user. means something?

Well, out of time for experimenting today! I've got remedy tickets to close :-(

Thanks again
Bill

Hi William

Did find something about the requirements for ad integration yesterday.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Installation_Guide/Directory_Services_Support_in_Red_Hat_Enterprise_Virtualization.html
So seems PTR record is required.
But glad to hear you got it working anyway.

I didn't really get it working any better, it is still incredibly slow to login... I will check the docs further, but the PTR record requirement is not promising for me to move the project forward as I can't provide that in our corporate environment.

I see the problem.
MS AD Domain Controllers actually doesn't need PTR records to function or a reverse zone at all. We have it because quite a few application needs to be able to resolve FQDN from IP addresses. Doens't help you much I know.
Does it help putting your MS AD controllers into /etc/hosts ?

I will try putting into /etc/hosts and see what happens, thanks for the suggestion

tried adding server to hosts file but still no luck... out of time today, will have to look at it more tomorrow, thanks

Sorry to hear you're stilll having trouble with this issue, William, and thanks for keeping us updated here. Is opening a Red Hat support case an option for you?

Thanks, it will be... the powers that be have given me the go ahead and bought a couple subs to RHEV :-) on my way to a meeting with Redhat in London and will find out about activating them there!

Bill

Ensure all of your AD servers being referenced by RHEV are actuallt serving LDAP. We had a similar slow login issue until we removed the "non-LDAP" AD servers from our config.

William,

Can I ask what method you used to join it to the domain? I don't have a RHEV-M installed currently so can't step through the process.
Is it using SSSD and the server has joined the domain? or are you using the AD servers as LDAP servers?

There are several options in sssd/LDAP that can cause lookups to be slow, especially if you have a lot of nested objects in your directory.

Two options to look into explicitly turning off for testing are:

enumerate
ldap_referrals

Another thing to test/look at is how the servers are defined in krb5.conf (if you are using it).

Rather than looking up the servers using:

 dns_lookup_realm = true
 dns_lookup_kdc = true

You can statically define exactly which servers you want to reference for the domain so the lookup / destination isn't left to chance or the whim of the AD server / DNS responses.

eg.

[libdefaults]
default_realm = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM = {
kdc = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM
admin_server = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM
}

Lastly, do you have any Red Hat servers joined to the same domain? are they functioning correctly / as you would expect?

Did you manage to get this one resolved via support case, Bill?

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.