Using Wireshark to sniff Active Directory (LDAP) traffic

Wireshark is a very power network sniffing tool. It used to be known as Ethereal (long story). It supports a ton of protocols, including LDAP. Active Directory is the Microsoft implementation of LDAP. You can download Wireshark here for most any platform. WinPcap is included in the install now, which is nice and saves some effort during installation. Once you have it installed, open it up and do the following to sniff your ldap traffic.

1. This step is optional, but I recommend it if you are interested in the actual dns names of the devices instead of just the ip addresses. Go to Edit menu | Preferences… | Name Resolution  and then make sure the Enable network name resolution is checked. This will slow the output, but it provides much easier to read data.
2. Go to Capture menu | Interfaces… Click the Start button on the network interface(s) you want to sniff.
3. Immediately you should start see traffic in the window. This is all traffic.
4. Filter the output to ldap only by typing in the Filter textbox (in the toolbar), and then hitting enter or clicking the Apply button. Unless you have some ldap traffic, you will see the window go blank. Do something that you know will perform a ldap query, then you should see the traffic in the window.
   
   NOTE: The ldap filter is just that a filter, all network traffic is still logged, you just don’t see it. You can use the Clear button to remove the filter.
5. Go to the Capture menu | Stop to stop capturing traffic.

Example

This example uses the Active Directory Users and Computers application as a source for generating ldap traffic. We will use the tool to query for a user and then find the query and results in the traffic.

1. Follow the above instructions to get Wireshark sniffing ldap traffic.
2. Go to Start menu | Administrative Tool | Active Directory Users and Computers
3. Select your domain in the left panel.
4. Choose Action menu | Find…
5. Type in something that has more than one result, but not too many. We are looking for something that has a small bit of sample data to look at. Maybe 3 or so results. You can type in particular names or usernames.
6. Go back to Wireshark and stop the traffic.
7. Now we can do some analysis of the data. Go to Edit menu | Find Packet…
8. Click the String radio button.
9. Click the Packet bytes radio button (you can also try the others, they typically work well also).
10. Type in the same text you typed into the Active Directory Users and Computers application.
11. Click the Find button. If you don’t find any results it may be because you have some bad reassembled packet or bad checksum. If that happens it is beyond me. Also, sometimes, the Find does work for me. I can’t explain it either. Sorry, I am programmer, not a network guy, so I am not of much help explaining what might be wrong, etc.
    
    However, I have had pretty good luck just looking at the traffic and figuring out what is going on. See the section below.

Understanding LDAP traffic

When you look at the Info column, you will see several different types data.

bindRequest()

This to be authentication request from us to the ldap server

bindResponse()

This is the response from the ldap server (domain controller) in response to our bindRequest().

SASL GSS-API Integrity: searchRequest()

This is a request to the ldap server. If you look in the middle pane of Wireshark, you will see a collapsed section called Lightweight-Directory-Access-Protocol | SASL Buffer | GSS-API payload | LDAPMessage searchRequest(). Here you will see specifics of what you are requesting from the ldap server. In particular, you can drill down to protocolOp: searchRequest(). Here you can see the Filter (this is the actual ldap query sent) that was used. You can also see the attributes that were requested. You can also see the baseObject here.

In terms of SQL, this is basically like the select statement.
Filter = SQL where clause
attributes = SQL list of columns to select
baseObject = roughly translates to a SQL table, but more just specifying at what level in the ldap tree the search should take place.

SASL GSS-API Integrity: searchResEntry()

This is the response to the searchRequest() request from the ldap server. If you look in the middle pane of Wireshark, you will see a collapsed section (unless you already opened it :) called Lightweight-Directory-Access-Protocol | SASL Buffer | GSS-API payload | LDAPMessage searchResEntry(). Each LDAPMessage searchResEntry() is a result from the ldap server. This is essentially a row or record. So, if the query found 7 matches, then you should have 7 LDAPMessage searchResEntry() here. You can expand each LDAPMessage searchResEntry() to see the exact objectName, and the values.

Here you will see specifics of what the response from the ldap server. In particular, you can drill down to protocolOp: searchRequest(). Here you can see the Filter (this is the actual ldap query sent) that was used. You can also see the attributes that were requested. You can also see the baseObject here.

SASL GSS-API Integrity: unbindRequest()

This is the disconnect from the ldap server. The clean up. The thing that tells the ldap server that we are done with it.