ASPNET Permissions on a Domain Controller 2

[link9]

Hello everyone --

Well, one of my biggest gripes about asp.net is the permissions issue for the aspnet user on a domain controller, and especially in a clustered environment.

The problem (for those of you that haven't discovered it yet) is that the ASPNET user needs the "log on as a batch job" permission in the local security policy setting of any machine where asp.net pages are to run.

When the machine you're running it on is a domain controller, though, Win2K won't automatically set this for you, resulting in a "Server Application Unavailable" big red message when you try to run pages.

To alleviate this problem, you just go in and manually create an ASPNET user account, grant the permission to that user, and you're off and running. (

http://support.microsoft.com/default.aspx?scid=kb;en-us;315158)

MS has confirmed this as a bug in the .NET framework concerning domain controllers, and has offered the "fix" outlined in the aforementioned kb article.

Here's the catch, though... after a re-boot, Win2K forgets you did this, and asp.net pages again return the "Big Red Message", as I've "affectionately" dubbed it.

This is especially bad in a clustered environment, since the same situation occurs on a regularly flavored fail-over, as well.

I've been fighting this problem for going on a year now, and it has been the bane of my existence (along with a few other things that we won't touch on here) concerning asp.net.

Well, we just figured out the work-around for this problem.

The fix is amazingly simple:

Create a new group. Call it ASP. Add the user to the group. Add the group under the various policies:
Domain Controller Security Policy
Domain Security Policy
Local Security Policy

Problem solved. Hope this saves someone alot of headaches.


paul

 

[Alcar]

Would be great to FAQ this Paul. Great help! Daren J. Lahey
Just another computer guy...
FAQ183-874 contains "Suggestions for Getting Quick and Appropriate Answers" to your questions.
Support your forums TODAY!

http://www.tek-tips.com/supportus.cfm

 

[hcotech]

I'm hitting my head against the very same problem right now.

Q. When you say add a new group containg in the new user *under* the listed policies - are you referring to the Log On as Batch Job policy setting for each of these?

I've been attempting to follow the MS prescribed work-around and I'm getting terribly confused by all the permission settings they refer to in Q317012. I could sure use that amazingly simple fix right about now.

thanks,

Eric

 

[link9]

Yes, if you're on a domain controller, you have three separate security policies to add the group:

Domain Controller Security Policy
Domain Security Policy
Local Security Policy

Open each of these and grant the new group the "Log on as a batch job" permission. Add the aspnet user to the group, and you're off and running.


paul

The answer to getting answered -- faq855-2992

 

[hcotech]

Unfortunately, I'm still banging my head against this one.

First off, let me state that if I simply change the user settings in machine.config to SYSTEM - everything works fine (of course) so I truly believe I'm just facing a permissions issue.

But when I go to use a custom ASPNET user, even after following link9's suggestion as well as that of Q315158 (MS's bug declaration) and then manually setting permissions using Q317012 (as suggested by above) and a MSDN article which actually makes sense of the later.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT01.asp

Still no luck - 401.5 and 500 errors in the web logs and the appropriate event IDs as listed in the KB articles above.

What could I have missed? Am I not creating the correct type of group possibly? Would Domain local (current config) vs Domain Universal group make any diff?

And just how big is the risk in running as SYSTEM? I've looked, but can't find any details on the path a breach would need to follow in order to do some kind of risk analysis.

Any help would be greatly appreciated

 

[link9]

As far as risk analysis, I can give you just one reason that should seal the deal for you:

The .NET framework has classes that give access to your registry. SYSTEM has permissions to modify the registry.

So now on to your problem. Currently, my 'aspGroup' group is created in the Active Directory Users & Computers snap-in, and looks like this:

Group Scope: Global
Group Type: Security

Now I'm no network admin (mine solved this problem, and I can get more info for you if this doesn't get you fixed up), but that sounds to me like a domain account, not a local account. So I'd go w/ Domain Universal and see if that clears it up.

If it doesn't, then please post back all the information about how you created the group, exactly what permissions you gave to that group (and where you gave them), etc...

I'll pass this info along, and get back to you on the exact setup.

-paul

The answer to getting answered -- faq855-2992

 

[hcotech]

OK, I got it finally. Much thanks to Paul (aka link9)!

So here's what I did to make finally work for me.

First I followed the KB article Q315158 to the letter with one exception. I simply created a new Global Domain (thanks paul) Group to and made my custom aspnet user a member of that group. Then, where ever the docs specified permissions for the user, I substituted the group name in place of the user.

In place of the suggested Q317012 ASP permission setting article, I used this MSDN article

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT01.asp

which explains it in much easier terms to follow.

Here's the kicker... Step 5 of Q315158 indicates you should define username parameter in machine.config using this form:

userName="DomainName\ASPUSER"

I figured that just the user name would be fine, but after some trial and error, I've found that I can make or break this thing simply by dropping or adding back in the DomainName prefix to the username setting.

I don't know why this should matter (probably because of some DC / AD / local group sec thing) or if anyone else has experiences anything similar, but that's how it works for me. Thanks.