Additional update 5/14/2012:
I have found success in using likewise to bind users to Active Directory instead of the regular OSX method. Follow the instructions in the PDF here: http://www.beyondtrust.com/Technical-Support/Downloads/files/pbiso/Manuals/Likewise-Open-5-Quick-Start-Mac.pdf. Slowdowns have pretty much gone away when using this method.
Update 4/27/2011:
Big thanks to Simon who brought up this fix which I have confirmed on my end to be working pretty well. You can either view his comments below, or here is what was stated:
Change the ‘ Preferred Domain Server’ option in Directory Utility to an IP address, and the Mac will NOT do a .local lookup for the domain login. (Which is the problem when not on the LAN).
——
I tested the solution by connecting to a wireless access point that was not connected to our LAN, and login was a 2 or 3 seconds. Before doing this it took 2 mins exactly every time.Try the following steps, I think its essential to re-bind.
1) Unbind from Active Directory
2) Change Preferred Domain Server to your Domain Controller IP address
3) Rebind to Active directory
This worked for me along with countless other Mac’s I tried as well. So before you go and remove you search policies as the steps below state, try out this fix and let me know how it goes.
Thanks Simon!
Overview:
There has been this ongoing issue with osx machines and snow leopard… A user joined to the domain will see log waiting periods when logging into the machine, logging out of the machine, and authenticating when running privileged commands. This commonly happens when the user is not on the same network as the domain controller, yet has a wireless/wired connection.
I have tried all the solutions I could find, creating login hooks to disable Bonjour, disabling mDNS multicasting, editing LDAP timeout entries (even though LDAP isn’t used!), nothing seemed to work! Until finally I found a solution!
The Problem:
The problem lies within search policies on the OSX system. After the computer is joined to the domain, 2 entries are added to the search policy. The entry /Active Directory/All Domains is added to both the Authentication and Contacts search path. Since there is no way to change the Kerberos timeout value on OSX (that I am aware of), the system tries to either authenticate to all 3 directory domains (‘/Local/Default’, ‘/BSD/Local’, ‘/Active Directory/All Domains’), or tries authenticating Active directory first even though it is in the bottom of the list.
Most of the time this has been seen when the domain is also a .local suffix. This MAY be due to problems with Bonjour (which also uses .local) and the .local Active Directory domain, but I’m not positive.
Fixing the problem:
Remove the /Active Directory/All Domains search path from both the Authentication & Contacts search policy.
* Please see the Notes section at the bottom for possible problems this may cause when doing this.
The How-to:
We must make sure that the user is first a ‘mobile’ user. This means that the user has a /Users/ directory created when the login, and the credentials have been cached. To verify this, we need to do the following:
- Navigate to System Preferences
- Click Accounts
- View the users account (they should already be binded to the domain), it should look like the following:

- Once this has been verified you will be able to continue.
We must now go through the process of removing the Search Policies from Active Directory:
- Navigate to System Preferences
- Click Accounts
- Click Login Options

- Next to Network Account Server, click on the Edit button
- Click on Open Directory Utility
- Under Services make sure LDAPv3 is unchecked, since we don’t use this, only Active Directory

- Click on Search Policyat the top
- Click on the Authenticationtab:
- Click on the Contactstab:
- Click once on /Active Directory/All Domains to highlight it
- Click on the - (minus) button to remove the entry
- There should be no listings under the contacts tab after removal
- Click Apply
- Close out the Directory Utility
- Close out the Accounts window
- Reboot the computer, and the login process should be MUCH faster.
Notes:
- New network users (who do not already have an account on the local machine) can not login to the computer after, since we removed Active Directory from the authentication tab. It is recommended you create an administrator local account, so an administrator can always login, along with a network admin account as well for backup.
- Changing passwords work fine, and have been tested. As long as the user has the green icon (connected) under Network Account Server, they can change their password and it will sync up with the domain controller.
- Authentication to network shares works as well since osx directly communicates with the server to authorize the connection.
- If for some reason the search paths need to be changed back, they are automatically generated again if you un-join and re-bind the machine to the domain (or they can be added manually).
TechSmog


God, this problem has been the bane of my life for the last 6 months. I keep telling my customers that this is an Apple problem, but I think they have stopped believing me! I have tried your suggestion and although the wake from sleep and privilege commands is much better, the initial logon from boot still takes a good couple of minutes. I hope Apple fix this properly in the next service update as this is such annoying problem!
Update on this. Wake from sleep is still taking a couple of minutes as well as the initial logon. Instead of Apple bringing out new swanky products, I wish they would just fix the basics!
Hi Mike,
Thanks for the updates. I am currently unable to reproduce the same issue you are describing on multiple machines. If I run into the issue again I will be sure to investigate further and update this page.
Its a bit crazy that apple hasn’t released a fix for this issue yet.
Thanks,
- Josh
Mike –
Please try the following as well,
- edit the file /Library/Preferences/DirectoryService/ActiveDirectory.plist and scroll to the bottom of the file.
- Under LDAP connection timeout, it should have a string underneath that says ’90′. Try changing this to ’5′, as I have below.
Let me know if this speeds things up for you…
Thanks,
- Josh
Josh,
Thanks for looking further into this. It really is a can of worms! We have mutiple customers all with SBS 2008 server at the backend. My Macbook is bound to our Active Directory and when I connect to a customer network who also has AD, logon is fine. Where the problem occurs is I take my Macbook home and there is no AD on the network. 2 minute + logon! I have tried your second suggestion before (another post) but this did not work for me. What I have not tried is both fixes together, which I will give a go now.
I have heard some rumours that 10.6.7 has some reworking of SMB and AD Mobile accounts, but I have been unable to get a developer to confirm whether this has fixed the issue properly.
I do hope so!
Josh,
No joy I am afraid. Anyone else had some success?
Mike
No change time from 90 to 5 don not work for me
Hi there,
I’m suing OSX 10.6.6 logging into a mobile account. I’m connecting to an Active Directory Server (win 2003).
I just tried this fix and timed my login afterwards. It took me 1:24 seconds….way too long. To add to the problem I’m connecting to my network using sonicwall net extender on an SSL VPN 200. I receive my mail (exchange 2003 with entourage) no problem at all. I use smb to connect to my files shares and it takes 3:00 to make the initial connection and then another minute or more for each subfolder.
When I connect on an account that isn’t mobile it’s much faster. Any ideas??? I’m really starting to despise these things. The few Mac clients i have are taking up ALL of my time.
Hi Dianne,
I’m sorry that this is still an issue.
Regarding the slow SMB share, I would try this:
edit the /etc/smb.conf file:
under the [global] section add the line:
socket options = TCP_NODELAY IPTOS_LOWDELAY
This should make smb browsing much faster. I had to do this for a bunch of macs in order to improve speed.
I’ll have a document outlining the steps as a blog post soon.
- Josh
Great article but honestly the only way to beat this scenario is to create a new domain, and call it something other then .local. We just recently built one and all our issues dissolved as of right now. Quick logins almost in 23 seconds or less. And this was after 5 minute logins.
We suffered similar symptoms with our offsite macs.
Packet capture tests revealed inbound LDAP connections were being allowed by our firewall inadvertently. The macs could see our domain controllers over the internet. The fact that they could not get any outbound response did not prevent the macs from trying to authenticate against them, and subsequently timing out.
Firewall fixed – problem resolved.
@Lemmin –
Were you binding to the domain controllers with an external address on the Mac’s?
I’m curious to know how the mac’s would see the domain controllers over the WAN if its using a LAN address to bind.
Thanks!
- Josh
Just applied 10.6.7 and this has not fixed the slow logon problem. End of the line for me now. I am going to recommend to all my customers that Snow Leopard does not support AD connections for Macbook users. After all the recommended Microsoft domain extension is .local and everybody that follows best practice will have this problem and you can’t just change it without a great deal of work. This is poor form from Apple and I will certainly re-consider purchases of MacBooks in a WIndows domain environment in the future. Back to Dell!
@jgilmour
I think you’ll find a more complete solution by adding an entry for active directory in the format below to replace the deleted /Active Directory/All Domains entry. If you simply remove the “All Domains” entry, then network users without an existing mobile account will no longer be able to logon, etc. Adding the entry below stops the Mac client searching once it finds the listed domain and doesn’t continue to look for additional domains (e.g. “All Domains”). New network users can still logon to the client using this solution. This only works if you only have one domain though, which most would…
/Active Directory/mydomain.local
@Mike,
The reason why Microsoft recommended the .local domain extension is because they knew that it would cause problems for Macs as the Mac OS uses the .local extension for bonjour to resolve hostnames (link-local addressing) in a similar way that Windows uses netbios.
Why would MS do that – because it impacts on the ability of their competition to get a foothold in the Enterprise market without affecting MS products whatsoever. As you said, everybody that follows the “best practice” recommendations from MS will have this problem. I was caught out by this “best practice” myself – thanks MS!
Thanks, Brad, for confirming what i thought was my problem. Our company recently merged with a new company and in the process of bringing the two domains together the .local extension was implemented in the new domain design. (head IT says, is best practices)
When i begin to migrate the mac immediately my remote users begin to send emails in the problems login in at hotels and clients offices. It tool to long to login I’ve been looking for a solution but have not found a viable one.
Out real test will be when we move our ERP which run on UNIX and is still .com domain.
I have this issue too, I hope Apple can patch this bug and make offline AD faster. Disabling the AD search policy works pretty good, but it is not a great solution. The LDAP timeout setting did not help at all for me.
Change the ‘Preferrred Domain Server’ option in Directory Utility to an IP address, and the Mac will NOT do a .local lookup for the domain login. (Which is the problem when not on the LAN).
This took ages to fix but is now resolved on all our Macs using AD on a .local domain.
Sorry I meant instead of using the FQDN for the Preferred Domain Server.
Simon, I believe I read about this somewhere, not sure if I tried it or not, since I spent ages trying to get this to work. I will definitely check this out tomorrow and report back on if it worked!
Thanks for the tip!
Did this work for you?
Make sure you re-bind as in my answer to Peter below
Hi Simon, It works! If I remove the search policies the login/authentication is instant. If I leave the search policies it takes around 20sec, which is awesome! Much faster than 5min!!
I will update the blog hopefully tonight with what you have stated. Much thanks!
Also working on a .local network
Solution from Simon:
Seems promising but it don’t work still have to wait 1,5 to 2 minutes for login (if connecting to another network Ethernet or Wifi) if both not available login is normal(fast)
Simon did you also test your solution on for example a wifi network?
thanks and greetings
Peter,
I tested the solution by connecting to a wireless access point that was not connected to our LAN, and login was a 2 or 3 seconds. Before doing this it took 2 mins exactly every time.
Try the following steps, I think its essential to re-bind.
1) Unbind from Active Directory
2) Change Preferred Domain Server to your Domain Controller IP address
3) Rebind to Active directory
I hope that works for you!
That was the fix for me. I tried all the other options given in various forums over the last few months, all of our Macs have the latest software updates but I am pretty sure thats not the issue.
This works!
Thank you SO much for this, Simon. I have had issues with OS X and Win AD for a long time now and had never found a resolution. The switch to IP address did it for me. I also removed the /Active Directory/All Domains entries from the Search Policies tab. Note that I was not even using a .local domain name.
Glad it works! We have also just switched over to centrify which seems to fix a lot of the issues as well. (Also works for mountain lion, which likewise did not)
Hi Simon, (.local domain – 10.6.7)
1) unbound from AD
2) reboot
3) At Directory Utility “Prefer this domain server” i fill in the IP address of server
4) First time login without network cable after password 5 sec delay after login logout and login again
time out for 2 minutes????
5) reboot login fast (without ethernet cable -wifi)
6) reboot again 2 minutes timeout again (without ethernet cable -wifi)
7) shutdown
8) startup again 2 minutes timeout again (without ethernet cable -wifi)
still long delays ;-(
One more thing to try – repair your disk permissions.
This speeded up slow logins too.
I just wanted to follow-up that we had 2 osx 10.6.7 machines binded to AD today that were having the slow login issues. After providing the fix that Simon suggested, and unbinding/re-binding, it was down to about a 10sec login time. Much better than the 5+mins that users were stating previously. This was with a .local domain.
i’m experiencing similiar issues over here. We have two MBPs (Mac OS 10.6.7) bound to our W2K8 AD – both with logon times of around two minutes. Unfortunately none of the above solutions worked for me. I even bought a Mac Mini Server to have an OD around which authenticates against the AD which didn’t do the trick either.
The updated work around does not seem to help at all for me.
The first workaround works, but is not great because once you disable the search path you can’t use any other AD accounts to log into the machines for support and maintenace.
I’m going to contact Apple about this and see if they have any other ideas.
Here is the solution that finally worked for me in all scenarios when using AD:
1. Replace the “/Active Directory/All Domains” entry in the search path with “/Active Directory/yourdomain.local” This is accomplished by unticking the “Allow authentication from any domain in the forest” on the ‘Administrative’ tab of the AD utility. You will need to unbind and rebind for this to work.
That doesn’t entirely fix the problem, although you should see an improvement. Even with the next step, you would still want to do this as it will speed up logins as the mac will not continue to search for additional domains once it finds the one you are bound to. So, on to the next step and the one that really fixes the problem.
2. Open ‘Network Preferences’ for both your Airport connection and Ethernet connection (any that might possibly be used off the LAN) and go to the DNS settings. In the “Search Domains” section create two entries:
yourdomain.local
local
The order of these entries is important because if your internal domain is not the first one, then you won’t be able to resolve yourdomain.local host names on your LAN.
Making these changes took logins from 10 minutes to 1 minute. I can get it down to about 10-20 seconds if I only have the “local” entry in the search domain, but internal DNS names can’t be resolved then. If that’s not a concern (e.g. you only access systems by their IP or a public IP address that is resolved by external DNS) then you can possibly do that, but I wouldn’t recommend doing it.
This problem comes with vengeance after updating to 10.6.8! Almost every Mac we have bound to a Win2k8 AD server now has very slow authentication. It seems to help if you unbind (then on the AD server, delete the machine name) then change the preferred AD server to the IP address of the AD server, and rebind. My auth time went from waiting 2 min, to about 5 seconds.
If you search the Apple forums, many people are having this issue after the 10.6.8 update, so Apple certainly changed something with the AD auth in 10.6.8. Apple needs to soak test these updates much longer. These are things that management gets upset about. An employee waiting at their login screen for 2 minutes, is unacceptable. It gives Mac’s a bad rap, when the Windows guys are working and the people in front of Mac’s are waiting.
Yes, I didn’t have this problem until I installed the 10.6.8 update. Apple says it’s a known bug and they are working on it. My temporary solution was to have an in-warranty replacement of my failed hard drive done and I asked the repair tech to install 10.6.7.
If I could rank this post I would give it a +20 !!!
I recently purchase OSX Lion Server and was surprised to see how the login (and authentication in general) was so slow. Change the AD to an IP and everything is fast again, THANK YOU.
On a side note, I would like to understand why apple didn’ t fix this time out issue. Like it was mentioned by another person, it makes OSX look bad.
Cheers,
For most problems, cleaning up your Mac before doing major software updates works for me. Try it – do maintanence and then update to the latest Software from Apple and try again with the login.
Apple gave me this link which should work around this issue if you have a .local active directory.
http://support.apple.com/kb/TS4041
I have not tested it yet though.
Hi Simon and jgilmour, i got a macbook os x laptop, i just updated my MAC too 10.6.8, in 1 week ill update too 10.7.2, now it takes ages to logout of 1 account, im only 17 and i need URGENT HELP. So please Help and Reply back with your MSN, SKYPE or Yahoo also can someone connect to my mAC (teamviewer) or something too help me fix my Issue ?
Thanks,
Hughy Dee
OK…. This is without a doubt the best “DiY” site I’ve ever come across. I tried several suggestions and just about all of them had a positive effect. I combined several where using an IP address was involved and all my woes are gone. Special thanks to Jgilmore and Simon
Awesome! Glad to hear its working!
Likewise seems to have been bought out by EMC and now Likewise Open is not available. Does anyone know where we can find the .dmg files to install?
Thanks,
Matt