
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 an 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 have Splunk Cloud, you must use the Splunk Universal forwarder to collect Active Directory data.
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.
After you have configured 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.
Why 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. Splunk Enterprise lets you 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.
What do you need to monitor Active Directory?
The following table lists the permissions you must have to monitor an Active Directory schema.
Activity | Required permissions |
---|---|
Monitor an Active Directory schema | * Splunk Enterprise must run on Windows * Splunk Enterprise must run as a domain user * The user Splunk Enterprise runs as must have read access to all AD objects that you want to monitor |
Technical considerations for monitoring Active Directory
For best results with monitoring AD, read and understand the following:
- The AD monitor is only available on Splunk Enterprise on Windows.
- 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 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 should run as at installation time, see Choose the user Splunk 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, perform any security ID (SID) translations while it gathers the AD schema or change events.
The AD monitor uses the following logic to interact with Active Directory after you set it up:
- If you specify a domain controller when you define the input (either with the
targetDc
setting ininputs.conf
or the "Target domain controller" field in Splunk Web, then the input uses that domain controller for AD operations. - If you do not specify a domain controller, then the input does the following:
- The input attempts to use the local system cache to authenticate or resolve SIDs.
- 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.
- If that does not work, then the input attempts to use the closest AD domain controller that has a copy of the Global Catalog.
- 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 an 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 should determine and fix the configuration problem within AD.
Configure Active Directory monitoring
You can configure AD monitoring either in Splunk Web or by editing configuration files. More options, such as the ability to configure monitors for multiple DCs, are available when using configuration files.
Configure AD monitoring with Splunk Web
Go to the Add New page
You can get there by two routes.
- Splunk Home
- Splunk Settings
By Splunk Settings:
- Click Settings in the upper right corner of Splunk Web.
- Click Data Inputs.
- Click Active Directory monitoring.
- Click New to add an input.
By Splunk Home:
- Click the Add Data link in Splunk Home.
- Click Monitor to monitor Active Directory on the local Windows machine.
Select the input source
- In the left pane, select Active Directory monitoring.
- In the Collection name field, type in a unique name for the input that you will remember.
- (Optional) In the Target domain controller field, enter the host name or IP address of the domain controller you want to use to monitor AD.
- (Optional) In the Starting node field, type in the Active Directory node you want the input to begin monitoring from. Use the Lightweight Directory Access Protocol (LDAP) format, for example,
DC=Splunk-Docs,DC=com
. - (Optional) You can click the Browse button to browse through a list of available Active Directory nodes to browse through a list of available AD domains.
- Check Monitor Subtree if you want the input to monitor all sub-nodes of the node you entered in the "Starting node" field.
- Click Next.
Specify input settings
The Input Settings page lets you specify application context, default host value, and index. All of these parameters are optional.
Note: Host only sets the host field in the resulting events. It does not tell the input to look on a specific host on your network.
- Select the appropriate Application context for this input.
- Set the Host name value. You have several choices for this setting. Learn more about setting the host value in "About hosts".
- Set the Index that Splunk Enterprise should send data to. Leave the value as "default", unless you have defined multiple indexes to handle different types of events. In addition to indexes for user data, Splunk Enterprise has a number of utility indexes, which also appear in this dropdown box.
- Click Review.
Review your choices
After specifying all your input settings, review your selections. Splunk Enterprise lists all options you selected, including the type of monitor, the source, the source type, the application context, and the index.
- Review the settings.
- If they do not match what you want, click < to go back to the previous step in the wizard. Otherwise, click Submit.
Splunk Enterprise then loads the "Success" page and begins indexing the specified Active Directory node.
Configure AD monitoring with 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, your changes are overwritten when you upgrade. For more information about configuration file precedence, see "Configuration file precedence" in this manual.
- Open
%SPLUNK_HOME%\etc\system\local\inputs.conf
for editing. You might need to create this file if it does not exist. - 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:
Attribute | 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 attribute if:
To target multiple DCs, add another |
n/a |
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 should begin its indexing. The software starts there and enumerates down to sub-containers, depending on the configuration of the monitorSubtree attribute.
The value of |
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. | 1 (set the baseline.) |
index
|
No | The index to route AD monitoring data to. | the 'default' index. |
disabled
|
No | Whether or not the Splunk should run the input. A value of 0 means that the input is enabled, and a value of 1 means that the input is disabled. | 0 (enabled). |
Example AD monitoring configurations
The following are examples of how to use inputs.conf
to monitor desired portions of your AD network.
To index data from the top of the AD directory:
#Gather all AD data that this server can see [admon://NearestDC] targetDc = startingNode =
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
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 Splunk AD monitoring utility runs, it gathers AD change events, which are then indexed by Splunk software. To view these events as they arrive, use the Search app.
There are several types of AD change events that Splunk software can index. Examples of these events follow. Some of the content of these events has been obscured or altered for publication purposes.
Update event
When an AD object changes, Splunk 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, Splunk software 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, Splunk software tries to capture a baseline of AD metadata when it starts. Splunk software generates event type admonEventType=Sync
, which represents the instance of one AD object and all its field values. Splunk software 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
PREVIOUS Considerations for deciding how to monitor remote Windows data |
NEXT Monitor Windows event log data |
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.1.0, 8.1.1, 7.0.11, 7.0.2, 7.0.3
Feedback submitted, thanks!