Posted on 10-08-2013 08:31 PM
Hi Guys;
finally got this working (SSID, WPA2 Enterprise, TTLS & PEAP protocols and MSCHAPv2). Logins are taking between 2 and 3 minutes. any tips to getting faster logins
TIA
LS
Solved! Go to Solution.
Posted on 10-10-2013 06:53 PM
Thanks for all the replies. what ended up working was logging in with the following format:
username@YOURDOMAIN.COM
and then users password
logins are just under a minute
LS
Posted on 10-08-2013 10:34 PM
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.
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.
Posted on 10-09-2013 07:08 AM
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
Posted on 10-09-2013 08:43 AM
Thanks, but I have not seen any change
Posted on 10-09-2013 09:14 AM
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.
Posted on 10-10-2013 06:53 PM
Thanks for all the replies. what ended up working was logging in with the following format:
username@YOURDOMAIN.COM
and then users password
logins are just under a minute
LS
Posted on 10-11-2013 09:13 AM
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.
Posted on 10-11-2013 07:19 PM
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
Posted on 10-14-2013 07:53 PM
@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.
Posted on 12-20-2013 06:47 AM
@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.
Posted on 12-20-2013 08:26 AM
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.
Posted on 12-20-2013 08:39 AM
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!
Posted on 07-24-2015 06:53 AM
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?
Posted on 08-28-2015 01:59 PM
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.