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.
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?
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?
That's normally an issue with he computer trying to check AD for a password change.
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.
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.
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
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?
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.
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.
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.
Seeing the same issue here, but only on Mac's with Native AD-Bind.
Some users are on Centrify Express, no issues there.
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.
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.
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.
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?
@bbot AFAIK the preferred DC is used for binding, & is attempted 1st IF sites & services offers it to clients at login.
Have tested with El-Capitan, upgraded from Yosemite and clean install. Same issue.
@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.
Any progress on this? We have the same issues when WAKING from sleep (LAPTOPS only) when the user is already logged in.
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.
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.
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.
