Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Currently I have a windows service written in C# (running as LocalSystem) which creates a user account, needed for impersonation, by using the DirectoryEntry to add the user/password and associated UserFlags. Then it simply uses this account to perform some tasks (using impersonation) using the LogonUser() functionality - works perfectly.

However this account should ONLY be used for impersonation by my service, a user should NEVER be able to login (even if he has the credentials) locally or via the network.

To accomplish this I tried setting the Local Policies for “Deny logon locally” and “Deny access to this computer from the network” and added the user my service creates. Now however impersonation fails with the following: Logon failure: the user has not been granted the requested logon type at this computer (1385)

So, I guess this is NOT the right way to do it … but I need to secure lockdown the account so it can only be used by my service for impersonation purposes and to ensure that no one else can ever logon to the account (even if they have all the credentials).

Is there something in LSA I can use? Or using the DirectoryEntry code similar to when the account was created? Is there a way to allow for an account to exist but not allow users to interactively logon?

Any help would be much appreciated. Thanks,

share|improve this question
    
That is the right way to do it, unfortunately your service doesn't like that. –  joeqwerty Mar 29 '11 at 20:33
    
Correct me if I am misunderstanding but if you are calling LogonUser are you not, in fact, logging on? I thought impersonation was designed to use credentials without using logonuser. Wouldn't it be simpler to just run the service as the user, skip the impersonation and then deny logon locally? –  Jim B Mar 29 '11 at 22:07

1 Answer 1

I'd suggest breaking out Process Monitor from sysinternals and finding out what file,registry,network access the impersonation requires. Then working backwards to find the minimal user rights assignment in local policy that you can deny or simply remove access to. I've used it many times in troubleshooting security issues on web servers accessing sandlots, datafiles, temp directories what-have-ya.

-Gft

share|improve this answer
    
But there is no easy way to ensure the user just can't logon at all? –  Shaitan00 Mar 29 '11 at 20:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.