Re: How to Stop a Service From Impersonating Other Users

From: Roger Abell [MVP] (mvpNoSpam_at_asu.edu)
Date: 11/25/05 

Date: Fri, 25 Nov 2005 09:25:37 -0700

Will,

Let me add a little, as I may to some minds have overstated things
when I mentioned to you that it did not seem impersonation was
the right term for what you had going on.

When you read the Windows API docs you need to keep in mind
the era during which the different APIs originated. Prior to NT4
about the only way there was for an process to spawn off something
as another account, in the published API, was for a log in to happen.
For example, in the Services Manager you can configure a service
to run as a specific account, and when you do this you provide the
user name and password. When the service is started, the scm
transitions the execution context for that service by doing a log in
to get an appropriate use token and running the service with it.
In this case you will likely find older documentation speaking of
the scm as impersonating the service account that was defined.
In one sense, if a revert to self call can transition back to the System
context, it is sensible to term what had been done as impersonation,
as there are actually two contexts involved. In another sense, it is
a strained use of the term impersonation as it was an actual login
with knowlege of the credentials that happened.
Later, NT4 added a concept of impersonation (and of delegation)
that differed from anything you will find termed impersonation in
early era docs for Windows. This impersonation follows the model
that would surface with Kerberos, and although the delegation vs
impersonation distinction was sketched out at that time (NT4) it
was not until Windows 2000 that delegation (in a true sense) can
to be possible.
So, when I said it did not appear that impersonation is what you
were dealing with, it was from the current era terminology that
I was making this statement. It did not seem that you were seeing
a process get handed a user token which it then used for starting
a next execution in that context (i.e. the account did not need to be
logged in at the time).
"Will" <DELETE_westes@earthbroadcast.com> wrote in message
news:luudnQlfFY6GgRvenZ2dnUVZ_sydnZ2d@giganews.com...
> So mechanically can you spell out the steps by which a service that does
> run
> as SYSTEM could use a user token of a user who has logged into that
> console
> to do a separate login on its own at 3am, when no one is logged into the
> console of the computer?
>
> 1) The service can monitor for interactive logins. That probably gives
> it
> the SID.
>
> 2) The service can request the user token based on the SID as input, and
> now
> it has that information.
>
> 3) Now the service does what with that user token to run in that user's
> security context when no one is logged into the machine?
>
> The Windows NT / 2000 programming APIs contain functions that have the
> word
> 'impersonation' in them. If I am misunderstanding what that word means,
> I
> would ask you to define what Microsoft meant by the word. The behavior I
> am seeing in sniffer and eventviewer logs unquestionably documents that a
> service running as SYSTEM on a specific computer is getting access to the
> Internet at times when no one is logged into the console. It can only do
> that by impersonating the user and assuming their security context,
> because
> our firewall only allows outgoing connections to the Internet from
> specific
> domain-authenticated userids (the firewall is verifying the credentials
> with
> the domain controller independently).
>
> --
> Will
>
>
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:uJYpZOP8FHA.2132@TK2MSFTNGP10.phx.gbl...
>> I believe you are misusing the term "impersonation"
>> To impersonate a different principal what is needed is the
>> user token of that principal usually obtained from a process
>> running in context of that principal. The account that does
>> the impersonation needs to be flagged as trusted to impersonate.
>> System, acting as part of the trusted computing base of the OS
>> is not doing impersonation. It is simply using the name of or
>> sid of the account in order to obtain a user token for that account.
>
>

Relevant Pages

  • Re: Going from anonymous security to Windows Security in an ASP.NET application
    ... as I said in my previous post - there is no context on the client... ... Your page.context exists purely on the server. ... we need to have our own login page instead of the standard Windows logon ... impersonation, which takes place on the server has no effect on page ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: defaultNamingContext property failing in asp.net
    ... thanks for the info Joe. ... anonymous user and when we set impersonation true for the aspx page then it ... > context isn't a domain account, ... > anonymous user in AD and don't have any permissions to see any objects. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: To obtain Web Service security context
    ... > self") and then undoing the impersonation context to start the ... >> need this to do a trusted connection to SQL Server. ... >> The current settings for the ASP.NET app are windows authentication and ... >> be in the context of the current user which I don't want. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: ASP.Net Running Under IIS 6 Application Pool
    ... If impersonation is not enabled, ... What account do you expect to see used instead? ... > context of a specific security account. ... > accesses a value from the registry. ...
    (microsoft.public.dotnet.security)
  • Re: Impersonate a user
    ... How are you doing the redirect? ... Server.Execute on the page while in the context of the impersonated user. ... Once the response goes back to the client, you will lose that impersonation ... > aspx pages to run on this new account (ACL on files is only for this ...
    (microsoft.public.dotnet.framework.aspnet)