Bulk Modification of Security Permssions on AD Computer Accounts RRS feed

  • Question

  • We need to change the ACL permissions on many computer objects in different OU's in Active Directory. What we need to set is the Allow permissions on "Write DNS host name attribute". However I'm unsure of how to accomplish this task. I think I can use Get-Acl and Set-Acl cndlets but am unsure how I can feed the command a list of computer names and make the change on all of the objects. If anyone has any idea or could provide some guidance it would be greatly appreciated.
    Saturday, February 9, 2019 4:21 PM

All replies

  • This should never be necessary.  A computer objects dnshost property should be writable by default and is set in the objects schema.  The attribute also defaults to "Domain Administrators" allowed.  No one else should have this capability.

    This is also not a scripting issue.  Post in the Directory Services forum to get more information and what you may be trying to do.

    You can also change the value once per OU and propagate to Computer object children.


    Saturday, February 9, 2019 6:28 PM
  • That's incorrect. I've checked both on our new production domain and in my own lab environment and this permission is not set by default. You can modify the default security descriptor for computer objects in the schema to allow this permissions and any new object created from that point going forward will have the permission set, but out of the box the permission is not allowed.

    Also that's incorrect, it's not an inheritable permission so it can't be set from a parent OU. This as an ACL property for "This Object Only".

    I still think there should be a way to script the permissions on multiple objects, thanks for the suggestion though.

    • Edited by llatrel Sunday, February 10, 2019 12:23 AM
    Sunday, February 10, 2019 12:17 AM
  • Because Domain Admins have "Full Control" because the owner of created computer objects is "BUILTIN\Administrators".

    The default SDDL is "O:BAG:BAD:S:"


    If you are having issues then there is something else wrong somewhere in the AD system.


    Sunday, February 10, 2019 12:26 AM
  • Also note that the "Enterprise Admins Group" and the  "Computer Operators Group" should also have "Full Control".  In fact there are a large number of entries in the permissions list  that must be present for correct operation of the system.  These are apparently added by The AD schema extensions.  If Exchange is present then Exchange will also have many entries in the list.

    The schema should have the minimum set by the base schema template.  In the ADSIEdit view of the schema the admin is not present.  System has full control which allows the object creation code under system to set the correct security.

    Post in the Directory Services forum to get help sorting out your issue.  It is not a scripting issue and changing things with a broken AD can result in total chaos.


    Sunday, February 10, 2019 12:43 AM
  • What is required is for the NT AUTHORITY\SELF account to have the Allow permissions to "Write DNS host name attribute". This will allow us to modify the Primary DNS Suffix on the client side and it will update it's own DNS Host Name attribute on it's own AD computer account.

    I'm unsure what you are referring to with Domain Admins, Enterprise Admins Group and Computer Operators Group. The issue is really much more simplified than that and I've tested and proved that this solution works.

    We just need a way to modify the existing 1000+ computer objects in AD to set the described permissions.

    I've seen some postings that point to DSACLS tool to modify AD permissions on objects but I'm unfamiliar with this tool so it will take some time to figure out how to properly utilize this tool. If anyone is familiar and can give some tips it would be greatly appreciated.

    • Edited by llatrel Sunday, February 10, 2019 1:32 AM
    Sunday, February 10, 2019 1:31 AM
  • By default "SELF" has full permissions but it is not evident without looking at the full SD.  There is more than one "SELF" entry but only one specified "FULL CONTROL"

    Again.  You need to post in the DS forum as this is not a scripting issue.


    Sunday, February 10, 2019 1:51 AM
  • Here is one instance of self that grants write to the attribute:

    The direct attribute entry for "Write DNS host name"s never specified anywhere on the newer (WS2008r2 and later) systems. "Validated Write" does what you are looking for.

    Again --- post in DS forum for your issues.


    • Edited by jrv Sunday, February 10, 2019 2:02 AM
    Sunday, February 10, 2019 2:00 AM
  • Trust me, that setting alone does no provide enough permissions for a client to write to it's own DNS Host Name attribute.

    Try changing your Primary DNS Suffix on and workstation and you'll get "The security database on the server does not have a computer account for this workstation trust relationship" error everytime. And it's not because of a broken AD it just doesn't have enough permission to write to it's own attribute.

    Sunday, February 10, 2019 2:41 AM
  • The default domain suffix must match the domain suffix for AD.  The DNSHost setting causes this and cannot be changed by the setting on the client.

    A cannot help you with this.  Please post in the DS forum for assistance.

    To answer directly - all of my domains work correctly.

    If you change the primary DNS suffix to an out of the domain suffix the computer account will never be found.  It will be looking in the wrong place.

    The setting is set by AD when the computer is joined.  The ability to change it only applies to workgroups and ad-hoc connections.


    Sunday, February 10, 2019 2:49 AM
  • Correct they must match and if you modify the write permissions on that security setting it will update it's own attribute in AD. You can name the workstation anything and it will always update it's own attribute to match. I'm telling you this works and we are currently doing in our production domain flawlessly.

    Ultimately what we are trying to accomplish by doing this is to segment workstations in DNS to their own forward lookup zone from all the other critical DNS records by prepending the FQDN with "client". This will force all workstations to register as We only need to do this on several other existing computer objects.

    Sunday, February 10, 2019 3:09 AM
  • Again. Post in DS forum.

    To segment a network consider using Sites and Subnets.  Segmenting on DNS will not likely work correctly with AD even if you can get it to.  For it to work AD has to see the foreign domain you will have to tell AD that it exists and that AD manages it.  Remember domain DNS is managed by AD and not by you.  If AD does not see the foreign domain (forward lookup zone) then it will complain.  I suspect it is possible to add the foreign domain but how to get AD to recognize and manage it is not something I have ever tried to do.  The DS people might have experience with this.  If AD "sees" the domain as its own then it will probably manage it.

    Again. This has nothing to do with scripting so this is not the forum to ask this question in.


    Sunday, February 10, 2019 3:47 AM
  • Thank you for your assistance. I appreciate your help with our issue. I posted a question in the DS forum as you stated to see if we can get additional guidance on this topic.
    Sunday, February 10, 2019 4:07 AM
  • You are welcome.  Sorry I can't give you more help on the core issue. One question comes to mind.  When you created the new forward zone did you create it as AD integrated?  This tells AD that it owns the zone and it adds the subfolders (child items) that allow AD to use the zone.  Without doing this AD cannot recognize the zone and will not allow it to be a primary DNSHost domain.  Look at a current AD zone to see how the extra folders provide AD with needed name resolution for an integrated zone.


    Sunday, February 10, 2019 6:06 AM