|
Authentication -- NT Challenge/Response
written and ©1998, 99 by Kevin Flick www.flicks.com
creator of Authentix
Using NT Challenge Response is an obvious choice, and is included as one of the options
when you set up each IIS directory. Any directory you want to protect must be on a NTFS
partition.
NTFS is the way to go if you are on a Windows Network.
For intranets NTCR can be an ideal solution with these conditions:
- all users are on accessible domains
- there aren't too many users
- you can require the use of a compatible browser (Internet Explorer is the only browser
which supports NTCR).
You won't want to use NTFS if
- you want compatibility with browsers other than IE, or older browsers
- you want to protect directories on FAT partitions
- you expect (don't we all?) a large number of users.
Having a large number of users becomes a problem because this clutters the NT user
database and it becomes very difficult to maintain. It can also impair the speed of the
operating system itself! Using the NT user base can also be a problem because of potential
security risks. You are elevating a 'mere' web surfer to the status of a full NT user. You
have to be careful not inadvertently grant too many permissions.
- there's a proxy server involved As documented in the IIS 4 Resource Kit, NTLM will not
work through a proxy. The problem is that it requires more than 1 round trip to complete
authentication and so needs a persistent connection end to end end, from client to origin
server. Proxies don't generally work that way.
Definitions
- NTCR = NT Challenge Response
- NTLM = NT Lan Manager
- NTFS = NT File System
How to set up NTCR
In Internet Service Manager (IIS1-3) or the Microsoft Management
Console for IIS (IIS4 and up) select the directory you want to protect. Make sure Basic
(Clear Text) is off and Windows NT Challenge Response is on. You can leave Allow Anonymous
on.
Create an account for each user you want to provide access, remove the permissions for
"IUSR_machinename" from the directory, and add permissions for the added users.
Alternatively, you could set up a group, permit access to that group, and add permitted
users to the group. Remember, the user will need execute rights if the directory has any
ASP, ISAPI extensions, counters, and so on.
Note that when the user returns to a non-protected page, they will be prompted for their
username and password again, unless you have also granted them read-access to
non-protected pages. However cancelling the prompt will let them in, disconcerting though
this may be.
If the user has permission to access the directory but is in a different domain than the
IIS machine, the user will have to prepend the domain name, so IIS knows where to look for
the password.
Because NTCR uses a token mechanism for verifying users, the password of the currently
logged in user is not available to IIS. This will have an impact if you are trying to
access a resource which is not on the same machine as IIS, since IIS will not be able to
login using the current user to a machine elsewhere on the LAN. For example if an NTCR
protected ASP page tried to read an Access mdb file on another machine, it would fail.
Similarly for SQL Server with Integrated or Mixed security. See Q166029, Q149425.
|