locked
Directory Service Access Auditing Events RRS feed

  • Question

  • Hi,

    We have successful auditing of directory services access enabled as per our auditing requirements on our 2003 DC's. The problem I have is the security logs on the DC's fill up rapidly because they are being smashed with the below events repeatedly. The events are being generated for lots of computer accounts and for each computer account there are a stack of events every second. I've had to turn logging off in the interum. Can someone please tell me what these computer accounts are trying to do and how to prevent the logging of these specific events?

    Thanks

    (sorry about the poor event log formatting)

    Source: Security | Category: Directory Service Access | Event ID: 565 | Type: Success A | User: domain\computername$ | Computer: DC_name

    Object Open:

        Object Server: Security Account Manager

        Object Type: SAM_USER

        Object Name: S-1-5-21-1957994488-1326574676-725345543-35413

    Handle ID: 543579264

        Operation ID: {4,1360320332}

        Process ID: 488

        Process Name: C:\WINDOWS\system32\lsass.exe

        Primary User Name: DC_name

        Primary Domain: domainname

        Primary Logon ID: (0x0,0x3E7)

        Client User Name: computername$

        Client Domain: domainname

        Client Logon ID: (0x4,0x51132DE0)

        Accesses: READ_CONTROL

        WritePreferences

        ReadAccount

        SetPassword (without knowledge of old password)

     

        Privileges: -

        Properties:

    ---

        user

    READ_CONTROL

    WritePreferences

    ReadAccount

    SetPassword (without knowledge of old password)

    General Information

    codePage

    countryCode

    objectSid

    primaryGroupID

    sAMAccountName

    comment

    displayName

    Account Restrictions

    accountExpires

    pwdLastSet

    userAccountControl

    userParameters

    Logon Information

    badPwdCount

    homeDirectory

    homeDrive

    lastLogoff

    lastLogon

    logonCount

    logonHours

    logonWorkstation

    profilePath

    scriptPath

    Public Information

    description

    Group Membership

    memberOf

    Reset Password

    %{7ed84960-ad10-11d0-8a92-00aa006e0529}

    READ_CONTROL

    WritePreferences

    ReadAccount

    SetPassword (without knowledge of old password)

    ListGroups

    Change Password

    Access Mask: 0

     

    For more information, see Help and Support Center at

     

     

    Monday, October 24, 2011 1:06 AM

Answers

  • Well after an extensive process I think we've finally got it. Ended up using TTTracer and tracked it down to being some software called "Browser Configuration Utility" by DeviceVM. There is a service called 'Browser Configuration Utility Service' which run the process bcuserivce.exe that keeps querying the class Win32_Account with the WQL "Select * from Win32_Account" which is trying to get account info from the domain.

    Once the 'Browser Configuration Utility Service' service was stopped, the successful audit event 565 stopped being generated on the domain controller.

    Now I just need to track down and remove the offending software from all effected machines.

    I hope this helps out someone else in the future.

    • Marked as answer by Zaphod6969 Thursday, November 10, 2011 3:34 AM
    Thursday, November 10, 2011 3:34 AM

All replies

  • According to Microsoft:
    Cause :
    An attempt was made to access a directory service object. Success or failure is indicated in the message. If access was successful, the listed accesses were requested and granted. If access failed, the listed accesses were requested but not granted.

    1)The Process ID and Process Name fields specify the process that was used to make the request.
    2)The Primary User fields specify the context (primary token) that the user used to access the process.
    3)The Client User fields, if present, specify the user on whose behalf the request was made (the impersonated user).
    Resolution :
    No user action is required. "Resolution According To Microsoft:"
    To prevent inadvertent denial of the SeSecurityPrivilege right to Exchange 2000 Enterprise servers, you can create a custom policy for domain controllers to implement the SeSecurityPrivilege right:

    1. Start the Active Directory Users and Computers Microsoft Management Console (MMC).
    2. Open the properties of the Domain Controllers container.
    3. Click the Group Policy tab, and then click New. Name the new policy (for example, "DOMAIN_NAME Auditing Rights").
    . This step is optional. This step makes the policy load faster. Right-click the new policy, click Properties, and then disable the User Configuration.
    5. Click the new policy, and then click Edit. Expand Computer Configuration, expand Windows Settings, and then expand Security Settings. Expand Local Policies, expand User Rights Assignment, and then configure all of the accounts that require the SeSecurityPrivilege right.
    IMPORTANT: All of the settings that you configure in this policy replace the same settings in other policies, instead of merging with them. Unconfigured options are still applied from other policies.
    6. Set the new policy to a higher priority than the default domain controllers policy. If you do not do so, the policy has no effect because the default policy configures the same setting.

    Regards,
    Sandesh Dubey.
    -------------------------------
    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator
    My Blog: http://sandeshdubey.wordpress.com
    This posting is provided AS IS with no warranties, and confers no rights.

    Monday, October 24, 2011 1:34 AM
  • Thanks for your input Sandesh but I'm not sure how your suggestion is going to stop the successful audit events being logged.


    FYI as an example, in a 2 hour random window over the weekend one computer account alone generated 99217 events, another 73288, and so on. There were at least 6 computer accounts in this time frame with high numbers like this.
    • Edited by Zaphod6969 Monday, October 24, 2011 4:04 AM
    Monday, October 24, 2011 3:57 AM
  • This issue may occur if one of the following conditions is true:
    •You enable the Audit the access of global system objects Local Security Policy setting. If you enable this setting, many audit events will be generated. These events will typically be source security events with Event ID 560, where the object type is event, mutant, process, section, semaphore, thread, or token. These events are of interest only to a system developer. Typically, the Audit the access of global system objects Local Security Policy setting is not enabled.
    •You enable auditing on a domain controller. When you enable auditing on a domain controller, audit events will be generated that typically contain references to the following object types:
    ◦SAM_ALIAS
    ◦SAM_GROUP
    ◦SAM_USER
    ◦SAM_DOMAIN
    ◦SAM_SERVER
    These events indicate that the Security Accounts Manager (SAM) objects have security access control lists (SACL) and that there is much SAM activity occurring. Typically, these events occur only on a domain controller.
    •You use an application that opens audited objects too frequently or that opens audited objects with greater access than the application requires. For example, the application may request full control access when the application requires only read access. When this behavior occurs, events may be generated where the referenced process is always the same application.

    To resolve this issue, use one of the following methods:
     
    Method 1
    Disable the Audit the access of global system objects Local Security Policy setting if you have previously enabled this setting. To do this, follow these steps:
    1.Click Start, click Run, type gpedit.msc, and then click OK.
    2.Locate the following entry:
    Console Root\Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
    3.Double-click the Audit the access of global system objects policy, click Disabled under Local Policy, and then click OK.
    4.On the Console menu, click Exit, and then restart the computer.

    Method 2
    Configure the custom application to open audited objects only as required. For example, configure the custom application to request only the minimum access that is required. If the custom application requires only read access for a specific object, assign only read access. In this case, full control access is not required.

    Refer this link for more details:http://blogs.msdn.com/b/ericfitz/archive/2005/01/11/350848.aspx


    Regards,
    Sandesh Dubey.
    -------------------------------
    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator
    My Blog: http://sandeshdubey.wordpress.com
    This posting is provided AS IS with no warranties, and confers no rights.

     

    Monday, October 24, 2011 7:35 AM
  • Can you disconnect the problem machine listed in the log and see if the event id 565 logs still.

    Did you get a chance to see below article.

    http://support.microsoft.com/kb/836419

    http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=565

     

    Regards


    Awinish Vishwakarma

    MY BLOG:  http://awinish.wordpress.com/


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.
    Monday, October 24, 2011 9:49 AM
  • Hi,

    PLease provided us more info about AD structure, Do you have any exchange server also as awinish suggested, disconnect the problem machine and observe the eventlog.

    please refer the below article, its already suugested by awinish...:-)

    http://support.microsoft.com/kb/836419
    microsoft says this is the issue .. however has not posted resolutions to this

    These are the success audits and I guess you can ignore this error otherwise disabling the audit is the opption for you..

    Regards,
    Abhijit Waikar.
     -------------------------------
    MCSA|MCSA:Messaging|MCTS|MCITP:SA
    My Blog: http://abhijitw.wordpress.com
    This posting is provided AS IS with no warranties, and confers no rights.

    Monday, October 24, 2011 11:35 AM
  • Sandesh, I've checked and Audit the access of global system objects is currently disabled on the Domain Controllers. I don't believe there will be any custom application either as the computers generating the logs are from different areas of the business that would not share the same apps.

    Awinish, thanks for adding your thoughts. There are many computers logging these events, I'd like to avoid running adhoc tests such as shutting down computers unless there's a real fix in site. This is because I will need to re-enable successful directory service access auditing which will fill up the logs which in turn will have an adverse effect on other things that rely on our security logs being complete.

    I don't believe KB836419 is effecting us as the logs don't show Undefined Access (no effect) Bit 7 nor are there event 560's indicating that handles are closed.

    Abhijit, thanks also for contributing. We have a single native forest, single domain, multi site AD built on all Windows 2003 R2 servers. We have over 10,000 computer objects, the vast majority of which run Windows XP. We do run Exchange 2003 Enterprise across all sites. Please let me know if there is anything else you would like to know. Unfortunately I can't simply ignore the successful audit reports because the event logs fill up to quick which renders other auditing reports useless and while I have temporarily disabled successful auditing I really need it turned on to capture things like OU and GPO changes. I really need to stop these specific successul audits being logged or at minimum to understand why they are being generated.

    Any other suggestions? I might like a call with premier support to get an answer I think

    Tuesday, October 25, 2011 12:27 AM
  • Please see below KB and take appropriate action.

    Event IDs 560 and 562 appear many times in the security event log http://support.microsoft.com/?id=841001

     

    http://technet.microsoft.com/en-us/library/cc773388(WS.10).aspx#BKMK_ReviewDomainPolicy

     

    Table 16 Default and Recommended Domain Controller Audit Policy Settings

    Policy Default Setting Recommended Setting Comments

    Audit account logon events

    Success

    (No change)

    Account logon events are generated when a domain user account is authenticated on a domain controller.

    Audit account management

    Success

    (No change)

    Account management events are generated when security principal accounts are created, modified, or deleted.

    Audit directory service access

    Success

    (No change)

    Directory services access events are generated when an Active Directory object with a system access control list (SACL) is accessed.

    Audit logon events

    Success

    (No change)

    Logon events are generated when a domain user interactively logs on to a domain controller or a network logon to a domain controller is performed to retrieve logon scripts and policies.

    Audit object access

    No auditing

    (No change)

    N/A

    Audit policy change

    Success

    (No change)

    Policy change events are generated for changes to user rights assignment policies, audit policies, or trust policies.

    Audit privilege use

    No auditing

    (No change)

    N/A

    Audit process tracking

    No auditing

    (No change)

    N/A

    Audit system events

    Success

    (No change)

    System events are generated when a user restarts or shuts down the domain controller or when an event occurs that affects either the system security or the security log.

     

     

     


    Sumesh P - Microsoft Online Community Support
    Friday, October 28, 2011 9:45 AM
  • See this

    http://blogs.dirteam.com/blogs/jorge/archive/2008/04/29/auditing-in-windows-server-2008.aspx


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
    Friday, October 28, 2011 12:39 PM
  • FYI I've logged a support case with Microsoft. We are currenly running some network captures on the clients to work out which client processes are making the thousands of requests to the domain controllers. I'll update again when we have some answers

    Sunday, October 30, 2011 10:13 PM
  • Thanks for the update. Do post back the outcome.

     


    Sumesh P - Microsoft Online Community Support
    Monday, October 31, 2011 5:02 AM
  • For anyone who maybe following this post here's an update so far.

    shutting down one of the offending computers stopped the event being logged. The event started logging again immidiately after the computer was booted into Safe mode with network support.

    Using TCPView, Network Monitor and the domain controller security log we found SamrOpenUser requests and responses that matched the event times. So we used tasklist /m samlib.dll to generate a list of processes to work with, then used process explorer to open each process to find which thread had samlib. We found it in wmiprvse.exe.

    Stay tuned, we're getting closer to an answer

    Thursday, November 3, 2011 4:50 AM
  • Well after an extensive process I think we've finally got it. Ended up using TTTracer and tracked it down to being some software called "Browser Configuration Utility" by DeviceVM. There is a service called 'Browser Configuration Utility Service' which run the process bcuserivce.exe that keeps querying the class Win32_Account with the WQL "Select * from Win32_Account" which is trying to get account info from the domain.

    Once the 'Browser Configuration Utility Service' service was stopped, the successful audit event 565 stopped being generated on the domain controller.

    Now I just need to track down and remove the offending software from all effected machines.

    I hope this helps out someone else in the future.

    • Marked as answer by Zaphod6969 Thursday, November 10, 2011 3:34 AM
    Thursday, November 10, 2011 3:34 AM