VMware Cloud Community
mark_chuman
Hot Shot
Hot Shot
Jump to solution

vCenter Permissions Riddle - Active Directory

Points to the first person to figure it out.

Here is my issue:

I have VC1, domain1, domain2, domainlocalgroup1 in domain1, user1 in domain2. VC1 is a member of domain1.

example 1

If I add user1 in domain2 as read only on VC1 and attempt to login to VC1 I am unable. VC logs report that user does not exist and it is attempting to query domain1 for user1. If I add domain2\user1 I am able to login.

example 2

If I add domainlocalgroup1 as read only to VC1 and then add user1 in domain2 to domainlocalgroup1 in domain1. I am unable to login as user1. If I login as domain2\user1 I am able to login. (fyi, in this example the domain2\user1 user was removed from VC permissions).

When you view memerships for user1 it does not list the membership in the domain local group in domain1. When you list membership of domainlocalgroup1 it does list user1 in domain2.

My question is how does VC validate the user in example 2? If I am unable to login as just user, I assume VC is not able to validate me because it is looking into domain1. But when I login as domain2\user1 I am able to login. I assume VC is looking for the user in domain2, but in example2 the user only has permissions to VC via the domainlocalgroup1 in domain1. How does VC validate user1 in example2????

Riddle Level - Genius

My Business Critical Tech who is an expert on VC did not know.

0 Kudos
1 Solution

Accepted Solutions
hicksj
Virtuoso
Virtuoso
Jump to solution

Example 1 - as expected. a) VC doesn't know the context of user1, so assumes its domain1... denies login. b) you provide the context and it works fine. thats correct.

Example 2 - just as expected as well. When viewing memberships, you will not see local groups from other domains listed in the user properties (just the same way, you won't see local groups on member servers that user is a member of within its own domain). I'm surprised VC enumerates domainlocal... My first thought is, you have VC installed on a Domain Controller??? Or do you have this on a member server, with a local group on the server? Either way, Virtual Center will look to the group and it is doing exactly what its supposed to, it detects domain2\user1 as a member of that group, validates user1's credentials against domain2 and allows you in. (assuming generic w2k3 ad with transitive trusts)

View solution in original post

0 Kudos
4 Replies
hicksj
Virtuoso
Virtuoso
Jump to solution

Example 1 - as expected. a) VC doesn't know the context of user1, so assumes its domain1... denies login. b) you provide the context and it works fine. thats correct.

Example 2 - just as expected as well. When viewing memberships, you will not see local groups from other domains listed in the user properties (just the same way, you won't see local groups on member servers that user is a member of within its own domain). I'm surprised VC enumerates domainlocal... My first thought is, you have VC installed on a Domain Controller??? Or do you have this on a member server, with a local group on the server? Either way, Virtual Center will look to the group and it is doing exactly what its supposed to, it detects domain2\user1 as a member of that group, validates user1's credentials against domain2 and allows you in. (assuming generic w2k3 ad with transitive trusts)

0 Kudos
mark_chuman
Hot Shot
Hot Shot
Jump to solution

The VC is not a DC, it's a stand alone 2k3 VM that's joined to domain1.

Makes sense, so VC is picking up the users membership in the domain local group in domain1. I am just starting to use domain local security groups to try and reduce the number of security groups I have to worry about.

I would be very interested to know the exact process VC goes through, because authenticating a user in domain2 that is a member of a group in domain1 would have to mean VC is some how matching the two up. IE, it queries domain1 for the group and then sees that the user does exist in domain2 and then matches the two up for the successful authentication.

0 Kudos
hicksj
Virtuoso
Virtuoso
Jump to solution

One thing VC does do is periodically check that users & groups are still valid. If you've assigned an AD group or user to a particular virtual resource, that AD object will be validated periodically (default = 1440 minutes). This is more of a "clean up" process... if the AD group has been deleted (or renamed!!! it doesn't reference the SID*), VC will automatically remove the assignment to the virtual resources.

See Administration -> VirtualCenter Management Server Settings -> Active Directory.

For your authentication scenario, the credentials provided during login of user1 will be sent to a DC in domain2 and validated via Kerberos (it knows user1 is a member of a valid group based on the data it synchronizes and tracks above), and if the credentials were valid, the group membership to group1 will then be verified against a DC in domain1. You could probably verify the exact process & order by capturing the traffic from your VC server at login time.

  • I know this used to be a problem, and I don't know if this was ever fixed. If not, hopefully they'll switch to SID references in the future.

mark_chuman
Hot Shot
Hot Shot
Jump to solution

Thanks for the information. That all makes sense.

One thing I did confirm is that a user who is a member of a different domain than the VC server is joined to has to preface their userid with their domain during logon.

0 Kudos