The chronicles of a Bostonian tech geek navigating through life, technology, and general geekiness.

Menu

Digging deep into the AD DS workstation logon process – Part 3

Today I will continue my series of posts on the AD DS workstation logon process. In part 1 I covered the DC locator process and in part 2 a breakdown of the SMB conversation. In today’s post we’ll focus on the NetLogon process.

Let’s first take a few minutes to talk about the NetLogon Remote Protocol (MS-NRPC). The protocol serve a number of purposes in an Active Directory environment. Those purposes vary upon whether it is a member or domain controller making a remote call, but can be summed up as follows:

Pass-through authentication – Deliver the logon request from the domain-joined machine to the domain controller for verification of the credentials and return of user authorization attributes (such as groups) back to the domain-joined machine.

Pass-through authentication and domain trusts – Establish a secure channel to pass a logon request from a domain controller in the trusting domain to a domain controller in the trusted domain.

Secure control maintenance – Allow the workstation to cycle its credential over a secure channel with the domain controller.

Account database replication – In Windows 2000 there existed the concept of a primary domain controller and backup domain controller. At that time NetLogon was used to replicate the account database between the BDC and PDC.

Since this series is focused on the workstation logon process, the sixth function for administrative services is functionality I’ll be breaking down in the remainder of the post. Here also is a link to the MS-NRPC specification which I used heavily to put together this post.

Shall we then?

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: 135
Protocol: RPC
Purpose: The domain-joined workstation initiates a request for a bind handle from the domain controller’s RCP EndPoint Mapper Service. The domain controller responds with a bind acknowledgement providing the information necessary for the workstation to now connect to the RCP Endpoint Mapper.
Link:

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: 135
Protocol: RPC
Purpose: The domain-joined workstation queries the endpoint mapper on the domain controller for the endpoint that it can connect to in order to call the NRPC application. The domain controller responds with the IP and port information.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: (Random port from DC’s dynamic port range)
Protocol: RPC
Purpose: The domain-joined workstation initiates a request for a bind handle for the NRPC application from the endpoint it received in the previous step. The domain controller responds with a bind acknowledgement providing the information necessary for the workstation to now connect to the NRPC application.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: (Random port from DC’s dynamic port range)
Protocol: RPC
Purpose: The domain-joined workstation calls the NetrServerReqChallenge method and and provides the necessary variables. Three of those key variables are:

PrimaryName – The name of the server receiving the call

ComputerName – The name of the client making the call

ClientChallenge – A 64-bit nonce generated by the client. I’ll explain how this is used later in the process.

The domain controller returns the ServerChallenge, which is a 64-bit nonce generated by the server.
Links:

AccountName – The name of the the account that contains the password of the computer account.

SecureChannelType – Describes the type of channel being requested. In this case we are requesting a WorkstationSecureChannel.

ComputerName – The name of the client making the call

ClientCredential – The client credential is the encrypted 64-bit client challenge exchanged with the server at the previous step. The challenge is encrypted using the workstation’s secret key (computer account’s Active Directory credential). The encryption used will depend on what the client supports. In this scenario, with the default configuration on a Windows Server 2016, it is AES128.

The domain controller validates the client credential by accessing the workstation’s secret key (computer account’s Active Directory credential) and inputing it into the agreed upon encryption algorithm along with the client challenge received earlier. After the workstation’s identity is validated, the domain controller returns the following information:

Server Credential – The encrypted 64-bit server challenge exchanged with the workstation earlier in the process. The challenge is encrypted using the workstation’s secret key (computer account’s Active Directory credential). The encryption used will depend on what the client supports. In this scenario, with the default configuration on a Windows Server 2016, it is AES128.

The workstation validates the server credential by accessing its secret key (computer account’s Active Directory credential) and inputing it into the agreed upon encryption algorithm along with the server challenge received earlier. Once the credential is verified, the computer value will be used as the session key going forward for communication between the two nodes.
Links:

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: (Random port from DC’s dynamic port range)
Protocol: RPC
Purpose: The domain-joined workstation requests that further calls to the NRPC application be authenticated and encrypted. The domain controller accepts the alteration in communication context.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: (Random port from DC’s dynamic port range)
Protocol: RPC
Purpose: *This conversation is encrypted* The domain-joined workstation calls the NetrLogonGetCapabilities method. The domain controller returns the same capabilities it returned when NetrServerAuthenticate3 was called. The client then examines these capabilities to verify they match what was originally received to setup the secure session. This is performed to mitigate man-in-the-middle attacks.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: 135
Protocol: RPC
Purpose: The domain-joined workstation queries the endpoint mapper on the domain controller for the endpoint that it can connect to in order to call the LSARpc application. The domain controller responds with the IP and port information.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: 389
Protocol: LDAP
Purpose: The domain-joined workstation establishes a connection to the LDAP service on the domain controller and queries the RootDSE with the following query:

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: (Random port from DC’s dynamic port range)
Protocol: RPC
Purpose: The domain-joined workstation initiates a request for a bind handle for the LSARpc application from the endpoint it received in the previous step. The domain controller responds with a bind acknowledgement providing the information necessary for the workstation to now connect to the NRPC application.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: 88
Protocol: Kerberos
Purpose: The domain-joined machine attempts to verify its identity with the domain controller by sending a KRB-AS-REQ without pre-authentication data. The domain controller checks the object that represents the principal to determine if the account has the “Do not require Kerberos preauthentication.” If the option is not checked, the domain controller returns KRB_ERROR (25) indicating preauthentication data is required.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: (Random port from DC’s dynamic port range)
Protocol: RPC
Purpose: *This conversation is encrypted* The domain-joined workstation calls the LsarLookupNames4 method. This method translates batches of security principals to their SID form. The domain controller responds by translates the principals to SIDs. The communication is encrypted with the session key established during the NetLogon process.

I can’t find any clear cut information on this, but my guess is the workstation is attempting to resolve its own SID and perhaps the SID of the domain controller for processing of access control lists.

Source: Domain-joined machine
Destination: Same Site or Closest Site Domain Controller
Connection: TCP
Port: 88
Protocol: Kerberos
Purpose: The domain-joined machine re-attempts to verify its identity with the domain controller by sending a KRB-AS-REQ with pre-authentication data. The domain controller validates the principal’s identity and responds with a KRB-AS-REP which includes a Kerberos TGT for the principal to use to obtain additional Kerberos service tickets.

We’ll break here for today. In the next entry we’ll start to hit some of the LDAP conversation that goes on between the workstation and the domain controller. Much of that conversation is encrypted, so I’ll be doing my best to correlate the LDAP queries that appear in the Directory Services log back to the packet captures.

About Me

Hi there! My name is Matt Felton and I am a long time geek with a passion for technology. I have over 10 years experience in the industry that spans the technology stack. Over the past few years I’ve had the opportunity to dig deeper into security and identity which I’ve been more than happy to do.

I started Journey Of The Geek over 6 six years ago when I saw an opportunity to provide in-depth technical deep dives to peel back the onion on technologies and products. I enjoy sharing what I’ve learned and giving back to the industry. Plus there is no better way to learn a topic than to teach it.

I hope you enjoy and if you have questions feel free to reach out via the comments, LinkedIn, or Twitter.

DISCLAIMER

All views expressed on this site are my own and do not represent the opinions of any entity whatsoever of which I have been, am now, or will be affiliated.