Partager via


3.1.2 Example 2: Joining a Domain by Creating an Account via SAMR

This example describes the process of joining a client computer to a domain by creating an account via the SAMR protocol. This is a secure method to join a domain. It establishes the account on the domain controller and creates a new, random password for the domain client and the account in the domain. This example is useful to join a domain or perform other domain-related operations that use the SAMR protocol in a domain environment.

This example builds on the use case described in section 2.7.7.1, Join a Domain with a New Account- Domain Client.

Prerequisites

The general requirements described in section 2.6, Assumptions and Preconditions.

The Active Directory system meets all preconditions described in section 2.7.7.1.

Initial System State

The client is in a workgroup.

Final System State

Upon successful completion, the client state is updated, which indicates that the client is now joined to the domain.

Sequence of Events

The following sequence diagram shows the message flow that is associated with this example.

Message flow to join a domain by creating a new account via SAMR

Figure 43: Message flow to join a domain by creating a new account via SAMR

  1. If the domain controller (DC) was not located earlier, the client locates a domain controller, as described in section 3.1.1.

  2. If the client receives a successful response from the domain controller, the DC is located. If the response is not successful, the task fails.

  3. To establish an SMB/CIFS session to the domain controller, the domain client sends an SMB session bind request. In this bind request, it sends anonymous user credentials to the domain controller ([MS-CIFS] section 3.2.4.2).

  4. When a successful SMB session bind response is received from the domain controller, the SMB/CIFS session is established between the domain client and the DC.

  5. By using the SMB/CIFS session (established in the preceding step) as transport, the domain client makes an LsarOpenPolicy2 RPC call to obtain a policy handle. This handle is used for subsequent calls to retrieve domain information from the domain controller ([MS-LSAD] section 3.1.4.4.1).

  6. Upon receiving a successful response from the domain controller, the domain client obtains a policy handle.

  7. Using the policy handle obtained from the preceding step, the domain client sends an LsarQueryInformationPolicy2 request to the domain controller to retrieve domain information ([MS-LSAD] section 3.1.4.4.3).

  8. Upon receiving a successful response from the domain controller, the domain client retrieves domain information and updates its abstract data.

  9. The domain client makes an LsarClose RPC call to close the policy handle ([MS-LSAD] section 3.1.4.9.4.) that was obtained in step 6.

  10. Upon a successful response from the domain controller, the policy handle is closed. Any failure during the preceding call sequence causes the task to fail.

  11. By using the SMB connection that was established previously, the domain client makes a SamrConnect5 request ([MS-SAMR] section 1.7.2) to the domain controller to connect to the SAM RPC server on the DC.

  12. Upon a successful response from the domain controller, the domain client receives a handle to the server object from the DC.

  13. By using the server handle that was obtained in the preceding step, the domain client sends a SamrOpenDomain request ([MS-SAMR] section 3.1.5.1.5) to the domain controller to obtain a handle for a domain object.

  14. Upon a successful response, the domain controller returns a handle for a domain object.

  15. The domain client sends a SamrCreateUser2InDomain request ([MS-SAMR] section 3.1.5.4.4) to the domain controller to create a new user account.

  16. Upon a successful response from the domain controller, a new user of the domain client computer is created on the domain controller. If this step fails because the account already exists, the domain client attempts to obtain a handle to the existing account ([MS-SAMR] sections 3.1.5.1.9 and 3.1.5.11.2).

  17. The domain client sends a SamrSetInformationUser2 request ([MS-SAMR] section 3.1.5.6.4) to the domain controller to set the password of the newly created user.

  18. Upon a successful response from the domain controller, the password is set.

  19. After the new user account has been created, the domain client sends a SamrCloseHandle request to the domain controller to close the handles that were opened previously ([MS-SAMR] section 3.1.5.13.1).

  20. Upon successful completion of the preceding call sequence, the domain client has successfully created or updated the client account in the domain.

  21. The domain client sends an IDL_DRSBind request, which creates a context handle that is necessary to call any other methods in the interface ([MS-DRSR] section 4.1.3).

  22. Upon a successful response from the domain controller, the domain client obtains a context handle.

  23. The domain client sends an IDL_DRSCrackNames request ([MS-DRSR] section 4.1.4) to the domain controller to obtain the distinguished name (DN).

  24. Upon a successful response from the domain controller, the domain client updates the DN of the client account.

  25. The domain client sends an IDL_DRSUnbind request, which destroys the context handle that was previously created by the IDL_DRSBind method ([MS-DRSR] section 4.1.25).

  26. Upon a successful response from the domain controller, the context handle that was created previously is destroyed.

  27. The domain client connects to the LDAP service, as described in the LDAP specification [RFC2251], and performs an LDAP bind to authenticate the connection by using the process that is described in [MS-ADTS] section 5.1.1.

  28. Upon a successful LDAP bind response, the client account is validated successfully.

  29. By using the LDAP connection that was created in the previous step, the domain client sends an LDAP modify request to the domain controller. This request is used to update the client account with values for the server principal name and host name attributes.

  30. Upon a successful response from the domain controller, the domain client updates the attributes in the client account.

  31. The domain client sends an LDAP unbind request to unbind from the LDAP service, as specified in the LDAP specification [RFC2251].

  32. Upon a successful response from the domain controller, the domain client unbinds from the LDAP service. This operation is performed even if errors were encountered in the preceding call sequence. Any errors in this operation are ignored.

  33. To retrieve the list of domain trusts from the domain controller, the domain client sends a DsrEnumerateDomainTrusts request ([MS-NRPC] section 3.5.4.7.1).

  34. Upon a successful response from the domain controller, the domain client retrieves the list of trusts from the DC.

  35. The domain client updates its local state variables.

  36. After the domain client updates its local state, the domain client sends an SMB session close request ([MS-CIFS] section 3.4.4.8) to the domain controller to close the SMB/CIFS session that was established previously.

  37. Upon a successful response from the domain controller, the SMB/CIFS session is closed.