OpenProcessToken access denied

[Brian]

Here's my problem:

I'm trying to get the users of a running process on a
Win2k server for a monitoring application. Basically,
there are about 40-50 of this process (mkas.exe) running
on the server at any given time. Each one runs under the
domain account of the client computer. I can verify this
by using Sysinternals Process Explorer.

The problem is, when I try to get the user by using
OpenProcessToken, I get error 127 - Access Denied. This
only seems to happen on the mkas.exe process. The
application looks up the users of a process just fine
when the process's user isn't a domain account (ie - it's
running under a local account).

So my question is, what's going on? I know it can't be
the permissions on the server's logged-in account, since
the Sysinternals Process Explorer can bring up the users
just fine. What could it be doing that I'm not?

Thanks in advance,
Brian

[Jeffrey Hamblin]

Brian,

This could be caused by several things.
First, what access are you requesting in your call to OpenProcessToken? If
you only want to query the TokenUser then you only need TOKEN_QUERY.
Second, are you able to open the process for PROCESS_QUERY_INFORMATION?
That is required to get at the process token.

mkas.exe might be putting a stricter DACL on its process token or the
process object itself.

I don't know for certain what Process Explorer is doing. Perhaps it is
using the TakeOwnership privilege to get access to the object (requesting
WRITE_OWNER, changing the DACL to grant itself access, then changing it
back) after the normal access check fails. If you are admin then you have
this privilege in your token by default.

You will have to look at the security descriptors on the process and its
token to be certain. HTH,

Jeff

"Brian" <anon...@discussions.microsoft.com> wrote in message
news:00f901c3b9ca$a9131bc0$a401...@phx.gbl...

[Brian]

Jeff (and anyone else who wants to help!),

Here's a little more background on what I'm doing.

The application is actually written in C#, and I'm using
p/inkoke calls to do the process manipulation. Initially,
I was using the
System.Diagnostics.Process.GetProcessesByName() call to
get the handles to the processes. Then, I would pass the
handle of each to OpenProcessToken using TOKEN_QUERY.
Then I would call GetTokenInformation with TOKEN_USER,
and finally, LookupAccountSid. I was getting access
denied on the call to GetTokenInformation.

So, I tried another route and replaced the call to
GetTokenInformation with GetSecurityInfo - passing the
process handle and SE_KERNEL_OBJECT as the parameter. At
this point, it was working somewhat, but it was returning
the group name Administrators for any user running the
process being monitored who is an admin on the domain,
plus it wasn't returning the correct user name all the
time. The real problem though was that the .NET call to
GetProcessesByName was taking 7 minutes to complete! This
only happened on the server I need to run this on. It
wasn't happening on my development machine (another thing
to point out is that on my development machine, I can't
test the same processes that run on the production
server, so I'm testing it on processes that are run
locally, not ones that are run from a remote domain
account).

So, I said the hell with it, and replaced the .NET call
to GetProcessesByName with native calls to
CreateToolhelp32Snapshot, Process32First, Process32Next,
and OpenProcess. At this point, I tried passing
PROCESS_QUERY_INFORMATION to OpenProcess (using my
development machine), but then got Access Denied on the
call to GetSecurityInfo. So I replaced that with
PROCESS_ALL_ACCESS and it then worked perfectly(?!). Lo
and behold though, when I put it on the server, I get
access denied on the call to OpenProcess.

I will say though that the calls to actually GET the
processes using CreateToolhelp32Snapshot, etc...
succeeded in a fraction of a second (as the .NET call
SHOULD have), so at least I've gotten over one hurdle.

I've never even delved into all window's security
functions before, so things are pretty confusing at this
point but I'm starting to piece things together. When
you're talking about WRITE_OWNER, what function call is
that for? Also, from reading up a little on things, one
thing I'm confused about is that if I take ownership of a
process, won't that effectively ruin what I'm trying to
do (get the true owner of the process)? Also, what
function calls give me access to the security descriptors
of a process?

Thanks!

-Brian

>.
>

[Brian]

Well, I figured things out, so I'm posting the solution
for anybody that's interested.

Basically, I had to try to call OpenProcess with
STANDARD_RIGHTS_READ, and if it failed, I needed to open
my OWN process token, call AdjustTokenPrivileges
and grant myself the SE_DEBUG_NAME privilege, then call
OpenProcess again and it would succeed. After getting the
process handle, I called AdjustTokenPrivileges on my own
process again and revoked the privilege so that my rights
went back to normal.

-Brian

>.
>

[Jeffrey Hamblin]

Brian, we should try to figure out what the security descriptors on the
process and the token look like. With a handle to the process, or a handle
to the token, you can call GetKernelObjectSecurity (request
DACL_SECURITY_INFORMATION | OWNER_SECURITY_INFORMATION).

If you are unable to OpenProcessToken for TOKEN_QUERY, then what you should
try is to overwrite the owner on the token's SD with your Sid. Then you
will be able to open the token object and look at the SD. You can do set
the owner by enabling TakeOwnershipPrivilege and then calling
SetKernelObjectSecurity.

When GetSecurityInfo failed, what type of information were you requesting?

"Brian" <anon...@discussions.microsoft.com> wrote in message

news:0bf501c3bb35$e89fe680$a401...@phx.gbl...

[Pavel Lebedinsky]

Can you use WTSEnumerateProcesses instead? (on win2k it
requires terminal services to be installed)

The most likely reason you can't open the token is that
(as Jeffery said) the security descriptors don't allow you to.

The easiest way to dump security descriptors for the process
and token objects is to run pview.exe from the System logon
session (unlike administrators, System is typically granted access
to all process tokens).

First you launch cmd as System using the 'at /interactive' trick.
Do something like

c:\> at 0:00 /interactive cmd.exe

then go to Scheduled Tasks, right-click the task and select Run.
This will launch cmd window running as System on the interactive
desktop.

Then you can run pview.exe from this cmd window (there's two
utilities with this name, the one you want has 'Process Explode'
window title, and I think it comes from reskit).