Nope, same issue.

No self-service. No AD Bind.

At least it's Friday!

stillworkingonit

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 :).

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

@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.

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

@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.

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.

@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.

@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.

@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.

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.

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.