• Insight
  • 9 min read

Introducing LAPSWebUI Enterprise

The conversation always starts the same way, “I need to be a local administrator to do my job…”

While LAPS is a great solution for IT staff, it falls short when a standard user needs their Local Administrator password. In a standard LAPS deployment, access to LAPS passwords are given to IT staff or Help Desk. When users need the password they have to reach out or raise a support ticket. Depending on the user, type of work and frequency of these requests the support staff may spend too much time providing passwords to end users.

This is where LAPSWebUI Enterprise shines! LAPSWebUI Enterprise allows your organization to provide a secure self-help portal to end users so they can retrieve their own local administrator password without giving them access to see other LAPS passwords. LAPSWebUI can also provide LAPS password lookup to other IT-related staff, such as Help Desk team members who may not have the required permissions like IT does.

User Flow


LAPSWebUI Enterprise supports Microsoft 365 and SAML as Authentication providers. Most organizations use Microsoft 365 as they are already equipped and access is controlled via an App Registration in Azure AD. LAPSWebUI supports SAML2 identity providers, such as Okta and PingID.

Password Request

Once logged in to LAPSWebUI a list of computers is presented to the user. Upon picking a computer the user clicks ‘Get Password’. (Don’t worry, you can remove the ‘Truesec LAPSWebUI’ and use your logo)

Password Results

The flow is super quick and super simple for the end user. They request the password, get it, and paste it where they need it.

Optional Features

LAPSWebUI offers some additional features that can be enabled to change the user experience.


Remember when I said LAPSWebUI could also be used to provide access to lower-level Help Desk/Technicians? The Search feature coupled with AD Mapping (explained later in Administrative Features) can provide an excellent tool for your Technicians. As you may imagine, populating the drop-down with thousands of machines that one technician has authorization for can slow the experience to a crawl. The Search feature instead shows a search text box to allow Technician to search their available machines.

Once ‘Search’ is pressed, a dropdown list is presented and User flow continues as normal.


The Reason feature prompts the User to provide a small blurb about why they are requesting the password. This information is logged for later review. Keep in mind that there is no guarantee the user will put anything useful in this box.


One complaint I’ve heard about LAPS repeatedly is the one weird edge case where one side of the password change process didn’t record the new password. This is very rare but it apparently happens more than I thought. LAPSWebUI implements password history to help mitigate this edge case when it occurs or if a server must be restored before the most recent password.

Users can request a Historic password from the same initial prompt as the current password. Once ‘Get Historic Password’ is clicked they are presented with a list of available history entries and the date that password expired.


The Reauth feature was added to help increase security in environments where Single-Sign-On is enabled. When using Microsoft 365 as an authentication source LAPSWebUI will function just like a Microsoft website and not prompt repeatedly to login. Reducing the number of times a user must login is one of the purposes of SSO after all. In short a user could access LAPSWebUI, login, pass MFA and then walk away from their machine with it unlocked, another user could open LAPSWebUI and acquire a LAPS password. To mitigate this risk, the Reauth feature, when enabled, will force a complete reauthentication step (including MFA) with each click of the ‘Get Password’ button. This helps ensure that any request to get a LAPS password will be locked behind an MFA challenge.

Administrative Features

While LAPSWebUI is simplistic in operation, the application has some advanced features worth mentioning. Administrative configuration is performed via a GUI on the server, soon to be moved to the web UI, and most options can be toggled on or off without restarting the site.

Windows LAPS

LAPSWebUI supports all three Windows LAPS scenarios as outlined by Microsoft.

  • Windows LAPS Compat Mode: In this mode you have installed April updates on 2019+/Win10+ and do not have Legacy LAPS CSE installed. The environment is still using Legacy LAPS schema with Legacy LAPS GPO policies.
  • Windows LAPS Local AD Target: In this mode you use the latest Windows LAPS schema and GPO policies with passwords being stored in Local Active Directory.
  • Windows LAPS Azure AD Target: In this mode you have AzureAD joined machines and are pushing a LAPS Policy with Intune. The passwords for computers are stored in Azure Active Directory. This feature is currently in Preview status on Microsoft 365 Tenants and must be enabled. The way this feature operates could change at any given time.

You can use all three scenarios simultaneously in a given environment but not all on the same machine. Meaning, ComputerA can be Compat Mode, ComputerB can be Local AD Target and ComputerC can be Azure AD Target, but ComputerC can not be Local AD Target and Azure AD Target.

LAPSWebUI will first look for the computer, and if that computer doesn’t exist in Local AD (or you don’t have Local AD connection configured) then it will search Azure AD (If enabled) for that machine and grab the password. If LAPSWebUI finds the machine in Local AD it will first check the Legacy LAPS attributes and then check for the Windows LAPS attributes. LAPSWebUI doesn’t care which Windows LAPS scenario you use, nor do you have to specifically configure LAPSWebUI to look for a certain scenario.


Mapping is the key concept to understand in LAPSWebUI. By default there is no way to know what computers a User should be able to pull LAPS passwords for. This is the goal of mapping. Mapping data is created by the administrator and provided to LAPSWebUI which will then use that information to determine what computers UserA is allowed to ‘see’. We have authored several Mapping providers.

  • XML Map – This is the simplest mapping method, a static file, generally one entry per user. We recommend this for testing as it’s quick to edit and visualize.
  • AD XML Map – This mapping method can map a User or member of a Group to a single Computer, a group of Computers, or an OU of Computers. For example, give all Users of ‘USA Office 1 Techs’ access to any computer in the ‘OU=Site1,OU=USA,OU=Contoso,DC=contoso,DC=com’. AD XML Map is designed to give you administrative control of the mapping through Active Directory instead of just editing a text file. This method is mainly used for the Technician scenario and not Self-Help.
  • SQL Database – This mapping method is the most popular and most diverse. This method connects to a SQL Server and runs your query. Your query can be as complicated or as simple as needed, as long as the result is a list of computers. We have used the Configuration Manager database as a mapping source with Device Affinity enabled by custom crafting a SQL query that takes the user and returns their ‘devices’ according to SCCM. One client has also used last logged on user from a Lansweeper database to provide mapping details for example.
  • AzureAD Map – This is the newest mapping provider. This method will access the Graph API, pull device ownership information and display those computers to the user.


LAPSWebUI will log to a ‘LAPSWebUI’ Windows Event Log by default. Every login, computer discovery, password request, timestamp change or failure is logged in this log for review. For example, you can use the log to help identify strange behavior. Bob down the hall is on vacation but someone is trying to request his LAPS password…..or Bob has requested his password 12 times today, what is Bob up to!


If the Windows Event Log isn’t robust enough, the built-in Reporting may be what you are looking for. Standard reports are currently available, and more reports will be added as more customers use the product. We continuously update the reports based on what you, the customer, need and believe is essential.

Overview Report

Provides a monthly overview of how often the system is used and all events.

Provided Password Summary (User)

Provides a summary showing how many times a User requested passwords

Provided Password Summary (Computer)

Provides a summary showing how many times a password was requested for a Computer

Provided Password Detail

Provides a list of all password requests with details on who requested for what computer, for what reason, and when.

Admin Dashboard

LAPSWebUI also provides an Admin Dashboard to help visualize how the system is being used. An admin can view up-to-date events from the logs, get a break down of health, and run reports or test mapping configuration.