Asp – IIS running as service Account with AzMan

asp.netiisspnwindows-authentication

I have a requirement to have a website running as a service account for IP reasons, I also want to be able to use AzMan for Auth/Auth of the users. For some reason I can't seem to get these working together. I have set up a sample app to test the waters that basically spits out some user credentials. Other than Azman and the web config set up the app has no integration code (no logging/DB/Webserice interaction) it's a one pager.

Running the app pool under the network service account with the Anon access denied I get:

Windows Identity Check - Name: 'NT AUTHORITY\NETWORK SERVICE'  
Request.LogonUserIdentity.Name = 'CT\rhyc'  
HttpContext.User.Identity.Name = 'CT\rhyc'  
User.Identity.Name = 'CT\rhyc'  
Is in UserRole = 'True'

..which is all good, everything is working, however the service account is network service not the service account I am supposed to be using.
If I switch the account to the service account I get the pop up window asking for user credentials (which I don't want, it should be single sign on); however I was getting these credentials passed down in the previous set up (ct/rhyc)

There has been a setspn command run for the web site (apparently), but I don't really know what spn does, let alone know how to check it.
Also if I allow anon access with the app pool running the service account the I get:

Windows Identity Check - Name: 'CT\SVC-PERAT2-T2DEV'  
Request.LogonUserIdentity.Name = 'PERAT2NTAH3WD1\CVX_IUSR'  
HttpContext.User.Identity.Name = ''  
User.Identity.Name = ''  
Is in UserRole = 'False'

Sorry guys, I'm and IIS n00b, it is not normally something I would do, however our admins don't seem to know much about IIS so it's left to me.. 🙁

Best Answer

with SPN you are getting into the World of Kerberos. This is typically an area of the unknown.

There is a great whitepaper that walks through troubleshooting security around this: http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en

It explains about how to turn on more logging to get to the root of the auth problem. Usually it is to do with delegation in Exchange not being setup to pass the credentials of a user on etc.

More here: http://support.microsoft.com/kb/262177

Related Solutions

IIS AppPoolIdentity and file system write access permissions

The ApplicationPoolIdentity is assigned membership of the Users group as well as the IIS_IUSRS group. On first glance this may look somewhat worrying, however the Users group has somewhat limited NTFS rights.

For example, if you try and create a folder in the C:\Windows folder then you'll find that you can't. The ApplicationPoolIdentity still needs to be able to read files from the windows system folders (otherwise how else would the worker process be able to dynamically load essential DLL's).

With regard to your observations about being able to write to your c:\dump folder. If you take a look at the permissions in the Advanced Security Settings, you'll see the following:

enter image description here

See that Special permission being inherited from c:\:

enter image description here

That's the reason your site's ApplicationPoolIdentity can read and write to that folder. That right is being inherited from the c:\ drive.

In a shared environment where you possibly have several hundred sites, each with their own application pool and Application Pool Identity, you would store the site folders in a folder or volume that has had the Users group removed and the permissions set such that only Administrators and the SYSTEM account have access (with inheritance).

You would then individually assign the requisite permissions each IIS AppPool\[name] requires on it's site root folder.

You should also ensure that any folders you create where you store potentially sensitive files or data have the Users group removed. You should also make sure that any applications that you install don't store sensitive data in their c:\program files\[app name] folders and that they use the user profile folders instead.

So yes, on first glance it looks like the ApplicationPoolIdentity has more rights than it should, but it actually has no more rights than it's group membership dictates.

An ApplicationPoolIdentity's group membership can be examined using the SysInternals Process Explorer tool. Find the worker process that is running with the Application Pool Identity you're interested in (you will have to add the User Name column to the list of columns to display:

enter image description here

For example, I have a pool here named 900300 which has an Application Pool Identity of IIS APPPOOL\900300. Right clicking on properties for the process and selecting the Security tab we see:

enter image description here

As we can see IIS APPPOOL\900300 is a member of the Users group.

C# – Error – Unable to access the IIS metabase

On Windows 8 Pro:

%systemroot%\inetsrv\config

On Windows 7 and 8.1 and 10

%systemroot%\System32\inetsrv\config

(Where %systemroot% is usually C:\Windows)

Navigate to the appropriate location above in Windows Explorer. You will be blocked access with a popup which says:

"You don't have access to this folder - Click continue to permanently get access to this folder"

Click 'continue' for this folder, and with the Export folder underneath. I changed the shortcut back to "Run as me" (a member of the domain and local administrators ) and was able to open and deploy the solution.

Best Answer

Related Solutions

IIS AppPoolIdentity and file system write access permissions

C# – Error – Unable to access the IIS metabase

Related Topic