An interesting registry fix

T wrote:

Hi All,

Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.

One of the machines popped a corrupted key on

[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\ 11.0]

"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).

Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.

RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.

Didn't matter if I was Administrator or not.

So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.

Linux rescues Windows again! It pays to know more than
one operating system.

:-)

-T

chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.

And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.

The problem is usually you are logged into an account that isn't listed
or doesn't have permissions to change the key, even when logged in under
an admin-level account. If propagation isn't enabled on the subkeys,
you cannot change the parent and have it propagate.

Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.

If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
children of the ownership and permission changes, I have to:

1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.

I have to repeat that process (written from memory so there might be
some steps missing) until I can get all the way down from the parent key
through all branches and sub-branches until I reach a leaf (no more
children whether hidden or not). That could take an hour to delete just
one USB enumeration for a device. If the device were ever plugged into
another USB port, repeat it all again for that parent key. All because
I cannot force recursion of changes on the parent into the children.
You can't push or recurse permissions onto subkeys unless the account
you use to change the parent also has permissions for the children.
Using an admin account to take ownership of a key is how you can then
add your account (or the Administrators security group) with full
permissions on the key so you have control over it -- but Microsoft
won't let you force ownership or permissions onto children if your
account isn't already on those children (or the security group your
account is within).

Too bad there isn't something for pushing (recursing) changes made on
the parent onto all its children for registry entries like there is
icacls for changing ACLs on files. Maybe there's a registry tool that
will perform the same steps as I outlined, like you pick a key and it
runs through a script or macro to do those steps to automate having to
inch its way down from parent through branches down to the leaves.
Luckily it is rare that I have to delete USB enumerations plus other
parent keys usually don't have as many branches with so many leaves as
do USB enumerations.

On 06/02/2017 05:10 PM, VanguardLH wrote:
T wrote:

Hi All,

Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.

One of the machines popped a corrupted key on

[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\ 11.0]

"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).

Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.

RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.

Didn't matter if I was Administrator or not.

So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.

Linux rescues Windows again! It pays to know more than
one operating system.

:-)

-T

chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.

And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.

The problem is usually you are logged into an account that isn't listed
or doesn't have permissions to change the key, even when logged in under
an admin-level account. If propagation isn't enabled on the subkeys,
you cannot change the parent and have it propagate.

The key will always show who the owner it. It will not come up blank.

And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.

Five other w7-pro sp1 workstations had no such problem.


Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.

If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
children of the ownership and permission changes, I have to:

1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.

I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.

I have to repeat that process (written from memory so there might be
some steps missing) until I can get all the way down from the parent key
through all branches and sub-branches until I reach a leaf (no more
children whether hidden or not). That could take an hour to delete just
one USB enumeration for a device. If the device were ever plugged into
another USB port, repeat it all again for that parent key. All because
I cannot force recursion of changes on the parent into the children.
You can't push or recurse permissions onto subkeys unless the account
you use to change the parent also has permissions for the children.
Using an admin account to take ownership of a key is how you can then
add your account (or the Administrators security group) with full
permissions on the key so you have control over it -- but Microsoft
won't let you force ownership or permissions onto children if your
account isn't already on those children (or the security group your
account is within).

Too bad there isn't something for pushing (recursing) changes made on
the parent onto all its children for registry entries like there is
icacls for changing ACLs on files. Maybe there's a registry tool that
will perform the same steps as I outlined, like you pick a key and it
runs through a script or macro to do those steps to automate having to
inch its way down from parent through branches down to the leaves.
Luckily it is rare that I have to delete USB enumerations plus other
parent keys usually don't have as many branches with so many leaves as
do USB enumerations.


When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!

T wrote:

The key will always show who the owner it. It will not come up blank.

Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.

In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.

And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.

I gave an example (in deleting USB enumerations) of how difficult it can
be to get the needed permissions to delete a registry key. I don't have
whatever software you installed to have that key and obviously you hid
its path in the registry, anyway.

Five other w7-pro sp1 workstations had no such problem.

Was the software part of a sysprep image, installed on a host while
logged under the Administrator account or another Windows account that
is included under the Administrators security group? You said you tried
to activate the software's license. You did not say you installed that
software.

Was the license used for all installs or did one come out of a different
license pack?

Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.

If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
children of the ownership and permission changes, I have to:

1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.

I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.

Everyone is a security group, not a Windows account. Easy to see by
going to a key, right-click to select Permissions, click on Advanced
button, Permissions tab, click Add button, click Advanced button, and
click the Find Now button. Security groups ha a double bobble-head icon
to represent more than one account may be in that security group.
Windows accounts are represented by a single bobble-head icon.

Normally you don't change permissions of a security group. You assign a
Windows account to the security group whose permissions you want
inherited by that Windows account. However, on a per-key basis, you can
alter the Everyone security group to change that security group's
permissions on that key.

I never try to assign a security group or one of the pseudo ones (e.g.,
Authenticated Users) as the owner. I'm not sure what permissions you
will get. Instead of pick an actual Windows *account* that is in the
Administrators security group.

With a policy editor to look at what privileges each security group has,
I don't know if Everyone has more or less default privileges than Owner.
Seems whichever has the reduced privileges set will be the effected
owner permissions on that key.

Every article I've read about taking ownership has you select a Windows
account, not a security group except maybe for the Administrators
security group *if* your Windows account is in there.

http://www.thewindowsclub.com/how-to...-registry-keys
https://www.howtogeek.com/262464/how...registry-keys/
Those have you pick a Windows account, not a Windows security group.

http://www.askvg.com/guide-how-to-ta...ey-in-windows/
Note this article mentions use the "Replace owner on subcontainers and
objects". That won't work if the subkeys are not configured to inherit
from their parent. However, even if it doesn't work all the way down
the branches to the leaf node, sometimes it will work on some of the
branch keys.

While the dialog lets you pick and assign a security group as the owner,
there is a question of whether you get the lowest common denominator of
permissions between the OWNER RIGHTS pseudo group or that of the
security group. I don't bother taking that unknown and instead assign
my account (which is in the Administrators security group) as owner. If
you're not deleting the key but want to just edit it, probably a good
safety net to record who was the original owner and which accounts or
security groups were listed as with what specific permissions on the key
so you can restore them after you modify owner and permissions to do
your editing.

In my case, I am the only user of that host. If there are multiple user
accounts, not only do you have to be careful which Windows account or
security group to take ownership of a key but you'll have to figure out
which of those need to have permissions and which ones on that key.

When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!

The description of chntpw is to change the NT passwords in the SAM
(Security Account Manager) database. It has to run offline so the
registry isn't protected by an instance of Windows using those registry
files.

https://en.wikipedia.org/wiki/Chntpw
http://www.chntpw.com/

Since its purpose was designed to reset passwords to thwart lockouts,
I'm not sure how accurate it is at assigning the correct permissions,
inheritance, and propation to children of permissions.

If it does alter permissions in the registry files, it seems a
sledgehammer approach and one not specifically geared toward the goal
you mentioned here.

I have to wonder if regedit.exe wouldn't also be usable to bypass all
the permissions in the registry if you imported the registry from
another host. That is, you can right-click on a hive in the currently
loaded instance of Windows and import the same hive from the exported
registry of another host. The only account SIDs (security identifiers)
that are constant across Windows hosts (that I know of) are the system
account and the Administrators security group. Other Windows account
will have a different randomly assigned SID, so the johndoe in one
instance of Windows is not the same johndoe account in another instance
of Windows.

The imported registry will have Windows accounts that do not exist under
the current instance of Windows in which you are using regedit to look
at those imported keys. That means the current instance of Windows
cannot enforce any privileges of the unknown Windows account or security
groups. Because they are unknown, I suspect regedit will let you do
whatever you want on those keys. Maybe that's how chntpw works, too,
since you do NOT run it under the same instance of Windows in which the
accounts and security groups are defined. The registry being edited is
not live in the instance of Windows where you are doing the editing.

I remember exporting a registry on one host, using another host to
import the other host's registry, and then doing just about anything I
want on those quiescent hives (since they are not used by the current
instance of Windows under which you are running regedit). Of course,
you need another Windows host (real or virtual) to do all that so the
imported registry is quiescent.

On 06/03/2017 12:16 AM, VanguardLH wrote:
T wrote:

The key will always show who the owner it. It will not come up blank.

Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.

In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.

And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.

I gave an example (in deleting USB enumerations) of how difficult it can
be to get the needed permissions to delete a registry key. I don't have
whatever software you installed to have that key and obviously you hid
its path in the registry, anyway.

Five other w7-pro sp1 workstations had no such problem.

Was the software part of a sysprep image, installed on a host while
logged under the Administrator account or another Windows account that
is included under the Administrators security group? You said you tried
to activate the software's license. You did not say you installed that
software.

Was the license used for all installs or did one come out of a different
license pack?

Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.

If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
children of the ownership and permission changes, I have to:

1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.

I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.

Everyone is a security group, not a Windows account. Easy to see by
going to a key, right-click to select Permissions, click on Advanced
button, Permissions tab, click Add button, click Advanced button, and
click the Find Now button. Security groups ha a double bobble-head icon
to represent more than one account may be in that security group.
Windows accounts are represented by a single bobble-head icon.

Normally you don't change permissions of a security group. You assign a
Windows account to the security group whose permissions you want
inherited by that Windows account. However, on a per-key basis, you can
alter the Everyone security group to change that security group's
permissions on that key.

I never try to assign a security group or one of the pseudo ones (e.g.,
Authenticated Users) as the owner. I'm not sure what permissions you
will get. Instead of pick an actual Windows *account* that is in the
Administrators security group.

With a policy editor to look at what privileges each security group has,
I don't know if Everyone has more or less default privileges than Owner.
Seems whichever has the reduced privileges set will be the effected
owner permissions on that key.

Every article I've read about taking ownership has you select a Windows
account, not a security group except maybe for the Administrators
security group *if* your Windows account is in there.

http://www.thewindowsclub.com/how-to...-registry-keys
https://www.howtogeek.com/262464/how...registry-keys/
Those have you pick a Windows account, not a Windows security group.

http://www.askvg.com/guide-how-to-ta...ey-in-windows/
Note this article mentions use the "Replace owner on subcontainers and
objects". That won't work if the subkeys are not configured to inherit
from their parent. However, even if it doesn't work all the way down
the branches to the leaf node, sometimes it will work on some of the
branch keys.

While the dialog lets you pick and assign a security group as the owner,
there is a question of whether you get the lowest common denominator of
permissions between the OWNER RIGHTS pseudo group or that of the
security group. I don't bother taking that unknown and instead assign
my account (which is in the Administrators security group) as owner. If
you're not deleting the key but want to just edit it, probably a good
safety net to record who was the original owner and which accounts or
security groups were listed as with what specific permissions on the key
so you can restore them after you modify owner and permissions to do
your editing.

In my case, I am the only user of that host. If there are multiple user
accounts, not only do you have to be careful which Windows account or
security group to take ownership of a key but you'll have to figure out
which of those need to have permissions and which ones on that key.

When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!

The description of chntpw is to change the NT passwords in the SAM
(Security Account Manager) database. It has to run offline so the
registry isn't protected by an instance of Windows using those registry
files.

https://en.wikipedia.org/wiki/Chntpw
http://www.chntpw.com/

Since its purpose was designed to reset passwords to thwart lockouts,
I'm not sure how accurate it is at assigning the correct permissions,
inheritance, and propation to children of permissions.

If it does alter permissions in the registry files, it seems a
sledgehammer approach and one not specifically geared toward the goal
you mentioned here.

I have to wonder if regedit.exe wouldn't also be usable to bypass all
the permissions in the registry if you imported the registry from
another host. That is, you can right-click on a hive in the currently
loaded instance of Windows and import the same hive from the exported
registry of another host. The only account SIDs (security identifiers)
that are constant across Windows hosts (that I know of) are the system
account and the Administrators security group. Other Windows account
will have a different randomly assigned SID, so the johndoe in one
instance of Windows is not the same johndoe account in another instance
of Windows.

Yeah, me too. It did not work this time.


The imported registry will have Windows accounts that do not exist under
the current instance of Windows in which you are using regedit to look
at those imported keys. That means the current instance of Windows
cannot enforce any privileges of the unknown Windows account or security
groups. Because they are unknown, I suspect regedit will let you do
whatever you want on those keys. Maybe that's how chntpw works, too,
since you do NOT run it under the same instance of Windows in which the
accounts and security groups are defined. The registry being edited is
not live in the instance of Windows where you are doing the editing.

I remember exporting a registry on one host, using another host to
import the other host's registry, and then doing just about anything I
want on those quiescent hives (since they are not used by the current
instance of Windows under which you are running regedit). Of course,
you need another Windows host (real or virtual) to do all that so the
imported registry is quiescent.

On 06/03/2017 02:07 AM, T wrote:
On 06/03/2017 12:16 AM, VanguardLH wrote:
T wrote:

The key will always show who the owner it. It will not come up blank.

Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.

In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.

And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.

I gave an example (in deleting USB enumerations) of how difficult it can
be to get the needed permissions to delete a registry key. I don't have
whatever software you installed to have that key and obviously you hid
its path in the registry, anyway.

Five other w7-pro sp1 workstations had no such problem.

Was the software part of a sysprep image, installed on a host while
logged under the Administrator account or another Windows account that
is included under the Administrators security group? You said you tried
to activate the software's license. You did not say you installed that
software.

Was the license used for all installs or did one come out of a different
license pack?

Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security
group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to
refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down
the
tree, one subkey at a time. That's because I cannot propagate
ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.

If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the
dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
children of the ownership and permission changes, I have to:

1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.

I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.

Everyone is a security group, not a Windows account. Easy to see by
going to a key, right-click to select Permissions, click on Advanced
button, Permissions tab, click Add button, click Advanced button, and
click the Find Now button. Security groups ha a double bobble-head icon
to represent more than one account may be in that security group.
Windows accounts are represented by a single bobble-head icon.

Normally you don't change permissions of a security group. You assign a
Windows account to the security group whose permissions you want
inherited by that Windows account. However, on a per-key basis, you can
alter the Everyone security group to change that security group's
permissions on that key.

I never try to assign a security group or one of the pseudo ones (e.g.,
Authenticated Users) as the owner. I'm not sure what permissions you
will get. Instead of pick an actual Windows *account* that is in the
Administrators security group.

With a policy editor to look at what privileges each security group has,
I don't know if Everyone has more or less default privileges than Owner.
Seems whichever has the reduced privileges set will be the effected
owner permissions on that key.

Every article I've read about taking ownership has you select a Windows
account, not a security group except maybe for the Administrators
security group *if* your Windows account is in there.

http://www.thewindowsclub.com/how-to...-registry-keys

https://www.howtogeek.com/262464/how...registry-keys/

Those have you pick a Windows account, not a Windows security group.

http://www.askvg.com/guide-how-to-ta...ey-in-windows/

Note this article mentions use the "Replace owner on subcontainers and
objects". That won't work if the subkeys are not configured to inherit
from their parent. However, even if it doesn't work all the way down
the branches to the leaf node, sometimes it will work on some of the
branch keys.

While the dialog lets you pick and assign a security group as the owner,
there is a question of whether you get the lowest common denominator of
permissions between the OWNER RIGHTS pseudo group or that of the
security group. I don't bother taking that unknown and instead assign
my account (which is in the Administrators security group) as owner. If
you're not deleting the key but want to just edit it, probably a good
safety net to record who was the original owner and which accounts or
security groups were listed as with what specific permissions on the key
so you can restore them after you modify owner and permissions to do
your editing.

In my case, I am the only user of that host. If there are multiple user
accounts, not only do you have to be careful which Windows account or
security group to take ownership of a key but you'll have to figure out
which of those need to have permissions and which ones on that key.

When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!

The description of chntpw is to change the NT passwords in the SAM
(Security Account Manager) database. It has to run offline so the
registry isn't protected by an instance of Windows using those registry
files.

https://en.wikipedia.org/wiki/Chntpw
http://www.chntpw.com/

Since its purpose was designed to reset passwords to thwart lockouts,
I'm not sure how accurate it is at assigning the correct permissions,
inheritance, and propation to children of permissions.

If it does alter permissions in the registry files, it seems a
sledgehammer approach and one not specifically geared toward the goal
you mentioned here.

I have to wonder if regedit.exe wouldn't also be usable to bypass all
the permissions in the registry if you imported the registry from
another host. That is, you can right-click on a hive in the currently
loaded instance of Windows and import the same hive from the exported
registry of another host. The only account SIDs (security identifiers)
that are constant across Windows hosts (that I know of) are the system
account and the Administrators security group. Other Windows account
will have a different randomly assigned SID, so the johndoe in one
instance of Windows is not the same johndoe account in another instance
of Windows.

Yeah, me too. It did not work this time.

RegKeyFixer wouldn't even delete the turkey. That has
always worked before.


The imported registry will have Windows accounts that do not exist under
the current instance of Windows in which you are using regedit to look
at those imported keys. That means the current instance of Windows
cannot enforce any privileges of the unknown Windows account or security
groups. Because they are unknown, I suspect regedit will let you do
whatever you want on those keys. Maybe that's how chntpw works, too,
since you do NOT run it under the same instance of Windows in which the
accounts and security groups are defined. The registry being edited is
not live in the instance of Windows where you are doing the editing.

I remember exporting a registry on one host, using another host to
import the other host's registry, and then doing just about anything I
want on those quiescent hives (since they are not used by the current
instance of Windows under which you are running regedit). Of course,
you need another Windows host (real or virtual) to do all that so the
imported registry is quiescent.

On Fri, 2 Jun 2017 17:49:46 -0700, T wrote:
The key will always show who the owner it. It will not come up
blank.

Not in my experience.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...

On Sat, 3 Jun 2017 02:16:22 -0500, VanguardLH wrote:
T wrote:

The key will always show who the owner it. It will not come up blank.

Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.

In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.


_That_ matches my experience. Very frustrating, because (at least on
the setups I have to deal with) propagation to subkeys fails, so I
have to do a couple dozen, one by one.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...

Stan Brown wrote:

On Sat, 3 Jun 2017 02:16:22 -0500, VanguardLH wrote:
T wrote:

The key will always show who the owner it. It will not come up blank.

Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.

In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.


_That_ matches my experience. Very frustrating, because (at least on
the setups I have to deal with) propagation to subkeys fails, so I
have to do a couple dozen, one by one.

What gets exascerbating is that as you get ownership and add permissions
on each key, a refresh shows you there are most subkeys to work on. The
branches keep growing and magnifying the task. As the hidden branches
get exposed, you have to do the same laborious task on each one while
drilling down to finally reach a leaf and repeat for each newly exposed
leaf just like you have to repeat for each newly exposed branch. You
start to wonder what the hell you got into.

Took me over an hour to delete just 2 USB enumeration keys for the same
printer. I didn't keep track of how many hidden branches and leaves got
exposed as I drilled down taking ownership and adding permissions but
it's always way more than I expect. Plus it's quite boring having to
redo the same actions on every newly exposed branch and leaf.

Maybe one day I'll look into getting AutoHotkey or AutoIt to create a
macro to automate the change on each key. I cannot expose a hidden
branch or leaf until the changes are effected on the parent but hitting
one hotkey per registry key would be a lot easier than manually wading
through the dialogs over and over and over and over and ad nauseum.

On 06/03/2017 06:09 AM, Stan Brown wrote:
On Fri, 2 Jun 2017 17:49:46 -0700, T wrote:
The key will always show who the owner it. It will not come up
blank.

Not in my experience.


99.9% of the time, not my experience either

On 06/03/2017 10:56 AM, VanguardLH wrote:
Took me over an hour to delete just 2 USB enumeration keys for the same
printer.

Hi Vanguard,

"chntpw" with its "rdel" would have aced that
sucker as fast as it took you to press "enter".
Now another tool in your tool box!

And, yes, it always goes through my mind
whether it would be faster to boot into Fedora
or to slug it through in Windows. I guess
wrong often.

-T

On Sat, 3 Jun 2017 12:56:57 -0500, VanguardLH wrote:
Stan Brown wrote:

[quoted text muted]

_That_ matches my experience. Very frustrating, because (at least on
the setups I have to deal with) propagation to subkeys fails, so I
have to do a couple dozen, one by one.

What gets exascerbating is that as you get ownership and add permissions
on each key, a refresh shows you there are most subkeys to work on. The
branches keep growing and magnifying the task.

Yup. It makes sense, if you once grant that Windows' Byzantine
permission system makes sense, and if you also grant that the owner
of a key cannot necessarily propagate permission settings to existing
subkeys of the key. (Both of those seem dubious to me, but they are
what we have to deal with.)

I agree with you: that repeated opening out, increasing the scope of
the job like the death of a thousand cuts, is indeed exasperating.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...