Re: Adding a Privilege via LsaAddAccountRights()

From: Pavel Lebedinsky (m_pll)
Date: 06/09/04

  • Next message: Tory Eneboe: "Re: problem signing CMC request with Enrollment Agent certificate" 
    Date: Wed, 9 Jun 2004 14:09:09 -0700

    "Rob Jones" wrote:

    > On a fresh Win2K Server with SP4 that is a Domain Controller, a new
    > privilege (SeImpersonatePrivilege) appears in the Domain Controller
    > Security snapin. This privilege was introduced with SP4. By default,
    > no account is granted this privilege - in fact, when you view this
    > privilege in the snapin, it appears as 'Not defined'.

    By default, SeImpersonatePrivilege is defined in the Local
    Security Policy and it should be granted to SERVICE and
    Administrators. You can add ASPNET account there as well.

    You can also override this by defining the right in the DC
    security policy (if you do this make sure to include SERVICE
    and Administrators).

    > If I run my
    > utility program that attempts to enable this privilege for the ASPNET
    > account, nothing happens. Running secedit, rebooting - nothing
    > happens. However, if I simply define this privilege BEFORE running my
    > utility program, rebooting (or running secedit) will now show that the
    > ASPNET account has this privilege.

    This is how it's supposed to work. Privileges have to be granted
    in the security policy first, and then they can be enabled.

    > As far as examining the token goes, I don't think that is possible, as
    > the ASPNET account never actually 'logs on' as a user.

    If your worker process runs as ASPNET then obviously there has
    to be a token for ASPNET attached to this process. This token is
    created by IIS/ASP.NET when the worker process is started by
    calling LogonUser API (or its equivalent).

    You can examine this token in debugger (using !token in windbg)
    or with a tool like pview (you'll probably need to run debugger or
    pview from the system logon session (using at.exe /interactive)
    to make this work).

    > And even if
    > the account is 'logged on', my website server code runs under
    > impersonation (assuming the credentials of the user account that
    > connects to my server) and so I could not grab a token for the ASPNET
    > account. When my code is running, the token is for the impersonated
    > account and NOT for ASPNET.

    You can always call RevertToSelf() or
    WindowsImpersonationContext.Undo to revert to the process identity.

    > What I'm looking for is a programmatic method of changing this new
    > privilege from 'Not defined' to 'defined' so that my utility program
    > can successfully enable this privilege.

    You should be able to use LsaAddAccountRights to change the local
    security policy.

    If you want to define this right in group policy (DC, domain or OU)
    then I don't think there's an API for that. But you can probably
    write a script to do that using secedit /configure /areas USER_RIGHTS.

  • Next message: Tory Eneboe: "Re: problem signing CMC request with Enrollment Agent certificate"

    Relevant Pages

    • Re: ASP.NET Impersonation / delegation
      ... If your security guys will not even allow delegation, ... Bruce - I think this is a major right to grant to the ASPNet account. ... I have included a description on SE_TCB_NAME privilege from one of the MS ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: Adding a Privilege via LsaAddAccountRights()
      ... >> Security snapin. ... This privilege was introduced with SP4. ... You can add ASPNET account there as well. ...
      (microsoft.public.platformsdk.security)
    • Re: ASP.NET Impersonation / delegation
      ... there will not be any security risk? ... The MS documention does not recommend SE_TCB_NAME privilege to a any account other than the default LocalSystem. ... Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned. ... best alternative for impersonating an account that is specially created for ...
      (microsoft.public.win2000.developer)
    • Re: Event ID 577 Every few seconds
      ... You see this because you are auditing privilege use. ... This privilege, which is normal for an admin account, ... Security) ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Installation error, do not have rights to install update
      ... security updates released in July 2004. ... This privilege identifies its holder ... I downloaded the patch from the KB article and> tried to install that way and got an error that stated I do not have the> rights to install this update. ... > that is the account I was using. ...
      (microsoft.public.windowsupdate)