Logging LDAP modify operations

  • 244 Views
  • Last Post 19 December 2013
slavickp posted this 16 December 2013

G'day -
We all know and love LDAP searches logging enabled through Field Engineering registry entries (http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/41/Default.aspx) and additional functionality enabled with hotfix 280945.
I was wondering if there is similar way to log LDAP Modify (and perhaps LDAP Delete) operations? Windows data collectors provide some information but don't go as far as providing parameters of modification. Audit logging isn't as convenient IMO.
And is there detailed description of all those Field Engineering settings?
Cheers
Slav

Order By: Standard | Newest | Votes
jeremyts posted this 17 December 2013

Hey Slav, "15 Field Engineering" Logging Levels:0 (None): Only critical events and error events are logged at this level. This is the default setting for all entries, and it should be modified only if a problem occurs that you want to investigate.1 (Minimal): Very high-level events are recorded in the event log at this setting. Events may include one message for each major task that is performed by the service. Use this setting to start an investigation when you do not know the location of the problem. 2 (Basic)3 (Extensive): This level records more detailed information than the lower levels, such as steps that are performed to complete a task. Use this setting when you have narrowed the problem to a service or a group of categories.4 (Verbose)5 (Internal:): This level logs all events, including debug strings and configuration changes. A complete log of the service is recorded. Use this setting when you have traced the problem to a particular category of a small set of categories. Setting both the “Expensive Search Results Threshold” and “Inefficient Search Results Threshold” to 1 also requires setting "15 Field Engineering" value to 5 to get the desired logging in the Directory Services event log. You could also try “16 LDAP Interface Events”, with the same logging levels as above. But that really only gives you ldap bind events. Reference: http://support.microsoft.com/default.aspx?scid=kb;en-us;314980 I’ve not found a direct way to track LDAP Modify and Delete operations other than enabling auditing in AD for Writes and Deletes for specific LDAP service accounts. What is hotfix 280945 for? I can find this one. Cheers,Jeremy 

show

slavickp posted this 17 December 2013

Sorry, I mad a typo. The hotfix is http://support.microsoft.com/kb/2800945, it allows logging long running searches only.
Regards
Slav

show

darren posted this 17 December 2013

Depending upon what information you need to know about the change operation, one of the mechanisms described in this article could work for you:

 

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677625(v=vs.85).aspx

 

I’ve used the LDAP change notification control in the distant past and it was passable for small applications.

 

Darren

 

show

gkirkpatrick posted this 19 December 2013

Each of the mechanisms has different advantages and disadvantages. As you mentioned, you can set up auditing and consume the audit log. That mechanism pretty much sucks. It requires configuring the SACLs appropriately, including when new containers are added. And auditing on DCs is often a performance hassle… I’ve seen audit logs run tens of minutes behind.  You can use persistent LDAP searches (MSFT calls them change notifications). That works pretty well if you have a specific container you want to monitor for changes. If you’re looking to monitor all changes, it doesn’t help. You can use the DirSync control. In this case your application looks like a replication partner to AD, and you’ll have to set up agreements with all the naming contexts you’re concerned about. It works well, but the change notifications are subject to the usual replication delays, which can be hours or days in some environments. You can poll a DC for USN changes. This works ok, but it is a hassle to make work correctly when you lose communications or lose DCs. The article Darren mentioned has a good description of the implementation issues. AD provides a whole set of ETW events. The basic mechanism is described here: http://msdn.microsoft.com/en-us/magazine/cc163437.aspx. The set of events has been enhanced since its introduction, and I would guess you can get pretty complete coverage at this point. The APIs are a little finicky as I recall. There were some hotfixes for WS2008 to fix some reliability problems with ETW and multi-proc DCs. I think it was pretty reliable after that. ETW is also pretty efficient. You can also use DLL injection on the DC. This is pretty challenging development work, but ultimately worked out to be the best way for us to detect AD changes in realish time with minimal system overhead. Codeplex has an example using Detours, a MSFT Research package that we used: http://research.microsoft.com/en-us/projects/detours/  -gil 

show

darren posted this 19 December 2013

Gil-

I’ve always been curious about how Microsoft feels about DLL injection of LSASS, even using an approved method like Detours. I know several vendors do it, but

it seems to me that introducing 3rd party code into a process as security-sensitive as LSASS is problematic at best, not to mention the inevitable issues you run into when MS issues patches on those dependent components. Curious if anyone has ever

had any support issues using products that take that approach.

 

Darren

 

show

gkirkpatrick posted this 19 December 2013

Early on (at NetPro) the MS field were saying they wouldn’t support DCs with our injection code (ChangeAuditor) on it. We had some back-and-forth with MS about it, and we got the right kind of arrangements with their support organization in place, and it all worked out. Frankly, we had more problems with MS’s ETW code than we ever had with our injection code :-/. We also made sure that we got early versions of Windows Server to test with. Supporting MSIT was the worst because they rolled out pre-release versions into production long before we ever saw the bits. There were some customers who wouldn’t allow DLL injection on their production DCs, but not many. The value that ChangeAuditor provided was substantial enough that pretty much everyone decided it was worth the risk. Because it was a DC-by-DC sort of thing, they could phase it in gradually and get confidence with the software without risking a massive disruption. -gil 

show

Close