{"id":386,"date":"2006-05-04T22:01:00","date_gmt":"2006-05-04T22:01:00","guid":{"rendered":"http:\/\/markwilson.me.uk\/blog\/2006\/05\/problems-accessing-virtual-server.htm"},"modified":"2007-05-15T09:34:34","modified_gmt":"2007-05-15T08:34:34","slug":"problems-accessing-virtual-server","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2006\/05\/problems-accessing-virtual-server.htm","title":{"rendered":"Problems accessing the Virtual Server administration website on a Windows Server 2003 domain controller"},"content":{"rendered":"

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<\/a>) so I figured that adding Virtual Server 2005 R2<\/a> to the mix shouldn’t be too big a problem. It’s certainly not good practice, but it works.<\/p>\n

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.<\/em> message, despite entering the domain administrator credentials when prompted (and already being logged on as the domain administrator).<\/p>\n

From checking the event log, I found that Virtual Server was logging the following event on startup:<\/p>\n

Event Type: Warning
\nEvent Source: Virtual Server
\nEvent Category: Virtual Server
\nEvent ID: 1130
\nDate: 01\/05\/2006
\nTime: 15:28:23
\nUser: NT AUTHORITY\\NETWORK SERVICE
\nComputer: SERVER1
\nDescription:
\nThe 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.<\/em><\/p>\n

For more information, see Help and Support Center at http:\/\/go.microsoft.com\/fwlink\/events.asp.<\/em><\/p>\n

I tried the steps in Microsoft knowledge base article 890893<\/a> but adding the appropriate SPNs to AD didn’t seem to make any difference.<\/p>\n

A bit of Googling turned up a blog entry from David Wang<\/a> 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:<\/p>\n

#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
\n2006-05-01 21:29:39 W3SVC2 ipaddress<\/em> GET \/VirtualServer\/VSWebApp.exe view=1 1024 domainname<\/em>\\Administrator ipaddress<\/em> Mozilla\/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 403 19 1314<\/code><\/p>\n

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<\/a> looked as if it might be relevant (Microsoft knowledge base article 842493<\/a> 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.<\/p>\n

Because my IIS server is also a DC, many of the user rights normally associated with the Network Service account<\/a> 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:<\/p>\n