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?
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.
You need to find out how many domain controllers you have and confirm that all of them are reachable.
Type: set type=srv
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
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.
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.
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
Could be a couple of things.
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.
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.
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:
Does this sound possible / fixable? Do I need to look to a 3rd party solution?
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
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.
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
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.
How about this?
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
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.
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.
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).
(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!!