
Monitor Active Directory
Active Directory (AD) is an integral part of any Windows network. The Active Directory database (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. When you make a change to Active Directory, such as adding or deleting a user, member server or domain controller, those changes are recordable. Splunk lets you alert and monitor those changes in real time.
You can configure AD monitoring to watch 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.
Once you've configured Splunk to monitor your Active Directory, it will take a baseline snapshot of your AD data and the AD schema. It will use this snapshot to establish a starting point against which to monitor. This process might take a little time before it completes.
The AD monitoring input runs as a separate process called splunk-admon.exe
. It runs once for every Active Directory monitoring input defined in Splunk.
Why monitor Active Directory?
If you are charged with maintaining the integrity, security and health of your Active Directory, then you are concerned with what is happening with it day to day. Splunk allows you to see what has changed in your AD, who or what made the changes, and when they were made.
You can transform this data into reports for corporate security compliance or forensics. 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 domain controllers (DCs).
What's required to monitor Active Directory?
The following table lists the explicit permissions needed to monitor an Active Directory schema.
Activity: | Required permissions: |
---|---|
Monitor an Active Directory schema | * Splunk must run on Windows * Splunk must run as a domain user * The user Splunk runs as must have read access to all AD objects that you want to monitor |
Considerations for monitoring Active Directory
To get the best results out of monitoring AD with Splunk, be aware of the following:
- This feature is only available with Splunk on Windows. You won't be able to monitor AD changes from a *nix version of Splunk (though you can forward AD data gathered from a Windows version of Splunk to a *nix indexer).
- The AD monitoring process can run under a full Splunk instance or within any kind of forwarder.
- The machine that's monitoring changes to AD must belong to the domain or forest you want to monitor.
- The user Splunk runs as must be part of the domain too. This is because the permissions that the user has determine what parts of AD Splunk can monitor.
For additional information on deciding how to monitor Windows data remotely, see "Considerations for deciding how to monitor remote Windows data" in this manual. For information on deciding which user Splunk should run as at installation time, review "Choosing the user Splunk should run as" in the Installation Manual.
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
1. Click Manager in the upper right-hand corner of Splunk Web.
2. Under "Data", click Data Inputs.
3. Click Active Directory monitoring.
4. Click New to add an input.
5. Enter a unique name for the AD monitor input.
6. Type in the name of a Target domain controller for Splunk to bind to in order to monitor AD.
Note: You can leave the field blank to tell Splunk to discover the nearest domain controller automatically.
7. Type in the name of a Starting node to tell Splunk where in the AD to start monitoring data, or leave the field blank to tell Splunk to monitor AD objects from the highest available part of the directory tree.
Note: Review "Considerations on how to monitor remote Windows data" to learn how the user Splunk runs as affects what Splunk displays.
8. You can also click on the Browse button to display a tree view of AD objects that it can see, and select the desired object that way.
9. If you click the Browse button, the Active Directory window appears. This window displays AD containers and objects, starting from the highest point of the AD tree that Splunk has access to. Select the AD container or object that you want to monitor, then click Select to close the window.
Note: Containers are represented by folders, and objects are represented by document icons. When a container or object is selected, its qualified name appears in the Qualified name at the bottom of the window.
10. Select Monitor subtree if you want Splunk to monitor the child nodes below the starting node you specified in Steps 7-9.
11. Choose the destination index for this input.
12. Click Save.
Splunk adds and enables the input.
Configure AD monitoring with configuration files
Active Directory monitoring configurations are controlled by inputs.conf and admon.conf. Be sure to edit copies of these configuration files in the %SPLUNK_HOME%\etc\system\local
directory. If you edit them in the default directory, any changes you make will be overwritten when you upgrade Splunk. For more information about configuration file precedence, refer to "About configuration files" in this manual.
1. Make a copy of %SPLUNK_HOME%\etc\system\default\inputs.conf
and put it in %SPLUNK_HOME%\etc\system\local\inputs.conf
.
2. Edit the copy and enable the scripted input [script://%SPLUNK_HOME%\bin\scripts\splunk-admon.path]
by setting the value of disabled
to 0.
3. Make a copy of %SPLUNK_HOME%\etc\system\default\admon.conf
and put it in %SPLUNK_HOME%\etc\system\local\admon.conf
.
4. Use the "Settings in admon.conf" section below to make edits to admon.conf.
Note: By default, when AD monitoring inputs are enabled, Splunk will gather AD change data from the first domain controller that it can attach to. If that is acceptable, no further configuration is necessary.
admon.conf settings
admon.conf
contains one stanza for each AD monitoring input. In each stanza, you specify:
targetDc
: The unique name of the domain controller host you want Splunk to use for AD monitoring.
Specify a unique name for this attribute if:
- You have a very large AD and you only want to monitor information in a particular Organizational Unit (OU), subdomain, etc.
- You have a specific (read-only) domain controller that is offered for monitoring purposes in a high security environment.
- You have multiple domains or forests in with transitive trusts established, and want to use this to target a different tree than the one where Splunk resides.
- You want to configure multiple AD monitoring inputs to target multiple domain controllers. For example, to monitor AD replication across a distributed environment.
Note: If you want to target multiple DCs, add another [<uniquename>targetDc]
stanza for a target in that tree.
startingNode
: A fully qualified Lightweight Directory Access Protocol (LDAP) name (for example "LDAP://OU=Computers,DC=ad,DC=splunk,DC=com"
) that specifies where Splunk should begin its indexing. Splunk starts there and enumerates down to sub-containers, depending on the configuration of the monitorSubtree
attribute. If startingNode
is not specified or is blank, Splunk will start monitoring AD data from the highest root domain in the tree it can access.
Note: The value of startingNode
must be within the scope of the DC you are targeting in order for Splunk to successfully get AD data.
monitorSubtree
: How much of the target AD container to index. A value of 0 tells Splunk to index only the target container, and not traverse into subcontainers within that container. A value of 1 tells Splunk to enumerate all sub-containers and domains that it has access to. The default is 1.
index
: The index to route AD monitoring data to. If not present, the 'default' index is used.
disabled
: Whether or not the input is enabled. A value of 0 tells Splunk that the input is enabled, and a value of 1 tells Splunk that the input is disabled. The default is 0 (enabled).
Example AD monitoring configurations
The following are examples of how to use admon.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 [default] monitorSubtree = 1 disabled = 0 [NearestDC] targetDc = startingNode =
To use a DC that is at a higher root level than an OU you want to target for monitoring:
[default] monitorSubtree = 1 disabled = 0 # 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. [DefaultTargetDc] targetDc = pri01.eng.ad.splunk.com startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com
To monitor multiple domain controllers:
[default] monitorSubtree = 1 disabled = 0 # 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. [DefaultTargetDc] targetDc = pri01.eng.ad.splunk.com startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com [SecondTargetDc] targetDc = pri02.eng.ad.splunk.com startingNode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com
Sample AD monitoring output
When Splunk's AD monitoring utility runs, it gathers AD change events. Each change event is indexed as an event in Splunk. You can view these events as they come into Splunk in the Search app.
There are several types of AD change events that Splunk can index. Examples of these events are detailed below. Some of the content of these events has been obscured/altered for publication purposes.
Update event
When an AD object is changed in any way, Splunk generates this type of event. Splunk 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
Splunk generates this event type when an AD object has been marked for deletion. 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 tries to capture a baseline of AD metadata when it is started. Splunk generates event type admonEventType=Sync
, which represents the instance of one AD object and all its field values. Splunk tries to capture all of the objects from the last recorded Update Sequence Number (USN).
Note: When you restart either Splunk or the splunk-admon.exe
process, Splunk will log 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 Splunk is started after configured 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
Answers
Have questions? Visit Splunk Answers and see what questions and answers the Splunk community has around monitoring AD with Splunk.
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: 4.3, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7, 5.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5, 5.0.6, 5.0.7, 5.0.8, 5.0.9, 5.0.10, 5.0.11, 5.0.12, 5.0.13, 5.0.14, 5.0.15, 5.0.16, 5.0.17, 5.0.18
Comments
When one Splunk UF is configured to get admon events from two DCs, admon events from second DC come to indexer in almost real time. But the admon events from first DC has hugh delay (more than 2 minutes and I see 10 minutes delay in some cases). Is this a bug? It seems a bug where Splunk code can handle only one DC correctly. So far, I did not find a pattern for the number of delayed minutes. The delay time is just ramdomized. Sometimes longer and sometimes shorter. But is always on minute level, not second level.
Why would events not be picked up on a delete? I am testing and I'm seeing lots of events from my DC but when I delete a user I don't get events with the isDeleted in them.