bugtraq - Re: Microsoft IIS Integrated Authentication

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <154F6B71B1D0D211B8790008C7397FA40931CD75@xtet0s28.dbva2000.hypovereinsbank.de>
Date: Tue, 29 Apr 2003 15:12:01 +0200
From: Michael.vonGlasow@...Info.com
To: bugtraq@...urityfocus.com
Subject: Re: Microsoft IIS Integrated Authentication

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.