Re: Adding a Privilege via LsaAddAccountRights()

From: Rob Jones (robjones_at_lightspeedsystems.com)
Date: 06/10/04

  • Next message: DeepT: "Detecting a file origin" 
    Date: Thu, 10 Jun 2004 08:05:22 -0700

    On Wed, 9 Jun 2004 14:09:09 -0700, "Pavel Lebedinsky" <m_pll ./.
    hotmail ./. com> wrote:

    >"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.
    >
    On a Win2K Server with SP3 and older, this is true. Once you install
    SP4 and the machine is a domain controller, there will be NO accounts
    granted this privilege. Also, on a domain controller, local security
    policy is not applicapble to the ASPNET account, as this account is no
    longer considered a local account, but rather a domain-based account.

    >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.
    >
    Which is what I want to do programmatically instead of forcing the
    admin who is installing our software to do this manually.

    >> 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.
    >
    This is worth looking into. However, I'm concerned that even if this
    is successful (meaning I'm able to grab a token for the ASPNET user
    instead of the impersonated account) I won't be able to enable the
    SeImpersonatePrivilege because it hasn't been 'enabled' yet. Would
    that not be the case - that you cannot grant a privilege to a token if
    the privilege is not enabled yet?

    >> 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.
    >
    Refer to my original post - that's exactly what I'm doing, and it does
    not work until the SeImpersonatePrivilege has been set (via the Domain
    Controller Policy snapin) to 'enabled'. Once that's done,
    LsaAddAccountRights() works just fine.

    >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.
    >
    This is probably what I'm going to have to do. I believe that I can
    create a policy template that has this privilege 'enabled', use
    secedit to apply it, and then use my utility to add the privilege to
    the ASPNET account.

    Thanks for your reply, Pavel.

    rob

  • Next message: DeepT: "Detecting a file origin"

    Relevant Pages

    • 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)
    • 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: 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: 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)