Wednesday, November 28, 2007 1:05 PM
janiquec
Virtual Server 2005 R2 Common Issues and Tips - Service Principal Name Registration Failures
This post is content adapted from Chapter 11 of the Microsoft Virtual Server 2005 R2 Resource Kit.
Service Principal Name Registration Failures
A service principal name (SPN) allows Kerberos authentication to be used for services running on servers distributed across an Active Directory domain. An SPN is stored in a multivalued attribute, called servicePrincipalName, of an Active Directory computer account. At minimum, the information encapsulated in a registered SPN is the service name and the NetBIOS name, fully qualified domain name, or alias assigned to the computer that hosts the service. An SPN can also explicitly define the port number for the service and the account name under which the service runs, if it is different from the Local System or Network Service accounts. A separate SPN must be set for each host name by which the computer can be referenced. For a client machine to identify, mutually authenticate, and connect to a service, the service must have properly registered SPNs in Active Directory.
During Virtual Server 2005 R2 installation on a host that is a member of an Active Directory domain, the following SPN registrations are attempted:
· vmrc/hostname:VMRC Port
· vmrc/fully qualified hostname:VMRC Port
· vssrvc/hostname
· vssrvc/fully qualified hostname
If a Virtual Server host is unable to successfully register its SPNs in Active Directory, you will experience connection failures to the VMRC server and Administration Website on that host. When the Administration Website application attempts to connect to the Virtual Server service on another physical host, user credentials must be passed from the Administration Website to the remote Virtual Server service. This depends on the proper configuration and function of constrained delegation. Constrained delegation is the mechanism that enables an Active Directory computer or service account to perform Kerberos delegation to a well-defined and limited set of services. Because constrained delegation depends on access to properly registered SPNs in Active Directory, successful authentication to the remote Virtual Server service will fail if the SPNs are not registered. In addition, you might also encounter denied access to virtual machine resource files stored on a separate file server, since this access also depends on constrained delegation.
Resolution
If Virtual Server SPNs are not successfully registered in Active Directory, you can manually register the missing SPNs with Setspn.exe, a free utility available from Microsoft. Using Setspn.exe, you can manually add, delete, or view SPNs stored in Active Directory.
Basic Setspn.exe Commands for Virtual Server Services
View registered SPNs
Add Virtual Server SPNs
- setspn -A vmrc/hostname:5900
- setspn -A vmrc/fully qualified hostname:5900
- setspn -A vssrvc/hostname
- setspn -A vssrvc/fully qualified hostname
Note: If you have changed the default VMRC Server port, replace 5900 with the new port number.
Delete Virtual Server SPNs
- setspn -D vmrc/hostname:5900
- setspn -D vmrc/fully qualified hostname:5900
- setspn -D vssrvc/hostname
- setspn -D vssrvc/fully qualified hostname
Note: If you have changed the default VMRC Server port, replace 5900 with the new port number.
Note: The Setspn command-line tool is included in the Microsoft Windows Server 2003 Support Tools that can be found on the product CD or downloaded from http://www.microsoft.com/downloads. For more information on installing Windows Support Tools, see “Install Windows Support Tools” at http://go.microsoft.com/fwlink/?LinkId=62270.
Filed under: Virtualization, Virtual Server, Virtual Server 2005 R2 SP1