DS Access Logging - Event 4662


  • I work in a large hospital environment, and I'm fine tuning the logging to put into splunk - and everything is working quite well EXCEPT DS access logging.  Before I enabled it - I removed all entries from the domain object's audit ACL tab (because I didn't want to flood the sec logs).  I ensured that the change was pushed down to each child/subtree object, as well, so that no domain object has anything defined in its audit tab.

    Upon enabling DS access auditing, my four exchange servers are spamming the sec log on the DCs with READ_CONTROL accesses to all user objects tied to mailboxes.

    Problem:  The security logs for my three DCs goes up to 11GB a night, and gave me a permanent overage mark on my splunk account, and even with NOBODY defined in the auditing tabs on a single AD Object, I'm still getting these messages.


    I do have "Audit Directory Service objects" applied to the whole domain... maybe I should just restrict this back to DCs?  I really only want to audit AD object changes, not READS.

    Monday, September 09, 2013 2:03 PM


All replies

  • If you restrict the auditing to specific DCs, you would not be able to enable all the changes as any RWDC can be used for making changes.

    You can specify a maximum log size so that you can avoid the DCs disks from becoming full: The problem here is that old events will be overwritten

    As for the auditing, I would recommend using a third party tool like AD Audit Plus. Such tools will collect the events and store them in a local database. Like that, even if they were overwritten on DCs, they are keeping a copy.

    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Get Active Directory User Last Logon

    Create an Active Directory test domain similar to the production one

    Management of test accounts in an Active Directory production domain - Part I

    Management of test accounts in an Active Directory production domain - Part II

    Management of test accounts in an Active Directory production domain - Part III

    Reset Active Directory user password

    Monday, September 09, 2013 2:37 PM
  • Apparently you need to fine tune your auditing in order to target events that are relevant to you.

    In order to determine the effective settings on your DCs, run the following:

    auditpol.exe /get /category:*

    Apply the settings via a GPO linked to the Domain Controllers OU - and start with the most basic ones (use Advanced Audit Policy Configuration settings). You may find helpful


    Monday, September 09, 2013 2:59 PM
  • I need to keep the events in the event viewer so my forwarder can spit them at my central log indexer, so that isn't an option for me. :(  Also, I used that walkthrough to configure everything initially.. just doesn't seem to behave like it should.

    I feel like this is completely doable via GPO, and here's really just where I am baffled.


    1. Enable Audit Directory Service Access via GPO to TESTDOMAIN

     [quote]- Directory Service Access

    This policy setting allows you to audit events generated when an Active Directory Domain Services (AD DS) object is accessed.

    [b]Only AD DS objects with a matching system access control list (SACL) are logged.[/b]

    Events in this subcategory are similar to the Directory Service Access events available in previous versions of Windows.

    Volume: High on domain controllers. None on client computers.

    Default on Client editions: No Auditing.

    Default on Server editions: Success.[/quote]

    2. Right click TESTDOMAIN, go to properties, security tab, advanced, audit tab.

    3. Configure logging ONLY so it logs SUCCESSFUL WRITES/DELETES/CREATIONS made by domain admins on TESTDOMAIN and subtree.

    4. Check logs - "Directory Service Access" EventID 4662 FLOODING the sec log with "READ_CONTROL" on AD User objects by my exchange servers (there are probably other access logs but exchange is very chatty so that's all I see)


    Even with a CLEARED auditing configuration on every single domain object, I still get flooded with 4662s.  According to the description of the item in GPO, it's only supposed to log what I have specified on the auditing tab.

    Am I missing something?

    Monday, September 09, 2013 4:07 PM
  • Post the output of the following (run on the DC where the events are recorded)

    auditpol.exe /get /category:*

    dsacsls  against a user object (for which you are seeing 4662) with /A switch


    Monday, September 09, 2013 4:17 PM
  • X:\>auditpol.exe /get /category:*
    System audit policy
    Category/Subcategory                      Setting
      Security System Extension               No Auditing
      System Integrity                        No Auditing
      IPsec Driver                            No Auditing
      Other System Events                     No Auditing
      Security State Change                   Success and Failure
      Logon                                   Failure
      Logoff                                  No Auditing
      Account Lockout                         Success
      IPsec Main Mode                         No Auditing
      IPsec Quick Mode                        No Auditing
      IPsec Extended Mode                     No Auditing
      Special Logon                           Failure
      Other Logon/Logoff Events               No Auditing
      Network Policy Server                   No Auditing
    Object Access
      File System                             No Auditing
      Registry                                No Auditing
      Kernel Object                           No Auditing
      SAM                                     No Auditing
      Certification Services                  No Auditing
      Application Generated                   No Auditing
      Handle Manipulation                     No Auditing
      File Share                              No Auditing
      Filtering Platform Packet Drop          No Auditing
      Filtering Platform Connection           No Auditing
      Other Object Access Events              No Auditing
      Detailed File Share                     No Auditing
    Privilege Use
      Sensitive Privilege Use                 No Auditing
      Non Sensitive Privilege Use             No Auditing
      Other Privilege Use Events              No Auditing
    Detailed Tracking
      Process Termination                     No Auditing
      DPAPI Activity                          No Auditing
      RPC Events                              No Auditing
      Process Creation                        No Auditing
    Policy Change
      Audit Policy Change                     No Auditing
      Authentication Policy Change            Success
      Authorization Policy Change             Success
      MPSSVC Rule-Level Policy Change         No Auditing
      Filtering Platform Policy Change        No Auditing
      Other Policy Change Events              No Auditing
    Account Management
      User Account Management                 Success
      Computer Account Management             Success
      Security Group Management               Success
      Distribution Group Management           Success
      Application Group Management            Success
      Other Account Management Events         Success
    DS Access
      Directory Service Changes               Success
      Directory Service Replication           No Auditing
      Detailed Directory Service Replication  No Auditing
      Directory Service Access                Success
    Account Logon
      Kerberos Service Ticket Operations      No Auditing
      Other Account Logon Events              No Auditing
      Kerberos Authentication Service         No Auditing
      Credential Validation                   No Auditing

    Monday, September 09, 2013 8:19 PM
  • my ACL is too long to post.. over 60,000 characters.

    Question - the output of the dsacls /A command... is that the control of what gets logged or not?  I was under the assumption it was the AUDITING tab.

    If so, does the ACL affect anything other than logging?  There are a ton of groups on that list and I'm afraid to change any of them.

    Monday, September 09, 2013 9:37 PM
  • You want to focus on the Audit list section (this typically would be a small portion of the entire output)


    Tuesday, September 10, 2013 12:25 AM
  • Permissions inherited to subobjects are:
    Inherited to all subobjects
                                      WRITE PERMISSIONS
                                      CHANGE OWNERSHIP
                                      CREATE CHILD
                                      DELETE CHILD
                                      WRITE PROPERTY
                                      DELETE TREE
                                      WRITE PERMISSIONS
                                      CHANGE OWNERSHIP
                                      CREATE CHILD
                                      DELETE CHILD
                                      WRITE PROPERTY
                                      DELETE TREE
    Tuesday, September 10, 2013 11:03 AM
  • This means that you currently have SACLS set - and the auditing enabled (for the categories listed above). You should see entries in the Security Log matching these conditions. Isn't this the case?


    Tuesday, September 10, 2013 11:33 AM
  • "Directory Service Access" EventID 4662 FLOODING the sec log with "READ_CONTROL" on AD User objects by my exchange servers (there are probably other access logs but exchange is very chatty so that's all I see)

    This is why I am wondering if I am missing something...

    Tuesday, September 10, 2013 12:32 PM
  • DS access subcategory is enabled (as per above).

    Are the 4662 events recorded in the security context matching either of the two groups included in the SACL?


    Tuesday, September 10, 2013 12:59 PM
  • Yes - also, this might help.. The "Directory Services Changes" auditing is working correctly off of the auditing SACL I created.  "Directory Services Access" is logging every AD object access - like it's completely wide open.

    That's why I'm wondering if "Directory Services Access" is based off of the security tab and NOT the auditing tab, because there is evidence that "Directory Service Changes" is working directly off of the auditing SACL.  Also, the directory service changes are listing as EventID 5141, and they are also working as intended.

    Tuesday, September 10, 2013 4:56 PM
  • I might be missing something here - but based on what you stated, you are seeing the behavior that is the result of your existing auditing settings


    Tuesday, September 10, 2013 5:08 PM
  • Yeah.  I'm still getting tons of 4662s when I enable "Directory Services Access" - It's simply not using my auditing SACL.  It APPEARS that it's using the actual security SACL to decide what to log, but one thing is for sure, it's not based on the auditing SACL.

    "Directory Services Changes" IS using my auditing SACL, and is working as intended.  These are 5141s and I'm getting what I expect.

    Is that by design?  If so, hypothetically, I could remove all security from all my AD objects without breaking anything except auditing levels.

    Is this correct?

    Wednesday, September 11, 2013 5:14 PM
  • I'm not clear on what you mean by "remove all security from all my AD objects". Are you referring specifically to SACLs? This would affect the ability to view 5141s

    What's the OS version of your domain controllers?


    Wednesday, September 11, 2013 5:19 PM
  • Right Click on AD Object, properties, security tab.  Those ACLs right there on the base security tab are the ones I'm questioning.

    If you go further and click advanced, then click the auditing tab, those ACLs there are directly affecting my 5141s, but have NOTHING to do with my 4662s.


    Wednesday, September 11, 2013 6:57 PM
  • "Removing" these would affect existing permissions - although you would also get rid of 4662s if that's your objective


    Wednesday, September 11, 2013 10:58 PM
  • Ok, that makes sense.
    Monday, September 16, 2013 6:31 PM