In this article I’m going to highlight some of the most common multi-forest scenarios you may have to deal with operating a System Center Virtual Machine Manager. The official Technet documentation claims that multi-forests scenarios are supported using Kerberos. Unfortunately I did not find an official deep dive on that yet.
Managing Hyper-V Hosts and Clusters in multiple AD Forests
This works pretty straight forward as long as you configure a host management “Run As account” for each forest. There is no need to trust the foreign forest (from a SCVMM management perspective).
Why? Because SCVMM uses CredSSP and provides “fresh credentials” for each task submitted to the remote host.
Update: (special thanks to Thomas Maurer for this feedback)
The following limitations apply when adding untrusted hosts:
- Updating VMM agent on host fails. Host must be removed and re-added to VMM
- Creating a host cluster or adding a cluster node fails
- Cluster validation fails
- A converged network setup with management interface being part of the logical switch fails (WMI error)
- VMM console does not display host or cluster properties when run from a remote client due to certificate errors on WSMAN level
Accessing SCVMM via console from a different AD Forest
This is a tricky one because a lot scenarios are as follows:
- SCVMM is located in a so called “resource forest”
- Admin / User Account is located in a user or so called “account forest”.
- The resource forest has an outgoing one-way trust to one or multiple account forests
If a user from the account forest tries to access SCVMM in the resource forest, the SQL server instance running the VMM database tries to verify the AD user object from the account forest.
–> Thx to Michel Luescher from Microsoft Switzerland for the hint!
VMM Console shows the following error after entering the user credentials from the account forest:
To verify the root cause execute the following SQL query against your VMM Database using the SQL instance service account:
If the query returns “NULL”, your SQL Server or the underlying service account is not able to resolve the user’s SID from the account forest.
To make this scenario working properly, you basically have two possibilities.
- Enable a two-way trust between the account and the resource forest
- Run the VMM SQL server instance under a service account from the account forest. Additionally you can enable selective forest authentication to leverage security level.
Both solution are not very sexy from a security point of view. However I’d prefer solution 2) as it has less impact overall while assuming you have a single account forest. Otherwise you have to enable outgoing trust relationships from all required account forests to the VMM resource forest.
Ok, so …. but..
…both solutions above are not accepted for whatever reasons.
Well you can still create user accounts in the resource forest as an exception. The main pitfall here is that VMM users can’t manage their account respectively their passwords in the resource forest. You could implement a custom solution or the IISPWD website enabling users to change their resource account password. However, there is no notification mechanism in the VMM management console telling the users that their password is going to expire.