Local Admin Password Solution
Our Local Administrator Password Solution (LAPS) was built to solve the issue of using identical accounts in your environment for user support or privilege escalation. LAPS creates strong passwords for local accounts which are stored securely in your own Azure Key Vault. For auditing, you also have to provide an Application Insights instance, though we are transitioning to using Log Analytics workspaces directly.
Before you can start with LAPS you have to meet the following pre-requirements:
- You have to have set up Application Insights
- You have to explicitly enable LAPS account types using group (or user) settings
We'll look at both of them below.
Application Insights play an important role when using LAPS. The password requests triggered by LAPS are logged by RealmJoin and piped to Application Insights. This way you have complete insight into who is retrieving passwords.
LAPS supports the follow global settings.
The following account types are supported.
Each account type may be configured independently using the following common settings. Some types have special settings described in their respective section.
By default truly random passwords will be generated based on the settings
PasswordLength. The default charset was chosen to exclude similar looking characters like
O0. Windows' cryptographic random number generator is used to provide high quality randomness for generation.
Truly random passwords can be painful to work with, which is why special preset templates are also supported.
- Preset 1 ⇒
[1 upper][3 lower][4 digit]
- Preset 2 ⇒
Key-[6 digit]-[6 digit]-[6 digit]-[6 digit]-[6 digit]-[6 digit]-[6 digit]-[6 digit]
- PasswordLength setting is supported! The setting determines the number of digit blocks.
Key-012993-230956-976475(PasswordLength = 3)
Key-497254-679158-631224-278319(PasswordLength = 4)
- Preset 3 ⇒
[word]-[word]-[word]-[word]-[word]-[word]generated from Eff Long List
- PasswordLength setting is supported! The setting determines the number of words.
Exciting-Unearth-Cried-87(PasswordLength = 3)
Neurology-Astute-Debate-Marshy-15(PasswordLength = 4)
After an account was used, that is after sign out of the local user, RealmJoin can be configured to delete and recreate the account using the
MaxStalenesssetting. This way accounts will always be pristine. If not configured accounts will never be recreated and will stay around indefinitely.
Even though RealmJoin tries its best to avoid naming conflicts when managing the accounts on a device, there is always the possibility that accounts might already exist on a device causing conflicts. This is why the
NamePatternsetting supports these tokens with special meaning to RealmJoin. The tokens will be transformed by the specified function and its length parameter following the colon.
B3C4F74E, ... (random hexadecimal characters)
066946, ... (random decimal characters)
02, ... (counter, will stay
01if no conflicts exist)
This account type is supposed to be your backup access to the device should it fail catastrophically. It will be created proactively. This way you will always have access for recovery. We recommend configuring it for account recreation.
"DisplayName": "Emergency Access",
This account type can be configured for on-demand creation. It is designed for use in a limited time window of 12 hours in on-demand mode. After triggered via the RJ portal, the account will be created with the next sync to the backend.
Requirements for the on-demand workflow:
- 1.The mode is enabled by setting
- 2.A user is signed in
- 3.The RealmJoin agent is running
- 4.The device is connected to the internet
- 5.The device can reach the RealmJoin backend
When not in on-demand mode it will be created proactively.
"DisplayName": "Support User",
This account type is designed to be used by power users that need regular but controlled admin privileges on their own devices. A fixed account expiration date can be specified (
Forced password rotations are supported:
2021-11-20T12:34:56+01:00: any explicit timestamp in ISO8601. Multiple timestamps can be specified.
DayAfterCreate: after the account has been created the account's password will be changed. This is useful when users are supposed to set up Windows Hello for additional sign-in options.
Weekly: Weekly takes preference over Monthly. If no more conditions are specified, defaults are "1st day of month" for Monthly or "Monday" for Weekly. All seven weekday can be specified. So if
Weeklyare specified, the password will be changed every Wednesday. If
Monthlyare specified, the password will be changed on the first Wednesday each month.
"DisplayName": "Privileged User",
"PasswordRenewals": ["DayAfterCreate", "Monthly", "Thursday"],
Use the RealmJoin Portal to access the passwords. It will appears similar to this.
Users may access accounts created on their own devices (they are "PrimaryUser") when enabled using the RealmJoin Portal starting with version
2022.5.1. To enable, define a setting using the key
Allow.SelfLAPS. This setting may be defined on groups and users. As with all settings prefixed with
Allow.*they are AND-joined across the user and all of their groups.
The value can also be pure boolean
false. This may be used as a wildcard and encompasses every current and future account type. Please note that this is only recommended for disabling access (
A sample configuration may look like this: