RE: Question on NTLM authentication.

From: Lisa Cozzens [MSFT] (
Date: 08/07/03

Date: Thu, 07 Aug 2003 20:26:25 GMT

Yes and no.

Domain controllers don't store user passwords by default. They store a hash
of the user passwords. This means that you cannot access resources on other
machines through IIS, even if it is running on a domain controller. The
hash stored on the domain controller is no more useful for authenticating
to a remote machine than the NTLM hash that a normal IIS member server
(i.e. non domain controller) receives during NTLM authentication.

BUT... Windows 2000/2003 domain controllers are "trusted for delegation."
This is a Kerberos concept that means that the domain controller can
request a Kerberos ticket for a service on a remote machine on behalf of a
client. In other words, if you're running IIS on a domain controller, you
can authenticate to a remote machine using the client's credentials and get
access to a file on a share, a SQL server, etc. using Integrated
authentication. Alternatively, you could run IIS on a member server and
simply make that server "trusted for delegation." (It's an option on the
Properties page for the server in Active Directory Users & Computers.)

There are some very important limitations to delegation:
1. Obviously, the client must be running Internet Explorer, which is the
only browser that supports Integrated authentication.
2. The client itself must also support Kerberos. That means it must be
Windows 2000 or later. No NT4, Win95, Win98, etc.
3. The client must be able to talk to the Kerberos Key Distribution Center
(KDC) on port 88. The DC is almost always the KDC as well. This is
generally not an issue in an intranet environment, but might be problematic
for clients connecting across the Internet.
4. "Trusted for delegation" is an all-or-nothing deal. If you choose to
make a server trusted for delegation, it will be able to access ANY service
on ANY server ANYWHERE in your network on behalf of the client. This is a
security risk, and you should make sure that any server that is trusted for
delegation is heavily locked down. (Hopefully your domain controllers
already are...)

Also note that running IIS on a domain controller is NOT recommended, for
security and performance reasons.

The bottom line: If you run IIS on a domain controller, you will be able to
access files on remote servers, but not because the DC stores a copy of the
user passwords. And this configuration is not recommended anyway.

By the way, if all your domain controllers are running Windows Server 2003,
you can raise the domain functional level (see Q322692 for more
information) and take advantage of two very cool new features: "constrained
delegation" and "protocol transition." Constrained delegation resolves
limitation #4 above by letting you specify certain services that your IIS
server can obtain Kerberos tickets for on behalf of the client. So instead
of allowing your IIS server to access ALL services on ALL servers, you can
specify that it can only access file shares on a particular server -- not
the SQL service running on that server, not file shares on any other
servers, etc. Protocol transition works around limitations #1-3 above by
allowing the client to authenticate to IIS using any protocol -- Kerberos,
NTLM, Basic, whatever. On the back end, IIS "transitions" to Kerberos,
which allows it to access resources on remote servers via constrained
delegation. This means that the client does not have to support Kerberos
(it can authenticate using a different protocol, such as NTLM) and it does
not have to be able to talk to the KDC (IIS talks to the KDC on the
client's behalf).

Hope this helps,

> Please refer to this document:
> In the section of Impersonation & Delegation:
> "Resources that require NTLM authentication in order to be accessed will
> be able to access resources on another
> physical NT machine". This is due to the IIS server not having a copy of
> domain users password.
> I would assume that this scenario applies to when the IIS machine is a
> member server and does not hold the Domain User Database.
> However, if the IIS Server is a Domain Controller itself, would it be
> possible for IIS to be able to access another file on another server under
> the context of the domain user accessing the ASP page??
> Hope this question is clear..

This posting is provided "AS IS" with no warranties, and confers
no rights. You assume all risk for your use.
2003 Microsoft Corporation. All rights reserved.