One of the most laborious tasks in deploying intranet application is setting up security on the server. In particular when one tries to implement Windows Authentication in ASP.NET 2.0 and IIS 6.0 there is a number of tasks to do and things to check out …
Note that what I describe below is only applicable to a certain type of setup – which is impersonation of the application through the pool…
So steps are as following:
1. Set up an active directory (deny logon type) account X
2. Set identity of the pool to this account X
3. Set application to work with the pool
4. Comment out in the web.config of application <identity impersonate="true">
5. So far nothing complicated? Right… So now starts the tricky parts - set the security of the application to Integrated Windows (uncheck ALL other checkboxes)
6. Check the NTAuthenticationProviders of the IIS and the nodes (node may be designated by web site number). Set it to “NTLM,Negotiate” if not set. The syntax is as following in cmd: cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM,Negotiate". The article describing it is here: http://support.microsoft.com/kb/871179
7. Add the account X to belong to IIS_WSG group
8. Make sure that HTTP Keep-Alives is checked. If it is not you may be in trouble – check out this blog: http://www.west-wind.com/Weblog/posts/4375.aspx
9. Go to file system and add all the necessary permissions for the application folder. I mean ASP.NET account, group IIS_WPG, IWAM and IUSER and also – important – Authenticated Users and Domain Users (from Active Directory)….
The steps above are by no means guarantees that your intranet application will work from the first attempt. There is a number of other things to consider, such as network topology permissions which accounts you use may have or lack of such, version of the .NET Framework and other things…
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment