From: nki00 on
> Does it work fine when using CreateWellKnownSid in this case?
>

No, it returns the same result.


> Which SID does it return instead?
> You can use ConvertSidToStringSid and then check the numbers like
> explained at the bottom here:
> http://msdn.microsoft.com/en-us/library/aa379597%28VS.85%29.aspx
>

S-1-5-32-546 in either case.

> And are you trying to run this as an administrator from the guest account?
>

Yes, if I run my process as an admin from a guest account your function
reports it as "not guest". I'm sure the admin part is what messes it up....
Man, I need to read up on those security APIs instead of blindly following
what you write for me :)


From: Leo Davidson on
On Jun 25, 6:06 am, "nki00" <lukkycha...(a)gmail.com> wrote:

> Yes, if I run my process as an admin from a guest account your function
> reports it as "not guest". I'm sure the admin part is what messes it up.....
> Man, I need to read up on those security APIs instead of blindly following
> what you write for me :)

If you run a process as admin, it's running as (the) admin and not as
the guest. It's just sharing the guest's desktop.
From: Jackie on
nki00 wrote:
> S-1-5-32-546 in either case.

So that would be an administrator, also like in their example.

> Yes, if I run my process as an admin from a guest account your function
> reports it as "not guest". I'm sure the admin part is what messes it up....

Yeah, that must be the "problem" like you and Leo say. I would just
assume it is correct behavior.

If you really want to go that far (I have my doubts though), it may not
be impossible to find the current session ID or the interactive desktop
of the logged on user, then somehow find the SID you need from there. I
have used WTSGetActiveConsoleSessionId in a service application to find
the logged on user's session, to aid in finding its interactive desktop
(because services do not have an interactive desktop by default).
But I don't think you really want to do this. I don't think I want to
try this either. Haha.

> Man, I need to read up on those security APIs instead of blindly
following
> what you write for me :)

Haha. I know how it feels to dig into those things when you don't really
need/want to know all that for such a small thing. I think it's like
figuring how to make wheels when you *just* want to drive the car and do
your job.

--
Regards,
Jackie
From: Jackie on
Jackie wrote:
> ... WTSGetActiveConsoleSessionId ...

Right.. I used that one and WTSQueryUserToken to get the user token from
the session ID.
But according to MSDN, the calling application must be running under
LocalSystem and have the SE_TCB_NAME privilege.
So you probably don't want to go this way. At least not use this method
(I don't know about other ones). It's just as I thought, though, so I
didn't need to mention it at all.

Source:
http://msdn.microsoft.com/en-us/library/aa383840%28VS.85%29.aspx

--
Regards,
Jackie
From: Jackie on
nki00 wrote:
> Man, I need to read up on those security APIs instead of blindly following
> what you write for me:)
>

There's of course always the chance that I or anyone else here gives you
false information, so it may be a good idea. I'll try to give you
sources though. :D
I have dealt with similar things before because it has tickled my
curiosity, so I don't know everything. I often need to look something up
on MSDN as well. :)

--
Regards,
Jackie