LAPS, kesako ?
Let’s start with a small important introduction: this article aims to present the LAPS tool (Local Administrator Password Solution) through my feedback from a large account customer. Namely, the article is not intended to recommend or not to recommend this tool, rather it aims to tell the story of the project that revolves around this technology.
For information and to make it simple, LAPS is a product offered by Microsoft allowing you to manage the passwords of the local “Administrator” accounts of workstations and servers. Like any tool, it has both advantages and disadvantages that a CIO must adapt to his organization.
First deployment and first feedback
The history is rather simple, I was asked to deploy this tool as part of a remediation associated with a security audit. For additional information, LAPS was already deployed on the perimeter of the workstations while a fixed local administrator password was used on all the servers: inconsistency!
We all know that using the same local administrator password is a real configuration vulnerability, as it would allow an attacker to bounce from server to server in the event that they have already taken control of a machine or the entire information system. LAPS then makes it possible, via the deployment of a GPO, to generate unique and robust passwords for each local administrator account, to define the expiration period of the passwords associated with these accounts, to define the complexity of the associated passwords to these accounts and to automatically regenerate a password when it expires: a good tool!
The password is then stored within the Active Directory, directly in the attribute editor of an object’s properties (ms-Mcs-AdmPwd). I therefore prepared all the necessary configuration upstream, namely: the creation of a GPO, the installation of the LAPS executable via our deployment tool: there are actually a few more steps , but I preferred to stay generic… safety first!
I had planned a batch deployment schedule across the entire information system. Unfortunately, I thought that the deployment of the tool was validated, but when it was put into production on the first batch of servers, the project was blocked by the system teams: the beginning of the problems!
A long-term brainstorming
The project is frozen following several problems raised by the teams: how to recover all the passwords in the event of the unavailability of the domain controllers? What policy should be set for the local administrator account of the same controllers? Should we set up a PRA (business resumption plan) dedicated to LAPS?
Several brainstorming meetings were held and we highlighted a number of solutions that could be adapted to the infrastructure already in place and to the organizational context.
The first solution is to take a snapshot of the primary domain controller’s Active Directory, but the ms-Mcs-AdmPwd attribute may not be up to date depending on the backup restore date. In addition, it will still be quite resource intensive and snapshots are not really for that.
The second solution consists of implementing a script that retrieves the ms-Mcs-AdmPwd attribute and sends it via API to the tool acting as a safe. This is a solution, but it makes it dependent on a PRA associated with the vault server and raises the same issues as before (accessibility outside the domain, local PMP admin, redundancy, etc.). We discover much later that this safe also has a tool capable of performing the same work as LAPS, but it has never been used and configured.
The third solution is to implement a script that retrieves the ms-Mcs-AdmPwd attribute and sends it to a file on a target server (EARLY LAUNCH ANTI MALWARE). The server will have a fixed local admin password with a policy to be set, but this makes it dependent on a PRA associated with that server (accessible outside the domain, local server admin, redundancy, etc.).
In all cases, we would always be dependent on the accessibility of the machine hosting the passwords. The standard deployment of LAPS is therefore not in my opinion a bad idea: we keep the cape!
An effective solution, but with new constraints
Finally, a derivative of the second solution was chosen. Namely, the configuration of a tool inherent to the safe allowing the dynamic resetting of passwords: we have changed the course!
The objective has been achieved since we meet the needs, but with new constraints. For example, ensuring that all the servers are configured and present in the vault and above all this makes us dependent on the continuity of accessibility to this vault server. The password for the local vault administrator account will only be known by a few key employees and only communicated orally: do we need a vault for the vault?
Finally, we centralized all of our password management (local administrator accounts, local accounts, service accounts, etc.) on the same server with the famous safe.
To conclude , and this is my opinion following my feedback, dynamically generating passwords for local administrator accounts is a very good thing in terms of security. On the other hand, in the case presented, the decision taken to fill the need unnecessarily prolonged its application to finally respond to it, but with new constraints without necessarily taking into account the level of reduction of the inherent risks.
