Link to home
Start Free TrialLog in
Avatar of dviolett
dviolettFlag for United States of America

asked on

IIS URL Authorization failed for the request with XML role provider

I'm having an intermittent issue on one of our windows 2008 R2 web servers. We have a site that uses windows authentication and a custom xml role provider that normally works fine. On some mornings the users are not able to access the site though, they receive login prompts 3 times, then an authorization failed screen. Simply restarting IIS or resetting the app pool generally fixes the issue, but sometimes has to be done 2-4 times before it will let users access the site. After, it will work fine for days or weeks before the next failure. It's behaving as if though it's not reading from the authorized users or roles xml files that are in the root of the web app, but there are no event log entries stating it was not able to open or read from the files.

--EDIT
This code was originally running on a windows 2003 server for about a year without this issue ever occurring, it's only begun since moving to the new windows 2008 R2 server in January and updating the framework from 3.5 to 4.0.
__

Here is the text out of the event log when it fails:
Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          7/13/2011 9:00:45 AM
Event ID:      1314
Task Category: Web Event
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      S1-CB-1.security-finance.com
Description:
Event code: 4007
Event message: URL authorization failed for the request.
Event time: 7/13/2011 9:00:45 AM
Event time (UTC): 7/13/2011 1:00:45 PM
Event ID: a8d76aab41484b79be0eb47853ab0435
Event sequence: 10
Event occurrence: 9
Event detail code: 0
 
Application information:
    Application domain: /LM/W3SVC/1/ROOT/sfcCentralBankruptcy-1-129550330325890352
    Trust level: Full
    Application Virtual Path: /sfcCentralBankruptcy
    Application Path: C:\inetpub\wwwroot\sfcCentralBankruptcy\
    Machine name: S1-CB-1
 
Process information:
    Process ID: 3280
    Process name: w3wp.exe
    Account name: NT AUTHORITY\NETWORK SERVICE
 
Request information:
    Request URL: http://sfccentralbankruptcy/sfccentralbankruptcy/ 
    Request path: /sfccentralbankruptcy/
    User host address: 10.1.8.133
    User: SECURITY_GROUP\dgv
    Is authenticated: True
    Authentication Type: Negotiate
    Thread account name: NT AUTHORITY\NETWORK SERVICE
 
Custom event details:

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="ASP.NET 4.0.30319.0" />
    <EventID Qualifiers="16384">1314</EventID>
    <Level>4</Level>
    <Task>3</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2011-07-13T13:00:45.000000000Z" />
    <EventRecordID>8084</EventRecordID>
    <Channel>Application</Channel>
    <Computer>S1-CB-1.security-finance.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data>4007</Data>
    <Data>URL authorization failed for the request.</Data>
    <Data>7/13/2011 9:00:45 AM</Data>
    <Data>7/13/2011 1:00:45 PM</Data>
    <Data>a8d76aab41484b79be0eb47853ab0435</Data>
    <Data>10</Data>
    <Data>9</Data>
    <Data>0</Data>
    <Data>/LM/W3SVC/1/ROOT/sfcCentralBankruptcy-1-129550330325890352</Data>
    <Data>Full</Data>
    <Data>/sfcCentralBankruptcy</Data>
    <Data>C:\inetpub\wwwroot\sfcCentralBankruptcy\</Data>
    <Data>S1-CB-1</Data>
    <Data>
    </Data>
    <Data>3280</Data>
    <Data>w3wp.exe</Data>
    <Data>NT AUTHORITY\NETWORK SERVICE</Data>
    <Data>http://sfccentralbankruptcy/sfccentralbankruptcy/</Data>
    <Data>/sfccentralbankruptcy/</Data>
    <Data>10.1.8.133</Data>
    <Data>SECURITY_GROUP\dgv</Data>
    <Data>True</Data>
    <Data>Negotiate</Data>
    <Data>NT AUTHORITY\NETWORK SERVICE</Data>
  </EventData>
</Event>

here is the authentication/authorization nodes from web.config


<authentication mode="Windows"/> 
		<authorization>
			<allow roles="Admin"/>
			<allow roles="Manager"/>
			<allow roles="User"/>
			<allow roles="DataViewer"/>
			<allow roles="BranchSupervisor"/>
			<deny users="*"/>
		</authorization>
		<roleManager enabled="true" defaultProvider="sfcXMLRoleProvider">
			<providers>
				<add name="sfcXMLRoleProvider" type="sfcMasterModules.sfcXMLRoleProvider"/>
			</providers>
		</roleManager>

Open in new window

Avatar of Gorkem Yuksel
Gorkem Yuksel
Flag of Canada image

Hi,

You may want to check to ensure the connection between the Active Directory server is always up.  If at any point the connection drops, it may not be able to re-connect - without a reboot - thereby causing the authentication issues you are seeing.

I've had these kinds of issues in the past where the AD server would occassionally blip off the network for a minute and come back online and break authentication for our Intranet.

Cheers,

G.
Avatar of dviolett

ASKER

Hi gyuksel,
Thanks for your response!
I thought about that too. I'm not a network guru, but since the event log has the following entries
 User: SECURITY_GROUP\dgv
    Is authenticated: True
    Authentication Type: Negotiate
does that mean that the user is being authenticated correctly when they are connecting to the site, or is this being passed up from the client machine? With these entries, could it still be an issue with the connection to the domain controller? We have 5 local domain controllers and one remote on a very fast network connection. How can I tell at the time the error is happening if it's an issue with IIS connecting to the DC? I can remote into the server just fine, so the desktop is connecting to the DC fine, and still continue to get the error while trying to open the web app.
ASKER CERTIFIED SOLUTION
Avatar of Gorkem Yuksel
Gorkem Yuksel
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I"ll ask our network folks to do that
Thanks
We are going to wait for the next time this issue occurs and see if we can track the network traffic to the domain controller, hopefully that will let us know if it's a connection to the DC issue.
We've not had this issue for several months now, not sure why it resolved. Could have been an update to the web server, our domain controller, or some change put in place by our network admins.
Sorry I can't give a definitive answer on the solution for anyone else experiencing this.
Giving gyuksel credit for answer since he tried to help.