Fyi, I just released an Update, version 4.0.3 that now fully supports Splunk Version 8.x.   Although 3.2.9 would work, the dashboards with the tabs had issues.    FYI, Version 4.0.3 has a lot of changes, with the biggest part consisting of now using the KVstore vs csv lookups.   This was needed for scalability purposes, but does greatly improve performance with synchronizing the lookups (ie applying diffs vs full rebuilds) and with performing lookups (Ex. ...| lookup lookup_usr AS src_user OUTPUT cn AS Admin_User).   I also now use macro's for pointing to the indexes, instead of eventtypes.    If you are upgrading, or doing a new install, you will need to walk through the Configuration - Getting Data In dashboard to verify/update the appropriate macros and migrate/build the new kvstore lookups.   ... View more

First, you can have discrepancies when you are either missing the admonEventType="Sync", which is only generated when the baseline is collected. Or if the baseline was collected before the MS Windows AD Objects application was installed and the "Build" step was never ran via the Build AD Lookup Lists - Main dashboard. The reason this is important is because the only objects, ie users, that will be available in lookups will be only new/updated/deleted ones that are extracted from admonEventType="Updated" or admonEventType="Deleted" events. The admonEventType="Sync" events are collected for all objects when a baseline is generated. So first I would suggest to run the report, AD Objects - Verify Baseline Data - Overall, which is in the menu Configuration Dashboards. If no results are returned then make sure that you have followed the below steps for enabling the following input on one of your domain controllers. **Note: **If it was enabled then see the next set of steps for recollecting the baseline. Add the following input to the Splunk_TA_Windows/local/inputs.conf either locally on the Domain Controllers *...\SplunkUniversalForwarder\etc\apps* directory, or if using the deployment server the *...\splunk\etc\deployment-apps* directory. [admon://NearestDC] disabled = 0 monitorSubtree = 1 baseline = 1 index=msad Restart the Splunk Forwarder Service, either locally or if using the Deployment Server then make sure the Restart Splunk option is selected for the Splunk_TA_Windows application. If the above input was already in the Domain Controllers inputs.conf, then do the following steps to recollect the baseline AD Data. Logon on locally on the AD Domain Controller Stop the Splunk Forwarder Service Navigate to the *..\SplunkUniversalForwarder\var\lib\splunk\persistentstorage\ADMon* directory. Delete the NearestDC.ini file, and any other .ini file if it exists. Note: If you see default.ini then the admon input is enabled somewhere else, and will prevent the baseline from being collected. It might have been enabled when you installed the forwarder by checking the enable “Active Directory” monitoring option. If You do see a default.ini, then navigate into the **...\SplunkUniversalForwarder\etc\apps\SplunkUniversalForwarder\local directory and remove the [admon://default] from the inputs.conf file. If it isn't there then check the local directory of any of the other applications on the forwarder. Start the Splunk Forwarder service Run the AD Objects - Verify Baseline Data - Overall report again to verify that you are getting admonEventType="Sync" data. If you are now receiving the baseline data, then if you want to force the rebuild then open the Build AD Lookup Lists - Main dashboard and click the button to Build All. Otherwise the Scheduled Searches will pick up the new "Sync" events within 15minutes. BTW: Below is a base search for getting the user objects. There are several macros used to build the lookup, because the group membership, deleted users, etc all needs to be synced up. : eventtype=ms_ad_obj_msad_data (objectClass="top|person|organizationalPerson|user") | fields admonEventType,cn,sAMAccountName,distinguishedName | stats values(admonEventType) AS admonEventType by cn,sAMAccountName,distinguishedName ... View more

A couple things to check, run, in order: Verify admon "Sync" data and index name used in eventtype 1. Run the following search against All Time to verify you are getting admon "admonEventType=Sync" data and what index it is being placed in. index=* sourcetype="ActiveDirectory" admonEventType="Sync" | head 100| fields index | stats count by index 2. If you see data return, then check the returned index against the ms_ad_obj_msad_data eventtype to either verify it is defined correctly or update it if needed. 3. If the index returned from the search was different then try running through the Configuration Dashboards - - > Build AD Lookup Lists - Main dashboard to build the AD_...._LDAP_list lookups. The lookups AD_Computer_LDAP_list/AD_Groups_LDAP_lists are referenced by the XmlWinEventLog:Security sourcetype in the props.conf. They aren't created by default because they use the collected admon data to build them. So if there is no results returned when you run the search | inputlookup AD_Computer_LDAP_list then the admon data either hasn't been indexed or there has not been Any Computer changes that have occurred since installing the MS Windows AD Objects application. (By default any changes get picked up every 15minutes, and the build process mentioned in step 3 rolls up all events Sync/Delete/Changed since the last day the Sync was collected. As far as the AD_Domain_Selector lookup, it uses the admon data to extract the host, DomainNetBIOSName, DomainDNSName, ForestName, Site information. Although I have ran into an issue with another customer where the admon data was not providing the sub-domains correctly values. So if you don't see data in the AD_Domain_Selector after verifying you are getting admon data, then you can try running either of the following Options to put the correct domain values in the AD_Domain_Selector lookup. Update the AD_Domain_Selector lookup: Option I On 1 AD Domain Controller Per Domain, Enable the Splunk_TA_Window's ## Health and Topology Information NT6 [script://.\bin\runpowershell.cmd nt6-health.ps1] or ## Health and Topology Information 2012r2 and 2016 [powershell://AD-Health] inputs, depending on DC OS version. After you start receiving data from the search sourcetype="MSAD:*:Health" | head 1 the use the following search to update the AD_Domain_Selector lookup. source=powershell sourcetype="MSAD:*:Health" | fields host, DomainNetBIOSName,DomainDNSName,ForestName,Site | stats count by host, DomainNetBIOSName,DomainDNSName,ForestName,Site | table host, DomainNetBIOSName,DomainDNSName,ForestName,Site | append [|inputlookup AD_Domain_Selector| table host, DomainNetBIOSName,DomainDNSName,ForestName,Site] | dedup host, DomainNetBIOSName,DomainDNSName,ForestName,Site | eval domain=DomainNetBIOSName | sort ForestName,Site,DomainDNSName,host | outputlookup AD_Domain_Selector Option II - Manually Update the AD_Domain_Selector lookup To manually update the AD_Domain_Selector lookup run the following search, with replacing the your_dc_host and your_domain_value text with the matching value for the AD Domain you are adding. Note: You can run the search multiple times, where you need to add multiple AD domains: | inputlookup AD_Domain_Selector | append [| makelist | eval host="your_dc_host" | eval DomainNetBIOSName="your_domain_value" | eval DomainDNSName="your_domain_value" | eval ForestName="your_domain_value" | eval Site="your_domain_value" ] | stats count by host, DomainNetBIOSName,DomainDNSName,ForestName,Site | eval domain=DomainNetBIOSName | outputlookup AD_Domain_Selector ... View more

Simon, I am working on a major update, with the main part using the kv store, along with other minor fixes/enhancements. I will split off a minor update to include the missing CIM tags as well as the planned minor fixes and Windows TA v5 + support. As far as github, I will place it there and update this answer with a link. Thanks for the feedback, Steve ... View more

It is recommended to deploy the UF, and Splunk TA Windows/AD on each domain controller. Also, with atleast the Windows Security Eventlog input enabled in the Splunk TA Windows. This will ensure you index all the audit events, because some are only collected locally on the authenticating DC. As for the admon ADMonitoring baseline=1 Splunk TA for AD input configuration, you only need to have this on one DC per Domain. Hope this answers your question, let me know if it doesn't. Thanks, Steve ... View more

You have several options for getting GPO details. First, as you mentioned, you can leverage the Splunk App for Windows Infrastructure, that has several dashboards/reports available. This application requires installation the following supporting applications: - Splunk Add-On for Active Directory (Installed on Splunk Search Head and AD DC Splunk Forwarder) - Splunk Add-On for Microsoft DNS (Installed on Splunk Search Head and AD DC Splunk Forwarder) - Splunk Add-On for Microsoft Windows (Installed on Splunk Search Head and AD DC Splunk Forwarder - *With atleast Security Eventlog Data input for GPO changes) - Splunk Support Add-On for Active Directory (Installed on the Splunk Search Head Only) Second option would be to use the MS Windows AD Objects (https://splunkbase.splunk.com/app/3177/) application which has numerous GPO dashboards/reports available. This app requires the following supporting add-ons: - Splunk Add-On for Active Directory (Installed on Splunk Search Head and AD DC Splunk Forwarder) - Splunk Add-On for Microsoft DNS (Installed on Splunk Search Head and AD DC Splunk Forwarder) - Splunk Add-On for Microsoft Windows (Installed on Splunk Search Head and AD DC Splunk Forwarder - With atleast Security Eventlog Data input for GPO changes) **Note:* The MS Windows AD Objects can also be integrated with the Splunk App for Windows Infrastructure app by replacing the Splunk Support Add-On for Active Directory (Remote LDAP Search) with local lookups. Documentation for doing this is located within the MS Windows AD Objects application UI menu. Hope this helps. ... View more

The scheduled search for gpo's was incorrectly disabled in the 2.2 version. I just released a 2.3 version, where this is fixed, if you want to upgrade. Whether you upgrade or not, you will want to either rebuild the lookup using the Build AD Lookup Lists - Main dashboard or by running the AD Hoc - Build searches in the Configuration menu. Also, if you don't want to upgrade then you will need to enable the ms_ad_obj_sched_sync_gpo search. ... View more

First, the ADMonitoring.ini is incorrectly stated in the troubleshooting steps. I had this as the input in version 1.0, and didn't update the steps until the latest release. For troubleshooting, you want to make sure that the only [admon://NearestDC] input specified is in the Splunk AddOn for Microsoft Active Directory. If you enabled the Active Directory input option during the Splunk Forwarder Installation, then remove it from the $SPLUNK_HOME/etc/apps/SplunkUniversalForwarder/local/inputs.conf file. To see the admon://NearestDC input settings, and what directory it is set at, the run the following command from a command line in the bin directory: splunk cmd btool inputs list admon://NearestDC --debug This will show all the settings for the admon://NearestDC. The key pieces that you want to make sure are there are: baseline = 1 disabled = 0 monitorSubtree = 1 ... View more

The admon - Sync data is only collected the first iteration of the admon collection. So if you deploy the Splunk Add-On for Microsoft Active Directory, or previous TA-DomainController-... then the admon collection has already ran once. What you will need to do is remove the .ini file that is checked by the admon job for seeing if it has already ran. Below are the steps for doing this: Note: If you have another data admon data input, then you might want to move the admon://NearestDC and admon.conf settings specified in the deployment steps to *$SPLUNK_HOME/etc/system/local** directory to ensure it takes priority.* Not seeing admon baseline, “Sync”, data Perform the following steps on the Splunk Universal Forwarder on the Domain Controller if you are not seeing results from the following search: - sourcetype=ActiveDirectory admonEventType=Sync 1) On the Domain Controller with the Splunk Universal Forwarder use Windows File Explorer to navigate to the $SPLUNK_HOME\SplunkUniversalForwarder\var\lib\splunk\persistentstorage\ADMon directory. 2) Delete the ADMonitoring.ini file and the NearestDC.ini file if it exists. 3) Restart the SplunkForwarder Service. 4) Rerun the following search from the Splunk UI to verify admon baseline data is being indexed. - sourcetype=ActiveDirectory admonEventType=Sync 5) If you are now seeing data from verification search, then go back to Step 4a and complete the AD Objects Splunk Lookup file building steps in the Build AD Lookup Lists – Main view. ... View more

For the MS Windows AD Objects macros, reports, and Dashboards the index is defined in the ms_ad_obj_msad_data eventtype. There were a few that i unfortunately didn't see still referenced the msad index specifically, which will be updated in the next release to use the ms_ad_obj_msad_data eventtype. Below is the list of searches and dashboards that you will need to update, either by putting in your indexes, or using the ms_ad_obj_msad_data eventtype: Reports that have index=msad specifically in them: AD Objects - Verify Baseline Data – Overall, and AD Objects - Verify Baseline Data – Completed Dashboard that uses index=msad in Drilldown Links: AD Object - Lookup Fields Information To update the eventtype, just navigate to Settings, eventtypes and search for ms_ad_obj_msad. Then update it with your index(s). Example: (index=yourindex1 OR index=yourindex2 OR index=yourindex3) sourcetype=ActiveDirectory I will fix the above Reports and Dashboards in the next release. Hopefully this helps you out. ... View more

New in Splunk 6.x a Universal Forwarder can perform nullqueue filtering for inputs leveraging the INDEXED_EXTRACTIONS setting, which $SPLUNK_HOME/etc/system/default/props.conf enables this attributes for iis, csv, and msexchange as default. You can review the new **structuredparsing** queue information here: http://wiki.splunk.com/Community:HowIndexingWorks So if you add a props.conf/transforms.conf to the Universal Forwarder's $SPLUNK_HOME/etc/system/local directory with the proper filtering then it will be done locally on the Universal Forwarder before sending to the indexer. ... View more

Assuming you are putting your SQL Statement in the DB Connect, Data Input, view, you need to put the WHERE clause in {{}} brackets, and use the DB Connects passed/substituted variables instead of putting the actual fieldnames\/values, like what you have above. Excerpt from documentation link:Splunk DB Connect Documentation To specify a custom query, place the where clause in curly braces {{...}}. The literal $rising_column$ will be replaced with the name specified in the rising column setting. The literal ? will be substituted with the checkpoint value. Example: SELECT * FROM my_table {{WHERE $rising_column$ > ?}} ... View more

After running into the same issue, the sourcetype renaming is probably not occurring because the regular expression used to force the sourcetype was changed from the previous version of the Splunk for Firewall app. Below shows what the previous version had specified in the transforms.conf, and what it was changed to. It was updated FROM: [force_sourcetype_for_cisco_asa] DEST_KEY = MetaData:Sourcetype REGEX = %ASA-\d+-\d+ FORMAT = sourcetype::cisco_asa TO: [force_sourcetype_for_cisco_asa] DEST_KEY = MetaData:Sourcetype #REGEX = %ASA-\d+-\d+ REGEX = %ASA--\d+-\d+ FORMAT = sourcetype::cisco_asa Note the extra - in the Regex. So to change this, just create a transforms.conf in $SPLUNK_HOME/etc/apps/Splunk_CiscoFirewalls/local, if not already there, and update the REGEX string. ... View more