Retroactively creating Jamf LAPS capable admin accounts???

[ericbenfer]

I am working with a Jamf environment that currently does not have any Jamf LAPS capable admin accounts.

They did not create a “Management Account” in User-initiated enrollment.

They did not create a “local administrator account” int PreStage Enrollment.

We have since specified a “Management Account” and a “local administrator account”. With two separate names.

They are using Apple Business Manager Automated Device Enrollment. There are some locations that do not have ABM, so they are using User-initiated enrollment. (That is begin resolved).

LAPS is working with newly enrolled Mac systems using either admin accounts. 

Is there away to retroactively add a User-initiated enrollment “Management Account”?

I’ve tried using “jamf policy -trigger enrollmentComplete”. This will successfully re-run the enrollment policies, but it does not create the “Management Account” from User-initiated enrollment.

“profiles -N” does work. But that requires user interaction.

Thoughts?

[ericbenfer · Accepted solution]

The goal here is to create a valid Jamf LAPS account, in case the “Management Account” in User-initiated enrollment, or the “local administrator account” in PreStage Enrollment were not created during initial enrollment.

Here is what I've come up with. 

We can use the "jamf enroll" command with an invitation id.

This will "re-enroll" the system into Jamf and in doing so will create the “Management Account” specified in User-initiated enrollment.

In Settings > Global > User-initiated enrollment > Management Account – enable Create management account. This must NOT be the same as the account in Pre-Stage Enrollment. 

In Computers > Enrollment Invitations – Create a new email invitation. Critically be sure to enable the invitation for multiple uses. This is where you will get $invitationID

Then setup a policy to run /usr/local/bin/jamf enroll -noPolicy -invitation "${invitationID}"

Setup a smart group "Managed By is not $yourManagementAccount"

Scope the policy to "Managed By is not $yourManagementAccount"

As always TEST TEST TEST in your test jamf cloud instance first.

[TheAngryYeti]

For UIE (Jamf) LAPS - simply create a policy to push out the desired user to endpoints.  After a recon, the system will pick up that the user is present and start rotating that account.

[ericbenfer]

No luck so far in testing.

I setup a “Management Account” in User-initiated enrollment – "jamfmanage".

I created a policy with the Local Accounts option. It creates an admin account named "jamfmanage" with a static password.
When the policy runs it successfully creates the "jamfmanage" account. I can even log into the account.

However, jamfmanage does not show in the inventory of that computer as a Managed By account.

The password is never rotated via LAPS. :-(

[msw]

The last time I checked the documentation, it stated explicitly that the account must be created at the time of enrollment, and could not be created later. That was a few months ago though, so possible something has changed.

[TheAngryYeti]

My Apologies....If you previously had it set up where the management account was listed yet not on the device before the auto-activation rollover in 10.49 you could just push a policy to create the user and it would pick it up.  It does look like you do indeed need to do a re-enrollment to get it to display as managed by and also be listed in the API as a viable account. for some reason I cannot put a picture here of the API, but it shows both MDM and JMF Laps accounts now where I was also seeing it as Ericbenfer mentions.

[ericbenfer · Accepted solution]

The goal here is to create a valid Jamf LAPS account, in case the “Management Account” in User-initiated enrollment, or the “local administrator account” in PreStage Enrollment were not created during initial enrollment.

Here is what I've come up with. 

We can use the "jamf enroll" command with an invitation id.

This will "re-enroll" the system into Jamf and in doing so will create the “Management Account” specified in User-initiated enrollment.

In Settings > Global > User-initiated enrollment > Management Account – enable Create management account. This must NOT be the same as the account in Pre-Stage Enrollment. 

In Computers > Enrollment Invitations – Create a new email invitation. Critically be sure to enable the invitation for multiple uses. This is where you will get $invitationID

Then setup a policy to run /usr/local/bin/jamf enroll -noPolicy -invitation "${invitationID}"

Setup a smart group "Managed By is not $yourManagementAccount"

Scope the policy to "Managed By is not $yourManagementAccount"

As always TEST TEST TEST in your test jamf cloud instance first.

[ericbenfer · Accepted solution]

I've an update to the smart group. "Managed By is not $yourManagementAccount" does not seem to work.
So I'm using "Local User Accounts does not have $yourManagementAccount"

As always TEST TEST TEST in your test Jamf Cloud instance first.

[markopolo]

Dude, thanks so much for this - you saved my bacon! I was trying to figure out how in the hell I was going to re-enroll 1,800 devices.

[colorenz]

@ericbenfer @markopolo @TheAngryYeti 

Is it safe to do this? Are there any problems doing this with DEP Macs to get that account created? Have you noticed anything?

Best Regards

[markopolo]

It worked well enough for me, but I was only using it for my UIE-enrolled Macs (I don't know why it wouldn't work for ADE-enrolled; it would basically just convert your ADE to UIE-enrolled). One caveat: it wiped out the user info on each computer and replaced it with the info from my user invitation. To fix that, I downloaded a report of all the computer records beforehand, then after re-enrolling I used MUT to re-add the user info.

[liubkkkk0]

I did everything as you recommended. As a result, I got a jamf binary account as I wanted with a password of 29 characters. The only problem is that this password does not change, I can change it only by running the policy with "Rotate Account Password". Your method was supposed to be my salvation and it still doesn't work for me

[ericbenfer]

You would only apply this to Mac systems that do not have a functioning Jamf management/LAPS account.

As always TEST TEST TEST in your test Jamf Cloud instance first.

[TheAngryYeti]

Here is a script from Bill that addresses this issue directly for those who are following this.  
https://gist.github.com/talkingmoose/9f4638932df28c4bebde5dd47be1812a