AD Login after sleep OSX 10.9

tijones
New Contributor II

Hey Guys,

Having some weird issues with 10.9 and AD logins, Picture this

Lab of 10.9 machines all working fine
Goes to sleep overnight
Wake up machines try login as AD user
Cant login immediate shake, Has IP address (according to login window) and can ping machine, send casper commands etc etc
Unplug Network Cable and Plug back in
Can Login fine

(also seems to work fine if reboot machine)

Anyone else having this issue?

33 REPLIES 33

tijones
New Contributor II

Ok if i push this command via casper remote

sudo ipconfig set en0 DHCP

A broken machine starts working again instantly,

Is there a DHCP problem from sleep with OSX 10.9

mdonovan
New Contributor III

I think I owe you a beer.

Sonic84
Contributor III

if you keep hitting enter at the login screen (after putting in your AD credential of course), will it let you login eventually? Like after 10 to 15 password shakes?

mdonovan
New Contributor III

Sonic - that's not something we tried as our staff/students wouldn't entertain the idea. Everything has to be instantaneous! ; )

pditty
New Contributor

Are you doing this over copper or wireless?

tijones
New Contributor II

This is over copper

pditty
New Contributor

sorry after re-reading your post I noticed your comment about unplugging the network cable. We had some similar symptoms that turned out to be wireless related, jumping between access points. Clearly this doesn't apply in your case.

tijones
New Contributor II

In order to resolve this issue we have had to use a launchdaemon to trigger the SleepWatcher software to monitor when the machine goes to sleep and wakes up, This software will then allowed us to trigger a script on wakeup to run

networksetup -setnetworkserviceenabled Ethernet Off
networksetup -setnetworkserviceenabled Ethernet On

Not the most elegant solution but it works.

dlondon
Valued Contributor

I'm seeing this exact same issue with 10.9.1

edramon
New Contributor

Hello

Just had to put some more info in on this.

I have been able to reproduce this same issue with virtual images of OSX 10.9.2. (VM Ware Fusion)

  1. VM Goes to sleep
  2. Wake VM
  3. Login via AD and slow login (3 mins) on VM1 and 5 seconds on VM2
  4. If I auth via a local user 5 seconds login for VM1 and VM2

So I am leaning toward something is is not right with OSX and Win Active Directory

While I am going to try the tweak of

networksetup -setnetworkserviceenabled Ethernet Off
networksetup -setnetworkserviceenabled Ethernet On

Does anyone have a root cause?

Ed

bentoms
Release Candidate Programs Tester

This "may" be fixed in an upcoming OS update.

mpittcasd
Contributor

@tijones How exactly did you configure everything SleepWatcher? I'm reading over the readme for it now, but I'm wondering how easy it would be to package and install via Casper for my labs. I'm getting the same kind of complaints about the login times.

tijones
New Contributor II

Confimed from my sources to be fixed in 10.9.3,

I just packaged the whole lot with a modified rc.wake to include those lines added it into a policy then under the files and processes tab of a policy

Execute Command

launchctl load /Library/LaunchDaemons/de.bernhard-baehr.sleepwatcher.plist

Seemed to work ok, Further testing revealed that you can just turn off ipv4 rather than the whole adaptor as I had 2 cases where the adaptor didntcome back on, This was over a month and 1300 ish macs

pnbahry
New Contributor III

I had the same problem as well with 10.9 and Lab Machines bound to AD, to fix that problem I have a script that I use to keep the desktops on during the day, as this also turns the machines on and off on a schedule.

This has fixed all the problems we had with the sleep issue and having to restart the machine for the AD user to login.

I am also seeing a different problem on a few machines that will try and login, it gets further than just the first shake but the user can still not login, a restart will not fix this like the first problem. To fix this problem I have a script that will unbind the machine and re-bind it to AD then the machine will work again.

This is all I can see in the error logs:

could not get the user record from open directory

Hoping 10.9.3 will also fix these problems, as we also have 2 labs full of 10.8 machines with no problems at all.

This is the Script that I use for keeping the desktops awake and for the schedule.

###
#!/bin/sh
# set power management preferences
# set scheduled events for startup and shutdown

# settings for desktops
setDesktopPrefs(){
pmset -a sleep 0 2>/dev/null # system does not go to sleep automatically
pmset -a powerbutton 0 2>/dev/null # do not allow power button to sleep the computer
pmset -a displaysleep 30 2>/dev/null # sets display sleep time
pmset -a disksleep 0 2>/dev/null # does not spindown hard drives
pmset -a womp 1 2>/dev/null # wake up computer if it receives wake-on-lan magic packet

# set scheduled startup and shutdown
pmset repeat cancel # clear all repeating startup and shutdown events
sleep 1
pmset repeat wakeorpoweron MTWRFSU 6:00:00, shutdown MTWRFSU 20:30:00
sleep 1
}
# settings for laptops
setLaptopPrefs(){
pmset -a sleep 0 2>/dev/null # system does not go to sleep automatically
pmset -a powerbutton 0 2>/dev/null # do not allow power button to sleep the computer
pmset -a displaysleep 30 2>/dev/null # sets display sleep time
pmset -a disksleep 0 2>/dev/null # does not spindown hard drives
pmset -a womp 1 2>/dev/null # wake up computer if it receives wake-on-lan magic packet
pmset -a lidwake 1 2>/dev/null # wake up computer when lid is opened
pmset -a acwake 0 2>/dev/null # do not wake up computer when power adapter is connected
pmset -a halfdim 1 2>/dev/null # sets display to halfdim before display sleep
pmset -a sms 1 2>/dev/null # use Sudden Motion Sensor to park disk heads on sudden changes in G force

# set prefs when using battery only
pmset -b sleep 20 2>/dev/null # system goes to sleep after idle time
pmset -b displaysleep 15 2>/dev/null # sets display sleep time
pmset -b disksleep 10 2>/dev/null # spindown hard drives

# set scheduled startup and shutdown
pmset repeat cancel # clear all repeating startup and shutdown events
}

checkIfLaptop=$(sysctl -n hw.model | grep -i -c book 2>/dev/null)
if [ $checkIfLaptop -gt 0 ]; then
echo "Setting power management for laptop..."
setLaptopPrefs
else
echo "Setting power management for desktop..."
setDesktopPrefs
fi
pmset -g
echo
pmset -g sched
sleep 1
exit 0
###

ColumbiaCollege
New Contributor

Its my understanding that this issue is a bug within OS X. I have confirmed that it is not fixed in 10.9.4. Any idea if there is a way to tell the machine not to put the NIC to sleep? I know on a Window's box this can be done from the devmgmt.msc within the power properties tab for the NIC.

snovak
Contributor

Our labs and workstations are just starting to show this issue. I'd like to avoid disabling system sleep if possible, but I'm quickly realizing this may not be possible without whipping up another package to monitor for wakeup, which will just make the whole load even more complex; I'm already monitoring AD connection status as we've had 10.9 machines simply lose their binding.

emily
Valued Contributor III
Valued Contributor III

This certainly explains why my users complain about seeing a Network accounts unavailable message when they get to the login screen on their machines. I've always posited that on Wake the machine takes about 20 seconds to obtain a new IP from our DHCP, for whatever reason. If there is a way to force the machine to renew its lease from the DHCP, that would be super awesome.

chicanogeek
New Contributor

Has anyone found a solution to this issue?

KCH080208
New Contributor II

I get the same issue. Here is my console log. Basically this keeps repeating.

12/16/14 4:20:08.304 PM SecurityAgent[12552] Could not get the user record from OpenDirectory.
12/16/14 4:20:08.304 PM SecurityAgent[12552] Will sleep 3 seconds and try again (retryCount = 3)
12/16/14 4:20:11.306 PM SecurityAgent[12552] Could not get the user record from OpenDirectory.
12/16/14 4:20:11.306 PM SecurityAgent[12552] Will sleep 3 seconds and try again (retryCount = 2)
12/16/14 4:20:14.308 PM SecurityAgent[12552] Could not get the user record from OpenDirectory.
12/16/14 4:20:14.308 PM SecurityAgent[12552] Will sleep 3 seconds and try again (retryCount = 1)
12/16/14 4:20:16.675 PM com.apple.launchd[1] (com.jamfsoftware.task.screensharingunloader) Throttling respawn: Will start in 10 seconds
12/16/14 4:20:17.309 PM SecurityAgent[12552] User info context values set for halvka
12/16/14 4:20:17.310 PM SecurityAgent[12552] Unknown user "halvka" login attempt PASSED for auditing
12/16/14 4:20:19.509 PM SecurityAgent[12552] Could not get the user record from OpenDirectory.

This issue was happening with a different version of deepfreeze that we used so i had to uninstall that on all of our macs and they have been fine. They updated in november and i had the newest version on there for a month and now its back to this. Funny thing is i can login with my domain admin account but not my regular one.

MichaelC
New Contributor III

Resetting the Ethernet connection via sleepwatcher doesn't work in our environment (OS X 10.9.5 with the Powerbroker Identity Services Open plugin for AD). What does seem to work is reloading the loginwindow - of course, care has to be taken not to do that in an active login session. I trigger the following script with sleepwatcher:

#!/bin/bash

echo "sleepwatcher triggered: $(date)" >> /Library/Logs/sleepwatcher.log

if [ "$(defaults read /Library/Preferences/com.apple.loginwindow lastUser)" != "loggedIn" ]; then
    killall -HUP loginwindow

    echo "Loginwindow reset" >> /Library/Logs/sleepwatcher.log
fi

It still seems a bit brute force, so if anyone comes up with a more elegant method I'd like to hear about it.

Not applicable

Hopefully this works: sudo ipconfig set en0 DHCP

If it does, Internet high five to @tijones][/url. I'll also have to try @Carey][/url's method if it doesn't work.

MichaelC
New Contributor III

Turns out the 'lastUser' value in com.apple.loginWindow isn't reliably updated, and will sometimes show 'loggedIn' when all users are logged out. Instead, I've replaced the test with:

-z "$(who | grep console)"

Tigerhaven
Contributor

hi guys this is happening on machines with 10.10.2 also. Is there a solution?

Kunal V

snovak
Contributor

I just disabled sleep in all of our labs; not the most ecologically friendly solution, but it does the trick.

Poseiden951
Contributor

@Tigerhaven

I disable " Put the hard disk(s) to sleep whenever possible" via Configuration Profile. Not energy. friendly, but the only solution.

Look
Valued Contributor III

@Tigerhaven Are the affected machines by chance upgraded all the way from 10.9?
I have only had this issue reported on a couple of post 10.10 machines and these had all been updated from 10.9 to 10.10
As a general rule we reimage regularly so probably %95 of our 10.10 machines were imaged directly to 10.10 and no one has reported this issue with these machines as yet.

Tigerhaven
Contributor

@Poseiden951 this issue is continuing on machines with 10.10.2 fresh install and ad bind. the machine shuts down and when you try to start it it is stuck on apple screen trying to boot.

Kunal V

Poseiden951
Contributor

@Tigerhaven

That issue is from Yosemite refusing to boot when machines are bound to AD. Apple released OS X 10.10.3 today to fix that issue.

KCH080208
New Contributor II

suppose to fix it, lets just hope it does because yosemite has been useless for me because of it.

Tigerhaven
Contributor

lets hope so to as i installed them on 10 test machines

Kunal V

RobertHammen
Valued Contributor II

The Yosemite Boot Hang/LoginLock is fixed in 10.10.3. Finally!

KCH080208
New Contributor II

is there a way to actually prove it. Other than shutting down and restarting the machine and it not getting locked up.

RobertHammen
Valued Contributor II

Well, it has an even newer version of the opendirectoryd patch that people received who opened AppleCare Enterprise cases. And many people have tested the seeds, including by powering-off AD bound Macs and trying to recreate the issue, without any success.

Test in your environment but this one appears to be resolved...