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

Comments (4)

  1. EdgeDC says:

    Hi Jiri - thank you for this blog post... it definitely confirms the recent unexpected behavior of LAPS in my environment - namely that certain unauthorized users are able to retrieve LAPS passwords when they were not supposed to. The root cause is definitely as you indicated - the "All extended rights" permission is granted to whoever is given the ability to join a computer account to the domain at the time of creation.

    Unfortunately, your suggested "best practice" to limit this ability to only dedicated service account is impractical in many organizations. There are many cases where troubleshooting a computer that has fallen off the domain (such as a laptop that was off network for more than 30 days, invalidating its computer account password) needs to be manually put into workgroup mode then rejoined to the domain to make it an active participant again. The same computer cannot simply be reimaged with SCCM OSD (and the dedicated service account), as the computer likely contains user data that must be recovered. While I fully agree that allowing regular end users to join computers to the domain is not a good solution, IT staff, the very people asked to troubleshoot computer problems, often need this right (without being a full-blown Domain Admin).

    It seems to me that if the ExtendedRight permission is not needed to join a computer to the domain (as demonstrated by both your testing and my own), then I don’t know why Microsoft hasn’t issued a corrective fix for the AD schema. Even if it does not rise to the level of importance to issue an independent fix, perhaps this can be addressed as part of the Server 2016 AD schema update?

    If that is impractical (have you spoken with the AD development team about this yet?), then perhaps a schema modification script could be bundled with LAPS, or at the very least step-by-step instructions provided on how to properly (and safely) make the change in the defaultSecurityDescriptor?

    To be honest - I consider this issue a glaring hole in LAPS security. It's not the fault of the product itself, but it is seriously affected never-the-less. I'm hoping you or your colleagues can provide some additional insight on getting this corrected in the AD Schema - especially with a sanctioned modification script *or* even as part of the pending Server 2016 schema update.

  2. EdgeDC says:

    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.

  3. JoshuaALuke says:

    Is this still valid for 2016 schema? The defaultSecurityDescriptor looks quite different as you indicated it may, however, after trying to remove the CR from the default (A;;LCRPDTLOCRSDRC;;;CO), we get the following ADSIEdit error:

    Operation failed. Error code: 0x20a2
    The security descriptor is invalid.

    000020A2: SvcErr: DSID-03171C98, problem 5003
    (WILL_NOT_PERFORM), data 1336

    1. 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 Server
      https://www.microsoft.com/en-us/download/details.aspx?id=23782

Skip to main content