Getting Data In

How to test that Splunk has access to UNC input?

gesman
Communicator

We have Splunk on Windows instance that is used to monitor UNC input like \\server123\share4
This worked well until the permissions on share4 were adjusted to tighten security. This caused Splunk to silently lose visibility of files on that share.

We want to re-configure permission to make sure Splunk can see the data, but is there any tool or approach that quickly shows that given Splunk instance can/cannot read data on specified network share?

Alternatively - is it possible to change existing splunk windows installation to run on behalf of different domain/user (instead of local system account)?

Tags (2)
0 Karma
1 Solution

gesman
Communicator

Close to impossible on Windows, but here's a solution. There is no built-in facility in Splunk to test accessability of the given data input and see if Splunk has access to it this moment or not.
To be able to test if Windows' local system account (on behalf of which Splunk is running) has access to UNC location we need to launch CMD (command prompt) running on behalf of local system account.
Please note this is not the same as Administrator.
To launch CMD on behalf of local system account do this:

  • Download pstools from here: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
  • Run .\PSTools\PSEXEC -i -s -d CMD (this will create desired command prompt)
  • Within new CMD window issue: dir \\server123\share4 to test access and visibility
  • Alternatively you may access share via IP address (if you get warning about duplicate resource or so)
  • Alternatively - if that share requires username password do this: net use x: \\server123\share4 PassW0Rd /user:Username
    • and then test accessability via dir X:\

View solution in original post

0 Karma

gesman
Communicator

Close to impossible on Windows, but here's a solution. There is no built-in facility in Splunk to test accessability of the given data input and see if Splunk has access to it this moment or not.
To be able to test if Windows' local system account (on behalf of which Splunk is running) has access to UNC location we need to launch CMD (command prompt) running on behalf of local system account.
Please note this is not the same as Administrator.
To launch CMD on behalf of local system account do this:

  • Download pstools from here: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
  • Run .\PSTools\PSEXEC -i -s -d CMD (this will create desired command prompt)
  • Within new CMD window issue: dir \\server123\share4 to test access and visibility
  • Alternatively you may access share via IP address (if you get warning about duplicate resource or so)
  • Alternatively - if that share requires username password do this: net use x: \\server123\share4 PassW0Rd /user:Username
    • and then test accessability via dir X:\
0 Karma

Richfez
SplunkTrust
SplunkTrust

While it's not a proper answer to the question, reasons like this is why I have converted all but the most ephemeral uses of UNC pathnames for monitor stanzas to the Universal Forwarder.

The UF can then read local files from local disk on the server involved then forward them in. More efficient in several ways, and seems to be far more robust as well. With a Deployment Server set up, it's also just as easy to manage (actually easier if you are reading the same or similar files from multiple hosts).

0 Karma

gesman
Communicator

I agree, but in current setup it is not possible to use UF. The only facility I can manage is share permissions.

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...