Quantcast
Channel: Johannes Weber – Weberblog.net
Viewing all articles
Browse latest Browse all 311

Joining an Active Directory: A Packet Capture

$
0
0

What happens on the network if you’re joining a Microsoft Active Directory domain? Which protocols are used? As I suspected, it’s a bit more complex than just seeing a single known protocol like HTTPS. ;)

Since a PCAP is worth a thousand words, I captured the process of a Windows PC joining an AD. Let’s have a look at it with Wireshark. And, as always, you’re welcome to download the packet capture to analyse it by yourself.

As usual, these packets are part of the Ultimate PCAP as well. If you haven’t had a look at it, try it out now! However, since it might be interesting to have a look at this Microsoft AD stuff solely, I decided to provide it here, too (zipped with 7z, 321 Kbyte):

The Lab

  • Windows Server 2022 Version 21H2 (OS Build 20348.2655), “vm39-ad2024.weberlab.de”, IP addresses 2a00:6020:ad0b:8380::10 and 172.16.80.10, being the domain controller for the AD domain “ad2024.weberlab.de”.
  • Windows 10 Enterprise Version 22H2 (Build 19045.2006), IP addresses 2a00:6020:ad0b:8381:2cc0:2f1a:cae2:aa7e (stable opaque), 2a00:6020:ad0b:8381:fd70:e2f9:f031:9dc4 (temporary during 1st uptime), 2a00:6020:ad0b:8381:c8c2:18f1:4b9d:7524 (temporary 2nd uptime), 2a00:6020:ad0b:8381:15f6:aeec:61d9:205f (temporary 3rd uptime), and 172.16.81.99.
  • TL;DR: server in VLAN 80, clients in VLAN 81, subnet-IDs following those VLAN IDs
  • The following steps are within the trace:
    • client joins the Active Directory domain “ad2024.weberlab.de” for the very first time with the credentials of “Administrator” (after I had used the wrong user for the join on my first attempt)
    • reboots
    • logs in with a local user
    • reboots again
    • logs in with an AD user (very little legacy IP traffic; almost everything via IPv6)
    • shutdown
  • As already noted, everything is dual-stack in my lab. And yes, with IPv6 it’s a little more complicated since after every reboot the client has a new temporary IPv6 address, while the stable opaque address is only used for very few messages, as well as for the dynamic DNS update.
  • The capturing process took place on the intermediate Palo Alto Networks firewall PA-440 with PAN-OS 11.2.3. (Yes, the VLAN IDs in the PCAP are mixed. Sorry for that. But never mind, Wireshark still does its job.)

Wiresharking

A look at Wireshark’s protocol hierarchy gives an overview of the different protocols that are used:

It all starts with a ton of DNS queries that I left in the trace (while I omitted all those outgoing HTTP/HTTPS sessions to MS servers) and some “Connectionless LDAP” queries/responses:

However, the joining process seems to start with some SMB/SMB2 packets as well as a Kerberos authentication:

before LDAP kicks in:

A little later, diverse remote procedure calls via DCE/RPC, EPM, DRSUAPI, etc. sessions take precedence. Don’t ask me for any details. ;) One thing I noted, though: While some sessions are based on the well-known port 135, some others are based on dynamic/high ports > 49152:

Also, note the dynamic DNS update from the client. It starts by asking for the SOA record of its own hostname (1) and tries an unsecured dynamic update which gets refused by the DNS server (2) since only secure updates are allowed by default. It then does the GSS-TSIG key exchange by using the TKEY RR (3 & 4) and finally starts a “secure” DNS update by using the additional TSIG signature (5 & 6). The updated IPv6 address (AAAA-record) holds the stable opaque address:

By the way, these are the applications as seen from a Palo Alto Networks Strata firewall between the client’s and the server’s zone:

Is there anyone among you who has a deeper understanding of the exact process? Perhaps she would like to go through the PCAP in more detail and make a screencast about it?

And because it fits the topic, I’ve captured an RDP session as well. This time between a management station (2a00:6020:ad0b:8321:34fb:d0ff:9ee8:abf2) and the AD server (2a00:6020:ad0b:8380::10). At least once I mistyped the password. :) In the end, it was a TCP port 3389 session that initiated a TLS handshake, while the data was transmitted via UDP port 3389. Note that Wireshark’s display filter of “rdp” only shows some negotiate packets from the TCP session while “rdpudp” filters the whole UDP stuff. However, you’re getting everything (incl. the TCP overhead) with a display filter of: “tcp.port eq 3389 or udp.port eq 3389”. These packets can be found in the Ultimate PCAP.

Soli Deo Gloria!

Photo by Toa Heftiba on Unsplash.


Viewing all articles
Browse latest Browse all 311

Trending Articles