468,554 Members | 1,910 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,554 developers. It's quick & easy.

Domain controller GPO does not deny logon locally right to IWAM_machinename when running aspnet.wp.exe

On a domain controller, the ASPNET (v1.1) worker process (aspnet.wp.exe)
runs under the IWAM_machinename acount (IIS 5). I have expressly denied this
user the logon locally right in the domain controller GPO and yet this
profile gets created under the Document and Settings folder. The
IWAM_machinename registry hive remains loaded when the process ends. I have
to manually unload it with regedt32.exe. Is this normal behavior?
Nov 18 '05 #1
4 2546
Denying log on locally doesn't prevent a service logon, which is what's
happening in this case. If you don't want the user to logon in any scenario,
you'll need to deny service, batch, and network logon rights too.

--
--
Brian Desmond
Windows Server MVP
de******@payton.cps.k12.il.us

Http://www.briandesmond.com
""Rob"" <@> wrote in message news:uV**************@TK2MSFTNGP12.phx.gbl...
On a domain controller, the ASPNET (v1.1) worker process (aspnet.wp.exe)
runs under the IWAM_machinename acount (IIS 5). I have expressly denied this user the logon locally right in the domain controller GPO and yet this
profile gets created under the Document and Settings folder. The
IWAM_machinename registry hive remains loaded when the process ends. I have to manually unload it with regedt32.exe. Is this normal behavior?

Nov 18 '05 #2
Ok, so why does IWAM_machinename registry hive remain loaded when the
aspnet_wp.exe process ends? I have to manually unload it with regedt32.exe.
Is this normal behavior?

Thanks for the tip Brian
--

"Brian Desmond [MVP]" <de******@payton.cps.k12.il.us> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Denying log on locally doesn't prevent a service logon, which is what's
happening in this case. If you don't want the user to logon in any scenario, you'll need to deny service, batch, and network logon rights too.

--
--
Brian Desmond
Windows Server MVP
de******@payton.cps.k12.il.us

Http://www.briandesmond.com
""Rob"" <@> wrote in message news:uV**************@TK2MSFTNGP12.phx.gbl...
On a domain controller, the ASPNET (v1.1) worker process (aspnet.wp.exe)
runs under the IWAM_machinename acount (IIS 5). I have expressly denied

this
user the logon locally right in the domain controller GPO and yet this
profile gets created under the Document and Settings folder. The
IWAM_machinename registry hive remains loaded when the process ends. I

have
to manually unload it with regedt32.exe. Is this normal behavior?


Nov 18 '05 #3
IWAM_MachineName is an IIS account, not an ASPNet account. IWAM should
unload when the IISAdmin service shutsdown.

--
--
Brian Desmond
Windows Server MVP
de******@payton.cps.k12.il.us

Http://www.briandesmond.com
""Rob"" <@> wrote in message news:eW**************@TK2MSFTNGP10.phx.gbl...
Ok, so why does IWAM_machinename registry hive remain loaded when the
aspnet_wp.exe process ends? I have to manually unload it with regedt32.exe. Is this normal behavior?

Thanks for the tip Brian
--

"Brian Desmond [MVP]" <de******@payton.cps.k12.il.us> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Denying log on locally doesn't prevent a service logon, which is what's
happening in this case. If you don't want the user to logon in any

scenario,
you'll need to deny service, batch, and network logon rights too.

--
--
Brian Desmond
Windows Server MVP
de******@payton.cps.k12.il.us

Http://www.briandesmond.com
""Rob"" <@> wrote in message news:uV**************@TK2MSFTNGP12.phx.gbl...
On a domain controller, the ASPNET (v1.1) worker process (aspnet.wp.exe) runs under the IWAM_machinename acount (IIS 5). I have expressly
denied this
user the logon locally right in the domain controller GPO and yet this
profile gets created under the Document and Settings folder. The
IWAM_machinename registry hive remains loaded when the process ends. I

have
to manually unload it with regedt32.exe. Is this normal behavior?



Nov 18 '05 #4
It doesn't

--

"Brian Desmond [MVP]" <de******@payton.cps.k12.il.us> wrote in message
news:O6**************@TK2MSFTNGP12.phx.gbl...
IWAM_MachineName is an IIS account, not an ASPNet account. IWAM should
unload when the IISAdmin service shutsdown.

--
--
Brian Desmond
Windows Server MVP
de******@payton.cps.k12.il.us

Http://www.briandesmond.com
""Rob"" <@> wrote in message news:eW**************@TK2MSFTNGP10.phx.gbl...
Ok, so why does IWAM_machinename registry hive remain loaded when the
aspnet_wp.exe process ends? I have to manually unload it with

regedt32.exe.
Is this normal behavior?

Thanks for the tip Brian
--

"Brian Desmond [MVP]" <de******@payton.cps.k12.il.us> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Denying log on locally doesn't prevent a service logon, which is what's happening in this case. If you don't want the user to logon in any

scenario,
you'll need to deny service, batch, and network logon rights too.

--
--
Brian Desmond
Windows Server MVP
de******@payton.cps.k12.il.us

Http://www.briandesmond.com
""Rob"" <@> wrote in message news:uV**************@TK2MSFTNGP12.phx.gbl... > On a domain controller, the ASPNET (v1.1) worker process (aspnet.wp.exe) > runs under the IWAM_machinename acount (IIS 5). I have expressly denied this
> user the logon locally right in the domain controller GPO and yet this > profile gets created under the Document and Settings folder. The
> IWAM_machinename registry hive remains loaded when the process ends. I have
> to manually unload it with regedt32.exe. Is this normal behavior?
>
>



Nov 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Leonard | last post: by
3 posts views Thread by Richard Chandler | last post: by
reply views Thread by Richard | last post: by
reply views Thread by Rob Roberts | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by UniDue | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.