Remote registry request access denied

[Guest DreamU]

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

[Guest Mr. Arnold]

"DreamU" <guest@unknown-email.com> wrote in message

news:1a2541f33b42dd3948311e89643722e0@nntp-gateway.com...<span style="color:blue">

>

> 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.</span>

<span style="color:blue">

> FYI Remote registry service is running and the registry key

> ...securepipeserverswinreg has granted permission to the non-Admin

> account.

></span>

 

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.

[Guest DreamU]

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

[Guest Paul MontDenturesDropped]

DreamU wrote:<span style="color:blue">

> 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 CurrentControlSetServices 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.

>

></span>

 

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>

[Guest DreamU]

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

[Guest Mr. Arnold]

"DreamU" <guest@unknown-email.com> wrote in message

news:b8aaab5665b9c7ab06c01fe17fd33931@nntp-gateway.com...<span style="color:blue">

>

> 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)

>

></span>

 

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

area.

 

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

[Guest DreamU]

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

[Guest Mr. Arnold]

"DreamU" <guest@unknown-email.com> wrote in message

news:d04270a73bb9f6ca1fb3f662dae0a11b@nntp-gateway.com...<span style="color:blue">

>

> 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.

></span>

 

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

[Guest Mr. Arnold]

"DreamU" <guest@unknown-email.com> wrote in message

news:d04270a73bb9f6ca1fb3f662dae0a11b@nntp-gateway.com...<span style="color:blue">

>

> 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.

></span>

 

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

 

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