By Tim Wheeler on 6/16/2008

Here is a common IIS error. 401.1 - Unauthorized: Access is denied due to invalid credentials.  Here is one possible resolution.

If an ASPNet site requires authenticated users, but your not using Integrated Windows Authentication then you might get a 401.1 error, with a login dialog that never accepts credentials no matter how many times you enter them. 

In IIS, edit the website or folder, click the Directory Security tab.  Make sure Integrated Windows Authentication is ON.  If you are still getting this error, it maybe that the account your app pool is running under does not have permission to files or registry keys.  Try turning on both Anonymous, and Integrated, or grant more permissions to your service account.  If your system impersonates, the requesting user will need permissions to whatever the site needs, like writing to the file system.  Not a very nice situation.  Its better to run under a service account and just impersonate when you need to.

Also try running:
Cd %systemroot%\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis –ga [domain]\ServiceAccount

 

By Tim Wheeler on 6/16/2008

If your Application Pool won't start in IIS 6, or has a little red x, make sure your account has correct local permissions.

When you specify a domain account to be your service account you need to add the account to:

Local Security Group IIS_WPG
Local Security Policy -> Local Policies -> User Rights Assignment -> Logon as a service
From a command prompt run:
Cd %systemroot%\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis –ga [domain]\svcSQL_Reports
iisreset
Note: Reboot after you change the local security policy.  Obviously your service account requires correct ACL permissions on the file system, registry etc.

By Tim Wheeler on 6/6/2008

One problem with developing on Windows XP using IIS 5 is we don't have application pools.  So if your hosted system needs to access a domain resource you will get denied because its using the worker process ASPNet_WP.  Sure you could use some windows api calls and login as another user but then you have to manage credentials, and also its not needed for production as you can just set the app pool.  So, in Windows XP I want IIS 5 to run under a domain service account.  After a bit of trial and error here is the process I went through. 

1. Create a domain user account to be used as a Serivce Account.
2. Grant local permissions
3. Grant local security policy
4. Run aspnet command.
5. Update your Machine.Config
6. Reboot

Local permissions
You need to grant local ACL permissions for any file access.  If it writes log files you will need write permission.  If you log to the event log you will need write permission on the appropriate registry key.  Or just grant the service account local admin.  (Not defence in depth but ok for development)

Local policy
Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
Add the service account to the following polices:

• Access this computer from the network
• Impersonate a client after authentication
• Logon as a service

IIS Permissions
Start -> Run:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -GA domain\accountname

Update your Machine.config
Run:
Notepad “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config”
Search the "<processModel" element and Add or edit  to look like:

<processModel comImpersonationLevel="Impersonate" userName="domain\accountname" password="password"/>

Note: This is under the element <system.web>, and there should only be 1 processModel element.

After you update the Machine.config you need to reboot.

Note: When you are using WCF here are the command to get the user or the system Account:
Service Account = System.Security.Principal.WindowsIdentity.GetCurrent()
Calling User = System.ServiceModel.ServiceSecurityContext.Current.WindowsIdentity

By Tim Wheeler on 6/5/2008

After integrating the Enterprise Libraries Security block into my current project, I kept receiving an "Element Not Found" exception when the block was trying to access the AzMan store. 

Situation:
By default the Security Block will look for only AzMan Tasks, I was trying to authorize Operations.

Solution:
Prefix your operation name with an "O:", and BTW its case sensitive.  I must have missed that part in the help file. 

Actually I found the security block help dismal.  Didn't find anything on the net and came to the conclusion that not many people use it with AzMan.  However, after sorting that issue out and building a permission class with a nice enum, I've found that using AzMan and the security block is actually really good.  You can define the authorization to a very granular level.  Note: I've upload my AzManPermission.cs class to the Code Zone if anyone is interested.