802.1X Wireless Login Window Authentication-Slow Login

This may be of some help:
sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>

The stock setting is super conservative. Apple suggested 30 seconds, but the value chosen is dependent on your infrastructure. I am going to try a 10-15 second value. If you monitor /var/log/opendirectoryd you can actually choose the most optimum value for environment by figuring out the value in which AD authentication fails. These are the steps that were suggested by Apple for finding this value.

1. Turn on debug mode: obutil set log debug
2. Set the value on DSBindTimeout to whatever you choose
3. Try to login
4. Look at /var/log/opendirectoryd

if you see errors such as:
2013-02-14 14:30:01.422 CST - 128.567, Node: /Local/Default - failed to use original node for cached user 'testuser', continuing with offline authentication

The value is set too low and should be raised.

What we've noticed lately is that our Config Profile for our hidden internal network was acting up, too. It suddenly stopped maintaining a connection and would retry constantly. I'll try these changes and see if that helps our situation, too. Thanks for the info @jhbush1973

Thanks, but I have not seen any change

LSinNY, you may need to check with the people who manage your wireless network. If you disable the wi-fi and use a wired connection is it much faster? If so then your wireless needs some examination and possibly your profile.

Long time problem here, first time spending time testing the solution above...

Note, the correct command to enable debug logging is odutil for step 1.

Turn on debug mode: odutil set log debug

Testing on an MBA mid 2013 10.8.5 with thunderbolt to Ethernet connection, I see I can go as low as 2 seconds before offline auth takes place. Just wondering if the robustness of AD environment or the speed of the computer has any effect. Should I set it to 15 seconds just to be safe with older devices and those with USB to Ethernet adapters? Just wondering if someone has done lots of testing on a wide variety of devices.

a quick update:

now able to use :
username password
no @MYDOMAIN.COM needed
jhalvorson I did not change DSBIND time. I am testing a macbook 2010 running 10.8.5. I pushed my config out to 5 Macbook Pro 2013, mix of 10.8.4, 10.8.5 with good results

hth

@easyedc could you please clarify your issue. I don't want to hijack this thread but it sounds similar to an issue that we're having.

@nathan.reiter Sorry for the late delay in responding. Just cleaning out my old emails when I saw this. What we've seen on our OS X.8 environment (10.9 is currently in testing for deployment) we get a persistent connect/drop/connect/drop when configured by profile. If we removed the profile, and manually joined our hidden network and provided the credentials, the connection maintains. This just happened to start at 10.8.4/5.

One other thing to note in Active Directory environments is that membership in a large number of security groups (especially if there are nested memberships in other groups) can increase login times dramatically. Even moderate latency to your domain controller will greatly exacerbate this. The reason is that the Mac resolves and caches all of those group memberships through a series of LDAP queries (which is why latency makes this much worse).

Mavericks introduced some better caching between logins so the system doesn't have to resolve everything, but it's maybe a 50% improvement at best in my testing.

My point is, if your wifi performance is poor, login times will suffer. Try testing a login with a user account with no group memberships vs. one with many.

Just to say I've finally got a loginwindow wifi profile working here and find I have the problem from the original post. i've tried a quick DSBindTimeout hack, and it's still working (the wifi connects) but it's definitely taking longer (> 2m) than the timeout i've put in (30 seconds). (a wired non-wifi login takes seconds)

i'll play with debug log of OD some more, but if @LSinNY has any feedback on what worked for him I'd be obliged!

I'm also noticing this on computers that are running OS X 10.10.3&4, encrypted, and go into screensaver mode. When logging back in from the screensaver they are trying to hit our AD and taking anywhere from 20 to 60 seconds. DSBindTimeout doesn't seem to make any difference for screensaver login. Has anyone run into this issue?

We also see slow screen unlock times for AD bound laptops with FileVault (randomly, some machines unlock under a second, others 15+ seconds). The DSBindTimeout does improve boot/login times for off local network situations.