Everhart,Glenn
From:	Paul Ashton [paul@argo.demon.co.uk]
Sent:	Tuesday, April 21, 1998 10:07 AM
To:	Paul Leach
Cc:	Stout, William; ntsecurity@iss.net
Subject:	Re: (Fwd) RE: [NTSEC] Anonymous logins 

TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
Contact ntsecurity-owner@iss.net for help with any problems!
---------------------------------------------------------------------------


paulle@microsoft.com said:

> When joining a
> workstation to the domain, you supply an account name and password of
> a user privileged to create new machine accounts. That password is
> used to encrypt the workstation's machine password. If the bogus PDC
> does not know the that password, the machine password will decrypt to
> garbage, and the workstation will be unable to establish a secure
> channel or log anyone in to a domain account.

The account name and password are *not* used to encrypt the machine
password, they are used to create the machine account in the PDC
with the default password of the hostname in unicode lower case,
i.e. to authenticate the RPC that creates a new SAM entry with
a default password. It would certainly be nice if they did use
the admin password to encrypt a new random machine password,
but it is not the case (unless you've recently changed this Paul?).

> Now, I'm sure you'll tell me that there is another way to join the
> domain. The owner of the rogue PDC can create accounts for all the
> workstations, whose password will be the name of the machine, and IF
> they can then convince the users of the workstations to rejoin the
> domain without supplying the name and password as above, then the
> workstations can be fooled. How the owner would do this without giving
> himself away is problematic.

I would also be surprised if that were the case. I'm sure I have
previously tried it.

However, if you do want to introduce a rogue PDC it is certainly
possible until the contents of some critical RPCs are signed
instead of just the authenication headers. Paul Leach projected
a fix for this "in about a week" 2 months back. I presume the
problems fixing this and the other lanman hash and session
key stealing problems discussed on ntbugtraq have delayed this
until sp4?

All the rogue PDC has to do is forward all requests to the real
PDC except the NetLogonSamLogon RPCs. With those, you pass the
request on to the PDC in order to get the RPC authentication
header and pass on any contents you wish back to the client.
I'd say you are then effectively a PDC. Amusingly enough,
if the real PDC says "bad password", the authentication header
is sufficient for the contents of the returned RPC to be
changed to "authentication as Domain Administrator accepted,
here are your SIDs, home directory, profile path,...", and
still be accepted as the client :-)

If the rogue PDC really wants to screw things up, it can
forward all requests other than machine password change
requests, and change those to random values before passing
them on (goodbye BDCs :-( ).

Paul