Create thread as another user

[Michael Zimmer]

I'am working on a windows service which runs under local system account. Now i need to create a worker thread that should use a network resource (not allowed for lacal system).
Now i thought of starting the worker thread not with PB Create Thread ..., but with API

hThread = CreateThread(SECdesc, 0, CODEPTR(SomeThread), _
BYREF Arg, %THREAD_TERMINATE OR %THREAD_QUERY_INFORMATION, _ BYVAL VARPTR(idThread))

I've read something in MSDN, that the passed security descriptor (here: SECdesc) is not filled (pass: BYVAL 0 instead of SECdesc) a default security descriptor based on the primary token will be created.
I know i can receive a primary token for another user with the LogonUser() API.
My question is: How can i get a security descriptor out of that new primary token?

[John McWilliams]

I'm not sure you can actually do what you want to do, the way you want to do it. Sure would seem like a huge security hole if you could programaticly create a security descriptor at will. Think about the consequenses of that!

A work around though is to not run the service as Local System but in a service account which you create at the box. To access the network resource simply create the same service account on the resource box and give that service account the same password and give that service account rights to the resource. Bit more complex in setup but it certainly works. I've done it.

[Michael Zimmer]

Thanks John.
I've tried this already and it works. Though the service should run with local service account (as requested by my client).

I've looked up at MSDN and found some functions like GetSecurityDescriptorDACL(). Maybe i can use CreateProcessAsUser() and then get the security descriptor from that process.
I'll keep this thread updated.

[Michael Mattias]

This whole thing sounds like a bad idea, but even if you do get it to work, bear in mind there are several PB intrinsic functions which are NOT guaranteed thread-safe if you don't use THREAD CREATE to create additional threads of execution (eg FREEFILE, DIR$)

Based on application description this could cause issues which will not be a whole lot of fun to debug.

[John McWilliams]

Thanks John.
I've tried this already and it works. Though the service should run with local service account (as requested by my client).
.

Then your client has no concept of NT security and it's an unreasonable request. Simply explain that it can't be done that way because the OS refuses to allow those kinds of security holes.

It's a bad idea to do it that way. It opens a bucket load of holes that can be exploited. BAD!

I might also add that no other software on the maket does it that way. None! Zero! Zip! Nada! I wonder why?

[Michael Mattias]

I have forty-six cents says an upcoming 'security update' to Windows will prevent this.

Any takers?

[John McWilliams]

I have forty-six cents says an upcoming 'security update' to Windows will prevent this.

Any takers?

It's already prevented. No patch required. Local System is denied access to network resources.

MZ wants to bypass that. Denial is done for a reason and the ability to create SIDS "on the fly" are denied for a reason. They are huge security holes. If MZ manages to do it I want to know how he did it. Please don't ask. And I will have to tip my hat to him because he's a hell of a lot more clever than I am.

[Roger Garstang]

Not to be redundant, but I confirm that you cannot do what you want to do as the SYSTEM account. It has pretty much full reign of your Local System, but no network. If you run it a different way you can use LogonUser(username, domain, password, %LOGON32_LOGON_NEW_CREDENTIALS, %LOGON32_PROVIDER_WINNT50, TokenHndl) and ImpersonateLoggedOnUser(TokenHndl) at the beginning of your thread function to access network shares.

[John McWilliams]

Here's another option, a server-to-server service. Both services could run as Local System and communicate over TCP/IP with one another (encrypted channel, if the connection was open (internet), no need if it's closed (intranet) unless we're talking DOD or NSA). They could pass "requests" to one another for the data that is needed on the other server. A "worker" thread could gather data for the local service and then the two services could handle the data transfer. Since both services are handling their own communication and both services are acting as Local System there should be no problem. Encrypt the pipe (IPSec + encryption) and you have a very safe way to pass data between the two servers and you don't need to try to trick the intrinsic OS security. But that's a lot more work than what you had planned on.....

As a side note this addreses MCM'sconcern of thread safety. Use the PB intrinsic THREAD functions for the local service

[Michael Zimmer]

Thanks for your suggestions.