AD Slow Login

[billystanton]

Hi All,

I'm sure this question has been asked a lot, but I cannot seem to find any solid answers anywhere.

Our machines are bound to AD and are setup as mobile accounts. They also have FV2 enabled.

Machines aren't shared, so that users' machine is theirs.

When our laptops go to screensaver you are required to type in your password again.

The problem is that if you are off site, IE, not on same network as the domain controller, then login can take anywhere between 10 seconds to 40 seconds.

This is not ideal, especially if you type in the wrong password the first time.

I have tried the following things in different orders, some altogether etc:

Uncheck box for - Search All Domains - little to no difference

Removed our domain from the search list - little to no difference

Changed the DSBindTimeOut (tried anywhere between 2 and 10) - This works perfectly on cable, but on offsite WiFi it just crashes the machine when you try to restart.

mDNSTimeOut - changed this from the default 5 to 1 and this made little to no difference.

Unchecked the box for "Map network home location"

I should add that MOST of our users have rMBP 13's. Fairly new machines with lots of spec.

I'm at a total loss here, its completely random as sometimes the user logs in instantly, other times it takes longer. Some users are affected, some users aren't.

Any help would be hugely appreciated.

[mm2270]

Hi there. I wish I had an answer for you here, because it would be something I would also use in our environment if I knew how to fix this. Many of us run into the same odd slow screen unlock and/or login delays with machines joined to AD. I'm not sure, but I don't think FV2 is a cause of the slowdowns here, at least not with the unlock from screensaver scenario, but I haven't done extensive testing to know for sure. We also use FileVault on our Macs. In fact, most of what you described mirrors our setup. AD joined, FV2 enabled, single user systems, relatively up to date Macs with good specs. Yet, the login times can randomly be extremely long. Its very frustrating. I can't even say I've tried all the things you listed, but have tried some, and like you, have found no resolution in any of the proposed fixes. Its a little discouraging to see all the steps you've taken and none of them have helped.

My understanding is the main issue is the fact that OS X will connect with any Domain Controller in your environment, not necessarily the closest one. So each time it negotiates with the network to pair up with its DC for that logged in session, it might be connecting to something far away from it physically. I don't know if your environment is spread globally like ours is, but we see very random connections happen to our DCs. There seems to be no logic in how it chooses, just whatever responds first I think.
So, is your org spread around the globe, with DCs in different locales? Or is everything close by?

I'd welcome any other insight from others who may have gone through this already.

As an aside, you can run the following command to grep out the DC a Mac is connected to.

netstat -a | grep ldap

I've found in testing that you might sometimes need to trigger a connection prior to the netstat command. I've seen in some cases it will return nothing with the above, so I often use the below instead. Replace the domain.company.com with your domain info.

ping -c 1 -o domain.company.com 2>&1 > /dev/null; netstat -a | grep ldap

The above might prove useful if you run it on machines experiencing long delays as well as ones with immediate login times to see what difference there is in the DCs they are connected to.

[jrserapio]

I am not sure about the screensaver login times, but we are looking to disable login hooks to improve login times For us the slowness is after the FV2 authentication but before a username/password prompt. Beachball/color wheel for anywhere between 30 seconds to ~5 min. When connected to the network its about ~10 seconds between the 2.

Similar environment:
AD/Fv2
mobile accounts
home directory not mounted at loginoot
no mcx
no login policies
no machines older than 2012

[Aziz]

@mm2270

I'm curious, is anyone on OS X 10.11.3 at your workplace? This update fixed slow AD logins for us (what a miracle).

Bigger post:

https://jamfnation.jamfsoftware.com/discussion.html?id=15267

[billystanton]

Glad to know I'm not alone!

Our machines are all on 10.10.5, not sure we are willing to update to 10.11 just yet, we are normally a year behind! Though it will be useful for testing purposes to try this out.

We do have DC's around the globe, I wasn't aware that this might be the issue.

I guess the problem here is also if the user is off site, the Mac doesn't seem to remember that it's not connected to the DC and then tries to find it again after screensaver. Very frustrating!

I'll do some testing with 10.11.3 and also thank you for the script to see what DC I'm connected to, this might help during testing!

Thanks again!

[billystanton]

So, 10.11.3 doesn't seem to fix the issue for me.

I also ran the command above and the machines are connecting to the correct DC.

SO ANNOYING!

[benshawuk]

Do you have a config profile (or MCX) for the login window prefs?
I've come across an issue where this needs to be set:

<key>LocalUserLoginEnabled</key>
<true/>

With this set to false, I was getting 5 minute logon times with AD mobile accounts. Admittedly this didn't start happening until 10.11 though..

[Jens_Mansson]

We had same issue after upgrading to ElCap.
Enable the setting "Local-only users may log in" in Configuration Profiles > Login Window (Access) did the trick for us with slow/delayed logins.