FileVault 2 Lag with Cached Active Directory Accounts

achand
New Contributor III

Does anyone have an issue with a 30-45 second lag when trying to log into a FV2 encrypted system with a cached AD account? I'm trying to figure out if its possible to reduce this lag somehow. If the Mac is plugged into the network, we are able to login with an AD account in about ~ 20 seconds. But if its disconnected from the network, it takes over a minute. Any ideas?

1 ACCEPTED SOLUTION

achand
New Contributor III

Opened up a case with Apple. There is a key that can be modified to lower the timeout value for AD when connecting off-network on a FV2 system. If the value is set too low, the user may miss password expiration notices and other AD policies.

sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>

View solution in original post

9 REPLIES 9

rtrouton
Release Candidate Programs Tester

There's an Apple KBase article on this:

http://support.apple.com/kb/TS4286

jarednichols
Honored Contributor

Their workaround is crap. You can instead remove your Active Directory from the search path in the plugin and it'll be nice and snappy. The downside is that a new AD user won't be able to log in, but you can re-enable it if you need to. Even with the AD search path disabled, your user will still get a Kerberos ticket.

achand
New Contributor III

Would removing AD from the search path cause any problems if a user was to change their AD password? Would it still sync up?

achand
New Contributor III
 

jarednichols
Honored Contributor

Not in my testing. We're using mobile accounts and all the password and kerberos stuff still works as expected. It simply prevents new AD users from logging in. However, AD environments can vary wildly so test test test.

achand
New Contributor III

Opened up a case with Apple. There is a key that can be modified to lower the timeout value for AD when connecting off-network on a FV2 system. If the value is set too low, the user may miss password expiration notices and other AD policies.

sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>

jhbush
Valued Contributor II

achand, did apple give you any indication of an appropriate number. I used 10 and saw my own login time improved.

achand
New Contributor III

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.

jarednichols
Honored Contributor

Nice find, this.