|
email this FAQ to a colleague
Q:
How can I authenticate users to NT?
A:
The simple answer is to remove IUSR_machine from the permissions of the pages you want to protect, and set the permissions of the various pages appropriately. This isn't always possible, though. Here's an alternative:
Even if the permissions for your entire web include IUSR_machine, you can force authentication for a particular page by issuing a 401. Try putting the following code in an INC filecalled security.inc and using
<!--#INCLUDE FILE="security.inc"-->
at the top of the ASP pages you want secured:
<%
'does the session know the user?
UserID=Session("UserID")
If IsEmpty(UserID) Or IsNull(UserID) Or UserID="" Then
'we need authentication -- is the browser authenticated?
UserID=Request.ServerVariables("LOGON_USER")
If IsEmpty(UserID) Or IsNull(UserID) Or UserID="" Then
'nope. reply with a 401
Response.Status="401 Access Denied"
%>
Put your custom "Access Denied" message here.
<%
Response.End
Else
'yes, they're authenticated
'Translate to DOMAIN/USER format, adding default domain if necessary
UserID=Replace(UserID, "\", "/")
If InStr(UserID, "/")<1 Then
UserID="defaultdomain/" & UserID
End If
'now tell the session about it
Session("UserID")=UserID
End If
End If
%>
How does this work?
If the user has already authenticated this session, we don't worry about checking up on them. This might seem dangerous, but if someone can sniff a session cookie as it goes past and then forge it, they're not going to have much trouble sniffing and forging the username and password, too.
If they haven't authenticated yet, we issue the browser a custom "access denied" page with status 401. The user's browser will then ask them for username and password.
If they hit cancel, they'll get your "access denied" page. This should explain why they're being asked to authenticate, who to contact if they don't have an account, and that if they hit their reload button they'll have another shot at authenticating.
If the user gives a valid username and password, their browser will request the page again, LOGON_USER will be appropriately set, and life is good; the session variable is set so we don't have to do all this again, and the rest of your page is processed.
If the user gets their password wrong, however, IIS will issue a new page with its default "access denied" message and status 401. This will be different to your custom access denied page. The good news is that it can be customised with Steve Genusa's IIScfg utility. The bad news is that it can only be set for the entire IIS machine.
I set the default message to read something like, "To authenticate to this server, you need a valid username and password in one of the following NT domains. Here's how to type your domain and username. Make sure your CAPSLOCK key is off; passwords are case sensitive. Please contact your system administrator if you have any more problems. Hit reload to try again."
This way, people get one error message if they've forgotten their password, and another if they self-admittedly don't have an account.
Another bonus of this technique is that you can put lots of extra code in security.inc to look up group memberships and other settings and stash them in the session object. Your pages don't have to do any hard work; they just include security.inc. Mine is now 185 lines long, and it is only that short because I have server-side components doing some of the work for me.
If all of your users (for the entire machine -- ouch!) will come from one authentication domain, use IIScfg utility to set that domain as the default.
IIScfg is available as:
http://www.genusa.com/iis/iiscfg.zip
- Garth T Kidd
|
