Another case of vCenter SSO–Part -II
Before I start, please don’t be surprised If I come up with Part-III. If you happen to read my blog on Another-case-of-SSO it is extension of same post but in different lights. In fact the previous post also faced the same problem which I ‘m going to discuss below here today.
Same situation or scenario. Goal –> Upgrade vSphere 4.1 infrastructure to 5.1. We have 4.1 Infrastructure and were moving up to 5.1. Similar procedure followed and all went ok with same warnings. Un-explained Reverse lookup problem when we know it is correct. It is unclear how this wizard checks the reverse lookup. It always gives us false alarms (some times just forces us to ignore even in real cases, which is bad I think).
However this time we changed the order of installation
1. I logged into vCenter with Service Account (we are going to install everything in single box, as I realized it doesn’t matter unless you have multiple sites accessing vCenter SSO)
2. SSO was first installed
3. We didn’t installed inventory service but installed Webclient first. Why ? check this post
4. Luckily Identity source was added, so we don’t have to do anything there. I was happy
5. We went ahead with inventory service installation. All was okay here as well
6. Last one–> vCenter Upgrade –> All okay again
Now the moment of truth. I tried to login to vcenter using my domain credentials. It failed.
For next 3 hours I tried all possible ways to get inside the vCenter using C# client or Webclient but no success.
This means only one of the two things
1. Either vCenter is unable to talk to identity source via SSO
2. Or Identity source is missing from SSO.
But in this case identity source was added automatically So point 2 was not the case. Then Point 1 was the case? For some reason it strike to me to get someone else account to login, So after another 30 min I requested one of my colleague to login to vCenter, Surprised Surprised !!! He can login using web client and also using C# client. It was getting interesting now. Even Point 1 was invalid now. So SSO was talking to identity source using my colleague account BUT was failing to authenticate using my credentials, Is something wrong with my account. To confirm further I asked few other users to login. I got mixed results. Few can login and few cannot. Problem was getting more and more interesting.
But we crossed the maintenance window agreed with the client. And we were at the moment where roll back was the only option. But great thanks to this article by NiTRo. I quickly disabled SSO and people can continue their work.
Next Day : I Google’d & found nothing. Finally opened a call with VMware support.
I was in the VMware queue for record 1 hr 30 min. You can guess why this wait time and this article might also supports your guess also.
Engineer took not more than 30 minutes to solve this problem. Again your guess might support this.
Problem was so easy but so difficult to see something which is so obvious. Unfortunately there is nothing in the VMware documentation to see this so obvious.
Authentication Type: Reuse Session –> This uses the account where you have put the service account credentials while installing SSO. This account must have permissions to read all user attributes in the active directory.
Sorry I know I’m not clear here but this is what KB Article:2037546 states
“If the service account cannot read these attributes, the logins fail. The solution is to increase the permissions on this service account so that it is able to read all user attributes.”
No one in our Active Directory team understood this statement. If you know please, May I request you to help me what this permission means for an active directory service account in the comments section. Thanks in advance.
I was very unhappy. I have raised it via my @techstarts twitter handle and I got response from the VMwareKB is below.
I greatly appreciate VMwareKB super fast response but unfortunately reading 65 KB article to understand single feature doesn’t sound good investment of time.
1. SSO sits between vCenter and your identity source. Its function is to pick your credentials and give to identity source and use “Authentication Type” to access AD. If this doesn’t work you won’t be allowed to login to vCenter SSO. If you are sure this is broken check SSO logs. SSO logs are many (Check here) and the one which you should use is log which is not part of this KB. This log is imsTrace.log (trace log) located in C:Program FilesVMwareInfrastructureSSOServerlogs
2. Check vCenter Logs
3. vCenter SSO is at 1.0 version expect yourself in the middle of this or that problem. Prepare yourself and Say “All is well”