OS X and AD integration, slow login times

[jhughes]

Hey guys,

I am having integrating our Mac's into Active Directory.

I am able to: -- Join Mac's to the domain (with no problems)
-- Log in to the domain with an AD authenticated user

Main Problem: -- When logging in as an Active Directory user, it normally takes 3 - 5 minutes to authenticate (no exaggeration). This happens whether or not it has been enrolled in JSS.

Possible Cause: We have a large AD structure (over 200,000 computer objects + associated users) and I suspect that it may be trying to scan the whole structure when it logs in. Is there a way we can limit the AD scope or somehow reduce the login time to something more reasonable, like under 30 seconds?

Any ideas?

Thanks!

[franton]

First thing to check: Make sure the option "Allow authentication from any domain in the forest" is disabled or the AD plugin will hunt through your entire AD structure.

Second thing: make sure your DNS is not reporting spurious domain controllers. We found that ours was reporting two servers that had recently been demoted from DC level, plus another that didn't exist anymore. AD plugin doesn't like trying to talk to DC's that don't exist anymore.

That's been our big issues. Hopefully one or both of those will help matters. Our login times are now down to around 1 minute or less.

[nessts]

and make them be mobile accounts that way they will authenticate locally

[Macintosh_HD]

You need to find out how many domain controllers you have and confirm that all of them are reachable.
Open Terminal.
Type: nslookup
Type: set type=srv
Type: _ldap._tcp.yourdomain.com
Type: _kpasswd._yourdomain.com

Confim all the domain controllers are reachable using ping/telnet over the corresponding ports. More info here: http://www.peachpit.com/articles/article.aspx?p=1431816&seqNum=2

[jhughes]

Thanks for the quick responses guys!

I unchecked the "Allow authentication from any domain in the forest" and that seemed to reduce it to about 1:30 - 2:00 minute log in times, but still hoping to get it down further.

I typed in the nslookup commands and got back a list of 27 domain controllers. I verified that I could connect to all of them.

Also, keep in mind, this isn't an issue where something went wrong; we've never historically supported OS X so this is entirely new ground for us.

[bentoms]

Can you perform a forward & reverse lookup of each DC?

[sgrall-pfg]

It takes 15-60 seconds for login here, and I think that's too slow, compared with a similar Open Directory infrastructure. But Active Directory is what they have here...

[franton]

27 domain controllers! Woah!

I ask about checking those because occasionally DNS can report servers that aren't DC's as DC's. We recently cleaned three out of the records and it's sped our login times right up.

Don't forget that when you log into a mac for the first time with mobile accounts enabled, OS X has to create a default user profile for that user on the hard drive. Depending on how much extra stuff has been stored in the user template folder, this file copy process can take a significant amount of time.

[jarednichols]

Don't suppose your domain ends in ".local"?

I had a big hand in creating this article: http://support.apple.com/kb/TS4041

You could also try changing the LDAP timeout settings: http://prowiki.isc.upenn.edu/wiki/Solving_timeout_issues_with_ActiveDirectory

[hasaanh]

This is a great page for different things to consider when troubleshooting AD Authentications:

http://emeadeployment.blogspot.com/2012/08/troubleshooting-mac-binding-and.html

[bsuggett]

Could be a couple of things.

1. User Template is bloated and new logons will take time while the user template is copied to the users home folder. This is exactly like the Default User profile in Windows. Large Default User profile = 1st logon is slow.

Suggestion: Since the post doesn't mention details, try creating a local account on the mac and see how long it takes to login.
If its quick, its most likely a domain related problem as it appears to be isolated to domain accounts.

1. It could be with your domain controllers. Active directory should be setup via active directory sites and services to point your subnet/location to use the nearest domain controller for authentication.

For example, If you have your PC/Mac in building A and you have 2 domain controllers. DC1 in building A and DC2 in building B. You'll want all your clients in building A to use DC1 for authentication, and All your clients in building B to use DC2 for authentication.

To exaggerate a poor setup. Your in Australia but your nearest DC is in the US. This would be a terrible setup as logon times would be terrible across a very slow link. Although I have seen some companies have setups like these, nowhere near to the extent of my example. Just scary!

Suggestion: Check how "local" you are to a domain controller if your far away that might be the cause.

I hope I've been some help.

Regards

[jhughes]

Thanks again for the suggestions!

I can perform forward and reverse lookups on all of the domain controllers. Our domain doesn't end in ".local". It does seem to run slower when someone first logs in, but logins are still slow during subsequent logins (sometimes 3 - 4 minutes).

A few other observations I've noticed:

1. There are different login times depending on who logs in, anywhere from 1 minute on some people to 5 minutes with others.
2. I turned up the opendirectoryd logging levels to see if I could figure out what's going on. http://support.apple.com/kb/HT4696
3. I'm in no way an AD expert, but I watched the opendirectoryd.log file when logging into the Mac and it looks like it begins by doing an LDAP search for the AD groups I'm a member of, and then looking at those groups to see who else are members of those groups. So every time I'm logging in, it's doing thousands (maybe 10's of thousands, not sure) of LDAP queries and with such a large AD infastructure, it looks like this might be what's taking so long. Maybe...

Does this sound possible / fixable? Do I need to look to a 3rd party solution?

[Nix4Life]

Suggett is on point, id also check network time. Our machines used to drift, and cause a similar problem.

LS

[Macintosh_HD]

If you still have issues with the logging times, you could possible weight the SRV records but this could affect remote sites. We had the same issue due to the lack of the Apple AD plugin to recognize local sites on AD and having a lot DCs. http://en.wikipedia.org/wiki/SRV_record

Here is an example of the records

Priority = 0 (Highest priority)
Weight = 100

_ldap._tcp.foo.domain.com service = 0 100 389 LA-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 LA-dc02.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 NY-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 NY-dc02.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 CHN-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 CHN-dc02.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 AUS-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 AUS-dc02.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 SF-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 0 100 389 SF-dc02.foo.domain.com.

To force macs to connect to LA and SF first, you'll have to set the priority and distribute the weight.

Logical Site - WEST (Assuming most of your macs are located on SF and LA)

_ldap._tcp.foo.domain.com service = 5 50 389 SF-dc01.foo.domain.com. (Most of the mac will try to connect here first)
_ldap._tcp.foo.domain.com service = 5 25 389 SF-dc02.foo.domain.com.
_ldap._tcp.foo.domain.com service = 5 15 389 LA-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 5 10 389 LA-dc02.foo.domain.com.

The priority was set to 5 and the weight was distributed to sum 100.

Logical Site - Southwest (Macs will try to connect to SF and LA first)

_ldap._tcp.foo.domain.com service = 10 50 389 AUS-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 10 50 389 AUS-dc02.foo.domain.com.

The priority was set to 10 and the weight was distributed to sum 100.

Logical Site - Northeast (Macs will try to connect to SF and LA first)

_ldap._tcp.foo.domain.com service = 20 75 389 NY-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 20 25 389 NY-dc02.foo.domain.com.

The priority was set to 20 and the weight was distributed to sum 100.

Logical Site - International (Macs will try to connect to SF and LA first)

_ldap._tcp.foo.domain.com service = 50 60 389 CHINA-dc01.foo.domain.com.
_ldap._tcp.foo.domain.com service = 50 40 389 CHINA-dc02.foo.domain.com.

The priority was set to 50 and the weight was distributed to sum 100.

These settings were configured in an environment I used to work for but since it's hard to maintain but we ended using AdmitMac which makes Macs site aware.

AdmitMac - http://www.thursby.com/products/admitmac.html
or
Centrify http://www.centrify.com

[wstewart3]

Has anyone else been experiencing these same problems on 10.10? Our users are experiencing login times anywhere from 1-5 minutes. It is really annoying....

I have read through this thread and have tried most of the things listed here. Has anyone had any further success?

[mkremic]

Hey @wstewart3 we've been experiencing a similar thing of late, especially with 10.10. Haven't had a chance to test on 10.9 for comparison but what i've found so far is that logons are taking between 1-3 minutes generally. Just of late they seem to be getting longer, perhaps with 10.10.2 rollout though can't be sure.

Interestingly enough, scouring the JAMF nation site and other sites, there was talk of the number of AD groups a user is a member of correlating to the length of time it takes to log in. I made a test user that wasn't a member of any groups and it logged in within 32 seconds (this is with FileVault enabled as well). My own user account on this test machine took well over 3 minutes. Next test is to add a few of our AD groups to see if it makes a difference and to test on a 10.9 machine for comparison.

I've mucked around with all the timeout values without much success.

Cheers

[wstewart3]

Odd,

I have actually removed the domain Search policy and this seems to make the login <20 seconds.

System Preferences -> Users and Groups -> Login Options -> Edit -> Open Directory Utility -> Search policy

So now it only has "/Local/Default". This of course has its drawbacks. No new AD/LDAP users can log into the machine, and on the initial login the operating system will only look for the local account. But since this has already been put on there it at least has our password complexity requirements since it pulled from AD.

I also found that you can still get a new password from our AD servers. On the initial login, unlocking Filevault 2, the account will still use the old password after updating AD to a new password for the account. But if you are plugged in with an ethernet cable to your network, you can actually "Log Out" and then log back in with the new password which will update the local account.

This is not quite ideal but it saves our engineers and researchers quite a bit of hassle until a better solution is found

[jacopo_pulici]

Hi everybody.
I have the same issue as well. In my company, login takes around 1 minute.
As @wstewart3 suggested, I did removed the domain entry in the Search Policy > Authentication and the login time is now around 10 -15 seconds.
But, as @wstewart3 pointed out, this is not exactly a solution due the drawbacks that brings. Really annoyed by this problem.
Has anyone found a solution?
Thanks to all.
Cheers

[davidacland]

How big is your AD forest? If there are multiple domains you can switch off "Allow authentication from any domain in the forest" and change the search base to /Active Directory/your.domain.com instead of /Active Directory/All Domains.

[gachowski]

How about this?

DSBindTimeout
Default value is unset, but the hard coded value is very high and conservative. I've only tested this on a couple computers so far. Needs much more testing before I roll it out.

Set it lower: /usr/bin/defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int 10

Extension Attribute to monitor value: /usr/bin/defaults read /Library/Preferences/com.apple.loginwindow DSBindTimeout

Sources: https://jamfnation.jamfsoftware.com/discussion.html?id=10894
https://jamfnation.jamfsoftware.com/discussion.html?id=6025
https://jamfnation.jamfsoftware.com/discussion.html?id=8598

From

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

[calumhunter]

having properly configured DNS and AD sites and services should fix it. I don't believe it is sheer volume of users/groups/objects that is your problem.

We have a very, very large AD with over 1 million users, more groups than we have users, and more than 500k computer objects. we also have multiple domains in the forrest, so we need to keep authenticate any domain in the forrest enabled.
can't say I've seen the slow login issues here with my machines. I'm seeing about 5 seconds max of the spinning gear at login before the machine goes ahead with the regular login stuff like creating the home directory and all that jazz.
Each site has their own RODC for the machines at that site, so no auth going over a wan link.
When I have encountered the long login times at other much much smaller sites its almost always been dns, dns, dns or incomplete/poorly configured AD sites and services or DC's that haven't been demoted and removed properly. In some instances it has also been to do with the SMB home folder.
We don't have any home folders or home directories set in AD for any users. We take care of this with login scripts and DFS shares.

[jacopo_pulici]

A little update.
I tried @davidacland advice with no luck.
I'm pretty sure the problem is in our domain forest, I'll buzz my AD guys...
Thanks all.

[rbeckerdite]

I spent some time cleaning up AD, Sites and Services, DNS etc. this resolved a longstanding login delays.

[bbot]

@rbeckerdite Would you be able to provide some information on your resolution? Did you find anything particular in AD, sites and services or DNS that caused the delay?

[rbeckerdite]

I can't give every solution without looking at a specific case but these steps might help you and covered most of the areas I had to adjust.

1. Any references to old removed domain controllers in sites and services configuration or dns.

a.Go to your AD domain in dns and confirm the start of Authority is referencing a valid server
b. Review all the name servers that are listed and make sure they are valid
c. make sure the name servers being handed out from your dhcp are valid domain controllers
d. Check and make sure your mac's have a valid search domain that matches your AD FQDN (eg, corp.domain.int)
e. Make sure that valid and appropriate domain controllers are used in your AD Sites and Services for IP replication. I have found hub and spoke a lot easier to troubleshoot (after years ago spending time with one of Microsoft global consulting partners).

1. Check wt32tm /monitor and see that all your servers domain controllers sync time with the FSMO role holder (PDC Emulator)
2. DCDIAG /A will reveal a lot of potential issues that you can investigate in the event logs. A clean event log in a Domain Controller is desirable in almost every case.

(BIG WARNING) don't change things you haven't seen fail before. DNS or time can cause authentication to fail. Without authentication you face DOS. please test anything in a test environment or work with someone that has done it before. Worst case ask my boss he might give away some of my time if you ask nicely. Good Luck!!