[cifs-protocol] [REG:112120610062311] Questions about "Unsecure Join" (old-style join domain)

[Edgar Olougouna]

Gordon,

I will assist you in answering this inquiry. Let's me first recommend the following overview documents.

[MS-DISO]/[MS-ADOD] provided an overview of domain join scenarios (see references). 
Particularly [MS-DISO] Sections 6.1.3.4 and 6.2.3 define the assumptions and pre-conditions Joining a Domain Using a Predefined Account. The initial password of the pre-created account as well as the DC support of SMB null session is described. Section 6.4 describes the task details and processing rules.

[MS-ADOD] may also be a useful informative overview reference. 

[MS-DISO]: Domain Interactions System Overview
http://msdn.microsoft.com/en-us/library/ee675892(v=prot.20).aspx

6 Joining a Domain Using a Predefined Account
http://msdn.microsoft.com/en-us/library/ee675975(v=prot.20).aspx

6.1.3.2 Supporting Actors and Task Interests Summary
http://msdn.microsoft.com/en-us/library/ee675948(v=prot.20).aspx

6.1.3.4 Join a Client Computer to a Domain Using a Predefined Account - Client Computer
http://msdn.microsoft.com/en-us/library/ff718288(v=prot.20).aspx
...
Precondition: The preconditions for this use case are the same as those listed for the task in section 6.2.3.

6.2.3 Task Assumptions and Preconditions
http://msdn.microsoft.com/en-us/library/ee675864(v=prot.20).aspx
The following are the success conditions for this task:
*	The administrator of the domain has created an account to represent the computer that wants to join the domain and this account is present on the domain controller selected by the client during task processing. The password for this account MUST be set to the machine's account name in lower case. This allows the client to have a priori knowledge of the key to use for authentication.
*	The domain controller selected by the client is assumed to accept anonymous SMB sessions.

6.4.4 Task Architectural Details
http://msdn.microsoft.com/en-us/library/ee676107(v=prot.20).aspx

6.4.5 Task Processing Rule Details
http://msdn.microsoft.com/en-us/library/ee676053(v=prot.20).aspx

[MS-ADOD]: Active Directory Protocols Overview
http://msdn.microsoft.com/en-us/library/hh871909(v=prot.20).aspx

2.7.7.1 Join a Domain with a New Account - Domain Client
http://msdn.microsoft.com/en-us/library/hh872084(v=prot.20).aspx

3.1.2 Example 2: Joining a Domain by Creating an Account via SAMR
http://msdn.microsoft.com/en-us/library/hh871863(v=prot.20).aspx

3.1.3 Example 3: Joining a Domain by Creating an Account via LDAP
http://msdn.microsoft.com/en-us/library/hh871988(v=prot.20).aspx

Regards,
Edgar

-----Original Message-----
From: Obaid Farooqi 
Sent: Thursday, December 06, 2012 3:22 PM
To: Gordon Ross
Cc: cifs-protocol at cifs.org
Subject: RE:[REG:112120610062311] Questions about "Unsecure Join" (old-style join domain)

Hi Gordon:
Thanks for contacting Microsoft. A member of the team will be in touch soon.

Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com


-----Original Message-----
From: Gordon Ross [mailto:Gordon.Ross at nexenta.com]
Sent: Thursday, December 06, 2012 2:10 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at cifs.org
Subject: Questions about "Unsecure Join" (old-style join domain)

Hi Dochelp staff,

I have questions about implementing "Unsecure Join" (a.k.a. old-style join domain) where one uses a pre-created computer account.
I've cc'ed the cifs-protocol list in case anyone there might know the answers I'm looking for.

I've searched msdn etc. and found a few pages describing the "Unsecure Join" method.  Here are some of them:

Automating the Domain Join [See the section on "Unsecure Join"] http://technet.microsoft.com/en-us/library/cc730845.aspx

NetJoinDomain function (Windows) [ See NETSETUP_JOIN_UNSECURE] http://msdn.microsoft.com/en-us/library/windows/desktop/aa370433.aspx

We would like to implement "Join using a pre-created computer account"
and I'm looking for more details about how this should work.

As I understand it, the "pre-created computer account" is one that has it's initial password set to the same string as the account name.
The first reference above seems to say that.  However, our test results suggest that this may not be the case.  (or not always?)

Also, on the AD server the MMC "User and Computers" tool offers an action to "reset the computer account".  I'd like to know what that action really does.  Does it set the machine account password back to the computer name?  (our tests indicate maybe not)




Is there a document describing the specific protocol actions we need to perform during an "unsecure join"?

Here's what we're doing now:

(a) get information about the domain from the LSA, via LsaQueryInfoPolicy  (which we do over NULL sessions).

(b) change the machine account password.  We currently use the SamrUnicodeChangePasswordUser2 RPC call [MS-SAMR 3.1.5.10.3] for that purpose.

Step (a) seems to work fine.  In order for step (b) to work, we need to know the password of the pre-created account.
Or is there some other trick for doing the password change?

Thanks,
Gordon Ross <gwr at nexenta.com>
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone
Microsoft is committed to protecting your privacy.  Please read the Microsoft Privacy Statement for more information.The above is an email for a support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE casemail at microsoft.com IN YOUR REPLY if you want your response added to the case automatically. For technical assistance, please include the Support Engineer on the TO: line. Thank you.