Tough question - get your thinking caps on

[Guest]

I need to remotely edit the HKCU\Software\Policies\Microsoft key, in order to
add the Security subkey and the CheckAdminSettings dword value required for
use with Outlook Security Templates.

Unfortunately, this is a "restricted" key, and only the Administrators have
full access. I've tried using SMS Installer to create the entry
progammatically, and have also tried using "regini.exe" from the Resource Kit
to change the ACL on the key prior to performing the edit. The result is
that, apparently due to the need to run with administrator permissions, the
current user key is bypassed and the entry is made in the Default User
context.

Does anyone have a reliable method for getting around this behavior? The
machines targeted are not necessarily single-user machines, so it's not as
simple as just making the users administrators on a temporary basis. I would
also like to avoid having to use multiple reboots to change the ACL on the
key, make the edit, and then restore the ACL on the key.

Thanks for your assistance!

 

[Harry Johnston]

I need to remotely edit the HKCU\Software\Policies\Microsoft key, in order to
add the Security subkey and the CheckAdminSettings dword value required for
use with Outlook Security Templates.

Unfortunately, this is a "restricted" key, and only the Administrators have
full access.

Hmmm. Depends a lot on context - the user's hive won't be loaded unless the
user is logged in, but you need to use administrator privilege to make the
change. Based on what you've said I suspect this isn't a problem in your
circumstances.

Assuming that you are already able to run code as administrator while the user
is logged in, all you should need to do is access the key in question via
HKEY_USERS instead of via HKEY_CURRENT_USER. The latter won't work because the
process isn't running in the user account you want to manipulate.

HKEY_CURRENT_USER is a shortcut to HKEY_USER\{sid} where {sid} is the SID of the
user account. I'm not sure offhand of the best way of finding that out (again,
it depends on the context) but failing all else you could enumerate the subkeys
of HKEY_USER and look in Software\Microsoft\Windows\CurrentVersion\Explorer for
the "Logon User Name" value.

Harry.

 

[Doug Knox - [MS-MVP]]

Assuming that you are already able to run code as administrator while the

user is logged in, all you should need to do is access the key in question
via HKEY_USERS instead of via HKEY_CURRENT_USER. The latter won't work
because the process isn't running in the user account you want to
manipulate.

HKEY_USERS will only show the user hives that are currently loaded/logged
on. And since they're in use, they're locked and unavailable to the Load
Hive function of Regedit, or the Windows API's.

--
Doug Knox, MS-MVP Windows Media Center\Windows Powered Smart
Display\Security
Win 95/98/Me/XP Tweaks and Fixes
http://www.dougknox.com

 

[Harry Johnston]

HKEY_USERS will only show the user hives that are currently
loaded/logged on.

Um, yes, that's what I said.

And since they're in use, they're locked and
unavailable to the Load Hive function of Regedit, or the Windows API's.

If the user is logged on, the hive is already loaded; why would you want to load
it again?

There is nothing preventing a process running in one account from accessing
another account's user hive, provided the other account is logged on and
provided permissions permit; I've done it on a number of occasions.

Harry.

 

[Doug Knox - [MS-MVP]]

I wrote a utility that allows you place GPO restrictions on specific users
in a non-domain computer. It uses the LoadHive API and every time you try
to load a user's hive that is already logged on, it errors out. I believe
the same thing happens in Regedit. If the user is logged on, then you don't
need to load the hive.

If they're not, then you have to load it specifically into the Registry
space and make your modifcations. '

The best thing this user could do is use a logon script to process a VBS or
BAT file that made the changes he wants. This could even be intelligent
enough to determine who the user is and whether or not to apply the changes
based on that.

--
Doug Knox, MS-MVP Windows Media Center\Windows Powered Smart
Display\Security
Win 95/98/Me/XP Tweaks and Fixes
http://www.dougknox.com

 

[Harry Johnston]

I wrote a utility that allows you place GPO restrictions on specific
users in a non-domain computer. It uses the LoadHive API and every time
you try to load a user's hive that is already logged on, it errors out.
I believe the same thing happens in Regedit. If the user is logged on,
then you don't need to load the hive.

Naturally, but if I've understood the original message correctly, the correct
user will already be logged on so it will not be necessary to load the hive.

The best thing this user could do is use a logon script to process a VBS
or BAT file that made the changes he wants. This could even be
intelligent enough to determine who the user is and whether or not to
apply the changes based on that.

A logon script won't do the trick, because logon scripts run in the context of
the logged on user, and Jeff needs the program to run with administrator privilege.

He could use a Winlogon notification package, or a system service that is
triggered by a user program in a logon script. Or if he knows the user is
logged on he could launch the process remotely using psexec or by any number of
similar means.

Harry.