Have you ever had issues using Active Directory User with Logon restriction in your Sphere 5.1 environment? I think so, otherwise you probably haven’t landed here 😉

Since I haven’t found any explanations how to deal with this situation I tried to summarize it.

We all know a good role-concept in vSphere is a very important thing. That’s why we typically create our own roles and attach (service/personal) active-directory users/groups to those specific rules.

vcenter_ad_restriction01

So far, this is nothing new for us and not very problematic at all if SSO is probably configured to use the Active directory as an identity source.

vcenter_ad_restriction02

Once we are forced to deal with strong security policies, we might run into some issues that our vCenter User is defined with a logon restriction.

vcenter_ad_restriction03

From a security perspective it definitely makes sense to restrict the access for the Users (e.g. service-accounts) to specific Computers. From a logical point of view, having access to the vCenter (vc01 in the picture) should be enough. Unfortunately things in the IT world are not always that logical, which leads us to the fact that we can’t login to our vCenter after having configured a restriction.

vcenter_ad_restriction04

Credentials are not valid? Sounds for me like a typo or wrong password, but a closer look at the imsTrace.log (located at %ProgramFiles%/VMware/Infrastructure/SSOServer/logs) gave me another hint.

vcenter_ad_restriction05

‘javax.naming.AuthenticationException: [LDAP: error code 49 – 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 531, v1db1 ];’

a short online search for LDAP error codes gave me the information what error code 49 and data 531 exactly means.

vcenter_ad_restriction06

531 means: not permitted to logon at this workstation, even though we are permitted to log on against the vCenter Server.

The only way to be able with this user to connect against the vCenter is adding the 2 configured ldap-server which are used by single-sign on to the User as well.

vcenter_ad_restriction06

vcenter_ad_restriction07

Once this is done, we are able to logon with this user at our vCenter.

vcenter_ad_restriction08

Nevertheless. For many organisations this is not a suitable solution, to grant access to the Domain Controllers itselves. Unfortuenately I haven’t found a satisfying workaround for this scenario so far. I’m not sure what the exact problem is, but it seems that the SSO service is just brokering the user-credentials to one of the configured ldap-servers. If the user has no access to log on at this machine….beduumm…*failsound*…

The only way to deal with it, is by getting into a mixed environment of vCenter 5.1 and 5.5 components. The new SSO component in vSphere 5.5 is much more robust and better working than the old one and regarding to VMware it is supported to use the SSO from 5.5 with vCenter 5.1.

I’m not a fan of such a mixture, but sometimes we have no other choice to to do it that way. Make sure to update SSO and update the vSphere Web-client to the newest Version of 5.5.

Once we have done the upgrade, we need to configure the new active directory identity source with the integrated windows authentication. In the first step, remove the old AD configuration setting. In the second step we add a new identity source and choose Active Directory (Integrated Windows Authentication).

vcenter_ad_restriction09

And voila, we are able to logon to the vCenter with a user log on restricted only to the vCenter machine itself. That’s what we typically want to have.

As a summary, the only thing we can do at the moment for using logon restricted active directory users with vSphere is…

  1. Using no restrictions for your vCenter User.
  2. Running a mixed vCenter infrastructure with vCenter 5.1 and 5.5 components.
  3. Upgrade directly to vCenter 5.5.

Since I struggled several days on this issue, I hope this summary might safe you some time during your vSphere implementation and the active directory integration.