have you verified the clock skews and stuff? ours hasn't broken that I'm aware of for upgrades or fresh installs.

Are you seeing this on upgrades or fresh installs?

Clocks are spot on.
Both. As well as manually trying to bind to AD and/or get a TGT. Unbind a Mac that was bound and try to rebind it using Casper OR manually.. failures.

We've confirmed it on half a dozen Macs so far.

I'm still waiting to hear from our enterprise core services folks to see if anything has changed in AD/DC.. but I doubt it. I'm also delving deeper into whether 10.10.3 pre supplemental actually works or we just got lucky a couple times.

@yellow I'm not having any issues with manual AD bind or via the JSS with build 14D136. Both Create mobile account at login and Force local home directory on startup disk boxes are checked in my Directory Bind in the JSS.

The only Yosemite lab I have on campus was experiencing the dreaded "50% Startup" issue for a long time.

10.10.3 appeared to resolve it, but the Supplemental Update was pushed out last night, and I came back to work to find 13 of 27 iMacs frozen at 50% of the boot process again.

Anybody else have this return?

I think the core services folks changed something... just verified that vanilla 10.10.2 devices won't bind manually. Same error. Grrrrr....

14D136 with AD bind/create mobile/force local home is checking in 100% here on 55 macs.

You may want to make sure your opendirectoryd build is correct and not off for some reason: 382.20.2

/usr/libexec/opendirectoryd -v

AD binding with DSS 1.6.12 on 10.10.1 - 10.10.3 (14D136) with no issues. Currently testing 10.10.3 with (build 382.20.2) and no issues. Using both Create mobile account at login and Force local home directory on startup disk.

I should note, either this hasn't been a problem until yesterday.. or I just hadn't noticed. I'm pretty sure it's the former.

Curiouser and curiouser...

So, wired 10.9.5, binds no problem.
wireless 10.9.5, binds no problem.
wired 10.10.x, will not bind, will not get kerberos ticket.
wireless 10.10.x, binds no problem.

10.10.x (our image) & 10.10.x (vanilla), same issue. No binding. "Authentication server could not be contacted" when manual attempt to bind. "Incorrect password" when manually trying to get a kerberos ticket.

Enterprise Core Services says they made no changes to AD or the DCs.
Network Infrastructure says they made no changes to the wired infrastructure.

Not having any trouble binding to AD (using the top level domain) or getting a kerberos ticket with a wired connection on 14D136. Are you trying to bind to a specific DC (FQDN or IP) or the top level domain?

We've tried it all.. now there are authentication reports from all over covering all devices, applications, etc. So I might have just stumbled upon the tip of the spear, or, my issue is being overshadowed at the moment.

Seems pretty likely though that this is a me problem and not an OS X problem.

Binding works and as others have noted the createmobileaccount binary is broken, and its not any better on any newer version of the OS either at the moment.

UPDATE: In the end, this was (apparently) a problem with DNS. Apparently we got "lucky" and took the brunt of it before everything else went problematic. The issue is resolved now, however. The sky is no longer falling.

I see this all of the time. Macs often are the "canary in the coal mine" and tend to find network/DNS/AD/Exchange issues long before Windows systems do. A good reason for platform diversity...

I had my working machine that lost AD bind after 10.10.3 upgrade. I didn't do much testing by now, but I will dig more into it and testing a few upgrades from 10.10.2...

Yellow.
I am experiencing in a recently created AD environment. Any way you could detail what the problem with DNS was?
Thanks,

Unfortunately I don't know.. when I asked the Network Engineers about the issue and the solution I was encouraged to 'hold on' and that was it. We've had issues in the past where the DNS servers aren't updating in a timely fashion, so it's possible to get different names for the same device/IP. I briefly noticed this at the time, could be that was the source or a contributing factor?

We had the same problem and found a fix for it.

sudo discoveryutil mdnsactivedirectory yes

Since Apple is moving away from discoveryd I'm not sure if this will be necessary in the future, but it's been working for us.