While the answers are around already, the simplified listing of what to do when you create a user in your domain to run an IIS 6.0 application pool on Windows Server 2003 is:
- Add the user to the IIS_WPG on the web application server.
- Run aspnet_regiis with the -ga flag and the domain qualified user name (ie. MyDomain\TheUser). This gives the app pool user the ability to read and write from appropriate files, etc. I thought this would be accomplished by adding the user to the group above, but it didn't work until I had completed both of these steps.
- Run setspn on the domain controller (you'll need to have the toolkit installed) with the protocol name 'HTTP' and application server name (ie. HTTP/myAppServer) and a second argument for the domain qualified username (ie. MyDomain\TheUser). All together that is 'setspn HTTP/MyAppServer MyDomain\TheUser'. It is also recommended that you run the same command again, but with the fully qualified name of the app server.
Some security minded folks will tell you that you shouldn't actually do this anyhow, but if you must this set of instructions will allow you to use a user with minimum permissions. Just make sure this user is not used for anything else - thus limiting the potential the user will have an increasing permission set over time that no one can remember.
Posts
6 comments:
You can most often skip the setspn step. Service Principal Names (SPN's) are only used when using the Kerberos Authentication Provider with delegation (and constrained delegation).
Adding a SPN (with setspn) will only be necessary if you require the impersonation of an account beyond the initial tier where authentication originally happened (this is a NTLM limitation). If a Domain User logs into a Web Site (using IE) through IIS with Integrated Authentication, enough permissions are granted on the web server for the App Pool Identity to impersonated that user on the web server. If 'identity impersonate' is off in an ASP.NET application, the web server will use the App Pool identity to log on to the database server.
If, however, your requirements dictate the need to impersonate the domain user from the web browser, through the web server and back to the database server (or another backend service ON A SEPERATE SYSTEM), you will need to enable Kerberos authentication on the web tier, setup a SPN for the Web Tier and the backend tier (SQL Server adds SPN's automatically), and then configure constrained delegation to limit the ability of the App Pool identity to impersonate people to the other services on the network.
To enable the Kerberos NT Authentication Provider in IIS by using the adsutil.vbs script in the AdminScripts folder to set the NTAuthentication provider to "Negioate, NTLM". After the SPN name is added for the Protocol\domain name (and optional tcp/udp port), constrained delegation can then be configured through the Active Directory Users and Computers snap-in.
If you enable Kerberos on a Web Site you have to be very careful when setting up multiple ASP.NET applications on that same Site. All other applications on that site will need to run under the same identity as you can only have one service principal name per domain registered in Active Directory. You can still set up separate App Pools, but the identities must be the same across the entire site.
True, an spn is most often not required.
MS suggests the following if you have multiple apps:
Note: You cannot have multiple Web applications with the same host name if you want them to have multiple identities. This is an HTTP limitation, not a Kerberos limitation. The workaround is to have multiple DNS names for the same host, and start the URLs for each Web application with a different DNS name. For example, you would use http://app1 and http://app2 rather than http://site/app1 and http://site/app2.
Excellent.
I did speak too hastily when saying "...[SPN's] are only used when using the Kerberos Authentication Provider with delegation (and constrained delegation)."
I should have said, "SPN's are only used when using the Kerberos Authentication Provider." - you ALSO would need an SPN with delegation, but the main requirement for a SPN is Kerberos. But if you connection between the web server and database server is forced to be Kerberos, you'd also need a SPN in that case and that's the scenario you're describing in the main Post.
Oh yea - one other question. Do you have any of the references to the "Security Minded Folks" who recommend not changing the App Pool Identity to another underprivileged user?
No one resource I can recall. The logic behind it is basically:
1. If you use a domain account instead of a local specialized account like Network_Service you are already elevating the user that could be compromised by making them a member of the domain (increased attack surface).
2. Admins forget about the reasons accounts are created/where they are used and may reuse a utility account in other areas, increasing the permissions of a user that can be compromised.
3. Most people do this in order to use trusted auth to sql server, and there are better ways to secure this operation, without exposing a user as a service.
Gabe,
Thanks for the article and commentary. In your last comment, you remark "... there are better ways to secure this operation, without exposing a user as a service." I am attempting to setup my WebService (anonymous access) with trusted Auth to SQL Server. Any insight would be appreciated.
Post a Comment