locked
Create Computer Account in one OU then move to another with an unprivileged account RRS feed

  • Question

  • Here is my basic challenge:

    I need to create a computer account in a temporary OU, work in-side the computer, then move the computer to a different OU.  After that, reboot the computer to pick up Group Policy changes.

    I need to do this with a powershell script that runs under an unprivileged account (i.e. not in Domain Admins, call it UnAdmin).

    My UnAdmin has been granted full access to the two OU's and has no problem creating the computer account with New-ADComputer.

    New-ADComputer -Name 'NewComputer' -SamAccountName 'NewComputer' -Path 'OU=TempFolder,DC=contoso,DC=com' -Credential $unAdminCredential
    

    and then inside the NewComputer, 

    Add-Computer -DomainName 'contoso.com' -Confirm:$false -Force -Credential $unAdminCredential

    Here is the challenge:

    If UnAdmin tries to move the computer to the permanent OU, the Move-ADObject cmdlet takes an Access is Denied error.

    $newServer = Get-ADComputer 'NewComputer'
    $ouPath = 'OU=PermanentFolder,DC=contoso,DC=com'
    Move-ADObject -Identity $newServer -TargetPath $ouPath -Credential $unAdminCredential
    

    I set up failure auditing on changes to my AD and found that the Move-ADObject cmdlet is trying to change the Common_Name property of the computer object.  When UnAdmin created the computer account, it was granted some privileges to change properties, but the WriteAllProperties was not added, neither was the Write Common-Name Property.  To make things challenging, the Write Owner privilege was also not granted.

    I set out to use Get-Acl and Set-Acl to update the privileges and add Write Common Name Property access, but Set-Acl wants the Write-Owner privilege and fails with Access is Denied.  In the file system, you can use GetAccessControl('Access') to skirt this, but and ADObject does not have this member.

    $unAdminUser = Get-ADUser "UnAdmin"
    $acl = Get-Acl "AD:\CN=NewComputer,OU=TempFolder,DC=contoso,DC=com"
    $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($unAdminUser.SID, 'WriteProperty', 'Allow')
    $acl.SetAccessRule($ace)
    Set-Acl "AD:\CN=NewComputer,OU=TempFolder,DC=contoso,DC=com" $acl
    

    I have also tried to use [ADSI] object's psbase.ObjectSecurity.SetAccessRule and CommitChanges, but the CommitChanges also needs WRITE-OWNER (or at least fails in event viewer requesting WRITE-OWNER).

    So, for this security conundrum, my scripting question is: "Is there a way to write an ACE, or update an existing ACE to allow write to the Common-Name without trying to update the Owner?" or "Is there a way to move a computer object from one OU to another without additional privilege?"

    Any assistance is appreciated.

    Thursday, March 9, 2017 9:18 PM

Answers

  • I modified the OU privileges to create an ACE on the TempFolder OU for descendant computer objects.  In this rule I granted the Write Public Information privilege to UnAdmin.  Now, when a computer account is created in the TempFolder OU, UnAdmin will be granted the Write Public Information privilege by default.  This does not answer the original question about setting an ACL on an AD object without changing the owner, and I would still be interested in an answer to that question.  However it does allow the computer to be moved to its permanent home.
    Thursday, March 9, 2017 11:36 PM

All replies

  • Account must have privileges on both OUs.  Both add and delete must be granted.  Permissions are set on the OU and not the computer object. The creating account is already the Owner.


    \_(ツ)_/


    • Edited by jrv Thursday, March 9, 2017 9:31 PM
    Thursday, March 9, 2017 9:30 PM
  • And it does.  The failure is not with the OU's and not related to create or delete.  The failure is Write-Property and the GUID suggests that it is the Common-Name property that it is trying to write.
    Thursday, March 9, 2017 9:31 PM
  • Then the add computer account to OU is not set for the UnAdmin account.  None of this has anything to do with the computer account settings.


    \_(ツ)_/

    Thursday, March 9, 2017 9:33 PM
  • If only it were that easy...  The problem is trying to write Common-Name on the computer object.  Here is the error from the Security Log:

    Object:
    Object Server: DS
    Object Type: computer
    Object Name: CN=NewComputer,OU=TempFOlder,DC=contoso,DC=com
    Handle ID: 0x0

    Operation:
    Operation Type: Object Access
    Accesses: Write Property

    Access Mask: 0x20
    Properties: ---
    {e48d0154-bcf8-11d1-8702-00c04fb96050}
    {bf96793f-0de6-11d0-a285-00aa003049e2}
    {bf967a0e-0de6-11d0-a285-00aa003049e2}
    {bf967a86-0de6-11d0-a285-00aa003049e2}

    It is clear that the object that failed is a computer object and not an OU.  If you look up the 2nd GUID, I believe you will find that it refers to the Common-Name property.

    Thursday, March 9, 2017 9:53 PM
  • To change the name of a computer object you need to use Rename-Computer. 


    \_(ツ)_/

    Thursday, March 9, 2017 9:57 PM
  • I appreciate your comments, but perhaps it is time for you to drop off and let someone who can read and understand the question answer.
    Thursday, March 9, 2017 9:59 PM
  • Without a sample of the code and the exact complete error message no one will be able to be of much help.


    \_(ツ)_/

    Thursday, March 9, 2017 10:04 PM
  • I can suggest that you post in Directory Services forum for help in how to set up AD OUs to allow moving of objects.


    \_(ツ)_/

    Thursday, March 9, 2017 10:06 PM
  • While it is clear that you believe you know what you are talking about, your ignorance comes through all too loud and clear.  If I go to the computer object in AD by hand and enable the Write Public Information privilege, then the Move-ADObject cmdlet works.  This has nothing to do with OU privileges.  
    Thursday, March 9, 2017 10:17 PM
  • If you correctly delegate the permissions in AD to the group that will gain these privileges and select Full Control of the selected computer objects then that capability will be granted to the group.

    If the public write is not set and you are trying to change a property that is public then it may fail.  I would suggest that something is altering the computer object or that the settings on the OU have been altered in some way.

    The CN of an object is not writable by normal means.  It can only be changed via a rename so it is curious that you are seeing that on a move.

    I will admit that some schema changes caused by management tools can alter this behavior and the management tool will need to be used to make your changes.

    Again - the Directory Services forum would be the best place as this is a product specific issue.


    \_(ツ)_/

    Thursday, March 9, 2017 10:25 PM
  • I modified the OU privileges to create an ACE on the TempFolder OU for descendant computer objects.  In this rule I granted the Write Public Information privilege to UnAdmin.  Now, when a computer account is created in the TempFolder OU, UnAdmin will be granted the Write Public Information privilege by default.  This does not answer the original question about setting an ACL on an AD object without changing the owner, and I would still be interested in an answer to that question.  However it does allow the computer to be moved to its permanent home.
    Thursday, March 9, 2017 11:36 PM