Binding macs have a host of challenges associated with them: Not connecting to the LDAP server, binding under the wrong name, and the infamous “keychain error.” Utilities like Enterprise Connect and NoMAD came about to give admins the features of binding without the potential challenges. Even with that, many admins still bind their mac computers.
This is not about the challenges of binding in general, though. This is about the challenges admins face when specifically trying to bind through DEP with a zero touch deployment. The ability to bind a computer through the setup assistant came out in Jamf Pro 9.9 – and was a pretty nifty feature for enterprise companies that wanted to bind their macs, but still have a zero-touch deployment. However, it has had a number of problems since it’s inception. Lets take a look at each one:
Problem #1: Wireless Network
In order to kick off DEP, the user needs to connect the computer to a wireless network, and this network would be the one that is used to bind the computer. Many companies require a certificate for their production network, and often deploy it through their MDM, which wouldn’t be in place until after the user went through the setup assistant, in which case, it has already attempted and failed to bind.
Problem #2: Computer Name
Since the user is getting a computer new from the box, the admin has no control over the computer name, which is typically used to bind the computer. By default, all the computer names would be based on the model, so if you’re company is full of MacBook Pros, the names would all be the same: MacBook Pro. This creates problems, since the computers will all try to bind under the same name. Luckily, admins can get around this by binding with the serial number instead of the computer name. However, that limits the admins from sticking to any type of naming convention for their macs within AD (and if you’ve ever managed a robust AD account, you know how important naming conventions are).
Problem #3: The Account Settings Payload
By default, users create a full local admin account through the setup assistant. In doing this, many users will make the username the same as their AD username, which creates problems when the user tries to login with the same username when the computer is bound. Luckily, the Account Settings payload allows you to skip the initial account creation, thus eliminating the problem.
However, the Account Settings payload has had a number of issues since its inception, from messing up the name of the computer (minor problem) to not installing the Jamf binary (major problem). Because of this, I recommend customers do not configure it during my jumpstarts. Which basically makes binding during the setup assistant impractical.
The Solution: Bind After the Setup Assistant
If you want a truly zero-touch deployment, at least until some of these issues are resolved, binding after the setup assistant is the way to go. With the power of Jamf, and some scripting magic, this allows you to:
Connect to the production network before binding
Rename the computer based on your company’s naming conventions before binding
Never have to configure the Account Settings payload!
What we need is a powerful workflow inside your Jamf server to make this happen.
The workflow
A prestage enrollment with computers scoped to it. I’d recommend requiring authentication if your Jamf server is connected to your LDAP server.
A configuration profile that deploys the wifi network (if applicable)
A policy which executes the following in this order:
A script which renames the computer. I’d recommend checking out this blog post for instructions on how to do that.
Binding the computer to the directory server.
A script that deletes the initial account the user sets up. I’ve created that here.
And that’s it! I haven’t actually tested this workflow, because I’m too lazy to setup an AD server to bind a computer to for testing, but I’ve seen it enough that I thought I should make a workflow for it. If you try this workflow in your environment, let me know how it works!