LAPS and permission to join computer to domain

Some you may have noticed that some users may be able to read local admin passwords on some computers without being delegated permission to do so by LAPS administrators. If you’re asking how is it possible, read further.

Creation of computer account

Let’s first explain, how ACL on new AD object is created: 

• Domain controller finds appropriate class in AD schema
• DC creates instance of AD object based appropriate schema class in AD container chosen by user
• During creation DC saves relevant inheritable ACEs from ACL of parent container into ACL of newly created object as inherited permissions
• Then DC takes value of „defaultSecurityDescriptor“ attribute of appropriate AD schema class and saves it to ACL of newly created object as non-inherited ACEs
• So ACEs in ACLs of newly created objects come from 2 sources: from parent container and from AD schema class definition.

Then, remember that when computer objects are created via DSA.msc console, wizard asks user to specify security principal who will be allowed to join computer to domain. When this principal is specified, then prior adding non-inherited ACEs (from defaultSecurityDescriptor) to ACL of created object, wizard replaces CREATOR OWNER SID in all ACEs by SID of security principal chosen for being able to join computer to domain – so effectively, joiner of computer to domain receives all permissions for CREATOR OWNER as they were defined on computer class in AD schema.

Content of defaultSecurityDescriptor on computer class in schema looks like this (taken from 2012R2 schema; in older versions may vary):

"D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPCRLCLORCSDDT;;;CO)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;CO)(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(A;;CCDC;;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;RPWP;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;CO)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;CO)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)"

Let’s see, what’s defined in it for CREATOR OWNER. We use simple PowerShell script:

$defaultSD="D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPCRLCLORCSDDT;;;CO)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;CO)(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(A;;CCDC;;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;RPWP;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;CO)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;CO)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)"

$sec=New-Object System.DirectoryServices.ActiveDirectorySecurity

$sec.SetSecurityDescriptorSddlForm($defaultSD)

$acc=New-Object System.Security.Principal.NTAccount("CREATOR OWNER")

$sec.GetAccessRules($true,$false,[System.Security.Principal.NTAccount]) | Where-Object {$_.IdentityReference -eq $acc}

Script gives the list of ACEs for CREATOR OWNER; one of them is as shown below:

ActiveDirectoryRights : DeleteTree, ExtendedRight, Delete, GenericRead

InheritanceType       : None

ObjectType            : 00000000-0000-0000-0000-000000000000

InheritedObjectType   : 00000000-0000-0000-0000-000000000000

ObjectFlags           : None

AccessControlType     : Allow

IdentityReference     : CREATOR OWNER

IsInherited           : False

InheritanceFlags      : None

PropagationFlags      : None

See highlighted ExtendedRight above: this access right gives the permission to read confidential attributes!

So this explains why some users may read LAPS passwords without being granted permission to do so – they were given the permission to join computer object(s) to domain, and can read the password on computers they joined!

So best practice: Join computers to domain using dedicated service account, use automated tools, such as SCCM OSD rather than allowing users to join computers to domain themselves – you are protecting your confidential attributes in AD.

Going further

Some of you may ask the same question I asked: Is the ExtendedRight permission really necessary for ability to join computers to domain? Let’s test:

• Change defaultSecurityDescriptor to remove ExtendedRight from CREATOR OWNER:
  • Change (A;;RPCRLCLORCSDDT;;;CO) to(A;;RPLCLORCSDDT;;;CO)
• Create new computer object, specifying some test user as joiner
• Let joiner join computer to domain. Will he succeed? Yes! This means that missing ExtendedRight permission does not impact the ability to join computer to domain
• Install LAPS CSE on joined computer and let CSE upload admin password to AD
• Let joiner to use LAPS UI or PowerShell to see if he can read password of local admin for newly joined computer. Will he succeed? No! this means that removal of ExtendedRight permission from defaultSecurityDescriptor on computer class in AD schema prevents security principals delegated to join computers to domain from reading confidential attributes on newly created computer objects (but not on already existing objects)

Reason why the ExtendedRight is there is not very well documented – maybe guys from AD development team will know better.

So you may consider changing defaultSecurityDescriptor appropriately. However, as always: test changes thoroughly, review your processes for any dependencies, and be ready to revert to original state.

UPDATE 9.8.2016

Even with the measures above that limit ExtendedRight permission assignment to account that creates computer account in domain, creator of the account becomes OWNER of computer account, which gives permission to modify ACL on computer account and elevate permissions.

In Windows 2008 and higher version of DC, this can be prevented by usage of Owner Rights, as described in this TechNet article.

So if you care about security of password stored by LAPS in Active Directory, proper usage of Owner Rights prevents computer object creators modify ACL and elevate permissions.

Credit goes to Tiernan Messmer for pointg out.

Jiri

• Anonymous
  April 06, 2016
  The comment has been removed
• Anonymous
  April 15, 2016
  Please disregard the latter 2 paragraphs of my previous comment here. I didn't realize that changing the defaultSecurityDescriptor for the object would be so easy to do! However, I do still hope that the AD development team will reconsider why the CREATOR OWNER needs "All extended rights" on all new computer accounts for the Server 2016 AD schema update.
• Anonymous
  January 26, 2017
  The comment has been removed
  • Anonymous
    February 01, 2017
    I had a look at the shipping schema definitions for 2016 and the default security descriptor for the computer objectClass hasn't changed between 2012R2 and 2016.Combined Active Directory Schema Classes and Attributes for Windows Serverhttps://www.microsoft.com/en-us/download/details.aspx?id=23782