for larger organizations with tons of AD domains and variations of trust and such between them, it is helpful for any system supporting security groups to support both kinds: country and western....
(global and local)
In seemingly backwards logic, in order to use domain trust to provision user or group objects from a trusted domain, you have to designate the security group as "local" rather than "global". This is not a vmturbo problem, this is within AD.
Trouble is, if you select "local" as the security group type, and add the trusted domain objects to it, it doesn't work.
vmturbo configured to authenticate against windows domain "Foo" and map users who are members in a global security group "vmturbo admins" to the "admin" role in vmturbo.
This works fine for all "Foo" domain members who are in the security group.
So...an enhancement is attempted.
"Foo" has bi-directional domain trust with domain "Bar". There are users within "Bar" that wish to authenticate to vmturbo as admins using their "Bar" account. These are valid admins.
To add these users to the security group "vmturbo admins" in domain "Foo", the group type has to be changed to "local" to see the trusted domain objects within "Bar". The group type is changed, and the users within "Bar" are added to the security group "vmturbo admins" within domain "Foo".
They try to login to vmturbo as "bar\username" and "foo\username" and neither works.
Ideas? We have a dozen domains and as we go deeper with coverage of vmturbo in our environment we will need to support all these users.
Our other option is to drop AD entirely and put vmturbo on our LDAP system which is common across the org, but folks want to login with AD who run vmware and vmturbo.