Windows Authentication + Security

[BrianB]

Hello all,

I have an asp application running on a corporate network behind the company firewall and patched into the main NT domain. I would like to use Windows Authentication to verify users’ identities for tracking purposes.

Originally, when users entered the application, the page checks for a Session Variable called “LoggedIn=TRUE.” If not present, it redirects them to a login page located inside a directory called Login. The idea is that we set up this directory as using Windows Authentication, and the rest of the application as allow anonymous. This limits the amount of user permissions we need to give on the application while still enabling us to use Windows authentication.

It worked really well, giving us the opportunity to customize content to different users, track the feedback they submitted about the application, and without their intervention.

The trouble is, that windows authentication requires that all users have permission to “become” the IIS application. On a domain level, this means permissions to execute scripts on the Web Server, as well as read permissions on our content directory (Login), Winnt, Winnt\System32, Winnt\System32\Inetsrv, and Program Files\Common Files. The client’s security officer rejected this solution to the problem, and disabled pretty much all these permissions, breaking our application. So we have instituted a manual database login that is a real pain to administer and deeply unpopular with users. I think for an application only available behind the firewall, he is over reacting, but IIS security is such a problem that I really can’t blame him.

Does anyone have a clever work around for this problem? I don’t really need users to actually use the resources in the Login directory; I just need IE to send their username. (Reliably authenticating isn’t really even that much of an issue. If they can spoof our domain and username, they can probably get us in ten other ways anyway. This data isn’t confidential.)

I thought about not giving the permissions, letting IE fail to authenticate, using a custom 401.3 error message to hide this from the user, and then scanning the IIS logs to find out who tried to use the resources and failed, then grabbing that entry as the user id. There are a host of problems with this approach, not the least of which would be the annoying pop up boxes that demand a username, password, and domain if IE’s automatic login fails.

Any suggestions are appreciated.

-Brian
Developer
Chicago Data Solutions

http://www.chicagodatasolutions.com

 

[Galrahn]

As long as users have access to the appropriate resources (for example, a file, an HTML page, an Internet Server API (ISAPI) application, etc.) you should be ok.

This could easily be accomplished with a single local group on the web server. The Admin could put the domain users who will use the application into a domain global group, and put the domain global group into the web server local group to solve the problem. This solution allows the admin to open the server up to the specific local group, not large global/local groups (like local machine 'users' or 'domain users'), and the admin can administrate access by controlling who is in the domain global group.

Auditing the web server local group would allow the administrator to control this situation, and if the admin was 'paranoid' he could audit the global group from the DC.

Sounds like your problem is the ignorant administrator. Integrated Windows authentication can be a nice feature and keep a web application secure rather than open it up. Afterall, as an Administrator looking at it from a security perspective, I would much rather know who is using a web application under credintials than to allow anonymous access to everyone if I was given a choice. It would help me know who is breaking my server should trouble arise.... Particularly if security was my primary concern.

Raymond