While working at a customer site with a pretty decent size Active Directory where they have implemented an Empty root structure, vCAC login through Single Sign On when using Active Directory accounts were pretty slow. It took up to 10-15 minutes at time per login attempt.
The customer had a multitiered domain in a single forest. The top domain/root domain or if you want to call it level 1 domain was empty, where all the users and where vCAC users were coming from is the level 2 domain. What was happening is when a user of the level 2 domain try to login he was facing one of the below two problems:
1- If the user does not have any group membership outside the level 2 domain, they were allowed to login, but it took quite a bit for the login attempt to complete. (10-15 minutes)
2- If the user has any group membership or any tie outside the level 2 domain, after the log on attempt, the progress bar on the log on page will stop and nothing will happen.
At first, I thought I might be short at resources on my SSO server so I boosted that up, while it speeded things a bit it was not too noticeable of improvement and I knew there was a bit more work to do. After doing a bit of digging with other resources within VMware, I was told that in particular use cases (Due to the way customers Active Directory being structured) that adding one of the following port numbers to the end of the identity source could help speed the login dramatically. The list of the ports I was provided was: 3268 (Highest Rate of success & the one I end up using), 636, and 389. While I tried using each of these, the 3268 seems to give me the best improvement and my login has became blazing fast afterward. The below screen shot shows my final identity store configuration:
Another tip that I want to add to this, try to make sure the domain controller that you are pointing to is an Active Directory Global Catalog. At last, I hope everyone can now enjoy a blazing fast login to vCAC. Please leave your comment of how did this tip worked out for you, or if you have found a different tip that worked for you.
9 responses to “How to fix: vCAC 6 AD Login is very slow”
Just a quick note, ldap for a global catalog server is 3268 not 3286. If using SSL for this it becomes 3269.
Thanks for the article. I was experiencing 30 seconds to login. Which compared to 10 minutes was very fast! I’ve now got this down to about 4 seconds which is very acceptable. My mistake was I used my domain name in the URL LDAP lookup rather than than using a specific server.
So I had this:
ldap://mydomain.com:389
I then changed to:
ldap://dc1.mydomain.com:389
But ended up using:
ldap://172.21.1.10:389 (IP of my DC – just so I did not have to do DNS lookup – naughty – yes – fast – for sure!)
I did however find it annoying that I had to DELETE my IDENTITY STORE (I could not edit all the fields – not sure why) and re-create. This has resulted in me having to reconfigure elsewhere in the product.
Thanks and all the best!
This article might help to explain why this is necessary and why your solution worked.
Global Catalog and LDAP Searches
http://technet.microsoft.com/en-us/library/cc978012.aspx
Thanks Andrew, it definitely help explain it.
Using the integrated authentication for the Identity source should also resolve all the issues. It will traverse “level 1” domains and allow users to login. Based on info directly from the SSO team, when using the Integrated Authentication method, searches are done must more efficiently and should also speed up login times.
Hi James,
While that is true, native AD is only available for the default tenant.
Hi Will,
Thanks for your comment, I have fixed that in the article now. It seems to be a big typo.
Thanks,
Eiad
Sharing another possible tip….
I keep coming back to this one since my login times are pretty shocking (30 secs). Today I found that if I installed the “VMware-ClientIntegrationPlugin-5.5.0.exe” accessible from my vCenter Web Client login screen then I found my login times did improve from 30 secs to 4 secs.
I don’t actually check the box to say “use Windows Session Authentication” since I can’t get this to work in Internet Explorer (our company std) but for what ever reason. This worked for me….
Alan, Thanks for sharing!