Monitor Active Directory

The Active Directory (AD) database, also known as the NT Directory Service (NTDS) database, is the central repository for user, computer, network, device, and security objects in a Windows AD domain or forest. You can use Splunk Enterprise to record changes to AD, such as the addition or removal of a user, host, or domain controller (DC).

If you use Splunk Cloud Platform, you must use the Splunk Universal forwarder to collect Active Directory data from a Windows domain controller or member machine and forward that data to Splunk Cloud Platform. On Splunk Enterprise, you can also use the universal forwarder, or you can Install Splunk Enterprise directly onto a Windows machine and collect the AD data that way.

You can configure AD monitoring to watch for changes to your Active Directory forest and collect user and machine metadata. You can use this feature combined with dynamic list lookups to decorate or modify events with any information available in AD. See About lookups in the Knowledge Manager Manual.

After you configure Splunk Enterprise to monitor your Active Directory, it takes a baseline snapshot of the AD schema. It uses this snapshot to establish a starting point for monitoring.

The AD monitoring input runs as a separate process called splunk-admon.exe. It runs once for every Active Directory monitoring input you define in Splunk Enterprise.

Reasons to monitor Active Directory

If you maintain the integrity, security, and health of your Active Directory, then what happens with it day to day is a concern. With Splunk Enterprise, you can monitor what and when things changed in your AD and who changed them.

You can transform this data into reports for corporate security compliance or forensics, for example. You can also use the data retrieved for intrusion alerts for immediate response. Additionally, you can create health reports with the data indexed for future AD infrastructure planning activities, such as assignment of operations master roles, AD replicas, and global catalogs across DCs.

Requirements

You must meet the following requirements to monitor an Active Directory schema:

Technical considerations for monitoring Active Directory

For best results with monitoring AD, note the following considerations:

  • The AD monitor is only available on the Splunk platform on Windows. Splunk Cloud Platform cannot monitor AD directly.
  • While you cannot monitor AD changes from a *nix version of Splunk Enterprise, you can forward AD data from a Windows version of Splunk Enterprise or the universal forwarder to a *nix indexer.
  • The AD monitoring process can run under a full instance or on any kind of forwarder.
  • The host that monitors changes to AD must belong to the domain or forest you want to monitor.
  • The user that Splunk Enterprise runs as must also be part of the domain.
  • The permissions that the user has determine which parts of AD Splunk can monitor.

For information on deciding which user Splunk Enterprise runs as at installation time, see Choose the Windows user Splunk Enterprise should run as in the Installation Manual.

How the AD monitor interacts with AD

When you set up an AD monitoring input, the input connects to an AD domain controller to authenticate and, if necessary, performs any security ID (SID) translations while it gathers the AD schema or changes events.

The AD monitor uses the following logic to interact with Active Directory after you set it up:

  1. If you specify a domain controller when you define the input, then the input uses that domain controller for AD operations. You can specify a domain controller either with the targetDc setting in inputs.conf or the Target domain controller field in Splunk Web.
  2. If you do not specify a domain controller, then the input does the following:
    1. The input attempts to use the local system cache to authenticate or resolve SIDs.
    2. If the monitor cannot authenticate or resolve SIDs that way, it attempts a connection to the domain controller that the machine that runs the input used to log on.
    3. If that does not work, then the input attempts to use the closest AD domain controller that has a copy of the Global Catalog.
  3. If the domain controller that you specify is not valid or a domain controller cannot be found, then the input generates an error message.

The AD monitor does not chase LDAP referrals

If the AD monitor makes a Lightweight Directory Access Protocol (LDAP) query and receives a referral, it does not chase this referral to complete the query. An LDAP referral represents a problem with your LDAP configuration and you or your designated administrators must determine and fix the configuration problem within AD.

Configure Active Directory monitoring with configuration files

You can configure AD monitoring either in Splunk Web or by editing configuration files. You can access more options, such as the ability to configure monitors for multiple DCs, when using configuration files.

The inputs.conf configuration file controls Active Directory monitoring configurations. Edit copies of inputs.conf in the %SPLUNK_HOME%\etc\system\local directory. If you edit them in the default directory, an upgrade overwrites your changes. For more information about configuration file precedence, see Configuration file precedence.

  1. Open %SPLUNK_HOME%\etc\system\local\inputs.conf for editing. Create this file if it does not exist.
  2. Add the appropriate AD monitoring stanzas and settings.

By default, when you enable AD monitoring inputs, Splunk Enterprise gathers AD change data from the first domain controller that it can attach to. If that is acceptable, no further configuration is necessary.

inputs.conf settings

inputs.conf contains one stanza for each AD monitoring input, with a header like the following:

[admon://<name of stanza>]

In each stanza, you can specify the following settings:

Setting Required? Description Default
targetDc Yes The unique name of the domain controller you want to use for AD monitoring.

Specify a unique name for this setting if the following circumstances apply:

  • You have a very large AD and you only want to monitor information in a particular Organizational Unit (OU), subdomain, and so on.
  • You have a specific read-only domain controller that can be used for monitoring purposes in a high security environment.
  • You have multiple domains or forests with transitive trusts established and want to target a different tree than the one where the host that runs Splunk Enterprise resides.
  • You want to configure multiple AD monitoring inputs to target multiple domain controllers. For example, to monitor AD replication across a distributed environment.

To target multiple DCs, add another [admon://<uniquename>targetDc] stanza for a target in that tree.

the local machine
startingNode No A fully qualified Lightweight Directory Access Protocol (LDAP) name (for example: "LDAP://OU=Computers,DC=ad,DC=splunk,DC=com") that specifies where in the AD tree that Splunk Enterprise begins its indexing. The software starts there and enumerates down to sub-containers, depending on the configuration of the monitorSubtree setting.

The value of startingNode must be within the scope of the DC you are targeting for Splunk Enterprise to get AD data.

The highest root domain in the tree that Splunk Enterprise can access
monitorSubtree No How much of the target AD container to index. A value of 0 means to index only the target container, and not traverse into subcontainers within that container. A value of 1 means to enumerate all sub-containers and domains that it has access to. 1 (monitor all domains that Splunk Enterprise has access to)
baseline No Whether or not the input enumerates all existing available AD objects when it first runs. A value of 0 means not to set a baseline. A value of 1 means to set a baseline. 0 (do not set the baseline)
index No The index to route AD monitoring data to. the default index
disabled No Whether or not Splunk Enterprise runs the input. A value of 0 means that the input is enabled, and a value of 1 means that the input is disabled. 1 (disabled)

Example AD monitoring configurations

The following are examples of how to use the inputs.conf file to monitor desired portions of your AD network.

See the following example to index data from the top of the AD directory: 

#Gather all AD data that this server can see

[admon://NearestDC]
targetDc =
startingNode =

See the following example to use a DC that is at a higher root level than an OU you want to target for monitoring: 

# Use the pri01.eng.ad.splunk.com domain controller to get all AD metadata for
# the Computers OU in this forest. We want schema data for the entire AD tree, not
# just this node.

[admon://DefaultTargetDc]
targetDc = pri01.eng.ad.splunk.com
startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com

See the following example to monitor multiple domain controllers: 

# Get change data from two domain controllers (pri01 and pri02) in the same AD tree.
# Index both and compare/contrast to ensure AD replication is occurring properly.

[admon://DefaultTargetDc]
targetDc = pri01.eng.ad.splunk.com
startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com

[admon://SecondTargetDc]
targetDc = pri02.eng.ad.splunk.com
startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com

Sample AD monitoring output

When the AD monitoring utility runs, it gathers AD change events, which the Splunk platform then indexes. To view these events as they arrive, use the Search & Reporting app.

There are several types of AD change events that the Splunk platform can index. Examples of these events follow. Some of the content of these events is obscured or altered for publication purposes.

Update event

When an AD object changes, the Splunk platform generates an update event. The software logs this change as type admonEventType=Update. 

           
2/1/10
3:17:18.009 PM                 
                
02/01/2010 15:17:18.0099
dcName=stuff.splunk.com
admonEventType=Update
Names:
                objectCategory=CN=Computer,CN=Schema,CN=Configuration
                name=stuff2
                displayName=stuff2
                distinguishedName=CN=stuff2,CN=Computers
Object Details:
                sAMAccountType=805306369
                sAMAccountName=stuff2
                logonCount=4216
                accountExpires=9223372036854775807
                objectSid=S-1-5-21-3436176729-1841096389-3700143990-1190
                primaryGroupID=515
                pwdLastSet=06:30:13 pm, Sat 11/27/2010
                lastLogon=06:19:43 am, Sun 11/28/2010
                lastLogoff=0
                badPasswordTime=0
                countryCode=0
                codePage=0
                badPwdCount=0
                userAccountControl=4096
                objectGUID=blah
                whenChanged=01:02.11 am, Thu 01/28/2010
                whenCreated=05:29.50 pm, Tue 11/25/2008
                objectClass=top|person|organizationalPerson|user|computer
Event Details:
                uSNChanged=2921916
                uSNCreated=1679623
                instanceType=4
Additional Details:
                isCriticalSystemObject=FALSE
                servicePrincipalName=TERMSRV/stuff2|TERMSRV blah
                dNSHostName=stuff2.splunk.com
                operatingSystemServicePack=Service Pack 2
                operatingSystemVersion=6.0 (6002)
                operatingSystem=Windows Vista? Ultimate
localPolicyFlags=0

Delete event

When an AD object has been marked for deletion, the Splunk platform generates a delete event. The event type is similar to admonEventType=Update, except that it contains the isDeleted=True key/value pair at the end of the event. 

2/1/10
3:11:16.095 PM                 
 
02/01/2010 15:11:16.0954
dcName=stuff.splunk.com
admonEventType=Update
Names:
                name=SplunkTest
DEL:blah
                distinguishedName=OU=SplunkTest\0ADEL:blah,CN=Deleted Objects
DEL:blah
Object Details:
                objectGUID=blah
                whenChanged=11:31.13 pm, Thu 01/28/2010
                whenCreated=11:27.12 pm, Thu 01/28/2010
                objectClass=top|organizationalUnit
Event Details:
                uSNChanged=2922895
                uSNCreated=2922846
                instanceType=4
Additional Details:
                dSCorePropagationData=20100128233113.0Z|20100128233113.0Z|20100128233113.0Z|16010108151056.0Z
                lastKnownParent=stuff
                '''isDeleted=TRUE'''

Sync event

When AD monitoring inputs are configured, the Splunk platform tries to capture a baseline of AD metadata when it starts. the Splunk platform generates event type admonEventType=Sync, which represents the instance of one AD object and all its field values. the Splunk platform tries to capture all of the objects from the last recorded Update Sequence Number (USN).

When you restart Splunk Enterprise or the splunk-admon.exe process, the software logs an extra sync event. This is normal. 

2/1/10
3:11:09.074 PM                 
 
02/01/2010 15:11:09.0748
dcName=ftw.ad.splunk.com
admonEventType=Sync
Names:
                name=NTDS Settings
                distinguishedName=CN=NTDS Settings,CN=stuff,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration
                cn=NTDS Settings
                objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=ad,DC=splunk,DC=com
                fullPath=LDAP://stuff.splunk.com/<GUID=bla bla bla>
                CN=NTDS Settings
Object Details:
                whenCreated=10:15.04 pm, Tue 02/12/2008
                whenChanged=10:23.00 pm, Tue 02/12/2008
                objectGUID=bla bla bla
                objectClass=top|applicationSettings|nTDSDSA
                classPath=nTDSDSA
Event Details:
                instanceType=4
Additional Details:
                systemFlags=33554432
                showInAdvancedViewOnly=TRUE
                serverReferenceBL=CN=stuff,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System
                options=1
                msDS-hasMasterNCs=DC=ForestDnsZones|DC=DomainDnsZones|CN=Schema,CN=Configuration|CN=Configuration
                msDS-HasInstantiatedNCs=
                msDS-HasDomainNCs=blah
                msDS-Behavior-Version=2
                invocationId=bla bla bla
                hasMasterNCs=CN=Schema,CN=Configuration|CN=Configuration
                dSCorePropagationData=
                dMDLocation=CN=Schema,CN=Configuration
                nTSecurityDescriptor=NT AUTHORITY\Authenticated Users
SchemaName=LDAP://stuff.splunk.com/schema/nTDSDSA

Schema event

When you restart Splunk Enterprise after configuring it for AD monitoring, it generates a schema type event: admonEventType=schema. This event shows the definitions of every object in the Active Directory structure. The available, required, and optional fields are listed for each AD object. Failure to see all of these fields can indicate a problem with Active Directory. 

02/01/2010 15:11:16.0518
dcName=LDAP://stuff.splunk.com/
admonEventType=schema
className=msExchProtocolCfgSMTPIPAddress
classCN=ms-Exch-Protocol-Cfg-SMTP-IP-Address
instanceType=MandatoryProperties
nTSecurityDescriptor=MandatoryProperties
objectCategory=MandatoryProperties
objectClass=MandatoryProperties
adminDescription=OptionalProperties
adminDisplayName=OptionalProperties
allowedAttributes=OptionalProperties
allowedAttributesEffective=OptionalProperties
allowedChildClasses=OptionalProperties
allowedChildClassesEffective=OptionalProperties
bridgeheadServerListBL=OptionalProperties
canonicalName=OptionalProperties
cn=OptionalProperties
createTimeStamp=OptionalProperties
description=OptionalProperties
directReports=OptionalProperties
displayName=OptionalProperties
displayNamePrintable=OptionalProperties
distinguishedName=OptionalProperties
dSASignature=OptionalProperties
dSCorePropagationData=OptionalProperties
extensionName=OptionalProperties
flags=OptionalProperties
fromEntry=OptionalProperties
frsComputerReferenceBL=OptionalProperties
fRSMemberReferenceBL=OptionalProperties
fSMORoleOwner=OptionalProperties
heuristics=OptionalProperties
isCriticalSystemObject=OptionalProperties
isDeleted=OptionalProperties
isPrivilegeHolder=OptionalProperties
lastKnownParent=OptionalProperties
legacyExchangeDN=OptionalProperties
managedObjects=OptionalProperties
masteredBy=OptionalProperties
memberOf=OptionalProperties
modifyTimeStamp=OptionalProperties
mS-DS-ConsistencyChildCount=OptionalProperties
mS-DS-ConsistencyGuid=OptionalProperties
msCOM-PartitionSetLink=OptionalProperties
msCOM-UserLink=OptionalProperties
msDFSR-ComputerReferenceBL=OptionalProperties
msDFSR-MemberReferenceBL=OptionalProperties
msDS-Approx-Immed-Subordinates=OptionalProperties
msDs-masteredBy=OptionalProperties
msDS-MembersForAzRoleBL=OptionalProperties
msDS-NCReplCursors=OptionalProperties
msDS-NCReplInboundNeighbors=OptionalProperties
msDS-NCReplOutboundNeighbors=OptionalProperties
msDS-NonMembersBL=OptionalProperties
msDS-ObjectReferenceBL=OptionalProperties
msDS-OperationsForAzRoleBL=OptionalProperties
msDS-OperationsForAzTaskBL=OptionalProperties
msDS-ReplAttributeMetaData=OptionalProperties
msDS-ReplValueMetaData=OptionalProperties
msDS-TasksForAzRoleBL=OptionalProperties
msDS-TasksForAzTaskBL=OptionalProperties
msExchADCGlobalNames=OptionalProperties
msExchALObjectVersion=OptionalProperties
msExchHideFromAddressLists=OptionalProperties
msExchInconsistentState=OptionalProperties
msExchIPAddress=OptionalProperties
msExchTurfList=OptionalProperties
msExchUnmergedAttsPt=OptionalProperties
msExchVersion=OptionalProperties
msSFU30PosixMemberOf=OptionalProperties
name=OptionalProperties
netbootSCPBL=OptionalProperties
nonSecurityMemberBL=OptionalProperties
objectGUID=OptionalProperties
objectVersion=OptionalProperties
otherWellKnownObjects=OptionalProperties
ownerBL=OptionalProperties
partialAttributeDeletionList=OptionalProperties
partialAttributeSet=OptionalProperties
possibleInferiors=OptionalProperties
proxiedObjectName=OptionalProperties
proxyAddresses=OptionalProperties
queryPolicyBL=OptionalProperties
replicatedObjectVersion=OptionalProperties
replicationSignature=OptionalProperties
replPropertyMetaData=OptionalProperties
replUpToDateVector=OptionalProperties
repsFrom=OptionalProperties
repsTo=OptionalProperties
revision=OptionalProperties
sDRightsEffective=OptionalProperties
serverReferenceBL=OptionalProperties
showInAddressBook=OptionalProperties
showInAdvancedViewOnly=OptionalProperties
siteObjectBL=OptionalProperties
structuralObjectClass=OptionalProperties
subRefs=OptionalProperties
subSchemaSubEntry=OptionalProperties
systemFlags=OptionalProperties
unmergedAtts=OptionalProperties
url=OptionalProperties
uSNChanged=OptionalProperties
uSNCreated=OptionalProperties
uSNDSALastObjRemoved=OptionalProperties
USNIntersite=OptionalProperties
uSNLastObjRem=OptionalProperties
uSNSource=OptionalProperties
wbemPath=OptionalProperties
wellKnownObjects=OptionalProperties
whenChanged=OptionalProperties
whenCreated=OptionalProperties
wWWHomePage=OptionalProperties