OS X Yosemite will not bind to AD

sanaumann
New Contributor III

Hello!

We just created a new Yosemite image. I just replaced 10.10.2 with 10.10.3. The images here are all basically identical except for a few minor items. However, our Yosemite image refuses to bind to AD while our Mavericks image continues to work perfectly.

I am using the same bind for both. I can manually bind the Yosemite machines once they are imaged, but that defeats the point of having it in there in the first place. Without the bind, no profiles are pulled down. Also, the machines are not enrolling in JAMF probably for related reasons.

I'm stumped. I'll redo the 10.10.3 DMG if I have to since it's the only variable, but I don't want to if it's not the problem. Any advice would be greatly appreciated. :)

PS: I'm looking for logs on a local machine after it has completed its image process. Do they exist there or on the JSS server?

Thanks,
SGN

1 ACCEPTED SOLUTION

sanaumann
New Contributor III

Hey, all. After eight hours with our integrator and three with our JAMF rep, we got it working. And it turned out to be something stupid simple.

1) Use Casper 9.72 Tools on our flash drive for imaging (we use 9.63 for our JSS and normally use 9.65 for Mavericks images).
2) Remove the AD Bind and the package we used for creating the local admin account in Casper Admin.
3) In Casper IMG, open Custom and go to Accounts. Add the local account there and give it admin rights. Also check the AD Bind box.
4) Image!

So far, it seems to be working. We've had a couple bumps on machines that have imperfect hard drive configurations (our Info Sec guys tend to do strange things to their Macs and then we get to fix them) but overall, it's going fairly well.

Thanks for all the help!

View solution in original post

38 REPLIES 38

tnielsen
Valued Contributor

They sure are working them real young these days...

mm2270
Legendary Contributor III

Is the time correct on the machines after they finish imaging? Time drift is always something that gets initially overlooked when binding fails. It may not be that, but I would check, just to rule it out.

If I'm not mistaken, there is no local imaging log stored on the Mac when using Casper Imaging, so I don't think there's anything you can check for there. But the JSS has an imaging log, and it may reveal something.

Just curious, but have you tried a test of using a binding script instead of the built in bind commands? When you set up a bind object in Casper Admin that CI uses, its calling the jamf binary's built in binding commands if I recall. Try using a custom script to see if it binds that way. If so, then somehow the jamf bind isn't doing what it needs to.

hkabik
Valued Contributor

So I have had some interesting problems with binding and 10.10.3 myself. Possibly related.

My new environment does not have Casper yet (luckily we are in the process of purchasing it now). So I have setup a custom .pkg that configures all of our settings post imaging to make things easier for our techs. On 10.9 machines this .pkg binds the machines just fine (via script)... but on 10.10.3 machine it not only fully locks up the machine, but totally corrupts the hard drive. I have to FSCK it just to get it to boot normally afterwards. I have also found the exact same effect if I try and run my bind script via ARD. Lock up > HD corrupt. It's 100% weird.

So I broke the bind portion of the .pkg out to a .command file, and when you run that... everything binds normally like the package (or remote script from ARD) did. It also binds just fine if the script is run locally or from the GUI bind process. But .pkg or ARD... womp womp. Fail>Lock Up>Corrupted HD.

I have not yet tested whether I get similar behavior from Deploy Studio since my predecessor had us working from a monolithic image - Disk Utility Restore process (and I'm only just now getting modular imaging setup here), and as we don't have Casper yet I obviously can't test that. But I thought maybe this odd behavior might be part of what you are experiencing so maybe it might help one of the genii out there solve your issue.

Or maybe I've just diverted the conversation... in which case please ignore me and cary on. :)

MAD0oM
Contributor

@sanaumann this write up may or may not help you...

https://derflounder.wordpress.com/?s=10.10.3

RobertHammen
Valued Contributor II

@sanaumann How did you create your 10.10.3 base OS? AutoDMG?

We already know that you're not getting binding... when you image, do you at least have the MDM profile in place? If not... you have two issues.

Can you look at the /var/log/jamf.log on the machine and see what is happening post-imaging? A first boot script will run, that should be taking care of the enrollment/profiles as well as the AD binding. Somehow that script may be failing.

What version of the JSS? What version of Casper Imaging?

Not applicable

Also how is the machine being named? https://support.apple.com/en-us/HT203193

sanaumann
New Contributor III

Hello, all.

That's my daughter, but she's 11 now. :)

The time is correct on the new images. That was the first thing I read about and checked off the list of possibilities.

We looked at the derflounder site but it did not apply in this situation. We have zero connectivity to our network pre-binding. And when we manually bind in 10.10.3, it works fine. Thanks for the information. :)

I thought about writing a script but I don't know enough about scripting in this environment to be sure I won't kill something important. I'm a native Windows scripter. I wasn't sure if I'd need to write something to unbind the machine first since some of these machines will be reimages, and then what logic to use to tell the script how to recognize when a machine was new, etc. #mightbeoverthinking

Hi, Robert.
Yes, I used AutoDMG.
No, we are not getting ANY profiles. If we manually bind a machine, we can also enroll it manually. However, it does not pull any down by itself until we enroll it. Self-Service is missing on the initial image as well. I don't know if there's a script in the image that runs post-first boot. Our JSS is 9.63, Casper is 9.5.

wdpickle
Contributor

Have you tried creating a new AD bind policy? We had an issue with a "corrupt" profile that worked on 10.9 but not on other versions.

sanaumann
New Contributor III

Trying a new bind now just for giggles. I'll let you all know.

sanaumann
New Contributor III

Pete, we are naming them by their SNs (without the S in front).

mm2270
Legendary Contributor III

I would also first try recreating it. if that doesn't work, you can attempt a scripted process, if just to see if it works as opposed to the built in function, which would point to some issue maybe with the built in binding function.

But, just so you know, If the Mac is re-imaged, its not typically necessary to first unbind, then rebind. Some places do that in order to keep the AD records more tidy, since just re-imaging without first unbinding will leave a record in AD for that Mac that doesn't match up with anything.

If a Mac gets re-imaged and ends up with the same computer name, for example if its a lab Mac and it always gets named with the serial number or something, when binding manually, it will ask if you want to overwrite the existing computer record in AD. This is typically OK as well, as long as you're certain its the same Mac (i.e, you aren't clobbering the AD record of another valid system) and the service account used for binding has the rights to actually overwrite an existing record. You'd need to check on that, because a lot of times binding accounts have the rights to create new records, but not update existing ones, for obvious reasons.

As for a scripted binding method, here's an example of that. On OS X you use dsconfigad to bind a Mac to AD (unless you are using a custom solution like Centrify)

#!/bin/bash

## Use your domain name between the quotes, usually something like "com.domain.pretendco"
dsconfigad -add "your.company.domain" 

        ## A username with binding authority (must have rights to add computer objects to the OU listed further down the script)
    -username "binding_username" 

        ## Password for the above user
    -password "binding_password" 

        ## Enter the computer name, or direct the script to pull the computer name with 
        ## something like "scutil --get ComputerName"
    -computer "COMPUTERNAME" 

        ## Set to disable if you don't want mobile accounts
    -mobile enable 

        ## Goes in hand with the above setting, warns on mobile account creation (enable), or not (disable)
    -mobileconfirm disable 

        ## Use disable if you don't want a locally cached home directory
    -localhome enable 

        ## Set to enable or disable based on whether the HOME should mount based on UNC path. Recommended to set to "disable" if you have users logging into their Macs away from domain controllers
    -useuncpath disable 

        ## Leave this as is unless you have a good reason to change the default user shell
    -shell /bin/bash 

        ## Set your OU to join the Mac to here (binding account used above must have rights to create/edit objects in this OU)
    -ou "OU=Macs,OU=Computers,DC=org,DC=company,DC=com" 

        ## Add any AD groups here that you want to allow local admin access on the Macs
        ## (while in range of your DC)
    -groups "ORGmac administrators"

Hope the above helps. Its just a template and I'm sure others will have different versions, or other recommendations.

One other thing. If you think you'll need to join to existing AD records, you need to add in -force after the dsconfigad -add "your.company.domain" part of the script. This forces the bind (join to existing)

AVmcclint
Honored Contributor

I've seen the same problem with our Yosemite image. However, I think there's actually a shift in WHEN the computer joins Active Directory. With Mavericks, it would join during the imaging process. With Yosemite, i've noticed that if I wait long enough (anywhere form 5 to 30 minutes) it will join AD after or during the post-imaging enrollment policy executions. I don't know why it waits until that point to join AD because our Yosemite image is basically identical to our Mavericks image with the exception of the OS. See if after a machine is imaged and it reboots, wait half an hour before even laying your hands on it to see if it did eventually join on its own.

donmontalvo
Esteemed Contributor III

TL;DR

A couple thoughts, have you checked to see if the computer is disabled in AD? If so delete it and then (re)bind.

Also if you're using a service account, make sure the password that JSS is using matches the one you're using when manually binding.

--
https://donmontalvo.com

JZing
New Contributor III

I'm struggling with the same problem too. I am creating a Yosemite image for the first time and cannot get it to bind to AD or to enroll with the JSS. The same bind package works fine with 10.9.

nessts
Valued Contributor II

check time on computers too if the time is off by >5 mins binding will fail.

JZing
New Contributor III

I got mine to bind and enroll! I was using an older version of Casper Imaging in my netboot server. I updated it to 9.72 and everything is working.

sanaumann
New Contributor III

I did a different bind, no change.

I tried the 9.72 tools in netbook, no change.

I recreated my OS X image, no change.

One thing I have noticed is that between the Casper screen and the black screen where it installs everything, it briefly pops up the Setup Assistant screen with the Yosemite background, which is really weird. It's like a second and then right to the black screen. Also, the dock is coming up with question marks for a bunch of apps that we don't allow, like FaceTime, Messages, etc. Something is seriously jacked up and all I originally did was replace the OS file.

Sad me.

sanaumann
New Contributor III

Also, we left one machine sit about 45 minutes and it did not bind.

I'm a little leery of using a script with a plain text password in it. Unfortunately, my company gets audited a lot and that's the kind of thing that could get me into trouble . . . ;)

mm2270
Legendary Contributor III

@sanaumann Not sure what may be going on in your case. You mentioned that the Setup Assistant pops up for a second and I wonder if somehow in your configuration, its not suppressing that Setup Assistant and the Mac is actually sitting there waiting for that to be dismissed and eventually times out. Since you can bind manually using all the same information, we know its possible for a bind to occur, but something is interfering.

Another possibility is that the jamf bind command isn't making it into your firstrun script, or maybe there's a timing issue on your network. There's a way to capture the firstrun script before the Mac reboots, but it escapes me how to do that at the moment. Maybe someone else can chime in on how to do that when using Casper Imaging.

As for the script and passing usernames/passwords in the clear, good point. My script was just posted as an example and not intended to be used as-is. You can pass almost all important items to the script as parameters so they aren't hardcoded into the script. For example, $4 becomes the domain, $5 becomes the bind username, $6 becomes the bind password and $7 can be the OU to bind the Macs to. If the script was ever located/intercepted, all anyone would see for those items are those parameters or variables instead of actual data.

sanaumann
New Contributor III

@mm2270 Yeah, something's strange but I'm still knocking around.

All of your help is appreciated, everyone! :)

donmontalvo
Esteemed Contributor III

@sanaumann did you try searching for and deleting the computer from AD? Also is the computer disabled in AD?

--
https://donmontalvo.com

sanaumann
New Contributor III

I'm actually an AD admin, so I went in and found one of the test MacBook Airs. It was not disabled. I deleted it out of the domain and after a while, readded it. I also compared all of its attributes with my machine to verify nothing weird was going on. It looked ok.

donmontalvo
Esteemed Contributor III

Maybe find/delete the computer object from AD, and then let the JSS policy re-bind?

--
https://donmontalvo.com

sanaumann
New Contributor III

So update time:

I was striking out on all of the suggestions I could implement from the JAMFnation, so I tried using a post flight script and put all of our scripts in it, set up a trigger, and let it loose. The result was better, we got profiles this time but still no bind (and a few of the scripts did not run but I'm sure I could fiddle with it and fix those).

I also tried putting a 10.10.3 update into a 10.9.5 image but that didn't work. I got our very pretty Mavericks image but the Yosemite piece didn't show up at all.

I decided to pull the InstallESD.dmg out of the Yosemite Installer, throw THAT into AutoDMG, and make a new OS DMG to put in the Yosemite build. It's about the only thing I haven't tried and the DMG is the only variable in this equation. I'll update again later . . . unless this also fails miserably, in which case you will all hear me screaming from wherever you're located because it will be loud.

~SGN

bentoms
Release Candidate Programs Tester

@sanaumann when you say "setup assistant" do you meant the "iCloud" assistant?

If so.. That's fine.

But seems like a clean OS.dmg might behave better, I've not heard much screaming so guessing so?

sanaumann
New Contributor III

Nope, same issue.

No self-service. No AD Bind.

At least it's Friday!

stillworkingonit

skeb1ns
Contributor

bump

Not wanting to hijack your thread but I'm on the same boat as of yesterday. The latest batch of macs that have arrived refuse to bind to AD. I didn't changed anything in my configuration (even with the 10.10.3 image I build when it was released, it worked fine) but now its broken.

My first boot script includes the line /usr/sbin/systemsetup -settimezone "Europe/Amsterdam" -setnetworktimeserver "time.euro.apple.com" -setusingnetworktime on to set the correct time and that works fine. Manually binding works with the same credentials used in the config so that's not the problem either.

To bad that Casper can't provide me with an explanation why it's failing instead of displaying the generic error "An error occurred binding to Active Directory".

Hoping to see a solution soon :).

bentoms
Release Candidate Programs Tester

@rschenk Can you verify/re-enter the credneitials & try the bind via Casper again?

skeb1ns
Contributor

@bentoms Done, reentered the credentials after first trying to do it manually (worked), but still no luck. I will try to use the script that mm2270 provided, maybe that will work.

bentoms
Release Candidate Programs Tester

@rschenk that would be interesting to see if it worked as AFAIK Casper is leveraging dsconfigad at the back end anyways.

skeb1ns
Contributor

@bentoms

I've just tried it script wise with dsconfigad and that worked as expected using the same service account!

It's getting interesting what is causing the issue when using the AD bind function in Casper doesn't work since it's essentially using the same method.

@sanaumann

I would encourage you to test if it works script wise. About that password in plaintext, the account that I'm using has only account operator rights so it can't do much harm if some obtains the credentials.

AVmcclint
Honored Contributor

For us, joining AD during the imaging of Yosemite Macs really is hit or miss. Mostly they don't, sometimes they will if I wait long enough. But for those that just flat out don't automatically join during imaging, I CAN use Casper Remote to send the command to join AD and that works 100% every time. It just sucks that I have to manually do that. - I've also found that FileVault does not automatically activate on Yosemite Macs at all during enrollment. That's another one that does work by using Casper Remote after imaging/enrollment is completed.

mm2270
Legendary Contributor III

@rschenk @bentoms is correct that the built in AD binding configuration (jamf bind) uses dsconfigad on the back end, but you just don't see it. If the example script I posted above is working, but the built in function is not, then this, in my opinion, points to an issue with the jamf binary, or the jamf bind command more specifically. It should work the same, so something's wrong if one works and the other does not. It may just be some kind of timing issue happening where it fires too soon in the process. Have you tried just putting a script as I posted in your firstboot run and that worked, or did you manually run the script after the fact?

If you haven't already, it might be worth a call to JAMF to see if they can replicate this or have any insight into what may be going on.
We use a custom scripted process that uses dsconfigad directly and does not use the built in AD bind config in the JSS, so we have not seen any binding issues here.

skeb1ns
Contributor

@mm2270

I first tested this separately as a startup script. I have now integrated this step in my first boot script which works flawlessly for the past couple of macs that I have imaged today.

mm2270
Legendary Contributor III

@rschenk Yeah? Well, then, sounds like there is some issue with the built in binding config setup. You're sure all the info you plugged into the JSS is identical to what you're using in the script? I would double and triple check that to be certain. If its all the same and the scripted process works and the other doesn't, then it sounds like it might be time to open a case with JAMF.

sanaumann
New Contributor III

Hey, all. After eight hours with our integrator and three with our JAMF rep, we got it working. And it turned out to be something stupid simple.

1) Use Casper 9.72 Tools on our flash drive for imaging (we use 9.63 for our JSS and normally use 9.65 for Mavericks images).
2) Remove the AD Bind and the package we used for creating the local admin account in Casper Admin.
3) In Casper IMG, open Custom and go to Accounts. Add the local account there and give it admin rights. Also check the AD Bind box.
4) Image!

So far, it seems to be working. We've had a couple bumps on machines that have imperfect hard drive configurations (our Info Sec guys tend to do strange things to their Macs and then we get to fix them) but overall, it's going fairly well.

Thanks for all the help!

sanaumann
New Contributor III

Our issue was that our first run script was not working correctly. Even when we debugged it, the script ran and there were no errors, it just didn't work. I had better luck with rolling all of our scripts into one post flight scripts and using a setup trigger but it didn't put everything out I wanted. Still kind of a noob at the policy writing.

Olivier
New Contributor II

Remember that for any AD troubleshooting in general, as the default message "An error occurred binding to Active Directory" will never help you, the appropriate way is to enable OpenDirectory module logging with "odutil set log debug" (and disable it immediately afterwards with "odutil set log default").

The logs are generated in /var/log/opendirectoryd.log.* . They are extreme verbose, but they contain 100% the root cause of the failed binding.
Stuff like Kerberos standard errors (date/time deviation, bad creds,...) or missing SRV records in DNS, DNS lookup failures, AD Site discovery process,... will appear there.