search

TheJumpCloud / MDM-Prestage-User-Enrollment

35 stars 11 forks source link

Enrollment complete Hanging #17

Closed dbjz closed 1 year ago

dbjz commented 1 year ago

The Enrollment Complete screen hangs. Seems to be indefinite. The enrollment user does not get logged out and the Bootstrap script never advances. MacOS Ventura, running the most up to date version of the scripts.
If you create a second desktop, you can logout manually and log in to the user that is bound during the process and the Bootstrap script finishes.

olaplex-tibby commented 1 year ago

The enrollment User doesn't get deleted either

jworkmanjc commented 1 year ago

Hey all, @dbjz @olaplex-tibby, I was able to validate this today. Sorry for not getting to this earlier. There was a change to the JumpCloud agent which prevented the last known secureToken user from being removed from the system. This project relies on this happening (at least for a moment until the next user logs in) I'll have to update the project to wait until a new user has secureToken before we remove the enrollment and decrypt users.

dbjz commented 1 year ago

Thanks @jworkmanjc Any timeline for an update on this

jworkmanjc commented 1 year ago

Hey @dbjz,

I did get a moment to test a thought on this today. My hands are a bit tied with what I can do ultimately but I did change the main shell script to hide both the enrollment and decrypt users, then forcefully logout the enrollment user.

At this stage the user would have to login to their new profile to finish enrollment. The script would hang as a launch daemon until it detects that the new user has logged in. Once that's happened the script would then remove the enrollment and decrypt users. From an enrollment user perspective, not much changes, we would just have to make sure that the user logs in or else the daemon can not remove the enrollment and decrypt user profiles. Do you have any suggestions or thoughts?

It's not a perfect solution but it's the only think I can do other than temporarily prompting for and writing passwords to storage, granting secure token w/o login & then prompting a password change. This isn't a route I want to explore due to the inherit risks.

dbjz commented 1 year ago

@jworkmanjc I think that will work. I will run a couple enrollments to see. Our main concern of course was the user not being able to complete the process. With the force logout and hiding the users at the login screen it makes it easier.
I totally agree with not wanting to go the prompt and storing passwords. The workaround you proposed sounds like the best route to take.

jworkmanjc commented 1 year ago

@dbjz I should have a branch up today after I run a few more tests. You are welcome to help test and validate but I'll post here when the branch is in a good state!

jworkmanjc commented 1 year ago

@dbjz

I've got the changes to the enrollment script that we would need in this branch: https://github.com/TheJumpCloud/MDM-Prestage-User-Enrollment/tree/SA-3426_enrollmentPostAgentSecureTokenProtection

There's still some validation and recovery items I would need to add to this body of work but if you want to rebuild and test the workflow you can give the changes in this branch a shot! I should be able to wrap up what I think remains this week.

jworkmanjc commented 1 year ago

@dbjz,

The only issue I'm running into with this flow is the fact that rebooting after the initial user is logged out will break the process. I'm going to see if I can get tricky with the script but it'll take me more time to figure out a good solution.

My guess is that most folks are going to login as their user account and not reboot but I don't want that to break the enrollment if someone accidentally clicks restart.

Best, Joe

jworkmanjc commented 1 year ago

I've got a PR open on this Issue #18, a few things are addressed in this code change but It's undergoing final review now. I'll plan to close this issue when we merge this in.

Of note, the entire process of removing the first and decrypt users is reworked, if you are curious, check out the PR #18, it explains the new process in more detail. In one sentence, the order now changes and a JumpCloud command is now used to remove the enrollment users.

jworkmanjc commented 1 year ago

I'm marking this closed, the last merge should address the issues noted here. There are a number of changes in the latest release, namely, I'm invoking a second process to clean up the enrollment users though JumpCloud Commands. This is a change in process but not really behavior.

Resolved in #18

Moving forward, we can continue to address bugfixes but I'm really in favor of folks using their MDM SSO enrollment to get information about JumpCloud users as opposed to this tool which is becoming needlessly complex and difficult to support.