-
Toutes les catégories
- Active Directory
- PCI DSS
Part 1 : LAPS, particular attributes
In this article, we will discuss the Local Administrator Password Solution (LAPS) and its representation in the NTDS database. This solution, first released on May 1st, 2015 by Microsoft, aims to eliminate the manual management of local administrative accounts on machines within an Active Directory environment.
Note : Microsoft released a new version of LAPS in April 2023. In this article, we only discuss the old version renamed LAPS Legacy, which is the most widely used version in production today. We will come back on the new version and the advantages it brings in a future article.
The Genesis of LAPS
Managing local accounts within a domain is always complicated. It is still very common today to identify the same password for the built-in local Administrator account across all workstations or servers in the domain. This security flaw allows an attacker who has compromised a single machine to laterally move across all machines in the domain by reusing this same password or its hash (cf. Pass-The-Hash technique).
Before LAPS, managing local administrator passwords was difficult. Microsoft had implemented a Group Policy (GPO) strategy that allowed for the automation of deployment and management of the local administrator account on workstations. This allowed for the quick deployment, across all domain workstations, of the same administrator account and password. However, Microsoft itself did not recommend using this functionality. (1)
Back in 2012, an article on the Sogeti ESSEC blog (2) demonstrated how to decrypt passwords used in Group Policy Preferences (GPP), prompting Microsoft, in May 2014, to release a security advisory (MS14-025) to block this functionality.
LAPS then emerged in 2015 to address this issue. Available from Windows Server 2003 SP1 and Windows Vista SP2 onwards, LAPS allows for the management of the local administrator password. It is random, unique, and regularly changed (by default every 30 days) on domain machines. These passwords are centrally stored in the Active Directory and restricted to authorized users using ACLs. Passwords are protected during transit from the client to the server using Kerberos and AES.
The LAPS solution is not directly integrated into the Active Directory service. A post-installation is required and modifies the schema to add two new attributes: ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime.
ms-Mcs-AdmPwd: contains the clear text password of the machine’s administration account (in binary form)
ms-Mcs-AdmPwdExpirationTime: contains the expiration date of the password requiring renewal (in timestamp form)
The script for reading LAPS passwords from an NTDS is available at the following address: https://github.com/xmco/ntds_extract/blob/main/Part-6-LAPS/extract_laps_attributes.py
Note : Unlike other types of secrets (user password hashes, Kerberos keys, etc.), LAPS passwords are stored in clear text in the NTDS. Therefore, it is not necessary to have the BOOTKEY contained in the SYSTEM hive to extract them (cf. https://www.xmco.fr/active-directory/on-depile-le-ntds-partie-3/). When encountering a backup of NTDS during a penetration test, it is worthwhile to extract the LAPS passwords, provided that the backup is not too old.
Therefore, we have seen the study of two specific attributes resulting from the installation of a third-party component. The LAPS solution is highly recommended in an Active Directory environment but requires vigilance on access rights to these attributes in the directory. In an upcoming article, we will explore the new features brought by the latest version of LAPS, including password encryption in NTDS and Azure AD support.
(1) https://adsecurity.org/?p=384
(3) With Windows Server 2008, Microsoft introduced additional settings to Group Policies to provide extra capabilities.
(4) https://www.it-connect.fr/chapitres/installation-de-laps-sur-un-controleur-de-domaine/
