Options
Sign in to Download

Windows Server 2008-2012 Domain Controller Security

Configuring Windows Remote Management (WinRM)

Take the following steps to properly configure Windows Remote Management:

1.     If not already done so, install PowerShell 2.0 and WinRM on the APM and target servers. Powershell 2.0 can be found here: http://support.microsoft.com/kb/968930.

2.     On the Orion APM server, open a command prompt as an Administrator. To do this, perform the following step:

     ·         Go to the Start menu and right-click cmd.exe and then select Run as Administrator.

3.     Enter the following in the command prompt:

       winrm quickconfig

       winrm set winrm/config/client @{TrustedHosts="*"}

4.     On the target server, open a command prompt as an Administrator and enter the following:

       winrm quickconfig

       winrm set winrm/config/client @{TrustedHosts="IP_ADDRESS"}

where IP address is the IP address of your APM server.

This template allows you to check locked and/or disabled users and events from the Windows security log related with Windows 2008 Domain Controller security.

Prerequisites:

  • WinRM must be installed and properly configured on the target server;
  • WMI access to the target server;
  • Auditing on domain controller (success and failure) must be enabled for the following items: Account Management, Logon Events, Policy Changes and System Events. To learn how to enable auditing , refer to this article: http://technet.microsoft.com/enus/library/cc731607(WS.10).aspx.

Credentials: Administrator on target server.

Monitored Components

Note: All monitors, except Locked out users and Disabled users, should return zero values. Returned values other than zero may indicate an abnormality. If you believe an abnormality exists, you should examine the Windows security log for details.


Locked out users

This monitor returns the number of currently locked out users. Set the threshold value according to your requirements.


Disabled users

This monitor returns the number of currently disabled users. Set the threshold value according to your requirements.


User Account: User account was created

This monitor returns the number of new user accounts created.

Event ID: 4720.

Only authorized people and processes should create network accounts. Examine the Primary User Name field to detect whether an authorized person or process created an account. This event also detects if administrators create accounts outside organizational policy guidelines.


User Account: Attempt to change password

This monitor returns the number of account password change attempts.

Event ID: 4723.

This event is logged as a failure if his new password fails to meet the password policy.

This event results from a password change request in which the user supplies the original password to the account. Compare Primary Account Name to Target Account Name to determine whether the account owner or someone else attempted to change the password. If Primary Account Name does not equal Target Account Name, someone other than the account owner tried to change the password.


User Account: Attempt to reset password

This monitor returns the number of times a user or process resets an account password through an administrative interface, such as Active Directory Users and Computers, rather than through a password change process.

Event ID: 4724.

This event is logged as a failure if the new password fails to meet the password policy.

Only authorized people or processes should carry out this process, such as help desk or user self-service password reset.


User Account: Account was disabled

This monitor returns the number of times an account becomes disabled.

Event ID: 4725.

Always investigate this event.


User Account: Account was deleted

This monitor returns the number of deleted user accounts.

Event ID: 4726.

Only authorized people and processes should delete network accounts. Search for these events and examine the Primary Account Name field to detect if unauthorized people have deleted accounts.


User Account: Account was changed

This monitor returns the number of times when changes were made to security-related properties of user accounts.

Event ID: 4738.


User Account: Account was locked out

This monitor returns the number of automatically locked out accounts.

Event ID: 4740.

A user account has locked out because the number of sequential failed logon attempts is greater than the account lockout limit.


User Account: Account name was changed

This monitor returns the number of changes to the normal logon name or the pre-Win2k logon name.

Event ID: 4781.

When an account name is changed, the SID remains the same. However the Target ID in this event indicates the new name. This is because when the operating system displays this event it evidently queries the database where the SID is stored and translates the SID to the domain\username.

A rogue administrator might change his account name or computer name seeking to cover his tracks.


Logon: Account failed to log on

This monitor returns the number of failed login attempts with an incorrect username and/or password.

Event ID: 4625.

Check for attempts where Target Account Name equals Administrator or the renamed default administrator account. Check multiple logon failures that are below the account lockout threshold.


Logon: Replay attack detected

This monitor returns the number of detected attempts by the authentication package to log on by replaying a user's credentials.

Event ID: 4649.

Investigate immediately. Alternatively, this could be a sign of improper  network configuration.


Logon: Attempted logon using explicit credentials

This monitor returns a number for the following events:

  • A user connects to a server or runs a program locally using alternate credentials (run as);
  • A process logs on as a different account; such as when the Scheduled Tasks service starts a task as the specified user;
  • With User Account Control enabled, an end user runs a program requiring administrative authority.

Event ID: 4648.


Policy: Domain policy was changed

This monitor returns the number of events when the computer's Security Settings\Account Policy or Account Lockout Policy was modified, either via Local Security Policy or Group Policy in the Active Directory.

Event ID: 4739.

Unfortunately, the Subject fields don't identify who actually changed the policy because this policy is not directly configured by administrators. Instead, it is edited in a group policy object which then gets applied to the computer. Therefore, this event always shows the local computer as the one who changed the policy since the computer is the security principal under which gpupdate runs.


Policy: Kerberos policy was changed

This monitor returns the number of times Windows detects a change to the domain's Kerberos policy. Kerberos policy is defined in GPOs linked to the root of the domain under Computer Configuration\Windows Settings\Security Settings\Account Policy\Kerberos Policy.

Event ID: 4713.

Unfortunately, the Subject fields do not identify who actually changed the policy because this policy is not directly configured by administrators. Instead, it is edited in a group policy object which then gets applied to the computer. Therefore, this event always shows the local computer as the one who changed the policy since the computer is the security principal under which gpupdate runs.


Policy: System audit policy was changed

This monitor returns the number of times audit policies have been changed either via Local Security Policy, Group Policy in Active Directory, or the audipol command.

Event ID: 4719.

According to Microsoft, this event is always logged when an audit policy is disabled, regardless of the "Audit Policy Change" sub-category setting.

If group policy was used to configure audit policy, the Subject fields do not identify who actually changed the policy. In such cases, this event always shows the local computer as the one who changed the policy since the computer is the security principal under which gpupdate runs.

This event does not necessarily indicate a problem; however, an attacker can change audit policy as part of a computer system attack. You should monitor this event on high value computers and domain controllers.

Policy: Encrypted data recovery policy was changed

This monitor returns the number of times a computer's Security Settings\Public Key Policies\Encrypting File System data recovery agent policy was modified either via Local Security Policy or Group Policy in an Active Directory.

Event ID: 4714.

Unfortunately, the Subject fields do not identify who actually changed the policy because this policy is not directly configured by administrators. Instead, it is edited in a group policy object which then gets applied to the computer. Therefore, this event always shows the local computer as the one who changed the policy since the computer is the security principal under which gpupdate runs.


System: Windows Firewall setting has changed

This monitor returns the number of changes that were made to the Windows Firewall with the Advanced Services MMC console.

Event ID: 4950.


System: Windows is shutting down

This monitor returns the number of times Windows goes to shut down.

Event ID: 4609.

On high-value computers, authorized personnel should restart computers in accordance with established policies. Investigate immediately when this event occurs on any server.


System: The system time was changed

This monitor returns the number times the system time has changed.

Event ID: 520.

This event indicates the old and new system times, as well as who changed the time as specified in the Subject section. It is routine to see this event, where the subject is "LOCAL SERVICE," and can probably be ignored. You will frequently see this event logged twice in a row.


System: Service installed in the system

This monitor returns the number of new services installed by the user as indicated in the subject.

Event ID: 4697.

Subject often identifies the local system (SYSTEM) for services installed as part of native Windows components and therefore you cannot determine who actually initiated the installation.

This is a key change control event as new services are significant extensions of the software running on a server and the roles it performs.


Portions of this document were originally created by and are excerpted from the following sources:

Microsoft Corporation, “TechNet Library,” Copyright Copyright 2012 Microsoft Corporation.  All rights reserved. Available at http://technet.microsoft.com/en-us/library/upgrade-domain-controllers-to-windows-server-2008-r2%28v=ws.10%29.aspx

Last Updated: 11/19/2014

solarwinds_worldwide_llc

  • Everything works nicely after following the steps...5 star post emoticons_cool.png

  • erlopez, due to the method of retrieving the domain information from the default template, using an account in a child domain does not work. However, you can modify the template for the DC nodes in the child domain to make it work.

    Modify the "Locked Out Users" monitor with the following: (Replace "ChildDomain" with the NETBIOS name of your child domain)

    Trap {"Error: $_"; Break;}

    if (([ADSI]"LDAP://RootDSE").dnshostname) {}

      else

      {

      write-host "Message: This is not a domain controller."

      exit 1;

      }

    try {

      $D = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()

      $Domain = [ADSI]"LDAP://ChildDomain.$D"

      $LOD = $Domain.lockoutDuration.Value

      $lngDuration = $Domain.ConvertLargeIntegerToInt64($LOD)

      }

    catch

      {

      Write-Host "ERROR: $($Error[0])";

      exit 1;

      }

    If (-$lngDuration -gt [DateTime]::MaxValue.Ticks)

    {

        $LockoutTime = 1

    }

    Else

    {

        $Now = Get-Date

        $NowUtc = $Now.ToFileTimeUtc()

        $LockoutTime = $NowUtc + $lngDuration

    }

    try {

      $Searcher = New-Object System.DirectoryServices.DirectorySearcher

      $Searcher.PageSize = 2000

      $Searcher.SearchScope = "subtree"

      $Searcher.Filter = "(&(sAMAccountType=805306368)(lockoutTime>=1))"

      $Searcher.PropertiesToLoad.Add("distinguishedName") > $Null

      $Searcher.SearchRoot = $Domain.path

      $Results = $Searcher.FindAll()

      }

    catch

      {

      Write-Host "ERROR: $($Error[0])";

      exit 1;

      }

    if ($Results.Count -eq 0)

    {

    Write-Host "Message: No locked users found.";

    Write-Host "Statistic: 0";

    exit 0;

    }

    else

    {

    $res = $Searcher.FindAll() | select-object Path | foreach-object { `

      $spl1=$_.Path.Tostring().Split("//"); `

      $spl2=$spl1[2].Split(","); `

      $spl3=$spl2[0].Split("="); `

      $cu=$spl3[1]; `

      $users += $cu;

      $users += " ; ";

      }

    Write-host "Message: Locked out users: $users";

    Write-host "Statistic:" $Results.Count

    exit 0

    }

    Modify the "Disabled Users" monitor with the following: (Replace "ChildDomain" with the NETBIOS name of your child domain)

    if (([ADSI]"LDAP://RootDSE").dnshostname) {}

      else

      {

      write-host "Message: This is not a domain controller."

      exit 1;

      }

    try
    {

      $strFilter = "(&(sAMAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=2))"

      $D = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()

      $objDomain = [ADSI]"LDAP://ChildDomain.$D"


      $objSearcher = New-Object System.DirectoryServices.DirectorySearcher

      $objSearcher.SearchRoot = $objDomain

      $objSearcher.PageSize = 1000

      $objSearcher.Filter = $strFilter

      $colProplist = "name"

      foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

      $colResults = $objSearcher.FindAll()

      }

    catch

      {

      Write-Host "ERROR: $($Error[0])";

      exit 1;

      }

    if ($colResults.Count -eq 0)

    {
    Write-Host "Message: No disabled users found.";

    Write-Host "Statistic: 0";

    exit 0;

    }

    else

    {

    $res = $objSearcher.FindAll() | select-object Path | foreach-object { `

      $spl1=$_.Path.Tostring().Split("//"); `

      $spl2=$spl1[2].Split(","); `

      $spl3=$spl2[0].Split("="); `

      $cu=$spl3[1]; `

      $users += $cu;

      $users += " ; ";

      }

    Write-host "Message: Disabled users: $users";

    Write-host "Statistic:" $colResults.Count

    exit 0

    }

  • This template works great, but I am having a small issue I can't seem to figure out how to fix. My Credential for Monitoring  resides in our parent domain, so for all the DC's in the parent domain it returns the Locked Out and Disabled users statistics fine. However for the DC's in the Child Domain, I get this error:

    Output: ==============================================

    ERROR: Exception calling "ConvertLargeIntegerToInt64" with "2" argument(s): "Cannot process argument because the value of argument "largeIntegerInstance" is invalid. Change the value of the "largeIntegerInstance" argument and run the operation again."

    If I change the Credential for Monitoring to an account that resides in the child domain, it works fine. Is there a way to get it to work with the account in the parent domain?

    -Eric

  • MS must have shuffled their pages around. Check out the two below. Hopefully this will get you started:

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.