This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(220.8, 81%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EF%3C/text%3E%3C/svg%3E)
Hi all,
I'm facing an inheritance question about Computer objects in AD.
In an OU, each Computer object does not have same ACL whereas inheritance is set on each object.
So I would to get same rights to all of these AD objects.
First question : why ACL are not the same ?
Second question : how should I do to get consistent ACL ?
Thank you.
Regards,
Hi,
You can reset the permissions using the ADUC security dialog, which is very manual, or you can use the dsacls /resetdefaultDACL command. I'm not aware of any powershell commands that can reset the permissions.
You could use powershell to automate the running of dsacls command, with a list of objects that you want to reset.
Gary.
Hello @Gary Reynolds and thank you for your answer.
I've found some time to go ahead on this topic, and I see something which could be the root cause of this behavior.
On Computer objects with inheritance issue, the owner is an user AD account (a legacy IT admin account) that no more exists in our AD.
First question : why the owner is an IT admin account instead of "Domain Admins" group ?
Second question : how can I set the good owner for all Computer objects ?
Thank you !
Regards,
The owner of the an object will be granted additional permissions, when they access the object, but these are not shown in the ACL of the object and don't affect the inheritance or inherited permissions.
The user is the owner of the object, because they created it or took ownership of the object. In the case of creating the object, the user has been granted rights to create the object but not a member of domain admins. By default in AD, if the user creating an object and is a member of administrators or domain admins, then the ownership of the object is set to domain admins.
To change the ownership of an object to domain admins, Logon or start a command prompt as a domain admin user, then run the following command:
dsacls <objectDN> /takeownership
and the ownership will transfer to domain admins.
Gary.
Thank you @Gary Reynolds ,
You're right, some of these Computer objects have been created by IT Admin who is not member of Domain Admins group.
On our AD, we use delegation for this kind of operations, which is usual in many companies I guess... So I don't want to believe AD objects ownership does not manage this behavior to avoid so dirty ACL !
The command you propose me to run should be run from any workstation with a Domain Admins member account ?
You will need the dsacls tool installed on the machine, but not sure which feature installs it. I'm assuming it will be the AD support tools, or it will be on domain controllers.
Yes delegation is common and normal practice for AD operational and management tasks.
In one of your previous responses you did provided the permissions but not the ou structure, are you able to share more details, so we can understand the issue?
Gary.
The OU structure is :
RootADDomain
-----Company_OU
----------Region_OU
---------------City_OU
--------------------Computers_OU
On RootADDomain, I set grp.HelpDesk.ADComputersManagement to create Computer objects on this object and all included objects.
On Company_OU, I set grp.HelpDesk.ADComputersManagement to read all properties, write "name", write "ms-Msc-AdmPwd" and "ms-Msc-AdmPwdExpirationTime" for LAPS purpose, on all Computer objects included.
My issue is I have different ACL between Computer objects in Computers_OU, and now a delegation issue which turns may AD ACLs dirty.
If you ignore the computer objects for the moment, and look at the ou permissions. If you check that the permissions on each of the OUs and confirm that the permissions are inheriting down the ou structure correctly, the same as the screenshots I shared in my previous response above.
Once confirmed, try creating a new computer object using ADUC in the computer ou and check the permissions have been inherited correctly on the new object.
Gary.
Hi @Gary Reynolds ,
Using NetTools comparison, I can see rights are the same between "Company_OU" and "Computers_OU".
After creating new Computer object in "Computers_OU", I can see rights are inherited from "Computers_OU" and another rights have been added on this Computer object ("Domain Admins", "System" and "Account operators" with "Total control", "Authenticated users" with "Special" and "SELF" with "Create/Delete all child objects", with some others...).
Regards,
Are the rights for grp.HelpDesk.ADComputersManagemen group inherited correctly on the new computer object?
Screenshots of the inherited permissions would be helpful.
Gary.
If you can check one of the computer objects that has the permissions issue, does it show any OU in the inherited from column? If not, then the block inheritance has been set on the object, you can clear this be clicking on the Enable Inheritance button on the security dialog.
You can see which objects has blocked inheritance set on the object using NetTools - ACL Browser, the blue exclamation mark on the object as shown below.
Gary.
Group "grp.HelpDesk.ADComputersManagement" is correctly inherited from parent OUs on Computer objects with issue.
Inheritance is well activated on both Computer object and OU.
But on this Computer object I can see some rights which should not be there :
These permissions have been set specifically on the object, if the other permissions from the parent OUs have been inherited correctly, then permissions are working correctly. These are legacy permissions that have been set on the objects previously and the fact that they are shown as Unknown Account means that the specified account has been deleted.
Gary.
I'm not agree with you : this unknown account is a former IT admin account which was set on parent OU, not specifically on the impacted Computer objects.
This account has been deleted from parent OU but not deleted on child Computer objects whereas inheritance is activated.
This is what I'm pointing on this thread.
If you think the issue is a result of inheritance, rather than directly assigned permissions, you could try using the Restore Default button, to reset the permissions and see if the unknown account permissions are still applied.
Gary.
OK, but when I click on Restore default button, all inherited permissions are removed.
So I've not applied this action because I'm not sure about these inherited permissions will come back after validation.
Can you confirm me this will be the case please ?
When you click the restore defaults button only the object's default schema permissions are shown, when you click apply button the inherited permissions will be applied. You can test this on the new computer object you created.
Gary
You're right, inherited permissions are correctly applied. So I've set default permission to an affected Computer object.
I'll be able to have feed back from the HelpDesk team tomorrow.
Thank you for your time.
Hello @Gary Reynolds ,
Nice to say you all is right this morning ! Thank you for that !
Next, how can I do the same for all Computer objects in an OU, i.e. restore defaults to all these objects ?
OK, thank you again for your help !
Have a good day.
