How to set vIDM (SSO) LDAP Site-Affinity for vRA (SKKB1024)

In this article we take a look into how can we set LDAP site affinity for VMware Identity Manager (vIDM) and VMware Identity Appliance (IDA) , especially when used as Identity Provider by vRealize Automation (vRA). We will look into native vIDM options that let us accomplish this as well as how to achieve this using F5 Big-IP Local Traffic Manager (LTM).

Lab Environment
Introduction
Use Case 1: Controlling LDAP with SSO Site-affinity
- Single LDAP Domain
  - Example 1: Single LDAP Domains
- Multiple LDAP Domains
  - Example 2: Multiple LDAP Domains
Use Case 2: Controlling LDAP with F5 BIG-IP
- Single LDAP Domain
  - Example 3: Single LDAP Domain with single VIP
  - Example 4: Single LDAP Domain with multiple VIP’s
- Multiple LDAP Domains
  - Example 5: Single LDAP Domain with single VIP
  - Example 6: Single LDAP Domain with multiple VIP’s
Conclusion & Next Steps
Setting LDAP Site-Affinity for vRA 6.x
- Method 1: Using SSO Site-Affinity option
- Method 2: Using F5 BIG-IP
Setting LDAP Site-Affinity for vRA 7.x
- Method 1: Using SSO Site-Affinity option
- Method 2: Using F5 BIG-IP
Final Step

Lab Environment

The logical design of this lab can be seen HERE.

Introduction

When configuring vRA tenant you must configure an Identity Store. The Identity Store configuration specifies an LDAP server for the tenant against which tenant users will be authenticated.
Further throuout this book I will:

Refer to the VMware Identity Appliance which is used by vRA 6.x as IDA.
Refer to the VMware Identity Manager which is used by vRA 7.x as vIDM.
Refer to both IDA and vIDM as SSO

If you specify directly and LDAP server name (e.g. lan1dc1.vmware.com) SSO will contact only that LDAP server. This is the recommended way. Obvious drawback is that you do not have LDAP server resiliency (redundancy/high-availability). You can also specify a domain name (e.g. vmware.com) instead of a single LDAP server as shown on the following screenshot:

This configuration is acceptable but you might end up with high vRA login times. Let’s see why this happens and how to better design our LDAP server strategy.
Let’s say you have specified a domain name vmware.com for the LDAP server.
What happens is:

vIDM will query the DNS server of the SSO appliance for the domain vmware.com
vIDM will query the DNS server of the _ldap._tcp.<domain_name> Service Location (SRV) records

DNS will return all _ldap records found in a round robin fashion. In this example there are two records.

We have two ways to affect LDAP servers returned by DNS:

vIDM SSO Site-Affinity
F5-BIG IP LDAP Virtual Server (or any similar functionality from another vendor.)

There is an option in SSO appliances called site-affinity. Enable site affinity when establishing connection to AD. When not set, by default, user specified connection string(s) are used. What this means is that if you have tenants logging from different domains, for example de.vmware.com and usa.vmware.com (these might not be in parent-child relationship) will get from DNS only LDAP servers that are located in the domain they are logging from.

You can also use BIG-IP virtual server ip (VIP) as an LDAP server in SSO appliances. This VIP might contain a pool of LDAP servers as members.

Let’s take a look into few use cases and see how we can affect this process.

Use Case 1: Controlling LDAP with SSO Site-affinity

Single LDAP Domain

Example 1: Single LDAP Domains

We have the following domain and vRA Tenant configuration:

vRA tenant named TenantGER logging to domain vmware.com
vRA tenant named TenantUSA logging to domain vmware.com
Domain controller (DC) named dcger01.vmware.com. Geographically located in GER
Domain controller (DC) named dcger02.vmware.com. Geographically located in GER
Domain controller (DC) named dcusa01.vmware.com. Geographically located in USA
Domain controller (DC) named dcusa02.vmware.com. Geographically located in USA
There are _ldap Service Locator resource records for all of the DC’s above.

Lets see how this will affect traffic:

// Without SSO Site-Affinity (default)

If you configure both TenantGER and TenantUSA with a single LDAP server, for example dcusa01.usa.vmware.com, vRA Clients logging from GER (TenantGER) might experience slow login times because the LDAP server is located in USA. And vice-versa.

If you configure both TenantGER and TenantUSA with a domain name, for example vmware.com, vRA Clients logging from both GER (TenantGER) and USA (TenantUSA) will receive an LDAP server via round robin from the DNS server which is located in their local site.

DRAWBACK: In all cases if an LDAP server is down the SSO appliance will not be able to determine that and might try to authenticate against it and will fail. As you can see no health checks are performed against the LDAP servers returned from DNS.

// With SSO Site-Affinity

In this use case we have only one domain vmware.com, therefore enabling SSO site-affinity will not make a difference.

Multiple LDAP Domains

Example 2: Multiple LDAP Domains

We have the following domain and vRA Tenant configuration:

vRA tenant named TenantGER logging to domain ger.vmware.com
vRA tenant named TenantUSA logging to domain usa.vmware.com
Domain controller (DC) named dcger01.ger.vmware.com. Geographically located in GER
Domain controller (DC) named dcger02.ger.vmware.com. Geographically located in GER
Domain controller (DC) named dcusa01.usa.vmware.com. Geographically located in USA
Domain controller (DC) named dcusa02. usa.vmware.com. Geographically located in USA
There are _ldap Service Locator resource records for all of the DC’s above.

Lets se how this will affect traffic:

// Without SSO Site-Affinity (default)

If you configure TenantGER with a LDAP domain name ger.vmware.com and TenantUSA with usa.vmware.com, this would be an optimal solution as each tenant will receive an LDAP server based in his domain.

// With SSO Site-Affinity

Use Case 2: Controlling LDAP with F5 BIG-IP

Single LDAP Domain

Example 3: Single LDAP Domain with single VIP

We have the following domain and vRA Tenant configuration:

vRA tenant named TenantGER logging to domain vmware.com
vRA tenant named TenantUSA logging to domain vmware.com
Domain controller (DC) named dcger01.vmware.com. Geographically located in GER
Domain controller (DC) named dcger02.vmware.com. Geographically located in GER
Domain controller (DC) named dcusa01.vmware.com. Geographically located in USA
Domain controller (DC) named dcusa02.vmware.com. Geographically located in USA
You have configured an F5 BIG-IP LTM VIP called f5-a-01-vs-ldap.vmware.com. This has as pool members the DC’s in both USA and GER: dcger01.vmware.com , dcger02.vmware.com, dcusa01.vmware.com and dcusa02.vmware.com.
There are _ldap Service Locator resource records for all of the DC’s above.

Lets see how this will affect traffic:

// With F5-BIG IP LDAP Virtual Server

If you configure both TenantGER and TenantUSA with a single VIP f5-a-01-vs-ldap.vmware.com, vRA Clients logging from GER (TenantGER) might experience slow login times because the LDAP server is located in USA. And vice-versa.

ADVANTAGE: F5 BIG-IP LTM can monitor the members of the LDAP pools and determine when they can or cannot response to an LDAP query by making constants probes. If a server cannot response to the LDAP query it will not be returned to the SSO appliance. This way we can achieve DC resiliency and optimize login process.

DRAWBACK: TenantGER might intermittently get an LDAP server from USA

Example 4: Single LDAP Domain with multiple VIP’s

We have the following domain and vRA Tenant configuration:

vRA tenant named TenantGER logging to domain vmware.com
vRA tenant named TenantUSA logging to domain vmware.com
Domain controller (DC) named dcger01.vmware.com. Geographically located in GER
Domain controller (DC) named dcger02.vmware.com. Geographically located in GER
Domain controller (DC) named dcusa01.vmware.com. Geographically located in USA
Domain controller (DC) named dcusa02.vmware.com. Geographically located in USA
You have configured an F5 BIG-IP LTM VIP called f5-a-01-vs-ldap-ger.vmware.com. This has as pool members the DC’s in GER: dcger01.vmware.com and dcger02.vmware.com
You have configured an F5 BIG-IP LTM VIP called f5-a-01-vs-ldap-usa.vmware.com. This has as pool members the DC’s in GER: dcusa01.vmware.com and dcusa02.vmware.com
There are _ldap Service Locator resource records for all of the DC’s above.

Lets see how this will affect traffic:

// With F5-BIG IP LDAP Virtual Server

If you configure TenantGER with the VIP f5-a-01-vs-ldap-ger.vmware.com and TenantUSA with the VIP f5-a-01-vs-ldap-usa.vmware.com as LDAP server, vRA Clients will be redirected to the LDAP servers in their geo.

ADVANTAGE 1: F5 BIG-IP LTM can monitor the members of the LDAP pools and determine when they can or cannot response to an LDAP query by making constants probes. If a server cannot response to the LDAP query it will not be returned to the SSO appliance. This way we can achieve DC resiliency and optimize login process.

ADVANTAGE 2: Each tenant will get an LDAP server based on geo location.

Multiple LDAP Domains

Example 5: Multiple LDAP domains with single VIP

Let’s consider an example DNS and vRA Tenant setup as follows:
We have the following domain and vRA Tenant configuration:

vRA tenant named TenantGER logging to domain ger.vmware.com
vRA tenant named TenantUSA logging to domain usa.vmware.com
Domain controller (DC) named dcger01.ger.vmware.com. Geographically located in GER
Domain controller (DC) named dcger02.ger.vmware.com. Geographically located in GER
Domain controller (DC) named dcusa01.usa.vmware.com. Geographically located in USA
Domain controller (DC) named dcusa02. usa.vmware.com. Geographically located in USA
You have configured an F5 BIG-IP LTM VIP called f5-a-01-vs-ldap.vmware.com. This has as pool members the DC’s in both USA and GER: dcger01.vmware.com , dcger02.vmware.com, dcusa01.vmware.com and dcusa02.vmware.com.
There are _ldap Service Locator resource records for all of the DC’s above.

Let’s see how this will affect traffic:

// With F5-BIG IP LDAP Virtual Server

DRAWBACK: TenantGER might intermittently get an LDAP server from USA

Example 6: Multiple LDAP domains with multiple VIP’s

We have the following domain and vRA Tenant configuration:

vRA tenant named TenantGER logging to domain ger.vmware.com
vRA tenant named TenantUSA logging to domain usa.vmware.com
Domain controller (DC) named dcger01.ger.vmware.com. Geographically located in GER
Domain controller (DC) named dcger02.ger.vmware.com. Geographically located in GER
Domain controller (DC) named dcusa01.usa.vmware.com. Geographically located in USA
Domain controller (DC) named dcusa02. usa.vmware.com. Geographically located in USA
You have configured an F5 BIG-IP LTM VIP called f5-a-01-vs-ldap-ger.vmware.com. This has as pool members the DC’s in GER: dcger01.ger.vmware.com and dcger02.ger.vmware.com
You have configured an F5 BIG-IP LTM VIP called f5-a-01-vs-ldap-usa.vmware.com. This has as pool members the DC’s in GER: dcusa01.ger.vmware.com and dcusa02.ger.vmware.com
There are _ldap Service Locator resource records for all of the DC’s above.

Let’s see how this will affect traffic:

// With F5-BIG IP LDAP Virtual Server

If you configure TenantGER with the VIP f5-a-01-vs-ldap-ger.vmware.com and TenantUSA with the VIP f5-a-01-vs-ldap-usa.vmware.com as LDAP server, vRA Clients will be redirected to the LDAP servers in their geo.

ADVANTAGE 2: Each tenant will get an LDAP server based on geo location.

Conclusion & Next Steps

As you can see F5 BIG-IP adds the benefit of health checks against the LDAP server which provides in turn higher LDAP resiliency .
Next I will show how to enable SSO site-affinity and how to configure F5 BIG-IP LTM for LDAP resolution.
I will be using the following setup:

vRA 6.2 IDA: vra-a-01-ida.vmware.com (172.16.50.31)
vRA 6.2 Web: vra-a-01-web.vmware.com (172.16.50.32), TenantA
vRA 7.0 (vIDM): vra-a-03.vmware.com (192.168.1.18)
AD Domain Controller: lan1dc2.vmware.com (172.16.50.6)
AD Domain Controller: lan1dc3.vmware.com (172.16.50.7)
F5 VIP LDAP: f5-a-01-vs-ldap.vmware.com (172.16.50.3)
F5 VIP LDAP Pool Members : lan1dc2.vmware.com , lan1dc3.vmware.com

Setting LDAP Site-Affinity for vRA 6.x

Method 1: Using SSO Site-Affinity option

You can enable the SSO site-affinity option for the IDA by logging via ssh to appliance and using the sso—config.sh. You will need to specify the vRA Tenant and Identity Provider for which you want to enable the option.

First you can get the Identity Store flags configuration for a tenant and an Identity Store:

vra-a-01-ida:/var/log/vmware/sso # /opt/vmware/bin/sso-config.sh -get_identity_store_flags -t TenantA -i vmware.com
Flags=0; [the following known flags: ]

To set the site-affinity run:

vra-a-01-ida:/var/log/vmware/sso # /opt/vmware/bin/sso-config.sh -set_identity_store_flags -t TenantA -i vmware.com -f enable_site_affinity
vra-a-01-ida:/var/log/vmware/sso # /opt/vmware/bin/sso-config.sh -get_identity_store_flags -t TenantA -i vmware.com
Flags=8; [the following known flags: enable_site_affinity]

Now login to the vRA Default Tenant and use a domain name like vmware.com for the LDAP server.

Method 2: Using F5 BIG-IP

Some of the values you fill in might vary depending on the setup and environment you have. I’ve used the following values:

High Availability – What IP address do you want to use for the virtual server?: 172.16.50.3
High Availability – Which LDAP servers are a part of this pool?: 172.16.50.6, 172.16.50.7
High Availability – Where will the virtual servers be in relation to the LDAP servers?: BIG-IP virtual server IP and LDAP servers are on the same subnet. (This might not be the case in your setup. )
Application Health – What user account should this health monitor use to log into the LDAP servers?: CN=Administrator,CN=Users,DC=vmware,DC=com. (This might not be the case in your setup. )
Application Health – What is the password for the specified user account?: <Type_the_pass_for_the_account_specified_above>
Application Health – At what level in the directory do you want the health monitor to begin searching?: CN=Users,DC=vmware,DC=com. (This might not be the case in your setup. )
Application Health – What search query do you want the server to return results for?: (&(objectClass=user)(name=Administrator)) (This might not be the case in your setup. )

In this case the BIG-IP device will use the domain admin account administrator@vmware.com (CN=Administrator,CN=Users,DC=vmware,DC=com) and query AD for an object which in this case is set to the administrator user account object ((&(objectClass=user)(name=Administrator)). You can specify any other AD object you want to query for. This is the LDAP health check that the BIG-IP device will do to determine if an LDAP server is up and running.

The configuration is shown on the following screenshot:

Navigate to Local Traffic > Network Map.
Verify that all LDAP serves are up and running.

Navigate to Local Traffic > Virtual Servers.
Verify that the VIP up and running.

Lets login to vRA and add that VIP as LDAP server.
Navigate to vRA Default Tenant > Administrator > Tenants.
Edit the tenant configuration and in the URL filed add the BIG-IP VIP f5-a-01-vs-ldap.vmware.com

You should see similar events being logged to the ssoAdminServer.log:

vra-a-01-ida:/var/log/vmware/sso # tail -f ssoAdminServer.log
[2016-02-01 22:22:26,847 pool-3-thread-5 INFO com.vmware.identity.vlsi.RoleBasedAuthorizer] User {Name: csp-admin-602bc43c-0297-4b54-a223-2c70e9199010, Domain: tenanta} with role ‘Administrator’ is authorized for method call ‘IdentitySourceManagementService.updateLdap’
[2016-02-01 22:22:26,847 pool-2-thread-5 INFO com.vmware.identity.admin.vlsi.IdentitySourceManagementServiceImpl] [User {Name: csp-admin-602bc43c-0297-4b54-a223-2c70e9199010, Domain: tenanta} with role ‘Administrator’] Updating ldap identity source ‘vmware.com’ details to ‘com.vmware.vim.sso.admin.LdapIdentitySourceDetails@54c2bb18 friendlyName=VMwareAD, userBaseDn=CN=Users,DC=vmware,DC=com, groupBaseDn=CN=Users,DC=vmware,DC=com, primaryUrl=ldap://f5-a-01-vs-ldap.vmware.com:389, failoverUrl=null, searchTimeoutSeconds=0’

Try logging to the vRA tenant you’ve configured before with a domain account.
You should see similar events being logged to the vmware-sts-idmd.log log.

vra-a-01-ida:/var/log/vmware/sso # tail -f vmware-sts-idmd.log
[2016-02-01 20:22:27,048 tenanta c868aad3-2524-4815-a955-0a34577900f6 INFO ] [IdentityManager] Provider [vmware.com] successfully set for tenant [tenanta]
[2016-02-01 20:30:43,150 tenanta 37fd3e97-25b1-4883-8a73-81da53cde937 INFO ] [IdentityManager] Authentication succeeded for user [administrator@vmware.com] in tenant [tenanta] in [609] milliseconds

Let’s simulate an LDAP server failure.
Shutdown one of the pool members. In this case I’m shutting down 172.16.50.7

Navigate to F5 > Local Traffic > Network Map. After a note that node failure is detected. The BIG-IP device will not use that LDAP server anymore in any responses.

Try logging again to the vRA tenant you’ve configured before with a domain account. You should be successful because at least one node of the VIP is still alive and responding to LDAP queries.
Let’s switch nodes and simulate failure of the other node.

Try logging again to the vRA tenant you’ve configured before with a domain account. You will not successful because there are no more nodes alive and responding to LDAP queries.

You should see similar events being logged to the vmware-sts-idmd.log log.

vra-a-01-ida:/var/log/vmware/sso # tail -f vmware-sts-idmd.log

[2016-02-01 20:37:20,519 tenanta              1e09c384-6922-4952-b58c-d89f918c000e ERROR] [IdentityManager] Failed to authenticate principal [administrator@vmware.com]. Login failed
javax.security.auth.login.LoginException: Login failed
at com.vmware.identity.idm.server.provider.ldap.LdapWithAdMappingsProvider.authenticate(LdapWithAdMappingsProvider.java:411)
at com.vmware.identity.idm.server.IdentityManager.authenticate(IdentityManager.java:2425)
at com.vmware.identity.idm.server.IdentityManager.authenticate(IdentityManager.java:8167)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$2.run(Transport.java:202)
at sun.rmi.transport.Transport$2.run(Transport.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:198)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.vmware.identity.interop.ldap.ServerDownLdapException: Can’t contact LDAP server
LDAP error [code: -1]
at com.vmware.identity.interop.ldap.LdapErrorChecker$43.RaiseLdapError(LdapErrorChecker.java:599)
at com.vmware.identity.interop.ldap.LdapErrorChecker.CheckError(LdapErrorChecker.java:826)
at com.vmware.identity.interop.ldap.LinuxLdapClientLibrary.CheckError(LinuxLdapClientLibrary.java:781)
at com.vmware.identity.interop.ldap.LinuxLdapClientLibrary.ldap_bind_s(LinuxLdapClientLibrary.java:377)
at com.vmware.identity.interop.ldap.LdapConnection.bindConnection(LdapConnection.java:132)
at com.vmware.identity.idm.server.ServerUtils.getLdapConnection(ServerUtils.java:306)
at com.vmware.identity.idm.server.ServerUtils.getLdapConnectionByURIs(ServerUtils.java:217)
at com.vmware.identity.idm.server.provider.BaseLdapProvider.getConnection(BaseLdapProvider.java:277)
at com.vmware.identity.idm.server.provider.BaseLdapProvider.getConnection(BaseLdapProvider.java:101)
at com.vmware.identity.idm.server.provider.ldap.LdapWithAdMappingsProvider.getConnection(LdapWithAdMappingsProvider.java:2507)
at com.vmware.identity.idm.server.provider.ldap.LdapWithAdMappingsProvider.getUserDN(LdapWithAdMappingsProvider.java:1784)
at com.vmware.identity.idm.server.provider.ldap.LdapWithAdMappingsProvider.authenticate(LdapWithAdMappingsProvider.java:407)
… 21 more
[2016-02-01 20:37:20,520 tenanta              1e09c384-6922-4952-b58c-d89f918c000e INFO ] [IdentityManager] Authentication failed for user [administrator@vmware.com] in tenant [tenanta] in [11] milliseconds
[2016-02-01 20:37:20,520 tenanta              1e09c384-6922-4952-b58c-d89f918c000e ERROR] [ServerUtils] Exception ‘com.vmware.identity.idm.IDMLoginException: Login failed’
com.vmware.identity.idm.IDMLoginException: Login failed
at com.vmware.identity.idm.server.IdentityManager.authenticate(IdentityManager.java:2535)
at com.vmware.identity.idm.server.IdentityManager.authenticate(IdentityManager.java:8167)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$2.run(Transport.java:202)
at sun.rmi.transport.Transport$2.run(Transport.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:198)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Setting LDAP Site-Affinity for vRA 6.x

Method 1: Using SSO Site-Affinity option

To set SSO Site-Affinity option in the vIDM that is built into the vRA 7.0, navigate to vRA <TenantID> > Administration > Directory Management > Directories and select This Directory supports DNS Service Location

Method 2: Using F5 BIG-IP

The BIG-IP device configuration in this case is the same as the one which we used above to configure LDAP Site-Affinity for vRA 6.x using F5 BIG-IP.

To set the BIG-IP VIP LDAP in navigate in vRA <TenantID> > Administration > Directory Management > Directories and remove the check for This Directory supports DNS Service Location.

In the Server host filed specify the VIP f5-a-01-vs-ldap.vmware.com

Logoff from vRA.

Try logging again to the vRA tenant you’ve configured before with a domain account. You should be successful because at least one node of the VIP is still alive and responding to LDAP queries.

You can perform the same tests we did when we set up LDAP Site-Affinity for vRA 6.x using F5 BIG-IP earlyer.

Final Step

If all went well, go grab a beer.

Spas Kaloferov's Blog

How to set vIDM (SSO) LDAP Site-Affinity for vRA (SKKB1024)

Leave a Reply Cancel reply