Share via

Active Directory domain join On Premises, Azure and Hybrid (Part 1)

  • Article

This article will be the first one of a 3 parts series which will deal with domain join (On-Prem,Azure, and Hybrid).

Introduction

In the TechNet forum, you'll see a lot of questions about users unable to join their computers into their corporate on-premise domain. 

This article series tries to help understand what happens behind the scene and how you can have a high-level view of the main components involved during this operation.

 

High-level process

Joining a computer to an on-premise domain will implicate 4 main network flows :

  1. DHCP (For dynamic addressing based client)
  2. DNS 
  3. LDAP 
  4. Kerberos authentication to Key Distribution Center (KDC)

Below a schema of the process :

As you can already see if you have an issue to join your on-premise domain based on the above you can already check :

  • The network configuration of your computer : 
    • If you have a valid IP address and not an APIPA
    • If the DNS servers configured are valid
  • If your client can communicate on the DNS port (53 UDP/TCP) with the DNS servers configured
  • If your client can communicate on the LDAP port (389 UDP/TCP) with the LDAP server
  • If your client can communicate on the Kerberos port (88 UDP/TCP) with the KDC

Note

In a Windows environment, the domain controller host the LDAP and KDC role and can also host the DNS server role.

To check the communication you can use telnet or PowerShell.
For Powershell, the cmdlet, Test-NetConnection, will work on Windows 10 so no need to install something.
***Example : Test-NetConnection dnsserver.fqdn -port 53

Detailed Steps

In this part, we won't deal with the DHCP communication because you can find a lot of articles regarding how a computer obtain a DHCP lease and how to troubleshoot that. So let's move to the second part of the communication the DNS query.

DNS communication

The first query when you hit the OK button when changing the domain affiliation will be :

  • A query to the DNS server configured to get all servers hosting the LDAP service, which mean your domain controllers. This query will take the form of an SRV request _service._transportprotocol.domain.

Note

All domain controllers register these kind of record and the list is located in a file named netlogon.dns which you can find under %systemroot%\System32\config

Below an example from a network trace :

  • The DNS server will answer with a list of records corresponding to the query and based on the priority and weight (Each SRV records have a priority and weight when registered).

Note

Priority is self-explanatory and weight is relative value which means how often this record will be queried if another one have the same priority

****

  1. asd
  1. asda
  • Because the DNS server answer with a hostname the next query will be to have the corresponding IP address of the LDAP server or DC.

  • The DNS server will answer with the IP address of the LDAP server or DC.

At this stage, the client got what it needs to start the LDAP communication.

Note

If you want to push your troubleshooting a step forward, you should not only check that your client can communicate with your DNS servers but also that your DNS server got the SRV record for at least _ldap._tcp.dc._msdcs.domainname.

nslookup can help on that with a set type=srv

LDAP communication

  • The client will query the LDAP server or DC to know if a computer object already exist in the LDAP server database


  • The LDAP server or DC will answer with a list of objects if any (In my case none)


At this stage, an SMB negotiation is done between the client and the LDAP server or DC.

Note

If you want to push the troubleshooting a step forward, you should look into the DC database that you don't have any computer objects for the computer you want to join and if you have one be sure that this object is reset.

SMB communication

  • The client and the LDAP server or DC will negotiate the security of the SMB communication.

Note

During your port query, you should include the SMB port (445).

Kerberos communication

Right after the SMB communication, a Kerberos authentication is initiated but before that, the client needs to locate the KDC service so another request is done to DNS server to gather information about the KDC service.

  • Client send a query in form of an SRV request to get information about the KDC to the DNS servers configured


  • The DNS server answers with a list of KDC servers


  • After that you have the real Kerberos authentication (For the account use to join the domain --> t.tom) in a form of :
    • KRB_AS_REQ
    • KRB_AS_REP

    • KRB_TGS_REQ (For the cifs of the domain controller)
    • KRB_TGS_REP


  • An SMB session is established using Kerberos and with the target the Administrative share (IPC$)

At this step of the process the client will do an LDAP query to get information about the version of the LDAP server (DC).

LDAP communication

  • This LDAP communication is only to get information regarding the naming context (or partitions) located on the LDAP server or DC, the supported version of LDAP protocol, etc...

  • The DC will answer with the requested information and another Kerberos authentication take place but this time for the LDAP service.

Kerberos communication

  • The client will request a service ticket for LDAP in order to bind to the LDAP server or DC for computer object creation


  • The client bind to the LDAP server or DC to create the computer object
  • Some RPC communication take place between the client and the LDAP server or DC

At the end of these communication another Kerberos communication occur but this time with the computer identity :

At this stage, we can safely say that the computer is joined to the domain.

Conclusion

As you can see now, the process of joining a computer to the on-premise domain involve different parts :

  • DNS servers
  • DNS records (Especially the SRV records)
  • LDAP server
  • LDAP database content (To check if the object exist)
  • Kerberos

To better troubleshoot issue of on-premise domain join it is important to look at these points above.

Below you will find a good article regarding error messages you can have during on-premise domain join operation :
https://social.technet.microsoft.com/wiki/contents/articles/1935.troubleshooting-domain-join-error-messages.aspx