Pre-Stage Enrollment and DEP

@mconners on the Account Settings page of your DEP Prestage Enrollment, you'll see "Skip Account Creation". Make sure that is enabled and the user will not be prompted to create an account.

Thank you @stevewood, I saw that there the whole time but it didn't dawn on me to click it. Sometimes looking too long at the same screen can be a problem. Trying again to see if I get the out come we need. Thank you.

The only word of caution I would give with not allowing a local account to be created is that if for some reason the machine fails to bind to active directory (or any other directory services), you will have no way for the user to login to do any troubleshooting. The only option would be to wipe it and start again. Instead of going down this path, why not create a local account (it can be an admin or standard account), and then run a script post-enrollment to validate that the machine is bound to AD, and then delete the current account and logout the user?

Thanks @jzeles for the advice. What we ran into in testing is, if a user creates a new local admin that is identical to their AD user name, which is likely to happen, then the user will not login with their AD creds after this setup. They end up using only this local account that was created.

We do have in the pre-stage enrollment a setting to create the management account so we should be able to login with that account even if AD binding fails.

Obviously this is very new to us and much more testing is needed. Right now, I am getting hung up on naming of the enrolled system so we can scope it to the appropriate policy for deployment of applications. We are experimenting with JSS MUT as well.

Hey, I had the exact same problem! What I am doing is that once the machine is bound to AD, I am deleting the user and the user folder, and then logging the user out.

What is your naming convention?

I think I have this working, sort of. It took a while to understand what was happening, the descriptions and titles for the fields in the JSS are little fuzzy in logic.

Anyhow, we have the logic working so upon setup the first time, the user is required to enter in their network ID and their password. At the account creation screen, the user is asked to enter in their full name. This works too. However, when the user is logged in after the setup is complete, the user should be a mobile account as this is set in our directory setting in the pre-stage enrollment.

It is creating the account without an issue, but the account isn't, to my knowledge, a local mobile account. It is simply a local account. I am close to having this ironed out, but I think it is something I am missing with AD/Local accounts tied to my directory settings and my pre-stage enrollment.

@mconners what is not readily clear is that the management account you set under Management Settings -> Global Management-> User Initiated Enrollment is placed on the system when enrolled via DEP. So the management account you put in the PreStage Enrollment is an additional account or duplication of your effort. Make sense?

Thanks @stevewood this makes sense now.

Okay, I have a directory binding in place for pre-stage enrollments. However, when I enter in my user name and password at the enrollment stage, it is not creating a mobile, managed account in users & groups. Therefore, the user who enters in their user name and password based on the settings you mentioned, are not getting setup as an AD user.

Am I missing something?

I feel we are close with that exception. Thanks again!

@mconners so when you are asked to authenticate with your LDAP creds during the enrollment that is primarily for authorizing and assigning the user to the computer in inventory.

If you have the pre-stage set to allow local account creation, setup assistant tries to be helpful and fill in the account name and password with what was entered in when asked for LDAP credentials (though doesn't fill in the full name field as you described) but this is still always just a local account.

If you look at the last screenshot you posted, you still have it set to allow the creation of a local account (and so the user is still getting promoted to create one). Change that to the last option of Skip Account Creation.

So what will happen then is user boots machine connected to network, goes through setup assistant, gets prompted to authenticate to ldap for the inventory record information, machine enrolls into Casper and your "create additional admin account) takes care of creating your admin user silently in the background, your directory binding payload binds to AD, and the user just gets dumped at the login window without being asked to create any account. If the binding worked properly they should be able to log in and then assuming your directory binding profile or script was set right, it should create their mobile account.

Thank you @chriscollins that is spot on. We have this working, thanks!! I was right in the middle of changing this as a troubleshooting step and it worked. I have to find a way to remove the "other" at the login window. Typically, we have the username and password fields showing.

Since the Mac isn't receiving any other profiles at this point, it is not receiving that piece of it. Once the computer is named correctly and moved into the correct group, it behaves normally.

So I think this is it. I have this enrolling and the behavior is what is expected. Thank you everyone!!

I tried playing around with this, but there are a few things missing that I'd like it to do:
- Ability to enter a custom computer name. We use asset tags with a three or four letter code. Example: 400400mba, 400401imac, etc. This then becomes the hostname, and localhostname which becomes the computer record in AD.
- After loading the MDM profile, other config profiles should install. For example, "Bind to AD," "Join Company WiFi," etc.
- Pre-assign the computer to a department. If this iMac is for "Production," then I'd like it to start downloading the software for Production computers after it enrolls.

So, for now, it's still a bit cumbersome for regular users to do on their own. Too many steps will confuse people and will cause errors.

For now, I'll continue using Casper Imaging. Though, I'm now opting for using a thin-imaging configuration without laying down an OS dmg.

@itupshot I discovered this being a bit cumbersome as well. My goal for this entire thing was to discover a new workflow. What I have found though is I can get the computer into the JSS without any problem. Until an account as been laid down to the hard drive, the computer sits as unmanaged. Through some manipulation, I can make this work. Like you said, cumbersome.

So, to manage all of this, I might just continue with Casper Imaging. Thin-imaging is likely the path I will take for new computers as they come in.

Again, with the thought of Casper Imaging disappearing, this was an exercise in how to create a new process without the use of Casper Imaging. While JAMF tells us there isn't an immediate desire to remove it, I still want to be prepared.

We will see how this all shakes out. My regular casper imaging process is quick and slick and works well so for now, I am sticking with it.

Mick

Hi All,

We are in the same process of trying to get rid of imaging. The process we are testing so far is pretty much the same, but since we have a tech touch each computer before the end user gets it we have some freedoms to do things a little differently, maybe you can adapt it to your process or maybe not, but figure ill share either way in case another Jamfer comes across this post.

DEP PreStage Enrollment is the same except we do not join it to the domain during PreStage.

I make our MDM profile mandatory to the scoped machines (once we get his 100% working I hope to have all machines get the Profile so i wont have the step of manually scoping by serial number)

Create a local admin account (so that our tech can log in and do a few tasks that i can figure out how to automate)

Skip all of Setup Assistant (which i could skip the Map time zone selection hopefully someone figures this out in the future)

I also have it assigned to a Site, that site has some policies that set the login window to be username and password with a configuration policy, and obviously a bunch or Policies that install software and whatever else is minimally needed.

The tech logs in, (after a time period that gives Jamf time to install everything about 30 minutes currently) Opens Self Service and with a Self Service Policy i prompt for computer name (using a scrip, let me knwo if you need the script) and then bind to AD by linking the two polices. This gives me the proper naming we are required by my management.

Wish i could prompt for computer name during the DEP PreStage Wizard because then i could bind it part of PreStage and save a few steps for the tech and potentially deploy directly to the end user.

Currently I have a manually step in JSS to move the computers into a different Site at which more policies and SmartGroups based on computer names will kick off.

-Peter

@szultzie , We have a very similar process where we have a tech touch each computer for our staff. I am looking at doing a workflow very similar to yours since we can't name computers during the pre stage enrollment process. Could you share the script that you are using in Self Service to rename and bind.... that sounds exactly like what we need.

Diane

We more or less mirror @szultzie

However, at this time we don't automatically create a local account for the following reason: To enable Filevault in 10.13, a local Admin account with a SecureToken is required. When automatically creating this, we found that the SecureToken wasn't being applied.
So, During PreStage, The Tech creates a local Admin Account and all is well.

A policy then runs and presents a script to Name the Mac and bind to Active Directory

>>#!/bin/bash

functions

function machinename () { osascript <<EOT tell application "Finder" activate set nameentry to text returned of (display dialog "Please Input New Computer Name" default answer "" with icon 2) end tell
EOT
}

function renameComputer(){ #Set New Computer Name echo "The New Computer name is: $ComputerName" scutil --set HostName $ComputerName scutil --set LocalHostName $ComputerName scutil --set ComputerName $ComputerName

echo Rename Successful
}

Script

ComputerName=$(machinename) renameComputer
exit 0

We then run a script to select a department, then this triggers a number of Policies to finish building and installing all components and Applications.

More or less a fully automated System now.

:-)

I'm happy to share the Department script if required.

@kerouak Thank YOU! This works great! I put it in self service with our AD bind and the tech can enter the computer name and bind all at the same time!

Diane

@dscro Sorry i forgot to bookmark this thread, and have not checked up on it. I actually re did some things in the past few weeks, and implemented splashbuddy to this workflow.

So everything is he same except i changed to what @kerouak does meaning do not create the local admin account using Jamf, same reason stupid SecureToken, (but i find that when my tech creates the local admin account during the wizard i still don't get a securetoken for that account (in 10.13.4) not sure if its a bug or if i'm doing something wrong, currently trying to figure that out), but what this does it makes the OS log in automatically for the first time, and then SplashBuddy takes over. Now splashbuddy is pretty cool tool, the basics of it is that it reads your Jamf log and gives you a nice GI that a tech cant exit until everything scoped to on enrollment finishes, but the added bonus it can handle text input. So Once SplashBuddy launches i have it ask for a computer name, which gets stored in a text fle on the computer, then i have a script that pulls the name, renames the computer and joins it to AD. The script is below.

So SplashBuddy does three things for us, 1 no longer have to tell the techs they have to wait 30 minutes for everything to install, because i give them a GUI that tells them whats going on, shows each app that is currently being installed (only what you want them to see, very customizable), 2 it forces them to name the computer and joins it to AD for them, so they cant forget to do that in Self Service before they give it to a client, 3 prevents them from just bringing the computer to a client after they "image" it (happens more times then i would like to admit, we use student workers for a lot of our Desktop support tasks)

#!/bin/bash
set -x #echo on
exec > /Users/admin/Library/Containers/io.fti.SplashBuddy/Data/logfile.txt
exec 2>&1


sleep 10

while [ ! -f /Users/admin/Library/Containers/io.fti.SplashBuddy/Data/asset-tag.txt ] ;
do
      sleep 2
done


file=/Users/admin/Library/Containers/io.fti.SplashBuddy/Data/asset-tag.txt

while IFS= read -r varname; do
    printf '%s
' "$varname"
done < "$file"


osascript -e "display notification "Changing Computer Name to $varname.""

/usr/local/jamf/bin/jamf setComputerName -name "$varname"

sleep 5

/usr/local/jamf/bin/jamf recon

sleep 5

/usr/local/jamf/bin/jamf policy -event join4

sleep 10

/usr/local/jamf/bin/jamf recon

sleep 5


echo Computer has been renamed and joined to the domain. > /var/tmp/done.txt


exit 0

In the script above, i use a policy that joins to AD called "join4" set as a custom trigger, the rest commands are built into the jamf binary.

There are some SplashBuddy contents that I could share just PM me if your interested in it. Or i can post here if more people are interested.

-Peter

Here is the original script i was using with a Self Service Policy in case you want to stick to that with out SplashBuddy.

script='display dialog "What is the Computer Name?" default answer ""
set ComputerName_answer to text returned of result
-- display dialog ComputerName_answer'

computerName=$(osascript -e "$script")

osascript -e "display notification "Changing Computer Name to $computerName.""

-Peter
jamf setComputerName -name "$computerName"

jamf recon

#sleep 5

# jamf policy -event Bind

Bind is a custom trigger to yor bind policy in JSS.

So just a follow up, turns out I hit this PI.

(PI-005185) macOS DEP management account creation variations

"Management account home directory is created in /Users/ and UID is set to 501 (first account created)

If you enable the Account Settings payload none of the accounts created get a secureToken which should be granted to the first account created and is needed for filevault functionality."

So hopefully it gets fixed in the next version of Jamf Pro.

-Peter

In JAMF 10.4.0 and macOS 10.13.4, the local admin user that is created by the DEP enrollment does have the secure token.

Great so i need to upgrade to Jamf Pro 10.4, wonder what will break after this upgrade. I also wonder if Jamf 10.3 and 10.13.5 using Internet Recover to do a DEP workflow is causing not being able to enroll in Jamf.