SID Conversions for elevated Restricted Users

I'm developing a program that needs Administrative privileges, so I
have added the "Vista manifest" to get UAC to prompt for a password.
So far, so good.

Now the following weird thing happens. When an Administrative user
logs in and confirms by pressing OK, everything goes allright. If, on
the other hand, a Restricted User starts and enters an Admin with
password, the program will kill itself when it tries to get the SID
for the current user.

Ok... This means debugging, and as I don't have Vista I add a bunch of
debug statements that are recorded in a log file, make it optional to
start debugging and let the user run it, so he can give me the debug
log back. One and the same exe, but starting with the debug switch
everything goes ok, and starting without the debug switch kills the
program. Grrrrrrr... Other means of debugging results in the same
effect. Opening a bunch of MessageBox()'es with the debug data instead
of recording to file, forcing debug log generation (the difference
might have been the start-up parameter). It doesn't matter. Debug on,
everything ok. Debug off, tilt...

What is going wrong here? Any ideas?

Thanks.

Maybe this is too obvious, but the basic suggestion is that you get yourself
a Vista box to test on.

What API are you calling to get the SID?

---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Frank Staal" wrote:

> I'm developing a program that needs Administrative privileges, so I
> have added the "Vista manifest" to get UAC to prompt for a password.
> So far, so good.
>
> Now the following weird thing happens. When an Administrative user
> logs in and confirms by pressing OK, everything goes allright. If, on
> the other hand, a Restricted User starts and enters an Admin with
> password, the program will kill itself when it tries to get the SID
> for the current user.
>
> Ok... This means debugging, and as I don't have Vista I add a bunch of
> debug statements that are recorded in a log file, make it optional to
> start debugging and let the user run it, so he can give me the debug
> log back. One and the same exe, but starting with the debug switch
> everything goes ok, and starting without the debug switch kills the
> program. Grrrrrrr... Other means of debugging results in the same
> effect. Opening a bunch of MessageBox()'es with the debug data instead
> of recording to file, forcing debug log generation (the difference
> might have been the start-up parameter). It doesn't matter. Debug on,
> everything ok. Debug off, tilt...
>
> What is going wrong here? Any ideas?
>
> Thanks.
>

"Jesper" <Jesper@discussions.microsoft.com> wrote in message
news:38E195D4-8B4D-41E6-B286-D95F8F2F8C6A@microsoft.com...
> Maybe this is too obvious, but the basic suggestion is that you get
> yourself
> a Vista box to test on.
>
> What API are you calling to get the SID?
>
> ---
> Your question may already be answered in Windows Vista Security:
> http://www.amazon.com/gp/product/047...otectyourwi-20
>
>
> "Frank Staal" wrote:
>
>> I'm developing a program that needs Administrative privileges, so I
>> have added the "Vista manifest" to get UAC to prompt for a password.
>> So far, so good.
>>
>> Now the following weird thing happens. When an Administrative user
>> logs in and confirms by pressing OK, everything goes allright. If, on
>> the other hand, a Restricted User starts and enters an Admin with
>> password, the program will kill itself when it tries to get the SID
>> for the current user.
>>
>> Ok... This means debugging, and as I don't have Vista I add a bunch of
>> debug statements that are recorded in a log file, make it optional to
>> start debugging and let the user run it, so he can give me the debug
>> log back. One and the same exe, but starting with the debug switch
>> everything goes ok, and starting without the debug switch kills the
>> program. Grrrrrrr... Other means of debugging results in the same
>> effect. Opening a bunch of MessageBox()'es with the debug data instead
>> of recording to file, forcing debug log generation (the difference
>> might have been the start-up parameter). It doesn't matter. Debug on,
>> everything ok. Debug off, tilt...
>>
>> What is going wrong here? Any ideas?
>>
>> Thanks.
>>

Maybe this is obvious as well but does your code work on XP? Try it
yourself -- login as restricted user and then use runas to launch your
application without debug switch as an administrator. This is an excellent
method to test applications before making the transition to Vista itself.

As well by "program will kill itself" do you mean your code exits
purposefully or it crashes? If it crashes you can get a crash dump and
really see what is happening on Vista without debug switch.

Sincerely,
Adrian Accinelli

On Wed, 23 May 2007 11:31:00 -0700, Jesper
<Jesper@discussions.microsoft.com> wrote:

>Maybe this is too obvious, but the basic suggestion is that you get yourself
>a Vista box to test on.
Being worked on. Vista is in the mail, but still in transit.
>What API are you calling to get the SID?
LookupAccountName()
> Your question may already be answered in Windows Vista Security:
> http://www.amazon.com/gp/product/047...otectyourwi-20
May be, but not released yet.

On Wed, 23 May 2007 15:29:17 -0400, "Adrian Accinelli"
<hclnospamalias2@newsgroup.nospam> wrote:

>Maybe this is obvious as well but does your code work on XP? Try it
>yourself -- login as restricted user and then use runas to launch your
>application without debug switch as an administrator. This is an excellent
>method to test applications before making the transition to Vista itself.
I'll try this. So far it worked in every situation apart from that one
Restricted User elevation thing in XP. I normally am not running as
Admin and use the program myself as well. So far without any weird
side effects.
>As well by "program will kill itself" do you mean your code exits
>purposefully or it crashes? If it crashes you can get a crash dump and
>really see what is happening on Vista without debug switch.
Nope, all I know from the debug files and the stories dripping back to
me is that it stops function after/during the call the call to
LookupAccountName(). Ergo, something is wrong with the translation
username to SID. As it works under "normal circumstances" I draw the
conclusion that the code in general is okay, but that there is just a
small difference between a Restricted User logging on as Administrator
and an Administrator okay-ing the whole deal. I'll ask about a crash
dump when I get the chance to talk to my Vista testers.

And in the mean time I am waiting for the postman to deliver my own
version of Vista Ultimate so I can do my own testing.

Thanks so far, and I'll let you know once I have more answers.

Frank.

On Thu, 24 May 2007 09:52:36 +0200, Frank Staal
<F.Staal_At_NOSPAM.Hushmail.com@> wrote:

>I'll try this. So far it worked in every situation apart from that one
>Restricted User elevation thing in XP. I normally am not running as
>Admin and use the program myself as well. So far without any weird
>side effects.

Of course I meant the elevation thing in Vista, not XP. My bad...
Nevertheless I've tried it (logged in as a normal user, right click,
Run As..., Administrator equivalent plus password), and no problem. So
far, the conversion from Username to SID goes all right in all
possible ways except for the Restricted User elevated one in Vista.

>And in the mean time I am waiting for the postman to deliver my own
>version of Vista Ultimate so I can do my own testing.

Yay! The delivery man granted me with a visit. Let's see if my VMWare
will let me install Ultimate so I can do my own testing.