Re: Adding a Privilege via LsaAddAccountRights()
From: Rob Jones (robjones_at_lightspeedsystems.com)
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
>> 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
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.