DEP and Active Directory Binding

One suggestion you have likely already checked but it caught me here.

Make sure your "binder" AD account has the right permissions on the AD side. For a long time we noticed that a Mac would bind well the first time out of a brand new box, but fail to bind after we wipe the device to give to someone else. My AD guys had to tweak with the permissions on our binder accounts to get re-adding done right.

@sgoetz I'm able to include our JSS AD directory binding in my pre-stage/enrollment policy and it works, I can login as a domain user directly after the policy runs.

However, it ends up binding with computer name "No Name" even though one of my before scripts is setting the computer name properly. So I just switched to an after bind script and all is swell.

@sgoetz I'm able to include our JSS AD directory binding in my pre-stage/enrollment policy and it works, I can login as a domain user directly after the policy runs.

However, it ends up binding with computer name "No Name" even though one of my before scripts is setting the computer name properly. So I just switched to an after bind script and all is well.

@dpertschi you mentioned you are switching to an "after" bind script here. We are and have had issues with DEP and directory bindings. Our issue is similar. The Mac is pre-enrolled into the JSS with a name like Mac mini. We have a configuration profile do our binding for us. With this profile, we have it scoped to exclude to our DEP Macs, those that have the "generic" name attached.

When we change the name, then the computer can be bound. However, the actual computer name hasn't been updated on the client just yet. The computer will still bind with the "generic" name. We added to our policy for deploying applications the rename function to match the JSS record. This works flawlessly with the exception of the name that is added to AD. We are working around this issue in our testing, but it sure would be nice to have a script that will bind when all of this is done.

I am intrigued with what you are doing with an "after" bind script.

@dpertschi and @sgoetz

Man you guys have brought up an issue i have been trying to tackle for a long time now. In my environment we also bind machines to AD and are part of the DEP program.

When using my prestage enrollment i have been speaking with my STAM to find the best way to get to zero touch as much as possible with using the DEP method. The problem i am having is that i need my Hostname of the system to be determined prior to binding for those exact reason of being bound in AD as xxx's macbook pro etc. And be able to bypass the create a local account step and just get to the blank line for user name and password with the system bound to the domain awaiting the user to log in for the 1st time as them with AD creds.

If anyone has a better process or an answer that would be amazing. Also if you have a good script to input hostname request from the user.

@bjones I have had to work around this process as I have found it problematic for precisely the reasons you mention. I have yet to actually type up my workflow and I am sure there will be those that have a better way, but for us, it is very hands off, for the most part. I will try to type something up to describe the process. I really wish it was truly zero touch. I just cannot find a way to do that.

It feels like no matter what, I am going to have to touch the computer, if for no other reason, to turn it on. We are deploying over 300 new systems this summer and somehow, someway, those Macs have to be turned on and touched.

I know this isn't really helpful but I want to point out that DEP was designed without AD in mind. Your posts and my research sure make AD with DEP is a square peg in a round whole.

I think you best bet would be a thin image using the factory OS or a NetInstall, then have Casper add the files and apps you need.

C

Hey All,

My original post was really about getting the Directory Binding to work at all using the Prestage. I figured out what I was doing wrong and it is not very well documented from what I can find, but if you don't check the box "Skip Account Creation", DEP will skip Binding the machine to AD. So once I checked that box. The machines bound to AD just fine.

Now I haven't tackled the AD binding name problem yet, but my general thought is I will write out some kind of script that will unbind the machine, change the name based on our naming convention. and re-bind the machine. And clean up AD afterwards. The reason is, I know the person is on the local network to be bound to AD since it just did it. So I shoudl be able to quickly unbind and rebind the machine.

Thanks for all your feedback

Shawn

@mconner @bjones Luckily, we just use serial number for computer names.

So my bind script uses serial number for the computer name, and is run at the end of the policy.

We just went through a new naming convention scheme here and with AD, we "were" limited to the number of characters we could use. Because I am a rebel being the Mac guy, I have modified this to meet our needs. Now the AD guys are happy and so I am.

@sgoetz if you wish to see my workflow, I have a very high level document that explains what we are doing. If others want to see it, just fire off an email to me; mconners@madisoncollege.edu, I will be glad to share what we are now doing. It may give you some new ideas or avenues to take.

Hope it helps...

@sgoetz

That is what we did unbind and rebind.. wasn't happy about having passwords in scrips I was able to use the jamf commands to hide the bind password but never came up with away to hide the unbind password..

C

PS also time was an issue as I had to unbind wait and the rebind I think it ended up being a few mins between them. ( that said we had tons of issue bound to AD and I am not 100% sure this wasn't part of the issues. ( we killed AD binding )

Hi all,

We have been running into issues with DEP, AD Bind and mac names and I came across this thread.

What we found is at DEP the user authenticates to AD and the Mac is bound to AD but the name of the Mac will be something like Mats Macbook. This is then the object created in AD which is not to our AD standard.

To get around this we script an unbind, name the Mac again and rebind however even though the Mac's 3 different names are set (ComputerName, HostName, LocalHostName) it still rebinds with Mats Macbook We double made sure the bind is gone by running a policy to delete the directory plist

We have tried all sorts but cannot get it to bind with the new name set.

Any tips here?

@dpertschi Would you mind sharing your bind to ad script? This is a thread I started today. Long story short, I created a policy to first name the computer the serial number in all three places on the mac and then mark it's priority as BEFORE, then included a Directory Binding payload configured via settings>computer management. We are seeing that an average of 3 out of 5 machines will bind successfully, but it says "binding No Name". Those have a failure message of: An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 1). Am I missing something in my script?

#!/usr/bin/env bash

# Get the Serial Number of the Machine
sn=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}')

# Set the ComputerName, HostName and LocalHostName
scutil --set ComputerName $sn
scutil --set HostName $sn
scutil --set LocalHostName $sn

Hello All,

Maybe we are doing things a little different with our DEP and AD binding piece, but we are keeping things as simple as we can.

We use a policy set to run early in the policy stages to bind using the built in binding process setup under the computer management section. We have this running on ANY Mac that isn't currently bound to AD (we use a smart group to determine this). Next we exclude specific computers such as those computers that come into the JSS via DEP. These computers will usually have a name such as MacBook, iMac, Mac mini or DEP-SERIAL NUMBER. Once we correct the name of the computer, then the process begins as it is set to run at check in.

I heard using the ClientID field in the directory payload, using something like $SERIALNUMBER variable will change the computername during the DEP process. Apparently there are other variables that work too. I'm new to DEP so...

https://www.jamf.com/jamf-nation/discussions/24364/valid-client-id-codes-for-directory-binding-with-prestage-enrollments

This may be too late for this thread, but I found this statement in a different Thread that really helped me with this issue.

From: https://www.jamf.com/jamf-nation/discussions/13965/ad-directory-binding-computer-name

"So it turns out that the JAMF Directory Bind takes the hostname at the START of the policy execution as the name to bind it with.

I ended up making two policies to solve this:
1) Runs the Computer name prompt/change script then calls a jamf policy custom trigger to a policy
2) Sets to execute at the custom event to perform the binding."

Hope this helps others cuz it really helped me!!!!!

I think this has been hinted at in other posts....

This process was suggested to us by a Jamf engineer.

We do not bind during pre-stage, main issue for us was timing of naming/binding the computer as mentioned in other posts.

Solution was to bind during software provisioning. After pre-stage we run a provisioning script that installs software packages - first line of the script prompts and sets the computer name - last line of the script runs a bind policy.

Our naming convention means we have to name computers manually so our best result would be One Touch.

Not sure why, but this issue started affecting our org recently after 10.42 upgrade
-We rename our macs to Serial as one of the 1st policies to hit the system

-We deploy policies for standard software

-One of the last policies is to domain bind with the Director Bindings policy payload

Macs are showing up in ADUC as "No Name". Is anyone seeing this as well? Suggestions? We can't add to our prestage...not all Macs get bound here.