Remote registry request access denied

I have a program that requests performance counter information from a
remote Vista machine. In its simplest form it is just a single line of
Visual Basic code:

PerformanceCounterCategory.Exists("Memory", remotemachinename)

If I run as an admin (admin accounts on both machines) everything is
fine. But if i run as a standard account (non-Admin on both machines) I
get an access denied error on "openHKPD". That is the hidden registry
hive HKEY_PERFORMANCE_DATA. Anyone have ideas about why a standard
account would fail? It does not fail if I run the request locally on the
machine so the standard account has sufficient permission.

If I run from Vista to a remote XP machine I do not get this error so I
am thinking it may have something to do with registry virtualization on
Vista. Or it may have something to do with UAC except these are
non-Admin accounts so UAC should not matter.

FYI Remote registry service is running and the registry key
....\securepipeservers\winreg has granted permission to the non-Admin
account.


--
DreamU

"DreamU" <guest@unknown-email.com> wrote in message
news:1a2541f33b42dd3948311e89643722e0@nntp-gateway.com...
>
> I have a program that requests performance counter information from a
> remote Vista machine. In its simplest form it is just a single line of
> Visual Basic code:
>
> PerformanceCounterCategory.Exists("Memory", remotemachinename)
>
> If I run as an admin (admin accounts on both machines) everything is
> fine. But if i run as a standard account (non-Admin on both machines) I
> get an access denied error on "openHKPD". That is the hidden registry
> hive HKEY_PERFORMANCE_DATA. Anyone have ideas about why a standard
> account would fail? It does not fail if I run the request locally on the
> machine so the standard account has sufficient permission.
>
> If I run from Vista to a remote XP machine I do not get this error so I
> am thinking it may have something to do with registry virtualization on
> Vista. Or it may have something to do with UAC except these are
> non-Admin accounts so UAC should not matter.

> FYI Remote registry service is running and the registry key
> ...\securepipeservers\winreg has granted permission to the non-Admin
> account.
>

What it really comes down to is that the user-id for the Standard user
account in not on the registry with proper access rights or it's not there
period on the remote machine, as opposed to the Administrators group is on
the registry entry when you are using an admin account. It's *access denied*
for the Standard user and its user-id.

Let me elaborate on my earlier comment: when I say the command works
when I run it locally that means I log in as that standard user with the
exact same username and password (which exists on both the remote
machine and the host). So, it does exist and because it runs fine
locally there are no registry access issues with the standard user.

Now, even though it runs fine locally I did something a little crazy to
try and troubleshoot: I specifically gave the standard user full control
permission on CurrentControlSet\Services which is where the performance
pointers are stored. So that local user was basically made equivalent
to an Admin even though it already ran fine locally.

I think the issue is with remote HKPD access and becuase it is hidden I
don't know how to grant permission. Secondly, there is something odd
about Vista which is clearly applying a different rule/permission when
run remotely as opposed to locally.


--
DreamU

DreamU wrote:
> Let me elaborate on my earlier comment: when I say the command works
> when I run it locally that means I log in as that standard user with the
> exact same username and password (which exists on both the remote
> machine and the host). So, it does exist and because it runs fine
> locally there are no registry access issues with the standard user.
>
> Now, even though it runs fine locally I did something a little crazy to
> try and troubleshoot: I specifically gave the standard user full control
> permission on CurrentControlSet\Services which is where the performance
> pointers are stored. So that local user was basically made equivalent
> to an Admin even though it already ran fine locally.
>
> I think the issue is with remote HKPD access and becuase it is hidden I
> don't know how to grant permission. Secondly, there is something odd
> about Vista which is clearly applying a different rule/permission when
> run remotely as opposed to locally.
>
>

It makes sense to me that a Standard user cannot access the registry of
a remote machine, Vista is not XP. I guess that kind of access is denied
on Vista. You can look-up more information about this.

<http://www.vistax64.com/vista-account-administration/98216-when-standard-users-access-vista-registry-remotely-access-denied.html>

Thanks for the link but that information is just plain wrong.
Specifically, it says "A standard user cannot connect to the registry of
a remote PC." This is not true, as a standard user on XP I can connect
to a remote Vista and read every key I have tried. Now, I can't modify
the remote registry but I certainly can connect. (P.S. This is through
Regedit/Connect Network Registry)


--
DreamU

"DreamU" <guest@unknown-email.com> wrote in message
news:b8aaab5665b9c7ab06c01fe17fd33931@nntp-gateway.com...
>
> Thanks for the link but that information is just plain wrong.
> Specifically, it says "A standard user cannot connect to the registry of
> a remote PC." This is not true, as a standard user on XP I can connect
> to a remote Vista and read every key I have tried. Now, I can't modify
> the remote registry but I certainly can connect. (P.S. This is through
> Regedit/Connect Network Registry)
>
>

Maybe your attempt to access as Standard user is being redirected to another
area.

http://technet.microsoft.com/en-us/m.../cc160882.aspx

Thanks for the link on Registry Virtualization. Ironically,
virtualization allows standard user writes to occur where they used to
fail under XP. So, my standard user would have more capability! I know I
questioned virtualization in my initial thread but it is really a long
shot. No only becuase it provides more power but also becuase I don't
write to any registry keys in my program so I don't need the extended
capability.


--
DreamU

"DreamU" <guest@unknown-email.com> wrote in message
news:d04270a73bb9f6ca1fb3f662dae0a11b@nntp-gateway.com...
>
> Thanks for the link on Registry Virtualization. Ironically,
> virtualization allows standard user writes to occur where they used to
> fail under XP. So, my standard user would have more capability! I know I
> questioned virtualization in my initial thread but it is really a long
> shot. No only becuase it provides more power but also becuase I don't
> write to any registry keys in my program so I don't need the extended
> capability.
>

Well, you had better take a long look at what you're doing, because as it
stands now, you have not found a solution that's going to allow you to come
around *access denied*, unless you have admin privileges with that VB
program.

This is just some FYI.

http://www.developer.com/net/net/article.php/3695651
<http://channel9.msdn.com/posts/jmazner/How-To-Tell-Vistas-UAC-What-Privelege-Level-Your-App-Requires/>

good luck

"DreamU" <guest@unknown-email.com> wrote in message
news:d04270a73bb9f6ca1fb3f662dae0a11b@nntp-gateway.com...
>
> Thanks for the link on Registry Virtualization. Ironically,
> virtualization allows standard user writes to occur where they used to
> fail under XP. So, my standard user would have more capability! I know I
> questioned virtualization in my initial thread but it is really a long
> shot. No only becuase it provides more power but also becuase I don't
> write to any registry keys in my program so I don't need the extended
> capability.
>

Here is one other thing for you about Vista and UAC.

http://technet.microsoft.com/en-us/m.../cc138019.aspx