Microsoft IIS Integrated Authentication

Microsoft's IIS server allows for an integrated authentication method
which allows users within an intranet environment to sign-on
automatically with "pass-through authentication" to servers set for
Integrated Windows Authentication. This works if users are logged into a
workstation in the same domain with the intranet server they are
accessing. In this system, the user's current logon credentials on their
workstation are compared to the server-retrieved credentials for the
user. If the hashes match and the user has rights to the directory, they
are in without a password prompt. The following article provides
additional details:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/comsrv2k/htm/cs_gs_security_xmky.asp

According to the Microsoft documentation, the only way for a user from
another domain to be able to use this method is for the two domains to be
trusted in some way. I happen to have a multiple Windows 2000 Active
Directory forest situation, and I found a way to get user credentials
from a completely untrusted domain into a site protected by this system.

I have two separate Active Directory forests; one in an external network
and one in an internal RFC1918 network. There are two different DNS
domains (matching the AD domain names) for these networks, one public and
one internal. Both forests have the same NetBIOS name. The NetBIOS domain
name is used in the Integrated Windows Authentication method as the user
ID prefix - <domain>\<user ID>. I placed a set of user credentials in
both domains with matching ID (sAMAccountName) and password. I placed a
test IIS Web server protected with Integrated Windows Authentication in
the internal network domain. I configured an IE Web browser on a client
in the external domain with the internal site as a trusted site. I was
then able to access the entire internal site from the external, non-
trusted workstation without a password prompt.

Now, the chances of a real-world exploit coming from this are slim. I
would still have to fully compromise a user and password and gain network
access to the protected resource. However, once these were accomplished,
I could spoof a given user very easily and make it look like I was from a
trusted domain.

[Michael.vonGlasow@HVBInfo.com]

The same is possible with SMB and probably with anything else that relies on
NTLM authentication. The two domains involved may even have different
NetBIOS names.

As I see it, this is as feature rather than a bug. It is a kind of "poor
man's single sign-on" which can be used in workgroup environments without a
domain.

Let us assume a local user (logged on as DUCK-TECH\dduck) tries to access a
remote server. The client tries to log on with credentials as follows:

USER: dduck
PASSWORD: quack (the password is not sent across the network, but verified
through a challenge-response scheme)
REALM (i.e. domain or computer): DUCK-TECH

If DUCK-TECH is not either the server's domain or a domain trusted by the
server's domain, the account DUCK-TECH\dduck cannot have any privileges on
the server and the server cannot perform an authentication against
DUCK-TECH. It will hence replace the realm DUCK-TECH with its own default
realm: Let us assume the server is a member of a domain called ACME, which
has no trust relationship with DUCK-TECH. The server will now try to
authenticate the user with those credentials:

USER: dduck
PASSWORD: quack
REALM: ACME

If these credentials are OK (i.e. there exists an account ACME\dduck with
"quack" as its password), the user is allowed in. The permissions for
ACME\dduck apply. Note that a valid user name and password are still
required for this to work. I wouldn't consider it a security hole at all.