Login window delay after logging in

[bbot]

I'm wondering if anyone else is seeing this issue.
I've been able to replicate it on 10.9.5 and 10.10.4.

The issue is when people are WAKING their computers from sleep(usually when they close the lid and walk to a meeting), then after entering their password to login, it sits on the login page for about 10-20 seconds and then takes them in.

Setting the DSBind Timeout -int 10 fixes the delay at initial login, but not waking from sleep.
We are using active directory. It doesn't seem to happen all the time.

[Aziz]

I've noticed this on my MacBook Pro Retina (early 2015). Takes me some time to sign in.

We're also using Active Directory and mobile accounts.

[RobertHammen]

What does /var/log/system.log say when this is happening?

What are they using for networking? Wireless? 802.1x? WPA2 Enterprise? Is it possible it's some kind of delay bringing up the wireless? Is it different if they are on a WPA/WPA2 Personal wifi network?

[#4]

Any static DNS entries assigned and have you verified they're reachable and performing normally?

Have you checked whether that location's primary domain controller is reachable from that network segment?

[pblake]

That's normally an issue with he computer trying to check AD for a password change.

[mscottblake]

I've seen this with AD bound machines that are also FileVault 2 encrypted. In this scenario, I've found no way of fixing it.

[bbot]

We're using 802.1x. I have not tested yet on a different network, but that will be something to look into. I'll also ask to see if this is also happening off-site or off the corporate wifi. @RobertHammen

Thanks for all your input guys.

[jacopo_pulici]

I have the same issue.
I've been able to mitigate the problem following THIS post.
Modifying the DSBindTimeout value I reduced the login times from 50/60 seconds to 10/20 seconds.
I'm also in contact with Apple in order to investigate further this issue.
Cheers

Jack

[bbot]

Setting the DSBindTimeout -int 10 resolves the issue at login after a full restart or shutdown, but is not fixing the delay when waking from sleep.

Has anyone seen a delay in login when waking from sleep?

[bbot]

Bump.

[bbot]

Bump

[kirkmshaffer]

We're seeing the same thing - and have on and off for awhile (most likely due to people 'learning to live with it' unfortunately). And I tend to agree with @mscottblake We're AD bound, use wired and wireless connections (and there doesn't seem to be a strong correlation with either), and are encrypting with FileVault.

We had a case open with Apple during the 10.10.0-3 days but the prevailing wisdom was that 10.10.4 would fix this issue along with a myriad other networking issues. And it mostly did. But we do have a current case open with Apple about this as well.

One method that has helped some people - although I suspect its voodoo - is to reset SMC, and uncheck all the "Today" extensions in System Preferences/Extensions (stocks, weather, etc) so that it's not trying to populate all that stuff before logging in.

[bbot]

Thanks @Shaffer

We seem to be getting more reports from users on a certain floor... I'm wondering if it's something AD/network related. Some users are reporting 30-45 second login delays when waking from sleep from the time they enter their password and hit enter.

[Key1]

Yup seeing the same thing here on mobile, managed, AD accounts with filevault enabled. The problem gets progressively worse each time they sleep until a system restarts which seems to help matters.

[chrisbju]

Seeing the same issue here, but only on Mac's with Native AD-Bind.

Some users are on Centrify Express, no issues there.

[bbot]

Confirmed that this issue is not related to Casper or FileVault as it's been happening to machines that aren't enrolled and encrypted.

I'm almost certain that this had something to do with the ldap search / AD as it tries to verify the user's network password... just not able to pinpoint exactly where the fault is at this time.

[bbot]

After more troubleshooting, I'm finding that when there is a delay, I run a netstat -a | grep tcp4 and look for anything with .ldap.
On the local Mac, I have set the preferred search policy and removed All Domains, and even set a preferred domain and somehow it's still picking up the wrong domain.

Computers with no login delay connect to abcdc1.domainname.ldap
Computers with login delay are connecting to wrongdc.qa.ldap

What would cause some computers to connect to a certain ldap for user authentication, and some others to connect to a different and/or multiple .ldap servers? All local mac AD settings are the same.

[kirkmshaffer]

Seems like there two different issues for us: 1) Why isn't the machine reaching the domain at all (or the correct domain in your case @bbot ); and 2) We set a bindtimeout of 10 seconds, so why does it take longer than 10.1 seconds? It should dump to local and auth that way immediately after the timeout limit is reached.

Anyone know what, exactly, the bindtimeout means? Is that 10 seconds to say yes/no the domain is there and the credentials match? Or does it include authenticating successfully, and then pulling all the data for that user down? We're currently testing the idea that limiting the number of levels loginwindow will go into nested groups can help limit the login times.

[jacopo_pulici]

I'm having this issue too (AD bound + FileVault).
I invited an Apple engineer at my office to check the problem and he acknowledged the issue. He reopened the ticket on OpenRadar. Afterwards I had to send them the required evidences (logs and video showing the actual login times).
All this happened in July.
Meanwhile I received a couple of email saying that the engineers are still looking into this problem.
Has anyone tried with 10.11 El Cap?

[bentoms]

@bbot AFAIK the preferred DC is used for binding, & is attempted 1st IF sites & services offers it to clients at login.

[chrisbju]

Have tested with El-Capitan, upgraded from Yosemite and clean install. Same issue.

[bbot]

@Shaffer Correct.
1) In all cases where there was always a delay. I found that it was not finding a domain at all because it somehow lost it's AD binding. (This happens quite often and we usually find out when a user comes down and says I can't reset my password). Looking at the GUI showed it was bound to AD, and the record was still in AD, but somehow it lost its' link. Rebinding fixed this issue.
Why it's finding the wrong domain is beyond me.
2) In my testing, setting the DSBindTimeout only affects initial login. The issue we're seeing is logging back into a computer when the user was already logged in. For example, the user closes his lid, walks to a conference room, opens the laptop and logs back in.

[Aziz]

Any progress on this? We have the same issues when WAKING from sleep (LAPTOPS only) when the user is already logged in.

[Sigma902]

From a MacBook Pro running 10.10.5 bound to AD without FileVault and with Mobile Accounts, after awaking I notice a mix of rejected valid password which will successfully authenticate after second or more re-entry, delays after password acceptance, or acceptance of password yet network services fail once in console. In the last case, it seems as though it is using the locally cached/mobile account authentication rather than the AD. Lately after awaking the MBP I enter my credentials slowly. This is done with the goal so as to allow greater time to establish network connectivity while preventing the laptop from falling back to sleep before completing entry. Doing this seems to allow full network access after log in.

[hkabik]

Had a similar issue, in my case it was specifically occurring on machines that were connected to wifi. It's not a perfect solution, but the workaround I instituted that got us past it was to turn off system sleep (we still let the display sleep) for machines plugged into AC (allowing machines running off of the battery to sleep normally). No more sleep, no more issue.

#!/bin/sh

pmset -a sleep 0

Like I said, not perfect but now our desktops come back lickity split from a locked state.

[chrisbju]

Anyone still seeing delays?

In my testing on Yosemite, i have set mDNStimeout from 5 to 1 and logins from wake have improved. Location: /System/Library/SystemConfiguration/IPMonitor.bundle/Contents/Info.plist

Remember to reboot.

[yellow]

From @bbot

1) In all cases where there was always a delay. I found that it was not finding a domain at all because it somehow lost it's AD binding. (This happens quite often and we usually find out when a user comes down and says I can't reset my password). Looking at the GUI showed it was bound to AD, and the record was still in AD, but somehow it lost its' link. Rebinding fixed this issue. Why it's finding the wrong domain is beyond me.

Yes! I see this a lot here too! And strangely it keeps happening to the same device, and not on other devices. I just assumed it was our poorly configured DCs & AD.

[Johnny_Kim]

I have quite a few laptops that looses its binding. I have a rebind script that I use along with a smart group using EA criteria.

#!/bin/sh

#  adbindingTest.sh
#  
#  Created by jkim on 9/24/15.
#

#Replace ADACCOUNT with an account that exists in the domain.
id ADACCOUNT 1>/dev/null
if [ $? == 0 ] ; then
echo "<result>Yes</result>"
else
echo "<result>No</result>"
fi

And the rebind script. The credentials are plane text and you can use

#!/bin/sh

#  ADBindScriptADM2.sh
#  
#
#  Created by jkim on 10/21/14.
#


#domain info
domain="domain.org"
username="Username"
password="Password"
ou="OU=ou,DC=dc,DC=domain,DC=org"

#unbind first

dsconfigad -force -remove -u "localAccount" -p "password"

#get serial for computer name

SN=`ioreg -l | grep IOPlatformSerialNumber | awk '{ print $4 }' | sed 's/"//g' | tr [:lower:] [:upper:]`
SN_CUT=`echo $SN`
echo "Serial Number: $SN_CUT"

#set hostname, localhostname, and computername to serial Number

scutil --set HostName "$SN_CUT"

scutil --set LocalHostName "$SN_CUT"

scutil --set ComputerName "$SN_CUT"

#bind to AD
dsconfigad -force -add "$domain" -username "$username" -password "$password" -computer "$SN_CUT" ou="$ou" -groups "domain admins" -mobile enable -mobileconfirm disable -localhome enable -useuncpath enable -alldomains enable -packetsign allow -packetencrypt allow -passinterval 14 -namespace domain

[analog_kid]

We have a case open with Apple as well for screen unlock delays (wake from sleep). We're an AD shop, using mobile accounts on laptops and FileVault is in the mix as well.

Our DC's are all behind a firewall so this issue seems to crop up on machines that are moving off and on our intranet. I'd be curious if anyone is having this problem who has at least a read-only DC open to the world.

It seems like after a while OpenDirectory loses track of the node state for our domain so (for example) if you're off campus it takes 20-30 seconds before it times out and authenticates from cached credentials. At this point you can bring the machine back on the intranet and it still won't jive with the domain and you get the same long timeout upon unlocking the machine from sleep.

I've found restarting the OpenDirectory service restores functionality (or just rebooting the machine) until the next time it goes haywire. Also, I haven't used 10.11.2 long enough to determine if there's any improvements to this issue. But we've seen this behavior from at least OS X 10.9.

We've also implemented DSBindTimeout set to 10 seconds which does help with login times from cold boots.

[bbot]

We're still seeing delays. I've been on 10.11.2 for a couple days and it feels as if the delays are less frequent. Also checked in with two other El cap users and they're saying the same thing.

We also have an open case with Apple and are waiting to hear back from them after giving them all of our logs.

The issue is much more frequent when switching between access points. (for example, going to a meeting on a different floor or building) Most likely due to having to find the authentication server again.

[bbot]

@chrisbju Still seeing delays after trying to set mdns_timeout and pdns_timeout to 1 or 0.

Issue seems to be much less frequent on El Capitan as of late...

[Aziz]

This is basically gone for me in OS X 10.11.3!

Can someone else confirm?

[winops]

No delay here on 10.11.3

[kirkmshaffer]

Because this is such a sporadic issue for us, we can't really tell so far. But the most prominent people having this issue are not on 10.11.3 yet... so that's something. Here's to hoping this is going to help us out!

[billystanton]

Can anybody else confirm the 10.11.3 fixes here?

Also be worth asking if anybody has tried 10.11.4 beta?

[jacopo_pulici]

In my case the problem is still there with 10.11.3.
Not tried the 10.11.4 beta

[Jens_Mansson]

We had same issue after upgrading to ElCap.
Enable the setting "Local-only users may log in" in Configuration Profiles > Login Window (Access) did the trick for us with slow/delayed logins.

[Iamroot]

I'm currently running 10.11.3 with ADS and this happens on one of our systems but not all which is quite confusing.

[chrisbju]

How many are using AD ending in .local ? We are still seeing this in 10.11.4, not tried 10.11.5 beta yet.

[Crowe87]

We have an intermittent issue with our macbooks (OSX 10.11.6) that run a network login.
When a user tries to login with their AD credentials, authentication fails on the first try. On the second try login works. This only happens on a mac they haven't logged into before.

The macbooks are bound to AD and we're using a login window configuration profile.
I think the issue occurs when the wifi switches over to the users credentials as I haven't seen the problem on wired clients.

Anyone had any experience with this issue?

Ive tried adjusting, DSBind Timeout, made sure that the config profile and user wifi credentials are looking at the same DNS server, specified preferred DC in directory services but the problem seems to persist.

Forgive me if posting in the wrong space, I have had a look for threads similar to my issue and cannot find any.