FIX: ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller

[Bill Kellaway]

Hello there people

As taken from the KB ...

After you install Microsoft Visual Studio .NET or the Microsoft .NET
Framework on a domain controller or on a backup domain controller, if
you try to run an ASP.NET application, the browser displays the
following error message: Server Application Unavailable. I've
encountered the above problem as described in KB Aricle Number 315158
[url]http://support.microsoft.com/default.aspx?scid=kb;[/url][LN];Q315158

One of the 3 recommended resolutions was - < Set the userName
attribute to SYSTEM in the <processModel> section of the
Machine.config file. > - which I choose.

Does anyone have input as to how risky this might be ? This is a web
server that hosts does DNS, SQL and IIS on Win2k.

I've been getting varying opinions on this.

Thanks,

Bill

[Holly Mazerolle]

Basically, this is not recommended because it will make your system
vulnerable. By running the process as the System account this basically
means that if anyone were able to get control of this process they would
have all of the priviledges that SYSTEM would have on the server and as you
know it has many.

My suggestion would be to Create a weak account that has the correct
permissions, and then
configure the <processModel> section of the Machine.config file to use
that account.

Here are some simple steps you can follow to grant NTFS permissions.
Keep in mind that if you are running the 1.0 framework you will need to
replace v1.1.4322 with v1.0.3705

1. Create the domain user and grant it "Log on as a Service", "Log on as a
Batch Job", "Deny Logon Locally", “Access this Computer from the Network”
2. Add domain user to the local Users Group
3. Grant domain user read access to C:\Winnt\microsoft.net
4. Grant domain user Full Control to C:\WINNT\TEMP
5. Grant domain user Full Control to
C:\winnt\Microsoft.Net\framework\v1.1.4322\Tempora ry Asp.Net files
6. Grant domain user Read access
toC:\WINNT\Microsoft.Net\Framework\v1.1.4322
7. Ensure domain user has Read access
toC:\Winnt\Microsoft.Net\Framework\v1.1.4322\confi g
8. Ensure domain user has Read access to C:\Winnt\Assembly
Note: You should use the following command to add permissions to this
folder because it is a special folder and does not have a security tab
cacls c:\winnt\assembly /e /t /p domain\useraccount:R

9. Modify the
c:\winnt\microsoft.net\framework\v1.1.4322\config\ machine.config under
<processModel> change these lines to read
Username="domain\user"
Password="password"
10. Restart IIS for the machine.config changes to take effect

You can use the following command to enforce the policy changes without a
reboot:
SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE

This posting is provided "AS IS" with no warranties, and confers no rights.

Holly

[Bill Kellaway]

[email]hollymamsft@online.microsoft.com[/email] (Holly Mazerolle) wrote in message news:<7br6SKq3DHA.2996@cpmsftngxa07.phx.gbl>...

> Basically, this is not recommended because it will make your system
> vulnerable. By running the process as the System account this basically
> means that if anyone were able to get control of this process they would
> have all of the priviledges that SYSTEM would have on the server and as you
> know it has many.
>
> My suggestion would be to Create a weak account that has the correct
> permissions, and then
> configure the <processModel> section of the Machine.config file to use
> that account.
>
> Here are some simple steps you can follow to grant NTFS permissions.
> Keep in mind that if you are running the 1.0 framework you will need to
> replace v1.1.4322 with v1.0.3705
>
> 1. Create the domain user and grant it "Log on as a Service", "Log on as a
> Batch Job", "Deny Logon Locally", ?Access this Computer from the Network?
> 2. Add domain user to the local Users Group
> 3. Grant domain user read access to C:\Winnt\microsoft.net
> 4. Grant domain user Full Control to C:\WINNT\TEMP
> 5. Grant domain user Full Control to
> C:\winnt\Microsoft.Net\framework\v1.1.4322\Tempora ry Asp.Net files
> 6. Grant domain user Read access
> toC:\WINNT\Microsoft.Net\Framework\v1.1.4322
> 7. Ensure domain user has Read access
> toC:\Winnt\Microsoft.Net\Framework\v1.1.4322\confi g
> 8. Ensure domain user has Read access to C:\Winnt\Assembly
> Note: You should use the following command to add permissions to this
> folder because it is a special folder and does not have a security tab
> cacls c:\winnt\assembly /e /t /p domain\useraccount:R
>
> 9. Modify the
> c:\winnt\microsoft.net\framework\v1.1.4322\config\ machine.config under
> <processModel> change these lines to read
> Username="domain\user"
> Password="password"
> 10. Restart IIS for the machine.config changes to take effect
>
> You can use the following command to enforce the policy changes without a
> reboot:
> SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> Holly

Thank you Holly ! It worked perfectly. One question - it's my
understanding that the machine.config file is XML. Therefore is the
"domain\user" case sensitive ???

Thanks again .. Yippee !!!!!

[Holly Mazerolle]

It is XML but that string with domain/username should not be case sensitive
for the file.

I am glad it worked.

This posting is provided "AS IS" with no warranties, and confers no rights.

Holly

[Joe Kaplan \(MVP - ADSI\)]

That might depend on what version of the framework you are running under.

1.0 has a bug where WindowsPrincipal.IsInRole IS case-sensitive. This is
fixed in 1.1 of the framework.

I have seen case sensitivity be a problem under 1.0 in this situation.

Joe K.

"Holly Mazerolle" <hollymamsft@online.microsoft.com> wrote in message
news:2cCsQU13DHA.3348@cpmsftngxa07.phx.gbl...

> It is XML but that string with domain/username should not be case

sensitive

> for the file.
>
> I am glad it worked.
>
> This posting is provided "AS IS" with no warranties, and confers no

rights.

>
> Holly
>