Post by TThe 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.
Post by TAnd 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.
Post by TFive 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?
Post by TPost by VanguardLHDeleting 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
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-take-full-control-of-windows-7-registry-keys
https://www.howtogeek.com/262464/how-to-gain-full-permissions-to-edit-protected-registry-keys/
Those have you pick a Windows account, not a Windows security group.
http://www.askvg.com/guide-how-to-take-ownership-permission-of-a-registry-key-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.
Post by TWhen 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.