Getting logged in user from a service?

[JamesB]

I am writing a service that monitors when a particular app is started.
Works, but I need to get the user who is currently logged in, and of course
Environment.UserName returns the service logon (NT_AUTHORITY\SYSTEM).

I understand that when the service starts, no user may be logged in, but
that's ok, as the app I am monitoring can only be run by a logged in user.
Do I need to use WMI to get the user context of Explorer.exe or is there a
neater way?

James.

 

[Nicholas Paldino [.NET/C# MVP]]

James,

I'm assuming you are using the Process class or something similar? If
so, you can get the handle to the process through the Handle property.

Once you have that, you can call OpenProcessToken (through the P/Invoke
layer) to open the process token for reading. Once you have that, you can
then call the GetTokenInformation function (again through the P/Invoke
layer) to get the SID of the user that began the process.

Finally, you can call the LookupAccountSid API function using the
pointer to the SID to get the domain name, user name, etc, etc.

Make sure you call CloseHandle on the token you get from the call to
GetTokenInformation.

Hope this helps.

 

[Willy Denoyette [MVP]]

I am writing a service that monitors when a particular app is started.
Works, but I need to get the user who is currently logged in, and of
course Environment.UserName returns the service logon
(NT_AUTHORITY\SYSTEM).

I understand that when the service starts, no user may be logged in, but
that's ok, as the app I am monitoring can only be run by a logged in user.
Do I need to use WMI to get the user context of Explorer.exe or is there a
neater way?

James.

The easiest is to use System.Management and WMI's "Win32_ProcessStartTrace"
class.
Here is how:

using System.Management;
using System.Security.Principal;
....
void WatchProcessStart(string procName)
{
WqlEventQuery q = new WqlEventQuery( );
q.EventClassName = "Win32_ProcessStartTrace";
q.Condition = "ProcessName = '" + procName + "'"; // Put the process
name you want to watch for here...
using(ManagementEventWatcher w = new ManagementEventWatcher(q)){
w.EventArrived += new
EventArrivedEventHandler(ProcessStartEventArrived);
w.Start();
// BLOCK this thread, wait for an event to stop the handler and
return...
...
w.Stop();
}
}
static void ProcessStartEventArrived(object sender, EventArrivedEventArgs
e) {
foreach(PropertyData pd in e.NewEvent.Properties) {
string userAccount =
GetUserAccountFromSid(((byte[])e.NewEvent.Properties["Sid"].Value)));
// do something with "userAccount" ..
}
}
static string GetUserAccountFromSid(byte[] sid)
{
SecurityIdentifier si = new SecurityIdentifier(sid, 0);
NTAccount acc = (NTAccount)si.Translate(typeof(NTAccount));
return acc.Value;
}


Willy.

 

[Ben Voigt [C++ MVP]]

I am writing a service that monitors when a particular app is started.
Works, but I need to get the user who is currently logged in, and of
course

You used the phrase "the user", so this is required reading:
http://blogs.msdn.com/oldnewthing/archive/2006/08/22/712677.aspx

Make sure you've thought about the questions Raymond asks, then use one of
the solutions already provided by Willy or Nicholas.

 

[JamesB]

You used the phrase "the user", so this is required reading:
http://blogs.msdn.com/oldnewthing/archive/2006/08/22/712677.aspx

Make sure you've thought about the questions Raymond asks, then use one of
the solutions already provided by Willy or Nicholas.

Valid points - it's actually conceivable that users would be running the
monitored application on a terminal server, so I guess when I said "user" I
am indeed meaning the user who has started the monitored application, not
just whoever is logged in on the console!

 

[JamesB]

James,

I'm assuming you are using the Process class or something similar? If
so, you can get the handle to the process through the Handle property.

Once you have that, you can call OpenProcessToken (through the P/Invoke
layer) to open the process token for reading. Once you have that, you can
then call the GetTokenInformation function (again through the P/Invoke
layer) to get the SID of the user that began the process.

Finally, you can call the LookupAccountSid API function using the
pointer to the SID to get the domain name, user name, etc, etc.

Make sure you call CloseHandle on the token you get from the call to
GetTokenInformation.

Hope this helps.

The "process" I have is Win32_Process (from following another example), so
my code is as below, however my token is always zero.
The "Handle" property on the process object is a string, hence the
conversion to Intptr to pass to the OpenProcessToken command, so perhaps
it's not the same thing?
The process object I have also has GetOwner() and GetOwnerSid() methods,
which would be ideal, however these always seem to return null! The process
object must be correct in a sense though, as the start and stop events where
I pass proc.ProcessID are indeed returning the correct PID as shown in Task
Manager.
James.

private void OnEventArrived(object sender,
System.Management.EventArrivedEventArgs e)
{
try
{
string eventName = e.NewEvent.ClassPath.ClassName;

//Create process obj
WMI.Win32.Process proc = new
WMI.Win32.Process(e.NewEvent["TargetInstance"] as ManagementBaseObject);

//Get handle...
int ph = Convert.ToInt32(proc.Handle);
IntPtr pHandle = new IntPtr(ph);
IntPtr token = IntPtr.Zero;

//get processtoken
try
{
if (OpenProcessToken(pHandle, TOKEN_ACCESS.TOKEN_QUERY,
out token) == 0)
{
//throw new ApplicationException("Can't open process
token for: " + process.ProcessName);
}
CloseHandle(token);
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}

String userAccount = "";

if (eventName.CompareTo("__InstanceCreationEvent")==0)
{
// Started
if (Started!=null)
Started(this, e, (Int16)proc.ProcessId,
userAccount);

}
else if (eventName.CompareTo("__InstanceDeletionEvent")==0)
{
// Terminated
if (Terminated!=null)
Terminated(this, e, (Int16)proc.ProcessId,
userAccount );

}
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}
}

 

[Willy Denoyette [MVP]]

James,

I'm assuming you are using the Process class or something similar? If
so, you can get the handle to the process through the Handle property.

Once you have that, you can call OpenProcessToken (through the
P/Invoke layer) to open the process token for reading. Once you have
that, you can then call the GetTokenInformation function (again through
the P/Invoke layer) to get the SID of the user that began the process.

Finally, you can call the LookupAccountSid API function using the
pointer to the SID to get the domain name, user name, etc, etc.

Make sure you call CloseHandle on the token you get from the call to
GetTokenInformation.

Hope this helps.

The "process" I have is Win32_Process (from following another example), so
my code is as below, however my token is always zero.
The "Handle" property on the process object is a string, hence the
conversion to Intptr to pass to the OpenProcessToken command, so perhaps
it's not the same thing?
The process object I have also has GetOwner() and GetOwnerSid() methods,
which would be ideal, however these always seem to return null! The
process object must be correct in a sense though, as the start and stop
events where I pass proc.ProcessID are indeed returning the correct PID as
shown in Task Manager.
James.

private void OnEventArrived(object sender,
System.Management.EventArrivedEventArgs e)
{
try
{
string eventName = e.NewEvent.ClassPath.ClassName;

//Create process obj
WMI.Win32.Process proc = new
WMI.Win32.Process(e.NewEvent["TargetInstance"] as ManagementBaseObject);

//Get handle...
int ph = Convert.ToInt32(proc.Handle);
IntPtr pHandle = new IntPtr(ph);
IntPtr token = IntPtr.Zero;

//get processtoken
try
{
if (OpenProcessToken(pHandle, TOKEN_ACCESS.TOKEN_QUERY,
out token) == 0)
{
//throw new ApplicationException("Can't open
process token for: " + process.ProcessName);
}
CloseHandle(token);
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}

String userAccount = "";

if (eventName.CompareTo("__InstanceCreationEvent")==0)
{
// Started
if (Started!=null)
Started(this, e, (Int16)proc.ProcessId,
userAccount);

}
else if (eventName.CompareTo("__InstanceDeletionEvent")==0)
{
// Terminated
if (Terminated!=null)
Terminated(this, e, (Int16)proc.ProcessId,
userAccount );

}
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}
}

You should use "Win32_ProcessStartTrace" for this (supposing you are running
XP or higher), take a look at my other reply in this thread for details.

Willy.

 

[JamesB]

You should use "Win32_ProcessStartTrace" for this (supposing you are
running XP or higher), take a look at my other reply in this thread for
details.

Willy.

Your example looked like it would block when the monitored app ran (until it
stopped?) - is that right? Not tried it yet.
Plus, manu users are still on W2k so if the Win32_ProcessStartTrace option
is XP or above, it may not be suitable.
Thanks though!

 

[Willy Denoyette [MVP]]

Your example looked like it would block when the monitored app ran (until
it stopped?) - is that right? Not tried it yet.

Not at all, in the sample I need to block the thread that owns the
ManagementEventWatcher object, this is required to keep the object alive as
long as you need to watch for events. Events from the trace provider keep
arriving on a worker thread from the pool.

Plus, manu users are still on W2k so if the Win32_ProcessStartTrace option
is XP or above, it may not be suitable.

True, but this means that in this case you are "watching" for instance
events on the Win_Process class, this implies polling with the inherent risk
to miss events.

Anyway, when you got the PID of the process, you can get the owner by
calling the "GetOwner" method on the Win32_process class instance.
Here is how...


static string GetOwner(int Pid)
{
string owner = null;
SelectQuery selectQuery = new SelectQuery(String.Format("Select *
from Win32_Process where ProcessId={0}", Pid));
Console.WriteLine(selectQuery.QueryString);
using (ManagementObjectSearcher searcher =
new ManagementObjectSearcher(selectQuery))
{
foreach (ManagementObject proc in searcher.Get())
{
Console.WriteLine(proc["Name"].ToString());
string[] s = new String[2];
proc.InvokeMethod("GetOwner", (object[])s);
if (String.IsNullOrEmpty(s[0]))
owner = "NA";
else
owner = s[1] + "\\" + s[0];
}
}
return owner;
}

However, keep in mind that you wont get anything back if the process has
already terminated at the moment you call this function.
This can happen when short living processes are getting traced.
Willy.

 

[Larry Smith]

Your example looked like it would block when the monitored app ran (until

it stopped?) - is that right? Not tried it yet.
Plus, manu users are still on W2k so if the Win32_ProcessStartTrace option
is XP or above, it may not be suitable.
Thanks though!

Whatever method you choose, you'll still have to factor in what happens if
the service is stopped and then re-started (given that the app you're
monitoring may already be running at this point - or rather this is usually
an issue unless your app is dependent on the service in some way). I don't
know what WMI classes you should rely on off-hand to assist in this area (to
enumerate and locate running processes) since I normally rely on the the
WinAPI itself. In this regard Nicholas' technique is more mainstream (really
the de facto way of doing things) though WMI is normally easier (and worth
considering on those merits though I'd personally stick with the WinAPI
because it is more mainstream).

 

[Willy Denoyette [MVP]]

Whatever method you choose, you'll still have to factor in what happens if
the service is stopped and then re-started (given that the app you're
monitoring may already be running at this point - or rather this is
usually an issue unless your app is dependent on the service in some way).
I don't know what WMI classes you should rely on off-hand to assist in
this area (to enumerate and locate running processes) since I normally
rely on the the WinAPI itself. In this regard Nicholas' technique is more
mainstream (really the de facto way of doing things) though WMI is
normally easier (and worth considering on those merits though I'd
personally stick with the WinAPI because it is more mainstream).

The purpose of the Framework is to virtualize the underlying OS services and
the HW, for instance by providing a layer in top of Win32, so you better
stay away from calling Win32 API's through PInvoke if you can achieve the
same (or better) when using the Framework classes.

That said, when the service restarts, you simply need to query whether the
process is already running using the System.Diagnostics.Process class or the
System.Management classes , get it's PID and pass it to something like the
"GetOwner" (using WMI Win32_Process class) I posted in my previous reply.


Willy.

 

[Larry Smith]

The purpose of the Framework is to virtualize the underlying OS services

and the HW, for instance by providing a layer in top of Win32, so you
better stay away from calling Win32 API's through PInvoke if you can
achieve the same (or better) when using the Framework classes.

That said, when the service restarts, you simply need to query whether the
process is already running using the System.Diagnostics.Process class or
the System.Management classes , get it's PID and pass it to something like
the "GetOwner" (using WMI Win32_Process class) I posted in my previous
reply.

He's dealing with Windows constructs here (services, WMI etc) which either
have no (compatible) analogue outside the Windows world or whose support
and/or availability is questionable (assuming he's even targetting such
environments which is highly unlikely). Pedantic arguments about a virtual
environment therefore don't apply IMO. Arguments about ease-of-use do apply
however so on that we agree. P/Invoke is complicated and error-prone so
should generally be avoided where possible. However, a service is inherently
low-level and shouldn't be relying on .NET in the first place IMO. Even WMI
is questionable here. While supported in .NET, a service should usually be
light-weight with few dependencies. This is much better accomplished by
relying on native OS functionality. Unfortunately, in the real world you
require very experienced (and more expensive) C++/ WinAPI developers to
write and support this. It's not viable in many shops and these types of
developers are also becoming an endangered species (I'm one of them). Your
points are therefore well taken.

 

[Willy Denoyette [MVP]]

He's dealing with Windows constructs here (services, WMI etc) which either
have no (compatible) analogue outside the Windows world or whose support
and/or availability is questionable (assuming he's even targetting such
environments which is highly unlikely). Pedantic arguments about a virtual
environment therefore don't apply IMO. Arguments about ease-of-use do
apply however so on that we agree. P/Invoke is complicated and error-prone
so should generally be avoided where possible. However, a service is
inherently low-level and shouldn't be relying on .NET in the first place
IMO. Even WMI is questionable here. While supported in .NET, a service
should usually be light-weight with few dependencies. This is much better
accomplished by relying on native OS functionality. Unfortunately, in the
real world you require very experienced (and more expensive) C++/ WinAPI
developers to write and support this. It's not viable in many shops and
these types of developers are also becoming an endangered species (I'm one
of them). Your points are therefore well taken.

Sorry, I'm afraid I have to disagree with your statement that a Service as
being low-level and should not rely on .NET, why did MS add Windows Services
support to the FCL if this was true? The days that authoring a Service was
a privilege of C++ are over, however, I agree that not all services should
be implementd using .NET, but the same goes for other kind of applications,
I also agree, that as a result of .NET, way too many applications are now
implemented as a Windows Services, but that's just another discussion.
Now , when I'm talking about "virtualization" I'm actually talking about
hiding details like "Windows OS" flavors and versions, and this is what the
CLR and the .NET Framework is all about. If you are coding directly 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? - What are the security constraints, what
privileges are there required to call these API when running as say "Local
Service"? Can the API access a remote server instance? 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.
Even if you opt to use C++ to implement "low-level" Services, you should
definitely consider WMI for most of it's "management" tasks, and this is
exactly what most of the MS Services do these day's.


Willy.

 

[Ben Voigt [C++ MVP]]

CLR and the .NET Framework is all about. If you are coding directly

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? - What are the security
constraints, what privileges are there required to call these API when
running as say "Local Service"? Can the API access a remote server
instance? 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, that's about it.

 

[Larry Smith]

Sorry, I'm afraid I have to disagree with your statement that a Service as

being low-level and should not rely on .NET, why did MS add Windows
Services support to the FCL if this was true?

That's a specious argument since MSFT is not the final arbiter on what's
good or bad for the programming community. Someone made the call to provide
it but they've provided many things over the years that weren't widely
adopted or necessarily good. In this case it's my judgment that they
provided it simply for ease-of-use. That's a good thing but it doesn't mean
it's the ideal platform for writing a service and IMO it's usually not. A
service is normally low-level by nature since it usually runs under the
System account as a member of the TCB (Trusted Computing Base). Its purpose
is to provide an-going (usually non-interactive) service of some type,
equivalent to a native OS service really. It should therefore have a small
footprint with few dependencies. .NET is a behemoth that doesn't lend itself
well to this. The OS itself does.

I agree that not all services should be implementd using .NET, but the
same goes for other kind of applications, I also agree, that as a result
of .NET, way too many applications are now implemented as a Windows
Services, but that's just another discussion.
Now , when I'm talking about "virtualization" I'm actually talking about
hiding details like "Windows OS" flavors and versions, and this is what
the CLR and the .NET Framework is all about. If you are coding directly
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? - What are the security
constraints, what privileges are there required to call these API when
running as say "Local Service"? Can the API access a remote server
instance? 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.

That sounds good in theory but in practice few services require OS-specific
function calls. The same core APIs that most people rely on to write a
service have been around for many years now. They usually work without issue
from one version of Windows to the next so it's rarely a consideration.
Other issues you mentioned are valid but only to a point. Privileges are
required to perform certain tasks for instance whether you use .NET or not.
If you don't have a required privilege in your token then how will .NET help
here. It will fail unless the .NET security mechanism relies on another
system I'm not familiar with (circumventing the standard Windows security
model). Even if you do have a privilege in your token it may be disabled
(most are by default) in which case it needs to be explicitly enabled to
work (even when running under the System account though most are enabled by
default - this is not the case for most other accounts however including the
administrator account itself)..Does NET do this in any or all cases? I'm not
a .NET expert so I don't know. I do believe you're simplifying the situation
however as .NET is not a panacea. Many of these issues still need to be
considered even though .NET is obviously easier to work with (which is not
in dispute)..

Even if you opt to use C++ to implement "low-level" Services, you should
definitely consider WMI for most of it's "management" tasks, and this is
exactly what most of the MS Services do these day's.

In my (long) experience WMI is not widely used in most organizations. That's
not a judgment call on WMI itself since I have tinkered with it on occasion.
It is an observation however. IMO the real issue is the OS itself. I agree
with the overall sentiment of your arguments but the Windows API is what
really needs to be changed to facilitate a simpler (and version-agnostic)
model. While that may not happen anytime soon since MSFT is probably
frightened to do it (and for good reason), the API is really showing its age
now. I don't believe .NET is always the answer however and sometimes you
just have to rely on the OS directly (or at least it should be strongly
considered for certain tasks like services).

 

[Willy Denoyette [MVP]]

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, that's about it.

No, the system.Management classes (and this is what we are talking about
here) and WMI makes it possible to call OS services without YOU having the
need to run with these elevated privileges.

Willy.

 

[Larry Smith]

No, the system.Management classes (and this is what we are talking about
here) and WMI makes it possible to call OS services without YOU having the
need to run with these elevated privileges.

Can you cite an example since this appears to defy standard Windows security
(if I understand you correctly).

 

[Peter Duniho]

Can you cite an example since this appears to defy standard Windows
security
(if I understand you correctly).

I can't cite an example with respect to WMI, since I haven't used it.
However, Windows services are themselves a broad category of examples of
just what Willy is talking about. The whole point for many services is to
provide a point of access through which users can access
otherwise-sensitive areas of the computer.

The service itself runs at elevated privileges, providing filtered access
to things that no user can with their default privileges access.

As an example: is it a bad thing, in defiance of standard Windows
security, for there to be a SQL Server service that has elevated rights to
access a database, and which delegates those rights (in a controlled way)
to a user that connects to the SQL Server service?

Pete

 

[Willy Denoyette [MVP]]

That's a specious argument since MSFT is not the final arbiter on what's
good or bad for the programming community. Someone made the call to
provide it but they've provided many things over the years that weren't
widely adopted or necessarily good. In this case it's my judgment that
they provided it simply for ease-of-use. That's a good thing but it
doesn't mean it's the ideal platform for writing a service and IMO it's
usually not. A service is normally low-level by nature since it usually
runs under the System account as a member of the TCB (Trusted Computing
Base).

Not at all, services should run with the least priviliges possible (don't
make the same mistake now that MS has made 15 years ago), Services should
run as "Local Service" or "Network Service", running as SYSTEM is considered
a serious security threat.

is to provide an-going (usually non-interactive) service of some type,
equivalent to a native OS service really. It should therefore have a small
footprint with few dependencies. .NET is a behemoth that doesn't lend
itself well to this. The OS itself does.

Let me see, I have a couple of native (MSFT) services running that consume
between 110 and 175MB (dwm.exe) on Vista, these are no .NET services, do you
call these low-level, small footprint, what about Exchange, SQLServer are
these also low-level services? Or do you consider them low-level because
they are written in C++? Or do you consider the CLR and a couple of BCL
libraries too much overhead?
Note that a managed process as a larger base footprint but this is just
overhead because of the runtime, once you add code this overhead gets less
important, especially when you have multiple managed applications loaded
(not necessarely services), because a lot of the code can be shared as of
V2.

That sounds good in theory but in practice few services require
OS-specific function calls. The same core APIs that most people rely on to
write a service have been around for many years now. They usually work
without issue from one version of Windows to the next so it's rarely a
consideration. Other issues you mentioned are valid but only to a point.
Privileges are required to perform certain tasks for instance whether you
use .NET or not.

Not at all, you don't need special privileges because of .NET, you need them
to call some of the WIN32 API's, sure if you run all of your services as
SYSTEM, all of the possible privileges are enabled and this not an issue,
but then you are running in the worse possible environment security wise.
But if you run with the "Least Privileges" enabled, you cannot call every
API you like without enabling the privileges, and here is where the problem
starts, and what forces user applications run as administrator, but again
these day's are gone with Vista and Windows Server2008.

If you don't have a required privilege in your token then how will .NET
help here. It will fail unless the .NET security mechanism relies on
another system I'm not familiar with (circumventing the standard Windows
security model). Even if you do have a privilege in your token it may be
disabled (most are by default) in which case it needs to be explicitly
enabled to work (even when running under the System account though most
are enabled by default - this is not the case for most other accounts
however including the administrator account itself)..Does NET do this in
any or all cases? I'm not a .NET expert so I don't know. I do believe
you're simplifying the situation however as .NET is not a panacea. Many of
these issues still need to be considered even though .NET is obviously
easier to work with (which is not in dispute)..

WMI runs as another service (as Network Service"), all calls from
System.Management (the WMI wrapper) are executed by this service, and this
service takes care about authentication authorization and enabling of
"privileges" required by the WMI method actually requested. Each WIM class
method clearly states (in the metabase) which "privilege" is required to
execute a certain method, WMI enables the privilege by adjusting his token,
all the user user has to do is a simple set the EnablePrivileges property
for the duration of the connection of for the duration of the call. No need
to PInvoke the security API's, which would be necessary when calling the
API4s directly from C# or any other managed language, as the FCL don't
expose most of these API's.

In my (long) experience WMI is not widely used in most organizations.

Note that WMI was included with W2K only, earlier versions of NT based OSses
did not come with WMI installed, now W2K and up come with WMI installed,
Vista and Windows2008 (which adds +200 new classes to the pack) can't live
without WMI and most major services like Exchange, SQLServer need WMI for
management purposes, even the CLR exposes it's counter data through WMI and
Office11 and 12 do use WMI to expose some of it's features and statistics .
Other services and appications (take perfmon) in the system heavely rely on
WMI as well, disable WMI and you kill these services too, stop this service
and the system will restart it automatically

That's

not a judgment call on WMI itself since I have tinkered with it on
occasion. It is an observation however. IMO the real issue is the OS
itself. I agree with the overall sentiment of your arguments but the
Windows API is what really needs to be changed to facilitate a simpler
(and version-agnostic) model. While that may not happen anytime soon since
MSFT is probably frightened to do it (and for good reason), the API is
really showing its age now. I don't believe .NET is always the answer
however and sometimes you just have to rely on the OS directly (or at
least it should be strongly considered for certain tasks like services).

I never said .NET was the solution for all problems in software business,
this is even not the point of this discussion, I believe that it only
accounts for a small but growing portion of the tasks at hand, what's
important is that it enables solutions that were previously too hard (which
in general means too expensive) to implement. It's an enabling technology,
no more no less.
In the company I work for, we have > 80000 PC's managed using SMS and MOM,
and some other management tools that also run in top of WMI, these tools,
built by major companies like IBM and HP, completely rely on WMI.

Willy.

 

[Willy Denoyette [MVP]]

Can you cite an example since this appears to defy standard Windows
security (if I understand you correctly).

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.


Willy.