Requiring authentication for DEP Enrollment

smithjw
New Contributor III

So I'm currently selecting to use authentication when people enrol their Macs into JAMF. Where I'm running into issues is where new employees start and requiring them to to auth with LDAP creds (AD) during the Setup Assistant.

Because these employees are new to the company they are given a temporary password on day-one which is required to be changed upon first login which presents an issue when they try to auth to setup their Mac. The Auth fails because they need to change the password, but can't because their at a pre-boot screen.

What this leads to is having an employee login on their mgr's Mac and setting a new password then being able to setup their Mac. This isn't a great experience and one I'd hope to change in the future.

What are other people doing in situations like this?

9 REPLIES 9

jared_f
Valued Contributor

What about creating a script that would require the password change a little after login and enrollment are complete (i.e. 10 minutes)?

ktappe
New Contributor III

Is there any way you can relax the requirement to immediately change the password? For example, it could be set to expire after 24 hours instead of on first login.

smithjw
New Contributor III

Thanks @jared_f / @ktappe. I was actually thinking about something like that but I don't have much experience with Active Directory. I did happen upon a PowerShell script that when run would trigger a user account to be marked as requiring a change on the next login, but I'd need to figure out how to trigger the script to run after the first successful authentication attempt.

The other option I was thinking about is having a policy that runs as part of enrolment and send's off a remote command to AD to run this script. That way it only kicks in when the employee has successfully authenticated, and has completed the setup of their Mac.

RJTablante
New Contributor II

We're seeing the same issue at our org w/ new user accounts requiring auth as well for enrollments. Seeing that it's 2018 now, have we progressed on this issue so that new AD user accounts that have a temp password w/ requiring them to change it on login are allowed to progress w/ enrollment?

qsodji
Contributor

@smithjw Here is a suggestion
I am assuming you are using AD here and your computer isn't bound to AD, although bound or not shouldn't matter much.
Ensure password complexity is set on AD and then manually or via script set the AD password to something that doesn't meet the complexity.
Uncheck the reset after login option as you won't need it anymore
Deploy a computer level passcode profile to the computer ensuring password complexity matching AD. Once the user has authenticated for DEP, the profile will be installed and by the time the user has to create an account, the temp password will fail complexity and have to be changed. This also ensures by the time the computer is ready to be used, the temp password is no longer.
Hope that make sense to you.
You could also, and this is if your computer is bound to AD, have as part of your enrollment process a script that will trigger a change password at login on the Mac which will then restart or log the user out and up on logging in again be prompted to change the password.

rderewianko
Valued Contributor II

The other option, is a generic DEP account that you utilize just for logging into DEP (Changing that password weekly or something).

qsodji
Contributor

One thing to keep in mind about that is the account used to validate DEP is the one designated as the MDM user.
If you are bound to AD, you should be able to add other users but having the wrong user associated can affect your scoping when dealing with profiles etc..

int-corpit
New Contributor II

are there new ideas to this?

we have a similar situation, but also involves enrolling MFA in Okta:

we use Okta as our identity provider and SAML/LDAP endpoint for Jamf.
i've created a group, and users that are a member dont need to enroll MFA, this way they can enroll through DEP and have a working phone, which they can use to setup MFA.

Now the next time they visit Okta from a browser, they are required to setup MFA, and they enroll still using the initial password.
the user has enrolled to MFA, and we have a script running that checks if the users that are member of the particular group have mfa, if they have, they are removed from that group And are required to reset their password.

hopefully we can have something better.

jonnyteix07
New Contributor

Any further development on this? Really hoping to come up with a better solution then to having a user reset their password first.