From: nki00 on 25 Jun 2010 01:06 > 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 25 Jun 2010 03:48 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 25 Jun 2010 08:07 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 25 Jun 2010 08:13 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 25 Jun 2010 08:30
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 |