An interesting article on SearchWindowsSecurity.com discusses when it’s useful to add new domains to your Active Directory network environment.

Here’s a link to our Active Directory UserAccountControl Quick Reference Guide.  It’s not intended to be a complete reference on the UserAccountControl attribute, but rather a quick reference for common values related to Access Rights.

It includes things like checking for password not required, password set to not expire, disabled accounts, and smart card required.

One method of monitoring possible inappropriate access attempts to Active Directory is to watch for Failed Logon attempts.  One way to do that is to monitor specific events in the Security Event Log on ALL servers within an environment.  The challenge with this has always been trying to monitor and gather all the appropriate information across all systems within an environment.

NetVision has greatly simplified this by centralizing the effort and applying filters at the event source that allow the system to gather only appropriate data and act upon the event information according to pre-defined rules (record it, write to file, send an alert, etc.)

NetVision reports on the following types of Failed Logons:

1. Failed Logon attempts to the Local System
2. Failed Logon because an account is Disabled
3. Failed Logon because an account is Expired
4. Failed Logon because an account is Locked
5. Failed Logon because of Machine Restrictions
6. Failed Logon because of an accounts Password is Expired
7. Failed Logon because of a Time Restriction
8. Failed Logon because of an account Type Restriction
9. Failed Logon because an account is Unknown

NetVision allows you to gather and process ALL Failed Logons centrally so you can evaluate the events, build appropriate reports, and take action on possibly inappropriate behaviors within your environment.

UPDATED: We can also track and report on failed logon attempts without relying on the security event log, making it easy to capture and report on a subset of users (such as system administrators) without having to store ALL failed logon attempts across the enterprise.  …forgot to mention that in the original post.

We put together this quick-and-dirty 3-minute introduction into one of NetVision’s core product offerings – directory monitoring.  In this example, we make a few common changes in Active Directory and show how the changes show up in our reports.

If you’re trying to audit the Last Logoff time of users in Active Directory or to programmaticly confirm whether someone is still logged on, your intuition might tell you to monitor the lastLogoff attribute. Unfortunately, you’d be wrong.

Active Directory does provide a User object attribute named lastLogoff where logoff Information should theoretically be stored. However, Microsoft currently does NOT utilize this attribute to store logoff information.  [more info on that]

In order to monitor User logoff activity on your own, you would need to watch the Security Event Log at every DC.  And you’d need to configure the Security Event Log policy on each relevant server to monitor logoff events. You would also also need to ensure that the event logs aren’t being overwritten before you capture the information (which can be tricky in large environments if you’re capturing all logon and logoff activity).  And you would have no ability to filter the events so that you’re getting only relevant information.

Because Microsoft doesn’t update Active Directory information during a logoff event, NetVision also monitors the event logs to capture logoff events.  But, because we’re already installed, there’s nothing else you need to do.  And we give you the ability to filter events based on what’s important to you (such as limiting Logoff events to a particular subset of Users).  The resulting reports are easy to read, exportable, and stored independent of logs so they’ll never get overwritten.

Note: Monitoring Logoff events is never 100% reliable. This blog entry from the Windows auditing team explains why.

Are you focused on Active Directory? And being asked to provide your end of a PCI audit? Figuring out how AD relates to PCI-DSS (Payment Card Industry Data Security Standards) can be quite complicated. If you’re interested in getting help or learning more, go to:

PCI Compliance for Active Directory Administrators