Logging the source IP of simple LDAP binds

Simple bind events don’t record the calling Computer as the source, but record the ADDS-DC or the ADLDS instance name, so you cannot determine where the simple bind request came from. So if you are trying to track down where the calling machine is that is locking out a user, you cannot determine this from the event log. However, you can tell what instance the event is taking place on if you are trying to determine which AD server is being used. Here are some ideas that might help you track down what machine the simple bind is coming from, even if you cannot log it normally.

Finding caller IP over LDAP/clear text

If it’s not using SSL/LDAPS on your server and applications, then you can start a network capture which is watching for that specific username in a bind request that is being locked out. Since you have the server instance name from the lockout event you can hopefully target the AD servers that were being used for the simple bind attempts.

If you are using Network Monitor 3.1 or nmcap you can use this as the capture filter:

protocol.LDAP.LDAPParsers.Parser.BindRequest.Name.OctetStream == “<username attempting bind>”

This will give you the IP address that made the bind request using that username when the username is used to attempt a simple bind. You can then track down to what application or process maybe issuing the simple bind request.

Finding caller IP over SSL/LDAPS

If you are using LDAPS, however you will only see traffic come across over SSL, and the LDAP parser cannot be used to grab the details since it is encrypted. I was recently testing with SSL simple binds with ADLDS, and was curious why something was not working. The issue at hand is that I was not able to network capture the connection, because it was over SSL, and I wanted to see why the bind attempt was failing. The application was not very descriptive in it’s error messages, and unfortunately the logging for SSL connections is minimal in Windows, even with debugging options enabled for sChannel. A recent discussion on the ActiveDir.org mailing list made me remember this event, and thought it might be applicable for helping to determine where a simple bind request came from, when on SSL.

Since I couldn’t capture the connection to see what values were being passed in the bind action, I wondered what I could see from the directory logging side if I enabled some of the directory services debugging options.

I turned on Field Engineering mode via the registry, and attempted to set the Expensive Search Threshold to 0, and the Inefficient Search threshold to 0. I wondered if this would log events for all search requests, but it essentially stopped the logging of field engineering events. I set the two thresholds to 1, which means that the search request would satisfy the threshold if 1 result was touched or found. This logged events for every query which met this threshold, which should be any query that returned a result.

Now when I started to attempt the simple bind from the application, something peculiar appeared in the log. A search request from NT AUTHORITYANONYMOUS LOGON for with the filter of (userPrincipalName=<attempted user logon ID>) and with the Client IP there is the application server that issued the request. This was interesting, since I know I denied anonymous binds on my instance, but this must be an internal function that is a search request during a bind operation, and not upheld to the disallowing anonymous enumerations of the directory.

So could this be a way to determine where the request came from if you filtered the event log by searching for the expected username value? If the simple bind is attempted over SSL, you can’t use network traces to watch for LDAP bind request parameters which match the username, so you can capture the calling IP address.

In my case the the user attempted to logon to the client on their workstation, which passed the credentials to the application server. The application server attempted the simple bind to the ADLDS instance, and the IP included in the event is from the application server.

Here is an example event logged:

Event Type: Information
Event Source: ADAM [MYDIR INSTANCE NAME] General
Event Category: Field Engineering
Event ID: 1644
Date: 5/19/2008
Time: 5:32:29 PM
User: NT AUTHORITYANONYMOUS LOGON
Computer: <My ADLDS Server>
Description:
Internal event: A client issued a search operation with the following options.
Client:
10.234.31.208
Starting node:
RootDSE
Filter:
(userPrincipalName=SVC-APPUSER)
Search scope:
subtree
Attribute selection:
distinguishedName
Server controls:
Visited entries:
1
Returned entries:
1
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Now, I was able to set these values on an isolated LDS instance I use for testing with minimal traffic. In a full production environment, the amount of activity to the server would quickly roll your event logs over, so I don’t think this is all that viable if you are trying to track down the source of the simple bind request. I thought I would mention it though, because I didn’t realize this happened, and it might be of interest to others. It might help in conditions where you have minimal traffic, or in your own testing.

For a long time, I keep hearing requests to add better logging of LDAP operations in Active Directory, because it shouldn’t be this hard to determine these kinds of operations. Hopefully we will see more user friendly diagnostics which can be used in large environments in future releases of Active Directory.

Update: You can find some more information on specific Account Lockouts here.