LAPS 4 All and Bitlocker Keys to ITGlue

[TMG-mmccool]

LAPS for All is similar to Microsoft's LAPS product, but can be deployed outside of a domain environment. It creates a unique password for the local admin account on a Windows workstation and saves the password to ITGlue.

This script was designed to be used with DattoRMM/Autotask Endpoint Management, but may be possible to port to other RMM platforms provided the RMM platform assigns a unique ID to the device and that unique ID is saved to the 'asset-tag' or similar field inside of the ITGlue configuration object.

After seeing computers hacked years ago through open RDP ports using admin accounts, we have made a progression of MSP policy changes to mitigate this (RDP only over secure VPN, no Domain Users in local admins group, etc.), as well as implementing other security changes, but we were unable to manually maintain the goal of having a single local MSP admin account on all computers that had a unique secure/complex password per computer. Microsoft had released LAPS to do this, but that was only for domain environments, and many of our clients do not have domains. This script provides the required automatic updating functionality and IT Glue provides the necessary password history in case System Restore or some other restorative function backdates the password to an older version. This allows us to confidently automate changing the password monthly. The script will not run on servers (to protect local service accounts) and will not allow the optional function to disable all other local accounts on non-domain joined computers. We can now finally disable all default/OEM and the previous IT's local user accounts in a single swoop on domain computers--great for onboarding.

Items of note:

1. This will work for all endpoints, including those not on domains.
2. Passwords are unique for each device and stored inside of the device's ITGlue configuration.
3. All required prequisites are automatically installed as needed. (Installation of .Net Framework and PowerShell 5.0 is handled outside the scope of the script.)
4. Required components are automatically updated to the latest available version.
5. Passwords are dynamically created utilizing the web security functions from .Net framework.
6. Local admin account name can be customized. (This is used for both the local account on the machine and the name of the embedded password entry in ITGlue.)
7. Customizable max age for local admin password. (Only passwords older than the max age will be reset/updated.)
8. Option to disable other local accounts on the endpoint. (This will only function on domain joined PCs.)
9. Safety checks in place to make sure that this script will not execute on servers.
10. If the ITGlue configuration cannot be found, no changes to the password or account changes will be made.
11. If PowerShell module logging is enabled, the script will automatically exit to prevent sensitive information from being recorded in the Windows Event logs. (ScriptBlock logging does not affect this component inside the DattoRMM environment.)
12. The script logs changes and status to std-out. This can be used for basic audits of the process.

*There is no number 6 - ref: https://tvtropes.org/pmwiki/pmwiki.php/Main/ThereIsNoRuleSix -- Apparently GitHub is smarter than I am and automatically renumbered the list to have a number 6.

Added additional script for saving the bitlocker recovery keys to ITGlue. - Bitlocker Readme

**These scripts depend on the DattoRMM GUID being synced to ITGlue as the asset-tag data. In our workflow, this data is synced first from DattoRMM to AutotaskPSA with the DattoRMM GUID being saved at the reference number. AutotaskPSA then syncs this data over to ITGlue with the reference number being saved as the ITGlue asset-tag. If this configuration is not used, other methods of matching DattoRMM device to ITGlue device will need to be implemented.

[luisgiraldo]

@TMG-mmccool Could you please reach out to marketing[at]itglue.com with your contact info? Just need to have all submitters' info.

[AceOfNitwits]

It looks like this script requires the IT Glue API key to be stored as an environment variable on each PC. This seems like a security concern.

[TMG-mmccool]

This isn't a security concern when using DattoRMM. The API key is provided by DattoRMM as an environmental variable at script runtime. It is not stored on the computer.

[n71C5Oxw]

Does the script pass the API key to the powershell and it runs unencrypted / uncompiled on the endpoint? If it's in plain text on the endpoint even just as a variable it can be easily sniffed out.

[CalebAlbers]

It definitely is a security concern. If you intend to use this script, I'd advise using something like this (at the least) as a customer-specific proxy: https://github.com/KelvinTegelaar/AzGlue

[TMG-mmccool]

Kelvin's AzGlue gateway is definitely a good option to use. This script was made long before Kelvin's AzGlue gateway was available. Having the API key on the machine at all was always a concern of mine as well which is why I included a test for module logging in the script as this could easily leak the API key. Script block logging does not leak the key. DattoRMM does encrypt the variables passed down through the component. They are available only to the powershell environment created by the DattoRMM agent process for running the script. It is not available to any other powershell environments on the system. That being said, since API key still has to be on the computer, there is always a chance that the key could be extracted from memory or some such process. When I wrote this a couple years ago, this was not one of the security issues considered. I did my best to protect the API key in the environment that this was designed to run in.

If I were rewriting this today, I would definitely use Kelvin's AzGlue gateway as that entirely removes the API key from the endpoint. I will point out that while moving the API key to the gateway instead, doesn't entirely remove the ability for malicious use of ITGlue. Depending on what commands you allow through the gateway, it could still be a security concern. Instead of leveraging the API directly, they simply utilize your proxy themselves. As long as a bad actor can extract the token from the local system, they can leverage the AzGlue proxy to run the commands on their behalf. The only secure computer is one that is turned off and locked in a closet. Everything else is a compromise.