Showing results for 
Search instead for 
Did you mean: 

LAPS for Windows aka "JC miniLAPS"

Rising Star III
Rising Star III
+++ This is a ReleaseCandidate (RC) version of JC-miniLAPS +++
Version: RC 1.0

Why is it called 'JC-miniLAPS'?
- The aim was to create a similar capability to Microsoft's LAPS for Windows-devices while not having the requirements in place.
- Instead, the OpenDirectory Platform JumpCloud is used.
- 'mini' because it's really lightweight.
Ingredients used:
- JumpCloud Tenant
- Windows-devices enrolled via JumpCloud Agent (not via self-service, see Caveats below)
- This script within a Command (Windows PowerShell) scoped to Windows-devices (tested with 10 Pro and 11 Pro)
What it does:
By using a Command - which can be scheduled - it will create a random password for a
specified Administrator account and write it back to the description field of the respective system.
Keep in mind that the password isn't obfuscated in the Admin Console.
During execution on each device, the password is handled as a SecureString as much as possible
and the password isn't revealed in the in the Command Results.
Due to the fact that the script runs on the device itself, the passwords are unique per device/cycle.
This script doesn't require an API- or ConnectKey as it is utilising the SystemContext-API.
To work best against a fleet of systems, the Administrator account is unified and most importantly,
in this case, not managed by JumpCloud or any other central IAM solution.
This current version also checks if the specified Administrator exists on a device or not.
If not, the account will be created and added to the local group 'Administrators'.
Currently, the account will also be enabled, this can be modified of course if not desired.
This script won't work with systems where the SystemContext-API isn't available:
Such systems have been enrolled via the JumpCloud UserConsole and they can be identified due the existence of a so-called provisionerID: get-jcsdksystem | where-object {$_.provisionerID}

To-Do (under consideration):
- check against existing provisionerID and exit if present
- explore other 'distribution channels' for the password
i.e.: other fields (tags), Slack, Jira, encrypted file etc.
- consider obfuscation and/or encryption methods to further protect the passwords

The script can be found here.

Novitiate III

Hi Juergen,

my case is "SystemContext-API isn't available", even if my test pc has been migrated from AD domain using the Jumpcloud ADMU. I'm not very good as a programmer, but how can I modify the script to use for example the API key or enable the SystemContext-API ?

Thanks a lot


Hello @dariovernelli 

It's doable without SystemContext-API as well, but be clear about the fact that this carry - in some form - an API-key in the scripts. If that's ok with you?

I'll put this on my bucket list to make an alternative version. 
Allow me some grace period as I'm going to travel as well.

Hi @JuergenKlaassen 

yes I know the "risk" of an API-Key into the script, but it will be very useful for me.

Thanks a lot

Hey @dariovernelli 

So, I got a couple of minutes to look into it and it's basically a minor change as you only have to change the last section where we're making the actual call against the API to set the password into the description field. 

The initial version using the SystemContextAPI looks like this: 

# Line 436 onwards:

# Invoke the WebRequest via API to writhe the password into the description of the device
$headers = @{
    Accept        = "application/json"
    Date          = "$now"
    Authorization = "Signature keyId=`"system/$($systemKey)`",headers=`"request-line date`",algorithm=`"rsa-sha256`",signature=`"$($signature)`""
$Form = @{
    'description' = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($LAPS_password));
} | ConvertTo-Json
Invoke-RestMethod -Method PUT -Uri "$systemKey" -ContentType 'application/json' -Headers $headers -Body $Form | Out-Null

We're going to replace this with the following changed code using the API-Key: 

# Replace "YOUR_API_KEY" with your actual JumpCloud API key
$apiKey = "<YOUR_API_KEY>"
$now = (Get-Date -Date ((Get-Date).ToUniversalTime()) -UFormat "+%a, %d %h %Y %H:%M:%S GMT")

# Set up headers for the request
$headers = @{
    Date          = "$now"
    'x-org-id'    = ""
    'x-api-key'   = $apiKey
    'content-type'= "application/json"

# Convert password to string and create JSON body
$Form = @{
    'description' = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($LAPS_password));
} | ConvertTo-Json

# Invoke the WebRequest via API to write the password into the description of the device
Invoke-RestMethod -Method PUT -Uri "$systemKey" -ContentType 'application/json' -Headers $headers -Body $Form | Out-Null

I've put the whole script (taken out unnecessary code and the lengthy description) on my GitHub here
I did 2-3 tests on my Windows Boxes and it worked fine. 





A potential improvement could be to obfuscate the API-key in one or another form. (thinking about options). 

Hi @JuergenKlaassen ,

many thanks. I'll try asap.

Iron II
Iron II

We were discussing this recently. Love this post.

Novitiate II

Would it be possible to store the password on a shared folder in JumpCloud Password Manager?

I've done that.

Do you mind sharing a script for that?


Novitiate I

Hi! Do you have the script for macOS? Or do you plan to implement it?


Hi Thomas
macOS is quite a 'different beast' here. 
There's an open source project:

I haven't dug in deeper yet on it though. 
Is this something you could consider?

It would be great to take advantage of the fact that JumpCloud installs an agent on all computers to resolve this LAPS requirement on both Windows and Macos natively to the JC console. Just a recommendation.
Thank you

Totally agree, Thomas
Always good to have Feature Requests. I encourage everyone interested to file such. 

Hi Juergen,

Do you have an updated script to store the password on other location aside from putting it on the Device Description. Sometimes people are provided with Read Only API on the platform and would gain access to those passwords via the Device description. Maybe storing them on a shared folder on JC's Password Manager?



Agree, it can be problematic to have it in the description field or any other rather unprotected one. 
I'd love to be able to store it in the PWM, unfortunately there's no API or CLI available for this yet. 
Also screams "Feature Request" 😉

Hi Juergen,

Appreciate you taking the time to respond.

Yeah it would be great if they can include it on the roadmap soon. Other than the description field any other channels (JIRA maybe) that we might be able to do with the current feature?

Now you got me thinking. 
Instead do writing it into the description field, it shouldn't be a crazy deal to make an API-call to Jira for example. (depending a bit on the version, hosted vs cloud). 
What do you use?

We are using the Cloud. The from JIRA we can have it stored on other channel. Just getting it from JC to JIRA would be nice. 🙂

Community Manager Community Manager
Community Manager

Best you could do, perhaps, is store in a secure note in a shared folder in PWM, but like Juergen said, no API to access it. But at least you could share it securely that way.

Like someone's post? Give them a kudo!
Did someone's answer help you? Please mark it as a solution.

Yup, had a word with JC reps and PWM API is underway maybe 1st Q of 2024 and hopefully this would be included on the first phase of the roll out.

This would be amazing in PWM!  Good stuff in this thread!