Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have sub webpage (classic ASP) set up with Windows Authentication and no anonymous access.

Permissions to the target directory are set as Read/Execute for a domain local group. This group comprises of members of another domain to which we have a trust relationship. Let's call it GroupA

Permissions are also set for the IT group of our domain, of which I'm a member (GroupIT).

All works fine, until something happens overnight...

Each morning the GroupA members cannot access the site, being challenged for a login/password. Entering their credentials here (with domain qualifier) does not work. GroupIT access works fine.

Webserver logs show "401 5" errors. Event viewer Security logs show the users authenticating successfully to the server.

IIS is not completing the authentication process. It looks as if the permissions for GroupA on the target folder are dropped. They are of course still visible though.

A restart of IIS sorts the problem until next morning.

Have spent a lot of time trying to get to the bottom of this, including using MS Auth Diagnostics, which confirms an Authentication (401) problem when I probe a login using a GroupA user's credentials. There is no task running on webserver or our domain that would obviously cause this. I don't think it's a case of cached credentials, as I have added new users to GroupA and found they could not access the site either.

I would greatly appreciate any thoughts..

share|improve this question

1 Answer 1

Thoughts:

  • Does recycling the Application Pool that contains the authenticated page fix the problem?

  • Can the app containing the page be isolated into its own App Pool?

If either fixes the issue, you might be able to work around it (in lieu of actually fixing it) by setting a sheduled recycle for that app pool, for (say) 5am each day.

After 5am, the first request coming in will spin up a new App Pool and worker process, and if that's what's fixing it, it'll make it transparent to the users.

There's not enough information about the application or app pool - and what other applications, ISAPI filters, etc it's using - to be more accurate than that.

share|improve this answer
    
Thanks Tristan, I will try out your suggestions and post back here with outcome... instead of recycling the IIS , I'll recycle the Application Pool. –  NotNowJohn Dec 8 '10 at 17:31
    
Just to update - have tried recycling the app pool, it temporarily fixes the problem but it reoccurs some time later. –  NotNowJohn Dec 16 '10 at 13:29
    
OK, so more information is needed. I'd suggest you grab a memory dump of the app pool when it's working, a dump in the broken state, and contact microsoft support for some help debugging it. Incidentally, the App Pool recycle should be your first step in restoring service - restarting IIS as a whole is probably only working because it does this as a side-effect... in short, you're looking at a broken application, not the whole server. I think! –  TristanK Feb 17 '11 at 21:03
    
I eventually resolved this problem... "Authenticated Users" requires read/execute permission to the root area of the website. Users of the protected sub-area need permission (other than the anonymous user) to traverse the root. Hope this helps somebody somewhere. –  NotNowJohn Aug 26 '11 at 19:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.