How to restrict Account Operators to see the password in LAPS

The “Local Administrator Password Solution” (LAPS) is a free solution provided by Microsoft to manage local account passwords of domain-joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset. You can read How to deploy the LAPS by SCCM – Part 1 to learn how to deploy it.

The ms-Mcs-AdmPwd extended attribute is where the password stored on the computer object. By default, Domain Admins and Enterprise Admins can see the password of computer objects as they have full control over all objects. You can also check the rights by the PowerShell cmdlet.

Find-AdmPwdExtendedrights -identity <OU name> | Format-Table

However, there is another builtin group that can see the password, Account Operators. According to the Microsoft document, the “Account Operators” group has full control of computer objects, which will also grant sufficient permissions to read the local Administrator password. In a delegated administration environment where the Account Operators are meant to be used for Domain User Accounts only and no or little permissions should be granted to computers, you may need to review changing or even removing this ACE from the schema default.

To restrict the ability to view the password to the Account Operators, I need to remove “All extended rights” from permissions. This is required because the All Extended rights permission gives permission to read confidential attributes.

Modify Schema

To modify the schema, you will need to be in the Schema Admins security group, and log in to the Domain Controller that has the Schema Master role. You can run the following command to find the Schema Master.

Get-ADForest yourdomain | select SchemaMaster

Open MMC and add the Active Directory Schema Snap-in.

Find the Computer Class and go to the Properties. Click the Advanced for special permissions.

Find the Account Operators and click Edit.

Uncheck the “All extended rights” box and click Ok to all windows.

Update permissions on existing objects

Now, the new computer objects should have the default permission that Account Operators don’t have the permission for All extended rights. You can create a new computer object and verify the permissions.

However, the schema change does not apply to existing computer objects. The ACE will need to be reset to default on the existing objects. This can be done by click “Restore default” or a PowerShell script.

To reset all computers in an OU, I create the following script with the function Oscar provided. Please change the value of $OU to yours.

# Reset to default permission on all objects in an OU

Function Reset-VirotADPermissions
{
<#
.SYNOPSIS
Reset AD Object permissions

.DESCRIPTION
Resets a single AD Objects permissions to the default permissions.

.PARAMETER DistinguishedName
Distinguishedname of the object to be reset

.EXAMPLE
Reset-VirotADPermissions -DistinguishedName 'CN=Administrator,CN=Users,DC=virot,DC=eu'

.LINK
Script center: https://gallery.technet.microsoft.com/scriptcenter/Reset-AD-Object-permissions-d71d9169
My Blog: http://virot.eu
Blog Entry: http://virot.eu/reverting-the-adminsdholders-changes

.NOTES
Author:	Oscar Virot - [email protected]
Filename: Reset-VirotADPermissions.ps1
#>
  [CmdletBinding()]
  param
  (
    [Parameter(Mandatory=$true)]
    [String]
    $DistinguishedName
  )
  Begin
  {
    Try
    {
      if ((Get-Module ActiveDirectory) -eq $Null)
      {
        Import-Module ActiveDirectory
      }
    }
    Catch
    {
      Throw 'Failed to load ActiveDirectory module'
    }
#Build up hashtable of default securities.
    $defaultSecurityDescriptor = @{}
    $rootDSE = Get-ADRootDSE
    ForEach ($Class in (Get-ADObject -SearchBase $RootDSE.schemaNamingContext -ldapFilter '(&(Objectclass=classSchema)(defaultSecurityDescriptor=*))' -Properties defaultSecurityDescriptor))
    {
      $defaultSecurityDescriptor[$class.Name] = $Class.defaultSecurityDescriptor
    }
  }
  Process
  {
    Try
    {
#Fetch object
      $Object = Get-ADObject -ErrorAction Stop -Identity $DistinguishedName
#Check if Objectclass has a default permissions
      if ($defaultSecurityDescriptor[$Object.ObjectClass])
      {
#Create the $CorrectACL for the objecttype
  	    $CorrectACL = New-Object System.DirectoryServices.ActiveDirectorySecurity
        $CorrectACL.SetSecurityDescriptorSddlForm($defaultSecurityDescriptor[$Object.ObjectClass])
      }
      else
      {
#If no default permissions exist for ObjectClass just exit.
        Exit
      }
#Reset the object with the correct ACL
      Set-ADObject -Identity $DistinguishedName -Replace @{'ntsecuritydescriptor'=$CorrectACL} -Verbose
    }
    catch [Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException]
    {
      Throw "Unable to find the adobject: $DistinguishedName"
    }
    catch [Microsoft.ActiveDirectory.Management.ADException]
    {
      Throw "Unable to update the adobject: $DistinguishedName"
    }
    Catch
    {
      Throw "Unknown error: $($_.Exception)"
    }
  }
}

# Change the OU below
$OU = "OU=Servers,DC=wu,DC=local"
$allobjs = Get-ADComputer -Filter * -SearchBase $OU

foreach($obj in $allobjs)
{
    $dn = $obj.DistinguishedName
    Reset-VirotADPermissions -DistinguishedName $dn
}

Disclaimer: The sample scripts are provided AS IS without warranty of any kind.