Mavericks Sleep/Wake Login Issue

[pblake]

I am having an issue, and I am hoping someone here has seen it or has a fix.

We use Centrify here to bind our Macs to AD.
The issue we are seeing is once a user logs in, creates a profile. If the logout and put the computer to sleep, they cannot log back in until after the reboot. I assume this is a networking issue, but I cannot find a resolution.

Please help JAMF Nation!

[Johnny_Kim]

What OS X version and are you running?

[pblake]

10.9.2

[Johnny_Kim]

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.

[pblake]

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.

[thoule]

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.

[pblake]

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?

[Johnny_Kim]

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/

[pblake]

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

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

[nessts]

@pblake why is it not an option?

[pblake]

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.

[nessts]

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.

[pblake]

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

[Look]

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

[BaddMann]

Any more info on this?

[Johnny_Kim]

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.

[BMCCGroup]

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

[pblake]

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

[BaddMann]

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.

[pblake]

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.

[mcooper]

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

[BaddMann]

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

[BaddMann]

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]

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

[emily]

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…

[Joseph_Morris]

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.

[emily]

Turns out that even though I had "Create mobile account at login" checked in my directory binding it didn't work on this MacBook Air. Once I made sure that checkbox was enabled the issue stopped. Not sure why it skipped creating a mobile account for that user… but at least it's working now.

[BMCCGroup]

Thought this would be fixed at 10.9.4 but unfortunately still happening...

[pblake]

@BMCCGroup - I was too. Haven't tested yet. Did you update and test? What if you unjoin and rejoin?

[BMCCGroup]

Yes, I already tested it. Still happening. I also put in a ticket to Centrify and they pointed out this is an Apple bug in Maverick. No resolution at the moment.

[pblake]

@BMCCGroup
I spoke with someone from Apple at the JAMF User meet up in NYC, and told of the problem as well.

[BaddMann]

Incase anyone is still looking for the work around until Apple starts taking this seriously. I've come up with this based on my findings on the loginwindow process.

#!/bin/sh
# Resets the LoginWindow Process so that the Active directory client gets a chance to login un-cached users.
# only use on Mavericks.

isUser=$((`ioreg -c IOHIDSystem | sed -e '/HIDIdleTime/!{ d' -e 't' -e '}' -e 's/.* = //g' -e 'q'` / 1000000000))
echo "HID idle for $isUser Seconds"
if test $isUser -ge 300 #If no Activitiy from the mouse and keyboard for 5 minutes....
then
    echo "No User Detected, Resetting Login Window"
    caffeinate -u -t 5 #Wake the display, that way there is no black screen of death
    sleep 5 #Wait for the Caffeinate Command to finish running.
    kill -9 `ps -Axjc | grep -E 'root.*loginwindow' | awk '{print $2}'` #Kill Roots LoginWindow
fi

The script runs at the interval, at a policy setting of ongoing, mine happens to be set at 60 minutes.
If a user has touched the HIDs within 5 minutes it cancels it's run.
To make sure we don't get a black screen of death, (sometimes happens if you kill loginwindow while the display is asleep), we "caffeinate the computer.
Then we kill only the loginwindow process associated with root.
Been tested in my open lab area over the last two weeks and works perfectly.
I've also limited the script to 10.9.x.

Hope this workaround helps for now.

Side benefit is it clears out any random characters that may be in the username and password fields as well.

[rcarey912]

This script works perfectly.

[tep]

@BaddMann - Your script saved the day!

[BaddMann]

My pleasure Guys!
Watch out for AirplayUIServer.app as well.
It destroys Airdrop and crashes logouts if airdrop was used.

I'll write more later.

[bwarsing]

We are currently having this experiencing this issue as well.

I recommend you try:

sudo pmset womp 0 && reboot

This appears to address the loginwindow issue for us.

It is not a desirable configuration, but if it works for you as well, it will be a good indicator what Apple needs to do to address this bug.

--
B.

[BaddMann]

@bwarsing

Please try my script.
It works and does not require a reboot.

[bwarsing]

@BaddMann

I think you missed the point. This is an energy saver setting and is therefore persistent across reboots and does not require any scripting.

The reboot is not strictly required.

[BaddMann]

Yeah after I posted my message I researched it.
Feeling sheepish....
Nice to finally know the underlying cause.

[tnielsen]

I had the same issue. I tried all pmset options, nothing fixed it. Killing the login window process did fix it when it happened however that's not feasible.

I re imaged the computer and did not transfer any settings from old computer to the new. This helped, the computer no longer has the issues. 10.9.4 I believe something in the migration from old to new caused the problem.