Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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

It has been my experience that local logon and impersonation are the same permission (log on locally) and can't be separated. i.e. Right clicking a program and doing "Run as different user" is the same as logging on directly as the user and running the program.

It is possible to grant an account the ability to run as a service separately from the local logon permission however and you may find that rather than running the service with localsystem you can run it with the user account. The service and user account could be created through localsystem by means of PSExec or other tools/methods.

Ultimately I think the way you're trying to accomplish your goal is not possible and you'll need to do a design change. Best of luck, please let me know if you find a way to prove me wrong. I would love to force certain admin accounts to only work through a 'run as'.

share|improve this answer

Is this program running on a domain? If so you could possibly create a service account to do what you need.

share|improve this answer

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.