Although I have several computers at home, most of my server roles are running on a single PC. That means Active Directory (AD) domain controller (DC), DNS, DHCP, RIS, WSUS, and print services are all on one box (file services are on my NSLU2) so I figured that adding Virtual Server 2005 R2 to the mix shouldn’t be too big a problem. It’s certainly not good practice, but it works.

Another bad practice is to run internet information services (IIS) on a DC, but I already have IIS installed for WSUS, so adding the Virtual Server administration website should have been reasonably straightforward. Following installation, existing websites on the server were working as expected but any attempt to access the Virtual Server 2005 administration website resulted in an HTTP Error 403 – Forbidden: Access is denied. message, despite entering the domain administrator credentials when prompted (and already being logged on as the domain administrator).

From checking the event log, I found that Virtual Server was logging the following event on startup:

Event Type: Warning
Event Source: Virtual Server
Event Category: Virtual Server
Event ID: 1130
Date: 01/05/2006
Time: 15:28:23
User: NT AUTHORITY\NETWORK SERVICE
Computer: SERVER1
Description:
The service principal names for Virtual Server could not be registered. Constrained delegation cannot be used until the SPNs have been registered manually. Error 0x80072098 – Insufficient access rights to perform the operation.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I tried the steps in Microsoft knowledge base article 890893 but adding the appropriate SPNs to AD didn’t seem to make any difference.

A bit of Googling turned up a blog entry from David Wang which although not completely relevant, contained a reference to a similar problem in the comments. Sure enough, when I checked the IIS logs, the error code was 403 19, as shown below:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2006-05-01 21:29:39 W3SVC2 ipaddress GET /VirtualServer/VSWebApp.exe view=1 1024 domainname\Administrator ipaddress Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 403 19 1314

I tried David’s advice of switching the IIS DefaultAppPool identity to LocalSystem and that worked (LocalSystem is a very highly-privileged account), but (despite my lackadaisical approach to co-hosting services and the probably security implications) I didn’t really feel that it was an ideal solution and I switched back to Network Service. I then set about trying to work out why the Network Service account (NT AUTHORITY\NETWORK SERVICE) didn’t have the appropriate permissions. Microsoft knowledge base article 332097 looked as if it might be relevant (Microsoft knowledge base article 842493 is similar) but didn’t seem to solve the problem (in any case the IIS_WPG group already had the correct permissions) so I fired up the Local Security Settings MMC snap-in and checked out the user rights assignment in the local security policy.

Because my IIS server is also a DC, many of the user rights normally associated with the Network Service account had been removed (and were overridden by the Default Domain Controllers Policy). NT AUTHORITY\NETWORK SERVICE was also missing from the IIS worker process group (IIS_WPG) membership (and could not be added as it is a local account) so I edited the local security policy and the Default Domain Controllers Policy (another bad practice – I should really have created a new policy for DCs running IIS) as follows:

• Replace a process-level token (Default Domain Controllers Policy).
• Adjust memory quotas for a process (Default Domain Controllers Policy).
• Generate security audits (Default Domain Controllers Policy).
• Log on as a batch job (Default Domain Controllers Policy).
• Impersonate a client after authentication (local security policy).

The following user rights were already in existence:

• Bypass traverse checking (inherited from Everyone).
• Access this computer from the network (inherited from Everyone).
• Log on as a service (Default Domain Controllers Policy).

After forcing a group policy refresh (using gpupdate /force) and issuing the iisreset command, I was able to access the Virtual Server administration website as expected; although the event 1130 warnings are still being recorded in the event log, along with event 1129 since I enabled the virtual machine remote control (VMRC) server:

Event Type: Warning
Event Source: Virtual Server
Event Category: Remote Control
Event ID: 1029
Date: 04/05/2006
Time: 21:19:18
User: NT AUTHORITY\NETWORK SERVICE
Computer: SERVER1
Description:
The service principal name for the VMRC server could not be registered. Automatic authentication will always use NTLM authentication. Error 0x80072098 – Insufficient access rights to perform the operation.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I stress that running multiple services on a single PC (even with proper server hardware) is not a good idea; nor is running IIS on a DC; and neither is editing either the Default Domain Policy or the Default Domain Controllers Policy. If you need to do it though, hopefully these notes will help to work out why processes that rely on the Network Service account are not working as they should.