What OS X version and are you running?

10.9.2

Have you tried manually binding just one machine to see if the behavior is the same? I'm using JSS to run a bind script after enrollment and haven't had any issues.

I'm also wondering if its the "Network not ready" at the login screen when you first wake it up.

I am running through my tests now. I turned off WiFi and I am testing that. The next is to bind using AD and not Centrify. After that I am going to create a new location instead of Automatic and test that.

It sounds to me that the network is not ready when you are trying to login. Can you try to create a mobile account (system prefs -> users) and try again? A mobile account will cache the password for offline access.

If it still fails, if you are command line friendly, try to ssh into the machine and login command line (type login in terminal after ssh-ing to the new box). See what happens and check log files.

Im seeing -
adclient: WARN <gpworker> network.state Unable to find usable DC for domain:mydomain, readon DNS is down

It is a mobile account shouldn't just log me in. If I reboot I can log in even with no network. It seems to be hung on trying to connect until I reboot.

Any ideas?

I spoke to early. Got a call from a school that I deployed 10 iMac 27" running 10.9.3. Same symptom. Cannot login after sleep.

For now, I'm testing by disabling sleep. Also, I came across this article.

http://howtoapple.com/mavericks-wifi-issues-fix/

My machines are laptops, so disabling sleep is not an option.

New location/Service order are on my next to do in my testing.

@pblake why is it not an option?

If I disable sleep on a laptop the power consumption is too large. Plus not all our laptops are SSD, so the HD might spin.

well if they have to reboot to be able to login, then it will help them remember to shut it down when they head out the door.

@nessts - I agree with you, but I'd like to get it to work properly. This is by no way a "showstopper". Easy enough workaround.

This seems to be a pretty common bug in 10.9 all our machines do it.
We got around the problem by using sleepwatcher (third party launch daemon) to fix it after every wake.
Current implementation is to have it swap the adapter to manual+DHCP and then back to full DHCP. It does cause a couple of seconds delay before you can login after waking, but it always fixes the issue.
Sleepwatcher uses a file in /etc that is read basically as a script, the current one we are using is along these lines.

INITIAL=networksetup -getinfo ethernet | grep IP address | cut -d " " -f 3
networksetup -setmanualwithdhcprouter ethernet $INITIAL
sleep 2
networksetup -setdhcp ethernet

The exact procedure might vary depending on your connection and environment.
The underlying cause seems to be some of the services or settings related to the ethernet adapter are not re-enabled after wake, it's possible if you could work out exactly what needed to be reenabled and do just that instead of my rather brute force solution.
If you go down the route of completely disabling and re-enabling the adapter, be aware that this can occasionally result in the adapter being stuck on disabled until the machine sleeps and wakes again (there are bound to be ways to avoid this but I moved to the manual address method instead).

Any more info on this?

We did the "set service order" from http://howtoapple.com/mavericks-wifi-issues-fix/ and seems to be fine for now. Students are able to login to the iMac's.

The issue does not seem to be fixed on 10.9.3. Having this issue on every Mac that has Maverick. Very annoying.

@BMCCGroup - Are you using the built-in AD binding or centrify?

Having the same issue with 10.9.3 and Open Power Broker.
Is there any "check" that can be performed to see that we are having issues? That way we can have a script running on the interval policy to fix those computers that aren't immediately in use.

From my conversations with Centrify, it seems to be a bug in 10.9.x with 3rd party directory plugins. They have an open ticket with Apple, but so far no resolution.

Our workaround was to disable "Allow authentication from any domain in the forest" in our binding settings.

Our workaround was to disable "Allow authentication from any domain in the forest" in our binding settings.

Oh how I wish that was an option!!

I've been experimenting with our macs and found that I had to kill the loginwindow process, that caused the loginwindow to quickly restart and suddenly work.
I'm going to test today and see if thats all that is needed, as quickly Disabling and re-enabling the network doesn't feel right.....

Confirmed that the issue is related to the login window process.
Running this command on my 10.9.3's without any other commands work every time:

kill -9 `ps -Axjc | grep -E 'root.*loginwindow' | awk '{print $2}'`

The command looks for only instances of loginwindow with root as the Process owner, and kills them.
Will not accidentally logout anyone else unless they have "root" in their username some how.......

hmm that just made me have a "ohhh no" moment....

Still need a proper test that tells us the loginwindow is having issues with nework logins.
Has anyone got any ideas?

@BMCCGroup][/url][/url - Are you using the built-in AD binding or centrify?

Issue appears in both cases for me, however, when joined via Centrify (with Casper installed), rebooting is the only thing that fixes this. Not even unplugging/plugging back Internet helps.

I've been doing tests by clicking on Sleep button at the login screen. Wait till it says Network Accounts Unavailable then entering a non-cached user account.

Things that kinda worked:
-Pressing Enter key many times lets you login in some cases (not always)
-Sleep watcher workaround works without Centrify installed. If unplugging and plugging back Internet does not fix issue, this won't fix it.

Update:
When joined via Centrify, the sleep watcher will not fix this. So basically Casper cause the issue but can be worked around using sleep watcher but with Centrify its actually worse and you will need a reboot...

I've had my first machine exhibit this behavior this week. Brand new, out of the box 13" Macbook Air. We used the directory binding within Casper. User can't log in on the screensaver login OR the main login screen after forcing a reboot. I haven't seen anything like it before on other machines I've issued…

Did the OP use the JSS AD bind? or did they script it using dsconfigad?

I scripted my AD bind using an old script of Bombich that was modified for my purposes and I haven't seen any issues like this after creating mobile accounts on brand new 13" MBAs.