Partager via

3.1.3 Example 3: Joining a Domain by Creating an Account via LDAP

  • Article

This example describes the process of joining a client computer to a domain by creating an account via LDAP. This is a secure way to join the domain. This task shares many of the actions to establish the relationship between the client and the domain controller (DC) with the example in section 3.1.2. As a variation of that example, the creation or modification of the machine account in the domain can be accomplished via LDAP instead of the SAM RPC interface. This can be useful for alternate domain client implementations that do not intend to include the SAM RPC interface client. This example also highlights again why the domain controller server implementation has to enforce that the multiple interfaces to the same underlying account database keep the objects synchronized across the different protocol interfaces. This example is useful to join a client to a domain or to perform other domain-related operations by using LDAP in a domain environment.

This example builds on the variation in the use case described in section 2.7.7.1.

Prerequisites

The general requirements are described in section 2.6.

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 LDAP

Figure 44: Message flow to join a domain by creating a new account via LDAP

  1. If the domain controller 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. The domain client computer sends an LDAP bind request ([RFC2251] section 4.2) to the domain controller with the credentials of the administrator.

  4. The domain controller uses one of the methods defined elsewhere ([MS-AUTHSOD] section 2) to verify the credentials. Depending on the negotiated authentication method, this might involve additional domain client and server interactions not directly relevant to this discussion. After verification, the domain controller sends an LDAP bind response ([RFC2251] section 4.2.3) to the domain client.

  5. The domain client computer sends an LDAP search request to the domain controller ([RFC2251] section 4.5.1) with baseObject set to the NULL domain name.

  6. Upon a successful response from the domain controller, the domain client updates the local domain name and the forest name in its abstract data.

  7. The domain client computer sends an LDAP search request to the domain controller ([RFC2251] section 4.5.1) with baseObject set to the domain name that was obtained from step 5.

  8. Upon a successful response from the domain controller, the domain client updates the local domain GUID and domain SID in its abstract data.

  9. The domain client computer sends an LDAP search request to the domain controller ([RFC2251] section 4.5.1) with baseObject set to the concatenation of "CN=Partitions," with the value of configurationNamingContext that was obtained in step 5.

  10. Upon a successful response from the domain controller, the domain client updates the NetBIOS name in its abstract data.

  11. The domain client sends an IDL_DRSBind request ([MS-DRSR] section 4.1.3) to create a context handle that is necessary to call any other DRSR messages.

  12. The domain controller sends an IDL_DRSBind response to the domain client.

  13. The domain client sends an IDL_DRSCrackNames request ([MS-DRSR] section 4.1.4) to the domain controller to get the NetBIOS name from the canonical name of the domain.

  14. Upon a successful response from the domain controller, the NetBIOS-formatted domain name and the computer name are used to form the NetBIOS-formatted computer name.

  15. The domain client sends an IDL_DRSCrackNames request ([MS-DRSR] section 4.1.4) to the domain controller to translate NetBIOS format computer name to fully qualified domain name (FQDN) (1) name format.

  16. Upon a successful response from the domain controller, the domain client gets back the list of computer objects with the above FQDN name. If there are more than 1, the task fails.

    If the returned result contains a name, and the domain client does not specify an OU, the domain client updates the DN of the client account. If the domain client specifies an OU, and the returned name is not in the same OU, the task fails.

  17. If no result is obtained in step 16 and the domain client does not specify an OU, the domain client sends an LDAP compare request ([RFC2251] section 4.10) to the domain controller to verify the OU.

  18. Upon a successful response from the domain controller, the domain client uses the DN of the OU and the computer name to form the FQDN formatted computer name.

  19. If the domain client does not specify an OU and no account was found in step 16, the domain client sends an IDL_DRSCrackNames request ([MS-DRSR] section 4.1.4) to the domain controller to get the FQDN format domain from the NetBIOS format domain name (obtained via IDL_DRSCrackNames request in step 13).

  20. Upon a successful response from the domain controller, the domain client updates the FQDN format domain name in its abstract data.

  21. The domain client sends an LDAP search request ([RFC2251] section 4.5.1) to the domain controller with baseObject set to the FQDN format domain name.

  22. Upon a successful response from the domain controller, the domain client parses the returned value for the DN of the default computer container DN (see [MS-ADTS] section 6.1.1.4 for details) and obtains the DN of the preferred OU, which it uses to form the computer DN. If this search fails, the task fails.

  23. The domain client sends an IDL_DRSUnbind request ([MS-DRSR] section 4.1.25) to destroy the context handle that was created previously.

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

  25. The domain client sends LDAP search request ([RFC2251] section 4.5.1) to the domain controller with baseObject set to the computer DN.

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

  27. The domain client sends an LDAP add request ([RFC2251] section 4.7) to the domain controller to add the new account to the directory with the updated DN from the previous step.

  28. Upon a successful response from domain controller, the new account is added in the directory.

  29. The domain client sends an LDAP unbind message ([RFC2251] section 4.3) to the domain controller to remove all the connections that were built in the previous steps.

  30. 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).

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

  32. The domain client updates its local state variables.