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:

1. 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.
2. 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.
3. Secure control maintenance – Allow the workstation to cycle its credential over a secure channel with the domain controller.
4. Domain trust services – Allows applications to obtain a listing of domain trusts
5. Message protection services – Used to authenticate the messages sent and received from a domain controller such as with the Windows Time service.
6. Administrative services – Used for the following operations
   • NetLogon on Domain Controllers
     • Receive logon request
     • Determine account domain
     • Determine trust link
     • Find DC in trusted domain and setup secure channel
     • Deliver logon request
     • Return user validation data
   • NetLogon on Domain Members
     • Find a DC in its domain and setup secure channel
     • Logon requests flow over that channel going forward, including machine account password changes
7. 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?

21. 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:
    • https://msdn.microsoft.com/en-us/library/windows/desktop/aa373819(v=vs.85).aspx
    • https://msdn.microsoft.com/en-us/library/windows/desktop/aa378995(v=vs.85).aspx
    • https://blogs.technet.microsoft.com/networking/2009/02/03/rpc-endpoint-mapper-in-a-network-trace/
22. 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.

23. 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.

24. 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:
    1. PrimaryName – The name of the server receiving the call
    2. ComputerName – The name of the client making the call
    3. 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:

    • https://msdn.microsoft.com/en-us/library/cc237239.aspx
25. 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 NetrServerAuthenticate3 method and and provides the necessary variables. The key variables here are:
    1. PrimaryName – The name of the server receiving the call
    2. AccountName – The name of the the account that contains the password of the computer account.
    3. SecureChannelType – Describes the type of channel being requested. In this case we are requesting a WorkstationSecureChannel.
    4. ComputerName – The name of the client making the call
    5. 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.
    6. NegotiateFlags – Provides information about the workstation’s capabilities including encryption methods the client supports.

    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.
    • NegotiateFlags – Provides information about the domain controller’s capabilities including encryption methods the client supports.
    • AccountRID – The workstation’s RID
    • ReturnValue – Success or Error

    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:

    • https://msdn.microsoft.com/en-us/library/cc237240.aspx
    • https://msdn.microsoft.com/en-us/library/cc237054.aspx
    • https://msdn.microsoft.com/en-us/library/ff359286.aspx
26. 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.

27. 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.

28. 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 NetrLogonGetDomainInfo method. The domain controller returns information about the domain the client belongs to. The information returned includes properties such as the DNS Domain Name, DNS Forest Name, and Domain SID.

29. 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.

30. 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:
    • Filter: (objectclass Present)
    • Attributes: Attributes: ( subschemaSubentry )( dsServiceName )( namingContexts )( defaultNamingContext )( schemaNamingContext )( configurationNamingContext )( rootDomainNamingContext )( supportedControl )( supportedLDAPVersion )( supportedLDAPPolicies )( supportedSASLMechanimsms ) ( dnsHostName ) ( ldapServiceName ) ( serverName ) ( supportedCapabilities)

    The domain controller returns the information to the workstation.

31. 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.

32. 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.

33. 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.

34. 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.

Thanks and see you then!