IT units on campus do not have a common method for managing the local administrator password on workstations or servers.  Current methods include a single common password on all of a IT unit's workstations, password templates that are unique but reproducible, and unique passwords that are managed and change through custom scripted changes.  The password may or may not be stored for lookup and retrieval.  If it is stored for retrieval it may be store stored as plain text store or in a secure store.  The storage is inconsistent because each IT unit will make its own decision.  The password may be rendered unknown if a scripted change fails, or an administrator leaves without sharing the password.  This case may render a workstation or server unmanageable by the IT staff.

Background

UW-IT customers have requested the installation of LAPS or LAPS.E to help manage the password using the NetID domain and group policy.  LAPS.E extends the capability of LAPS with the ability to store the local administrator password as an encrypted string in Active Directory. LAPS is officially released and supported my Microsoft. LAPS.E is neither released by nor supported by Microsoft. LAPS.E was developed by and released by a member of the LAPS team at Microsoft. LAPS stores the local administrator password, in plain text, in a secure attribute of the machine account in Active Directory (AD) and includes a client side extension (CSE) to be installed on a workstation or server to change and store the password.  A Group Policy Object (GPO) is used to configure the password settings such as length, complexity and the frequency it is changed.  LAPS.E's additional capability is implement by inserting an encryption and decryption service between the CSE and the AD attributes.

Description of Solution

The LAPS(.E) implementation consists of several parts.

• An AD schema extension to create two new extended attributes to store the password and its expiration date.
• Configuration of AD permissions, allow domain admins and other designated administrators, such as OU admins, explicit access to the extended password attributes to computer objects in designated OUs.
• SRV record in the netid.washington.edu domain which allows the CSE to discover the PDS
• A Password Decryption Service (PDS) which is responsible for encrypting and decrypting passwords when stored and retrieved

There are three client access mechanisms which allow retrieval of administrator passwords.

• A set of PowerShell Cmdlets which are installed from an MSI package
• A fat client that is installed from and MSI package
• An optional website available from GitHub which allows designated administrators access to retrieve passwords

A fourth mechanism is Active Directory Users and Computers which works with LAPS, but not LAPS.E. The LAPS product documentation can be found at: https://technet.microsoft.com/en-us/mt227395.aspx

Other Solutions

An analysis of alternatives to LAPS was performed by discovering a series of password management solutions online and evaluating their suitability based on several criteria.  Those criteria included:

• License type - does the product have a free or commercial license?
• Scope of the product -  is the product standalone or part of a management suite?
• AD considerations - does the product require a schema change?  Are the passwords stored in AD or another database?
• Local agent - does the product require a local service or agent?
• Encrypted store - does the product store the passwords in encrypted form?
• Temporary elevation - does the product allow for limited elevation of privileges?
• Platform considerations - is the product cross platform?
• Auditing capabilities - does the product allow for tracking and auditing?
• Price - how much would it cost in hardware, software, design, and maintenance?

After analyzing more than a dozen products using the criteria above, it was concluded that the free options don't meet security and compliance requirements.  Most of the commercial products are components of commercial suites and some carry a high cost to implement and maintain.   The analyst has recommended LAPS or LAPS-E (AdminPwd-E) for use in this environment.

Support

Support of LAPS(.E) can be split into Microsoft Infrastructure service team (MI) responsibilities and customer responsibilities.  MI will be responsible for creating a design to implement LAPS(.E) in the NetID domain.  MI will also have both one-time support responsibilities and ongoing support responsibilities. MI one-time support responsibilities will include the initial setup and configuration of the AD schema, DNS records, PDS installation and configuration, setup and configuration of the optional web site, and initial configuration of AD permission on existing delegated OUs.  MI will need to ensure the LAPS.E version of the Group Policy and client media are available. Ongoing support responsibilities for MI will include adding configuration of permissions to delegated OU setup either on demand or as part of a standard delegated OU depending upon design decisions. Answering support questions regarding the configuration of LAPS(.E) clients and GPOs.  Providing current passwords to a customer in the event they are unable to retrieve and decrypt a password.  Monitoring PDS and web site availability and respond to outages.  Maintaining contingency plans in the event LAPS.E becomes inoperable and unrepairable without support. LAPS(.E) customers will be responsible for implementation of LAPS.E on the IT unit's servers and workstations.  This include installation of the CSE on computers.  Configuring GPOs that will configure the CSE on computers.  Installation and configuration of the password retrieval clients, and retrieval and lookup of passwords.

Risks

Maintaining the status quo of no local password management leaves our large population of workstations joined to NETID at risk. The implementation of LAPS, while not perfect, will provide UW-IT and our customers with a solution to mitigate some of that risk. The implementation of LAPS.E over LAPS has several risks associated with it.  LAPS.E is an unsupported product released independently as open source software.  The only support channel is the comments section on the project source page.  The product availability can be revoked at any time.  This has happened once already at the request of Microsoft.  The author of LAPS.E made it available via new mechanisms. Security of the stored passwords depends upon correct permissions in Active Directory.  This risk is mitigated by the fact that these permissions can only be modified by Domain Admins.  Misconfiguration of permissions can still allow unintended users to retrieve and decrypt passwords with PowerShell Cmdlets, the fat client or the optional web site. The installation of LAPS.E does not preclude IT groups from using standard LAPS, an IT unit can simply install the LAPS CSE and use the LAPS GP templates. Degradation or failure of the PDS service will prevent customers from retrieving passwords.  Adding several additional mechanisms to the solution makes failure of the LAPS.E service more likely.  MI may not have resources to support the additional services and service requests or repair the solution in the event of a failure.

Recommendation

We recommend use the standard LAPS product, contingent upon CISO agreement that protection of plain text passwords with ACLs in AD is a sufficient security mechanism, for the following reasons. Both LAPS and LAPS.E require the same permissions to be set in AD to protect the passwords.  Misconfiguration of either product will allow unintended disclosure of passwords to parties that were not intended to retrieve passwords. The additional software and services of LAPS.E requires additional investment of both capital and human resources reducing the ability of MI to dedicate resources to other projects and services.  These additional services also increase the likelihood of service failure and support issues compared with the LAPS solution, while providing a minimal increase in security over LAPS, LAPS.E does not prevent departments from using standard LAPS and therefore the implementation of LAPS.E does not enforce the additional level of password security.

Resolution

UW CISO has agreed LAPS is an acceptable solution and that AD ACLs are a sufficient mitigation to protect the password. Microsoft's analysis of the risk of storing the password in plain text is worth reading. The Microsoft Infrastructure service team has installed the LAPS schema, and moved forward with a delegated support approach to password escrow/retrieval. Presentation of this new option happened at the April 2017 Microsoft Technology community, and announcement of this new capability happened on 2017/04/21.