First published on MSDN on Aug 04, 2009
Hi,
Using the Windows Server Failover Clustering WMI provider from within script is a simple approach to avoid dealing with the complexities of the clustering native C APIs, however WMI does has some limitations. In this blog I am going to discuss the impersonation of the security contexts. Since WMI uses DCOM to communicate to the remote machines it is limited to impersonation issues imposed by DCOM and the domain policies. More information about impersonation and delegation is available at:
http://msdn2.microsoft.com/en-us/library/ms680054(VS.85).aspx
For security reasons, many domains impose a policy which allows only a single remote impersonated connection. Therefore, additional remote connections cannot impersonate the connection. Unfortunately, with the nature of clustering being a distributed platform, remote connections are commonly required. This can put a limitation on how WMI can be used for some clustering features.
Since the Failover Clustering WMI provider impersonates the callers security context this affects these four methods.
· MSCluster_Cluster.EvictNode
· MSCluster_Cluster.CreateCluster
· MSCluster_Cluster.AddNode
· MSCluster_Cluster.DestroyCluster
In order to limit these connection constraints, if the connection is made directly from the local node the connection becomes a local connection. Therefore, another remote connection can be performed and the impersonation limitations will not come into play on this connection.
Evicting a Node
Let’s examine the case of evicting a node from an existing cluster. First, a connection to either the cluster name or one of the nodes in the cluster is required and this connection may become impersonated (in the case of a remote connection). Internally, the WMI provider will make a call into clusapi.dll EvictNode API to remove the node from the cluster. The MSCluster_Cluster.EvictNode API first removes the node from the cluster, but then a connection to that node is required to perform additional cleanup of the node’s membership. This cleanup requires another remote connection to the node.
If the original connection was made to the local node, then the call required for cleanup becomes a local call and no impersonation limitations exist. In the case when the original connection is made as a local connection to a node that is in the cluster but not the node being evicted, then a remote connection is required by the cleanup call in the EvictNode API to the node being evicted, and this remote call is allowed since it is the first remote call and there are no impersonation limitations. Now let’s consider the case where the original connection is made from a client to a cluster node that will be evicted. Now, the first connection is impersonated by the original remote connection. When the EvictNode API tries to connect to the node there is already an impersonated connection, therefore the new connection is refused with ERROR_ACCESS_DENIED. In this case the impersonated connection cannot create the second connection so the call will fail. This is also known as the “double hop” scenario. For more information about the “double hop” scenario, check out our earlier blog post:
http://blogs.msdn.com/clustering/archive/2009/06/25/9803001.aspx
Creating a Cluster
In the case of MSCluster_Cluster.CreateCluster the Failover Clustering WMI providers requires a connection to all of the cluster nodes. Since only one remote connection is allowed, this can become challenging. If the WMI connection is made to a remote node then when CreateCluster API tries to connect to the node(s) to add the node(s), it will fail since a remote connection has already been made. The only way to use CreateCluster with WMI is to connect to a local node. From this connection a cluster can be created. The cluster will only require a remote connection for each node it adds. Since only one connection is made at a time so this allows the nodes to be added to the cluster. In order to add other nodes the MSCluster_Cluster.AddNode method can be used as well.
Adding a Node
The MSCluster_Cluster.AddNode method has the same limitations which occur in MSCluster_Cluster.EvictNode. For MSCluster_Cluster.AddNode, a connection to the cluster is required. If this connection is local then the connection to the node to add will be allowed. However if the connection to the cluster is remote then that additional connection to the node we want to add will fail due to the “double hop” limitation.
Destroying a Node
In MSCluster_Cluster.DestroyNode a connection is needed to the cluster. Also a connection is needed to each of the nodes which will be evicted. All the nodes must get evicted before the cluster can be destroyed. Again, if the original connection the cluster is local then one hop to each node is allowed. However, in the case where the original connection is remote, the hops to the individual nodes will fail due to the “double hop” scenario.
WMI can be an alternative to using the complex native C APIs, but it is important to remember that these four methods have limitations which need to be understood. Excluding these four methods, there are currently no more impersonation limitations in the Failover Clustering WMI Provider. In some cases these limitations can be avoided by knowing in which conditions these methods work and when impersonation becomes a concern. In other cases these limitations are just the nature of how DCOM works. Another alternative is to use PowerShell on Windows Server R2 or to use the native C API outside the context of WMI, because no impersonation limitations exist.
Thanks,
Noah Davidson
Software Development Engineer
Clustering & High-Availability
Microsoft
