Author: Jacob Chang | Post Date: 5/27/2009
More Articles by Author | E-Mail Author
What are Directory Service logs? Directory Service logs are logs specific to Domain Controllers for Active Directory objects that have the Event ID: 566. If you are familiar with Account Management logs on Windows (logs that say a user was created and/or assigned group memberships), think of them as a more extensive and advance logging for Active Directory.
On top of users and groups, in Active Directory there are unlimited amount of object types that can exist, the most common ones being users, computers, groups, GPOs, OUs and Contacts. Almost everything you wish you can log in Active Directory is actually being logged. There is a treasure of log information in Directory Service logs. Even changes to the fields of user objects can be collected. For example, if you edit the phone number or email address of a user in Active Directory, Microsoft can log this information.
Now this might sound like a great thing to have, but unfortunately, the benefits of Directory Service logs stop here. First thing you'll notice if you try to offload the logs from Event Viewer is that the logs are stored with Active Directory GUIDs, and not the sAMAccountname, cn, name, displayName, or distinguishedName which would be a lot more useful than the GUID. Microsoft thuoght that the advantage to doing so would be that GUIDs are static, and everything else mentioned can change at any time, and might point to the wrong user/object or a non existant user/object if it were to change. Although there is some truth in that, only collecting the GUID is just as problematic. First thing about GUIDs is that there is no easy way to translate the GUIDs. Second, if something changes, the old values are not logged and the GUIDs can only reference the new values of the logs. In other words, it can tell you if something has changed, but it won't tell you what it has changed from. Only gathering GUIDs is the achilles heel of Directory Service logs.
Another problem with Directory Service logs is that the logs are very low level. And by low level, I mean the logs are not meant to be user friendly. Its like someone turned on debugging on Active Directory, and only someone intimately familiar with the behavior of the logs will know what the logs actually mean rather than trying to interpret what the logs are saying at face value. For example, say a user object in Active Directory was moved from one OU to another. A user might think to look for a log that says a user was moved, or a user's location has changed. But what happens in the background is that a log gets generated that says the user was deleted in a location that no longer exists, then a user with the same GUID is created in the new location. This might make sense to some seasoned professionals, but without knowing that this is how it is logged, the logs may just as well not exist to someone wishing to find the log of what exactly happened.
And the last problem with Directory Service logs is the volume of the logs. Majority of the Directory Service logs are meaningless garbage. Unfortunately, they look identical to the ones that hold valuable information. If they look identical, how can a filter be set for any solution? The answer is, filters do not work for Directory Service logs.
So what is the solution? LogClarity does all the work for you. Imagine if you have someone doing this complicated task manually 24 hours a day, and all he did was pick out the important Directory Service logs, then recognize the patterns, then translates the GUID. It can translate and correlate the logs in a way so they mean what they say at face value. And just incase you are curious, LogClarity does this without affecting the original logs at all. This is why LogClarity is better than any solution where all you get is the ability to set rudimentary filters.
This is just one very small example of everything that LogClarity does for you while its collecting the logs. It analyzes during collection, so that it makes sense to the user as they would expect to work with the log.
Labels: EventID 566, Event Logs, Event Viewer, GUID, Active Directory