splunkd access to a UNC file that requires username/password ?

[landau351]

Splunk server : Windows XP SP3. Remote servers : Windos XP SP2

I am not permitted to install ANY software on the remote targets such as Splunk forwarders, ssh, ftp etc. Nor can we access the servers via WMI/DCOM. UNC paths is all we are allowed.

The remote files are on different UNC paths (different servers). The remote server files are only accessible with the use several username/passwords. These users don't exist on the Splunk server (different windows domain). I can use NET USE to connect manually providing the user/password on each NET USE command.

I am wondering can I somehow have the set of NET USE commands run before Splunkd starts. This would have to be part of the service environment so that Splunk can access the files.

As alternative I assume I could use scripted input, but that seems to be a waste of network bandwidth if I have to regularly copy the entire file from the remote to the local server.

Is there a way to monitor these remote files via UNC with user/pass?

[ftk]

Unfortunately mounted volumes (with NET USE) are only available to the interactive session, as such the Splunk service will not be able to use it.

You have a few options available to you:

1. Use a scripted input to pull the file local and index. As you noted, not very efficient.
2. Establish a trust relationship between the two domains. Run Splunk as a service account and give that service account read access on your remote share. This can be a one-way trust if need be, with the remote domain trusting the Splunk indexer domain.
3. Create local passwords on the machines with identical user names and passwords. Give the account read access to the share on the remote box, and run Splunk as this same user account. Splunk should now be able to access the share.
4. Use a different machine (that you are allowed to install on) in the receiver domain, and configure it as a forwarder. Have this forwarder index the files you need from your remote server, and have it send the data to your indexer in the other domain. Note that you will have to run this forwarder as an account that has access to the share you want to monitor.

Out of the options available I believe number 4 would be the most elegant and fault tolerant. Number 2 would probably be pretty hard to implement due to security policies and politics, but would be a very solid solution. Number 3 is kind of a crappy hack, and will probably lead to other problems (such as not being able to monitor UNCs in the indexer's domain unless you create the same local accounts there, and you are likely not allowed to create accounts in the first place). Number 1 appears to be the fall back if everything else fails.

I hope this will help you solve your problem. Let me know if you need additional info or some clarification.