So kerberos servers are used in aaa-ldap only if you want to use kerberos SSO to access webadmin/userportal.

If we are talking about LDAP servers, you have several options in aaa-ldap to specify LDAP server:

1. You can use single server:

     pool.default.serverset.type = single
     pool.default.serverset.single.server = ldap.example.com

2. You can use multiple servers and choose a method which one to use (round-robin|failover|fastest-connect|fewest-connections)

    pool.default.serverset.type = <method>
    pool.default.serverset.<method>.1.server = ldap1.example.com
    pool.default.serverset.<method>.2.server = ldap2.example.com

3. You can use multiple servers with DNS round-robin selection (server can be resolved to multiple IP addresses)

    pool.default.serverset.type = dns-round-robin
    pool.default.serverset.dns-round-robin.server = ldap.example.com
    pool.default.serverset.dns-round-robin.selectionMode = RANDOM | FAILOVER | ROUND_ROBIN
    pool.default.serverset.dns-round-robin.dnsRecordTypes = A
    pool.default.serverset.dns-round-robin.cacheTimeoutMillis = NNN

4. You can use what's defined in DNS SRV records for the domain

    pool.default.serverset.type = srvrecord
    pool.default.serverset.srvrecord.service = ldap
    pool.default.serverset.srvrecord.protocol = tcp
    pool.default.serverset.srvrecord.domain = example.com
    pool.default.serverset.srvrecord.ttlMillis = NNN

   You can even do filtering those SRV records (more info in README.profiles)


So could you please describe customer's problem more deeply? From above comment I just don't see what is missing

They are using AD, so for them the only option is srvrecord. What they miss is that they want to see DC, currently AFAIK it's not even visible in logs, because that's what UnboundID LDAP SDK does for us, I will take a look what we can do about it. For now at least the visibility in logs.

(In reply to Ondra Machacek from comment #2)
> They are using AD, so for them the only option is srvrecord. 

Not true, srvrecord is default and easiest option for AD, but above mentioned options can also be used if needed.

> What they miss
> is that they want to see DC, currently AFAIK it's not even visible in logs,
> because that's what UnboundID LDAP SDK does for us, I will take a look what
> we can do about it. For now at least the visibility in logs.

Greg, is that the core of this RFE?

The core of this RFE is to give the admin a way to find the Active Directory domain controller that's authenticating logins.  Somehow, some way, RHEV reaches out to a DC.  Why not log which DC it used?  Then when users have trouble authenticating, the admin can look at logs to troubleshoot.

OK, changing the title accordingly

More details:

My specific use case is with a customer with a large Windows Active Directory environment and several independent Windows domains, each in their own AD forests.  Some of those domains are split into AD sites that correspond to physical geography, so a Windows PC in, say, Boston authenticates against a nearby domain controller instead of reaching out to, say, India.  

It makes most sense to find Windows AD domain controllers using DNS SRV records the same way Windows does it.  So then when RHEVM needs to authenticate users against AD, somehow it has to select a domain controller.  

RHEVM should let the world in on that secret somehow. 

One way to do that might be to put in a CLI, GUI, and API to answer this question: "Hey RHEVM, if I were to try to authenticate against the example.com AD domain, what domain controller would I use?"

And RHEVM should also record the domain controllers used by previous logins.  These could be log entries or maybe a database entry; when user mydomain\alice authenticated logged into RHEVM, what was the last domain controller used?

(In reply to Greg Scott from comment #6)
> More details:
> 
> My specific use case is with a customer with a large Windows Active
> Directory environment and several independent Windows domains, each in their
> own AD forests.  Some of those domains are split into AD sites that
> correspond to physical geography, so a Windows PC in, say, Boston
> authenticates against a nearby domain controller instead of reaching out to,
> say, India.  

Please just bare in mind that the selection of 'nearest' AD server should depend on location of RHEVM server and not RHEVM user's computer. So in theory RHEVM should always choose closest AD server (but that depends on configuration of DNS server that RHEVM host is using and assuming you are using srvrecord method to resolve LDAP servers).

> 
> It makes most sense to find Windows AD domain controllers using DNS SRV
> records the same way Windows does it.  So then when RHEVM needs to
> authenticate users against AD, somehow it has to select a domain controller.
> 
> 
> RHEVM should let the world in on that secret somehow. 

OK, we will investigate if it's possible to log which LDAP server is used for each query (this information is contained only inside unboundid-ldapskd library). But it seems to me as candidate for DEBUG log level as there will be a lot of those messages.

> 
> One way to do that might be to put in a CLI, GUI, and API to answer this
> question: "Hey RHEVM, if I were to try to authenticate against the
> example.com AD domain, what domain controller would I use?"

This is problematic, because we can return ldap1.example.com, but on next execution we can return ldap2.example.com, as result heavily depends on srv records configuration.

But as I said above, if we can get this info from unboundid-ldapsdk, we can use ovirt-engine-extensions-tool to display it.

> 
> And RHEVM should also record the domain controllers used by previous logins.
> These could be log entries or maybe a database entry; when user
> mydomain\alice authenticated logged into RHEVM, what was the last domain
> controller used?

This is very problematic:

1. aaa-ldap extension is not using database at all and I definitely don't want to add any database requirement to it
2. Please bear in mind that during login we execute several queries to LDAP server (1 to get info about user and 1 per each group that user is member of including nested groups) and each time we may (but may not) ask different LDAP, server (that depends on srvrecord content)

Oh wow.  Ain't nuthin' simple in this world.  Although not specifically called out in this RFE, support for AD sites in aaa-ldap will also be essential. I think that's already in place but I should mention it.

Included in ovirt-engine-extension-aaa-ldap-1.3.0

Verified with:
ovirt-engine-extension-aaa-ldap-1.3.1-0.0.master.20170115190508.gitda48d9d.el7.noarch

2017-02-06 11:20:36,596+02 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (default task-14) [] Performing SearchRequest 'SearchRequest(baseDN='DC=...,DC=redhat,DC=com', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=0, filter='&(sAMAccountType=805306368)(|(givenName=*)(sn=*)(displayName=*)(name=*))', attrs={objectGUID, userPrincipalName, name, displayName, department, givenName, sn, title, mail}, controls={SimplePagedResultsControl(pageSize=500, isCritical=false)})' request on server '....redhat.com'

*** Bug 1339939 has been marked as a duplicate of this bug. ***