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.
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.
[ reply ]