Re: Getting logged in user from a service?

Not at all, WMI is client/server based using DCOM, you call a service and
the service executes the service call, when WMI needs to "enable" a
privilege (note that I said 'enable'), it' s up to the caller to ask the
service to enable the required (whatever this one may be)privilege, the
user doesn't need to know the "privilege" required, WMI know which one as
it's stored in it's metabase.
In the exceptional case (there are only a few) that a call requires a
privilege that is not held by the WMI account (say "Network Service"),
then it's up to the caller to run as a more privileged user (or get a
stronger logon token) and ask WMI to impersonate when executing the
service call.

Part of my argument has been in response to these (sometimes) confusiing
comments about security. All WMI would be doing here is enabling privileges
that are already present in the caller's token (not its own). That's what
Ben Voight was referring to in his earlier response. It's a minor
convenience but one that's expected over the native OS since WMI sits on top
of it (providing higher-level services). If you don't have the required
privilege(s) in the first place however then WMI can't help you. Nor should
impersonation be required here since it's not needed. Your earlier comments
such as "... most of these things are taken care of by the framework and
it's underlying services" and " ... WMI makes it possible to call OS
services without YOU having the need to run with these elevated privileges"
are therefore misleading. Security is still an issue that needs to be
considered but you've been implying otherwise. In any case, I can't counter
arguments about ease-of-use in general. Higher-level services are inherently
easier to use by their very nature so it's compelling to champion their use.
They're not always the right tool for the job however. The entire crux of my
argument centers around that and their place in a service in particular. I
find your earlier arguments about monolithic services as self-defeating in
fact since there's no special threshold involved here. Nor is memory
consumption (necessarily) an accurate indicator of just how big these apps
really are (since memory is affected by other things such as the amount of
client data currently being cached). A small footprint is therefore a
relative term. Imagine how much larger and slower those services would be if
they actually relied on .NET instead of C++ and the native OS (which they
most likely do at the core). Do you think MSFT or most organizations would
even consider .NET for most services? Not likely.


.

Relevant Pages

  • Re: Getting logged in user from a service?
    ... the service executes the service call, when WMI needs to "enable" a privilege, it' s up to the caller to ask the service to enable the required privilege, the user doesn't need to know the "privilege" required, WMI know which one as it's stored in it's metabase. ... All WMI's security levels are highly customizable, the namespaces are all protected by DACL's you can adjust, you can prevent certain user to access, read, write, execute etc...it's namespaces, if a user is allowed to execute a method, WMI will simply enable or add the privilege when needed on a per call basis. ... Some classes and methods need an impersonation token from the base client, if the token holds a needed privilege to execute or access a namespace class, WMI enables this privilege, when the token misses the privilege, the call fails. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Getting logged in user from a service?
    ... against the OS services (that is, by directly calling WIN32 Api's) you have to consider a lot of things at "development" time, things like - is the API available on the *target* machine? ... Most of these things are taken care of by the framework and it's underlying services, whatever these are, and in this particular case the underlying service is native WMI in top of Win32. ... I don't see how using .NET Framework exempts you from worrying about security constraints, privileges, etc. ... It might automatically enable a held privilege in your token, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Set previlege with Windows Management
    ... setting EnablePrivilege to "true" should 'enable' all privileges ... required to execute a specific WMI class methods. ... Note that the principal must have been granted the required privilege (see ... PS.Please post System.Management (WMI) related questions to ...
    (microsoft.public.dotnet.general)
  • Re: Set previlege with Windows Management
    ... > required to execute a specific WMI class methods. ... > PS.Please post System.Management related questions to ... >> include the RemoteShutdown privilege when connecting to WMI. ... >> control the shutdown behavior. ...
    (microsoft.public.dotnet.general)