AD DB size

• Password: Stored as string, 1 byte per character (syntax of respective attribute is IA5 string)
• Password expiration time: 64-bit number, stored as string (currently 18 chars), 1 byte per number

• Before creating 25K computer accounts: 32 MB
• After creating 25K computer accounts: 262 MB
• After populating password and expiration time: 262 MB

Client - DC traffic

• Download of registry.pol file from SYSVOL: .pol file contains LAPS-specific GPO settings
• LDAP traffic caused by LAPS client: LAPS client always reads password expiration time from AD, and - if password expired - uploads new password and expiration time

Registry.pol file

LDAP traffic

• Initial rollout:
  • Client -> DC: 10 frames, 2782 bytes
  • DC -> Client: 7 frames, 847 bytes
• Normal operation, no password change:
  • Client -> DC: 6 frames, 2308 bytes
  • DC -> Client: 6 frames, 767 bytes
• Normal operation, password change & upload:
  • Client -> DC: 8 frames, 2674 bytes
  • DC -> Client: 7 frames, 908 bytes

Replication traffic

Summary

Changes in ws2016lab scripts

Variables.ps1

$LabConfig=@{AdminPassword='LS1setup!'; DomainAdminName='JiriF'; Prefix = 'NanoLAPS-'; SecureBoot='On'; CreateClientParent='No'; DCEdition='ServerDataCenter'; ClientEdition='Enterprise'; InstallSCVMM='No'}

$NetworkConfig=@{SwitchName = 'LabSwitch'; StorageNet1='172.16.1.'; StorageNet2='172.16.2.'}

$LAbVMs = @()

1..2 | % {"Nano$_"} | % { $LAbVMs += @{ VMName = $_ ; Configuration = 'Simple'; ParentVHD = 'Win2016Nano_G2.vhdx'; MemoryStartupBytes= 128MB ; DSCMode='Pull'; DSCConfig=@('LAPS_Nano_Install','LAPSConfig1')} }

3..4 | % {"Nano$_"} | % { $LAbVMs += @{ VMName = $_ ; Configuration = 'Simple'; ParentVHD = 'Win2016Nano_G2.vhdx'; MemoryStartupBytes= 128MB ; DSCMode='Pull'; DSCConfig=@('LAPS_Nano_Install','LAPSConfig2')} }

#LAPS Lab

$LabConfig=@{AdminPassword='LS1setup!'; DomainAdminName='JiriF'; Prefix = 'NanoLAPS-'; SecureBoot='On'; CreateClientParent='No'; DCEdition='ServerDataCenter'; ClientEdition='Enterprise'; InstallSCVMM='No'}

$NetworkConfig=@{SwitchName = 'LabSwitch'; StorageNet1='172.16.1.'; StorageNet2='172.16.2.'}

$LAbVMs = @()

1..10 | % {"Nano$_"} | % { $LAbVMs += @{ VMName = $_ ; Configuration = 'Simple'; ParentVHD = 'Win2016Nano_G2.vhdx'; MemoryStartupBytes= 128MB; DSCMode='Pull'; DSCConfig=@('LAPS_Nano_Install','LAPSConfig1')}}

11..20 | % {"Nano$_"} | % { $LAbVMs += @{ VMName = $_ ; Configuration = 'Simple'; ParentVHD = 'Win2016Nano_G2.vhdx'; MemoryStartupBytes= 128MB; DSCMode='Pull'; DSCConfig=@('LAPS_Nano_Install','LAPSConfig2')}}

2_CreateParentDisks.ps1

{

  Ensure = "Present"

  Name = "DSC-Service"

}

xDscWebService PSDSCPullServer

{

  Ensure = "Present"

  EndpointName= "PSDSCPullServer"

  Port = 8080

  PhysicalPath = "$env:SystemDrive\inetpub\wwwroot\PSDSCPullServer"

  CertificateThumbPrint= "AllowUnencryptedTraffic"

  ModulePath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"

  ConfigurationPath= "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"

  State = "Started"

  DependsOn = "[WindowsFeature]DSCServiceFeature"

}

xDscWebService PSDSCComplianceServer

{

  Ensure = "Present"

  EndpointName = "PSDSCComplianceServer"

  Port = 9080

  PhysicalPath = "$env:SystemDrive\inetpub\wwwroot\PSDSCComplianceServer"

  CertificateThumbPrint = "AllowUnencryptedTraffic"

  State = "Started"

  DependsOn = ("[WindowsFeature]DSCServiceFeature","[xDSCWebService]PSDSCPullServer")

}

File RegistrationKeyFile

{

  Ensure = 'Present'

  Type = 'File'

  DestinationPath = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"

  Contents = $RegistrationKey

}

3_Deploy.ps1

#DCM Config

[DSCLocalConfigurationManager()]

Configuration PullClientConfig {   param (

    [Parameter(Mandatory=$true)]

    [string[]]$ComputerName,

    [Parameter(Mandatory=$true)]

    [string[]]$DSCConfig

  )          

  Node $ComputerName

  {

    Settings

    {

      AllowModuleOverwrite = $True

      ConfigurationMode = 'ApplyAndAutoCorrect'

      RefreshMode = 'Pull'

      RebootNodeIfNeeded = $True

      ActionAfterReboot  = 'ContinueConfiguration'

    } ConfigurationRepositoryWeb PullServerWeb  {

      ServerURL = 'https://dc.corp.contoso.com:8080/PSDSCPullServer.svc'

      AllowUnsecureConnection = $true

      RegistrationKey = '14fc8e72-5036-4e79-9f89-5382160053aa'

      ConfigurationNames = $DSCConfig

    }

    $DSCConfig| ForEach-Object {

      PartialConfiguration $_

      {

        RefreshMode = 'Pull'

        ConfigurationSource = '[ConfigurationRepositoryWeb]PullServerWeb'

      }

    }

  }

}

LAPS Client for Nano Server

#LAPS_Nano_Install -ConfigurationData $ConfigData -Ensure Present

$OutputPath='C:\temp\LAPS\'

$ConfigName='LAPS_Nano_Install.mof'

LAPS_Nano_Install -ConfigurationData $ConfigData -Ensure Present -OutputPath $OutputPath

Rename-Item -Path "$OutputPath\localhost.mof" -NewName $ConfigName -Force

New-DscChecksum -Path "$OutputPath\$ConfigName" -OutPath $OutputPath

In LAPS.Nano.DSC.Config.ps1 first setup LAPS client parameters as desired:

#LAPS_Nano_Config -ConfigurationData $ConfigData -Ensure Present

$OutputPath='C:\temp\LAPS\'

$ConfigName='LAPSConfig1.mof'

LAPSConfig1 -ConfigurationData $ConfigData -Ensure Present -OutputPath $OutputPath

Rename-Item -Path "$OutputPath\localhost.mof" -NewName $ConfigName -Force

New-DscChecksum -Path "$OutputPath\$ConfigName" -OutPath $OutputPath

#remove space before version number in path below if you copy/paste - seems that blog engine does not like <backslash><zero> combination

Compress-Archive -Path c:\temp\LAPS\LAPS.Nano.DSC\ 0.9.0.5\* -DestinationPath c:\temp\LAPS\Laps.Nano.DSC_0.9.0.5.zip

New-DscChecksum -Path c:\temp\LAPS\Laps.Nano.DSC_0.9.0.5.zip -OutPath c:\temp\LAPS\

#example to start VMs one by one (run from Host)

1..20 | % { 

    Start-VM *Nano$_ 

    Start-Sleep 30

}

#run this from DC

#get DSCconfig status from Nano1 VM

(Get-DscConfigurationStatus -CimSession nano1).resourcesindesiredstate | ft ConfigurationName,InstanceName,InDesiredState

#Push DSC Config again

Start-DscConfiguration ComputerName nano1 -UseExisting -Verbose -Wait

#Review LCM Config

Get-DscLocalConfigurationManager -CimSession nano1

(Get-DscLocalConfigurationManager -CimSession nano1).ConfigurationDownloadManagers

(Get-DscLocalConfigurationManager -CimSession nano1).PartialConfigurations

#review LAPS Client Settings

invoke-command -ComputerName nano1 -ScriptBlock {Get-ItemProperty "HKLM:\software\policies\Microsoft Services\AdmPwd\"}

get-service -ComputerName nano1 -Name *Laps*

• Download LAPS https://www.microsoft.com/en-us/download/details.aspx?id=46899
• Install LAPS on DC with following settings:

• Note: You don’t need GPO templates on DC for this lab with Nano servers, as LAPS for Nano does not use GPO at all. However, for real environment with mixed Nano and “normal” machines, you will need GPO templates as “normal” machines still receive configuration via GPO
• Run Update-AdmPwdADSchema from PowerShell to extend AD schema.
• Run Set-AdmPwdComputerSelfPermission -identity:Workshop from PowerShell to delegate computer permission to write password under OU Workshop
• Wait some time and check password of managed admin account on Nano machines reported to AD:

• Rather than GPO Client Side Extension (CSE), LAPS client for Nano Server is implemented as a Windows Service
• Configuration parameters (password complexity, age, etc.) are still taken from Windows registry, but are distributed there by the PowerShell Desired State Configuration (DSC), rather than Group Policy.

• Find the configuration parameters at the same place in registry (HKLM\Software\Policies\Microsoft Services\AdmPwd)
• See event source AdmPwd in the Application log, with the same Event IDs and messages

Prerequisites

• Solution was tested on TP5 of Nano server, and is not expected to work on earlier builds of Nano
• Solution only works on Nano server - it is not designed to run on standard Windows 2016 server, or on earlier versions of Windows
• Solution depends on PowerShell DSC. Depending on where you will test it, you may need to install PowerShell DSC
  • Azure VM provisioned from Nano RTM image in Azure VM gallery needs this
  • Installation commands for your reference:

Save-Module -Path "$Env:ProgramFiles\WindowsPowerShell\Modules\" -Name NanoServerPackage -MinimumVersion 1.0.1.0 Import-PackageProvider NanoServerPackage Find-NanoServerPackage Microsoft-NanoServer-DSC-Package | Install-NanoServerPackage

• Solution expects that Nano server is joined to domain - join it via djoin prior installing
• For remote management using GUI tools (event viewer, etc.), you may want to enable firewall rules via Enable-NetFirewallRule
• Solution expects AD permissions delegation the same as for "classic" LAPS client - perform the necessary delegations via Set-AdmPwdComputerSelfPermission cmdlet, if needed

Installation

How to install

• Copies VC++ runtime to %SystemRoot%\System32
• Copies LAPS client binaries to %ProgramFiles%\AdmPwd\CSE\
• Registers ETW manifest for event logging
• Installs LAPS.Nano Windows Service
• Starts the service

Frequently asked questions

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

We released update to LAPS last week. Changes in new version:

• Fixed bug that caused computer account not to be found by LAPS UP and LAPS Powershell in forest containing multiple domain trees, and computer account was in different domain tree than tree of forest root domain
• Added –SchemaNotUpdated switch parameter to cmdlet Find-AdmPwdExtendedPermissions that allows running this cmdlet in AD forest that does not contain LAPS AD schema update. Previously, doing this caused „No such object found“ error, because cmdlet looked for LAPS schema attribute in AD schema
• LAPS UI: Replaced text box for password expiration with datetime picker
• Fixed typos and better wording in ADMX templates
• Updated documentation

 Download location did not change, so visit Download center for download

Jiri

Management of local account passwords via GPP was not best thing to do from security perspective, so this functionality was disabled by hotfix mentioned above.

However, installation of hotfix just disbles ability of making changes to relevant parts of GPP, but keeps current settings in place, so as not to disrupt  processes that may be in place and rely on settings distributed by GPP.

When installing LAPS into the environment, people may forgot to remove local administrator password management settings from GPP, thinking it was removed by installation of the hotfix mentioned above. This results in having two independent processes managing password of local administrator account and invalidates password that LAPS stores in AD in computer account.

So when installing LAPS, please always make sure that local administrator password management settings are removed from GPP prior deploying LAPS.

Main reason for the decision to store password in AD as clear text was simplicity of the solution: focus was on implementation of Client Side GPO extension that manages local administrator account on local machine, and get the result (password and expiration timestamp to AD. Administrators can then use tools provided with the solution (PowerShell cmdlet of LAPS UI client), or built-in tool (such as dsa.msc) to retrieve the password.

When considering encryption of password in AD, implementation needs to decide how to protect and distribute decryption key:

• Symmetric encryption/decryption algorithms are not good here: key would also be used for encryption, so it would need to be known by all managed machines that are expected to encrypt password using it, plus administrators who need it for decryption of password. Not good. Maybe separate key for each machine? A lot of keys would be needed, which is not good, and still there is a need to make sure that only approved admins have access to the key to perform decryption of password
• Asymmetric encryption/decryption algorithm? Probably a better solution: encryption would use public key, so all managed machines can easily use the same key, but still, there is a challenge to solve: how to make distribute private key to administrators who need it for password decryption. Probably best way would be to implement a central service that would be owner of private key and used it for password decryption. This would work, but it's far from simple design that was the original goal

Actually, there are 2 sides of story when speaking about password stored as clear text in AD:

1. Password protection while stored in AD
2. Password protection during the transport to end user who needs it

Password protection when stored in AD

Permission to read the password from AD

As you probably know, ms-Mcs-AdmPwd attribute that stores password in AD is marked as Confidential in AD - this means that users need to have extra permission (CONTROL_ACCESS permission) to read the value - Read permission is not enough. AD honors the read request for confidential attribute value when at least one of the following is true:

• Caller is granted 'Full Control' permission
• Caller is granted 'All Extended Rights' permission
• Caller is granted 'Control Access' on the attribute permission (this is what LAPS PowerShell uses to grant the permission)

So it's important that AD administrators detect who has permission to read the password before managed machines start reporting password to AD and align permissions with desired administration model to prevent password reads by people who should not be allowed to.

There is LAPS PowerShell cmdlet that helps identify who effectively has permission to read password, so IT admins can change permission delegation model to remove the read password permission from people who should not have it – cmdlet name is Find-AdmPwdExtendedRights

Theft of Domain controller and harvesting for passwords stored there

Yes, theft can happen. AD database itself is one of biggest security assets of company and as such, needs to be protected properly. Protect your AD backups and you will protect local administrator passwords stored there as well.

For physically insecure environments, consider using Read Only Domain Controllers (RODC). ms-Mcs-AdmPwd attribute is flagged not to replicate its value to RODC, so theft of RODC will not reveal any local administrator passwords to the thief.

Also, ms-Mcs-AdmPwd attribute is flagged so as DC does not audit change of values - so harvesting of security logs of domain controllers will not reveal any local administrator passwords.

Password protection during transit

LAPS tools have built-in protection for password transport implemented. Protection is based on ‘Kerberos encryption’ that’s available out of box for domain joined machines for a few protocols including LDAP. Both LAPS PowerShell and LAPS UI use this protection to make sure that password is protected during transit.

However, it’s important to understand, that this protection cannot be enforced from DC side, and it always needs to be initiated from client side, so keep this in mind when you choose to use different tools or decide to develop own tools instead.

Support for encryption from tools available on platform

Recent versions of common MS tools do a good job in terms of securing data during transport:

• Dsa.msc: uses encrypted connection by default
• Adsiedit.exe: uses encrypted connection, even when configured not to use LDAP/SSL
• Ldp.exe: offers to use encrypted connection by default, when binding:

 However, with LDP, you can connect unencrypted if you want to, provided you know what you’re doing

Recommendation: always use SW that encrypts traffic when retrieving data from AD – either Kerberos encryption, or – if your DCs have a SSL certificate – use SSL connections whenever possible.

Your own code

Let’s see below on typical approaches for AD data retrieval and how to make sure that data is protected during transport

ADSI

Simple PowerShell script using ADSI is usually a bad choice:

$comp=[adsi]"LDAP://CN=MyComputer,OU=LAPS,DC=MyDomain,DC=com"

$comp."ms-mcs-admpwd"

 This script reveals password on the network. Never use ADSI this way. If you must use ADSI, always use  IADsOpenDSObject interface and specify USE_SIGNING and USE_SEALING in OpenDSObject method. See https://msdn.microsoft.com/en-us/library/aa706065(v=vs.85).aspx for more details.

AD Powershell

Get-ADComputer cmdlet uses AD WS rather than LDAP, and connection uses SSL, so password is protected during transport

System.DirectoryServices namespace in .NET Framework

Objects is this namespace are based on ADSI, so generally, it tends not to protect transmitted data by default. To ensure protection, make sure you turn it on before touching a directory object, as shown on simple PowerShell script below:

$comp=new-object System.DirectoryServices.DirectoryEntry

$comp.AuthenticationType=$comp.AuthenticationType -bor [System.DirectoryServices.AuthenticationTypes]::Sealing

$comp.AuthenticationType=$comp.AuthenticationType -bor [System.DirectoryServices.AuthenticationTypes]::Secure

$comp.Path="LDAP://CN=MyComputer,OU=LAPS,DC=MyDomain,DC=com "

$comp.Properties["ms-mcs-admpwd"]

System.DirectoryServices.Protocols in .NET Framework

Personally, API of my choice for managed programming; robust and powerful (see my sample on how to use it in PowerShell here: https://gallery.technet.microsoft.com/Using-SystemDirectoryServic-0adf7ef5).. However, encryption needs to be turned on explicitly on LdapConnection object, as shown on PowerShell script below:

[System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.Protocols") | Out-Null

$directory=new-object System.DirectoryServices.Protocols.LdapDirectoryIdentifier("MyDC.MyDomain.com", 389)

$LdapConnection=new-object System.DirectoryServices.Protocols.LdapConnection($directory)

$LdapConnection.SessionOptions.Sealing=$true

$LdapConnection.SessionOptions.Signing=$true

 Conclusion

Even when password is stored as clear text in AD by LAPS, still the solution provides significant amount of security:

• Password is protected by ACL
• Password is not replicated to RODC and is not revealed in audit logs on DC
• Is protected in transit by LAPS tools

You only need to understand how the password is protected and use the solution a proper way to keep the password secure