Windows privileges (examples) are assigned to accounts and groups, and by default the "SERVICE" built-in principal has a couple of privileges assigned, such as the "impersonate user" privilege.

I want to create a restricted account for a service that doesn't have this privilege. Can I somehow set a "deny" rule for this privilege, just like one can use with file ACLs? Or do I have to remove "SERVICE" from the list of SeImpersonatePrivilege grantees to achieve this? (something I'd rather avoid if I can, since this can conceivably break other services)

Edited to correct a brain-cloud-induced conflation of two completely unrelated things into one monstrosity of a question.

  • I know this is an old thread OP, but I read something that made me think of this question and you might enjoy it (the accepted answer): serverfault.com/questions/70484/… – Ryan Ries Jan 17 '12 at 19:57
  • @RyanRies Fortunately, unlike forums this place actually welcomes keeping everything in one place, regardless of how old the question is. – RomanSt Feb 28 '12 at 21:23

No, Windows privileges are completely different from file system ACLs.

You use the Windows API to programmatically adjust Windows privileges. There is no GUI. They are binary; the privileges can be added or taken away, but there's no "Deny" mechanism like there is in NTFS ACLs, etc.

For instance, I needed to import advapi32.dll into my code to access the GetTokenInformation() function, which among other things contains the privileges for an account of a given SID.

I'm not sure that I agree with your assertion that the domain\Users group has the SeImpersonatePrivilege by default. That would fly in the face of any attempt at securing a Windows environment.

Check your local security policy and your domain policies, and expand Computer Config -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment and check the "Impersonate a client after authentication" setting. I do not see the Users group listed anywhere.

| improve this answer | |
  • 1
    +1 - I concur re: "I'm not sure ... that the domain\Users group has the SeImpersonatePrivilege by default." They do not. Somebody has munged up the default GPOs in the OP's domain. – Evan Anderson Dec 21 '11 at 22:32
  • @EvanAnderson You guys are right, I wanted to ask about a service! I got confused by a completely separate issue, where the entire drive D:\ was readable by any member of "Users", and hence absolutely every authenticated user, but that was easily fixable with ACLs. Question edited. – RomanSt Dec 22 '11 at 1:39
  • 1
    P.S. "There is no GUI" - I'd certainly call "User Rights Assignment" a GUI, vehemently so after managing permissions on a headless CentOS over SSH. That dialog is as GUI as GUIs get :) – RomanSt Dec 22 '11 at 1:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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