Running a script in another user context

[kholleran]

Hello,

My splunk server belongs to a different domain with a trust set up. I have a python script that does some Active Directory stuff and I want to feed that into Splunk. It runs great when I run the script but then I realized that as a scripted input, it is using the system account which is not on my domain. I am trying to specify the other domain in the script instead of the domain the user is running under but it is being difficult so I was wondering if there is there a way to run a scripted input in another user context?

Thanks.

Kevin

[bwooden · Accepted solution]

In the old days, you could do something like...

runas /user:<user>@<domain> /savecred calc.exe

...you would be challenged for a password. After entering it once, you could do this again:

runas /user:<user>@<domain> /savecred calc.exe

...and calculator would be started as <user>.

If that is still true, you may be able to substitute calc.exe with your script and use that as your scripted input.

[jrodman]

Splunk doesn't have a built-in way to launch a script in another user context. I think generally the operating system's security model isn't going to provide any possible way for the "local system" user to transparently launch a process as a domain user. Maybe it's possible by drastically relaxing a lot of security guarantees -- I'm no windows expert -- but I wouldn't recommend that.

Here are some options:

• Run splunk as a domain user with the right permissions. (Problem, this can be problematic with an indexer, since now all its files are owned differently. Fixing this can be as simple as changing ownership on all the files, and changing the user that the splunk services run as, but backups are appropriate for such experiments.)
• Run your script externally to splunk, and write to log files that splunk tails. This has some nice properties of decoupling your code from splunk so it's easier to inspect, debug, etc. It also makes it much easier for you to always get complete data and never get duplicates. It has the additional burden of ensuring your code is running. Python's logger framework is a handy way to create the files.

[gkanapathy]

Apparently Python has a win32security module out there that works similarly and may be built on top of this.

[gkanapathy]

There are non-.NET ways to do this too, but I'm pretty sure I can't explain them. The .NET WindowsIdentity.Impersonate() call is no picnic either, but not too bad.

[gkanapathy]

There is a .NET api (WindowsIdentity.Impersonate) that lets a process to switch Security Context to run as another user, if they have the credentials of the "other" user. However, they must also have the OS/Windows Local Security Right to do so. I think the name of the right was "Impersonate another user", but it also might have been "Act as part of the Operating System", or maybe both. The ASP.NET account has these rights and is able to do this, bu I am not sure that "LocalSystem" can do this. You may need to create a real local or domain account to be able to assign the right(s).

[jrodman]

Sure, but Local System isn't a domain user.

[kholleran]

On point 2, you are basically saying write my output to a file of some sort, then have Splunk index that file?

Thanks for your suggestions. I wouldn't think that it would be very good security if I COULD do it the way I wanted.... there is a trust in place between domains so maybe that's not why the scripted input is failing... (though the script runs fine when not launched by Splunk...)