There's an Apple KBase article on this:

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

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.

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

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.

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>

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

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.

Nice find, this.