Many users were surpised to discover that Active Directory no longer worked when they upgraded their Macs from Tiger to Leopard. Mac OS X 10.5 broke Active Directory binding and login, and other aspects of Mac integration with Active Directory. Apple has released update that have improved the situation for some users, though issues remain. This page contains descriptions of the problems, as well as workarounds and fixes.
Leopard 10.5.2 addresses AD bug
Released February 11, 2008
For the Mac OS X 10.5.2 update and the Mac OS X Server 10.5.2 update, Apple said that the update fixes problems with binding to Active Directory Domains, which was widely reported with 10.5.0 and 10.5.1.
Click here for a full description of cross-platform fixes in Leopard 10.5.2.
Leopard Server’s wiki server can affect AD binding | Top of Page |
Apple tech article 306750 warns that when running Mac OS X Server 10.5 bound to Active Directory, using the Wiki Server can cause problems with users authenticating to Active Directory. Apple's solution is to set authentication for Wiki Server that comes with Leopard Server (wikid) to clear text. The article explains how to use Terminal to set Wiki Server authentication in clear text.
Apple explains why this is needed:
This is required because, by default, the wiki server uses CRAM-MD5 authentication, which is not supported by the Active Directory plugin.
Because sending clear text passwords is not secure, Apple recommends configuring the wiki server to use SSL.
Upgrading to Leopard from Tiger breaks binding to Active Directory | Top of Page |
Users can no longer bind to Active Directory after Leopard update
Dave McCristall's lost the ability to bind to Active Directory after a Leopard update:
I updated one of our Macs to 10.5 from 10.4 (as a test). Users were authenticating through Active Directory, but on this Mac, we've got nothing. I can't seem to get Leopard to bind to the Active Directory server.
Many more reports of Leopard Active Directory binding problems
Wednesday, October 31, 2007
Many readers are reporting the inability to bind to Active Directory after upgrading to Leopard that we first reported on Monday. Some are seeing dialogs that report an "unknown error." Others report an error message that says "Invalid user name and password combination." One reader said that his Macs freeze when they attempt binding.
Ryan Gilbert described his experience:
I am having issues with Leopard and Active Directory as well. After upgrading a system that uses AD auth I am no longer able to login with AD user accounts. Logging in with a local account and removing/re-adding to AD does not solve the problem.
I have also tried an erase and install of Leopard. In my case the computers 'seem' to bind to AD, but will not let any users log on using AD user credentials.
Bob DeSilets was able to get a Kereberos ticket:
I'm having the same problems authenticating to the AD domain after upgrading. Here are all the details I can think of:
- I did an Upgrade rather than an Archive and install from a fully patched Tiger installation
- When I first attempted to log in with my mobile account, I got an error message that said that there was a problem creating the mobile account (even though the local directory already existed)
- I logged in to a local admin account, unbound the machine from the AD domain in Directory Utility, and re-bound the machine to the domain. No luck accessing the mobile account.
- I am able to get Kerberos tickets from both the AD domain and our central campus Ticket Granting server
Rob Groome is getting the "unexpected error" messages on multiple Macs:
I have the same issue with binding AD to Leopard. I have an Intel Mac and when I try to bind to the domain, which worked flawlessly on Tiger, I get an error message.
From the Directory Servers Tab under Directory Utility, it says:
Unable to add the domain. An unexpected error of type -14090 (eDSAuthFailed) occurred.
Or, from the Services tab and clicking on Active Directory, I get the following:
Unable to access domain controller. This computer is unable to access the domain controller for an unknown reason.
I love the unknown reason - it's really helpful in troubleshooting! This also happened on two other systems with fresh installs and one with an upgraded install. Same error on all 3 systems.
David Marcus's Macs freeze when they try to bind, and found a workaround, of sorts:
I can relate to your post "Reader can no long bind to AD after Leopard update." As far as we're concerned the bind on the AD literally froze the MacBook Pros concerned (2 different machines) to the point where we had to make a hard reboot. Removing the domain in the Directory Utility removed the issue immediately. The downside is that the users cannot benefit from full AD integration.
We noticed the origin of the problem as the Macs didn't freeze if connected outside the AD's LAN.
Stephane Rossan gets the user name error message:
I upgraded my Mac Pro to Mac OS X 10.5 this morning, and I can not bind to AD. I unbinded it and try to bind it again, but I cannot anymore. I have an error message: Invalid user name and password combination. You provided a user name and password combination that is invalid. You should check the user name and password and try again.
Obviously, I tried multiple times with no success. This morning, the error message was about a time difference between the client and the server.
Jay Rozgonyi found that he could not unbind after the update:
I'm clearly seeing problems with AD binding here at my University. We have our Macs bound to AD for authentication (laptops use mobile accounts), as well as to an Open Directory server for preferences. I left on Friday with my Tiger bound machine, booted into my mobile account at home, and did an Archive and Install of Leopard. I brought over the Network and User Account info, and I was running quite well over the weekend.
When I plugged in back at the office this morning, however, everything went wrong. Authentication was not being passed to AD correctly, and when our Windows guys recommended that I unbind the computer and then bind it again, I found that I was not allowed to unbind! Even a forced unbind (i.e., one not based on my authentication to AD) did not work. I'm now in the process of doing a fresh install of Leopard, bringing nothing over from the previous build or from Tiger, but I'm very reluctant to even attempt to bind to AD. The machine, by the way, is a two week old MacBook.
Fred Steputis:
I've tested 2 clean installs and 1 upgrade so far. Leopard seems to not allow network login when bound to AD. I spent several hours yesterday trying to figure this out. The binding works fine as in 10.4, all settings are the same except the listing of BSD/local as an authentication path on 10.5. I cannot get rid of the BSD listing under Directory Services.
I don't think we will be upgrading anytime soon.
Kenny Red:
I am have a massive amount of difficulty getting my new Leopard upgrade to bind to Active Directory. Every time I try it goes past validating my credentials and then give error "An unknown error occurred".
if you have these issues with Leopard.
Some Leopard users can connect to AD, but not without issues | Top of Page |
Wednesday, October 31, 2007
A few readers did report being able to connect to Active Directory with Leopard.
Alan Auman said that his logins are "horrendously slow:"
While I've been able to bind my Leopard upgrades to AD, the login for an AD user account takes up to 3 minutes to complete. Disengaging screensavers when using an the AD account credentials also suffers from this delay.
Derrick Rashidi was able to bind after multiple attempts:
I'm having the same issue with some differences. I did manage to get the laptop to bind, however I didn't do anything different. It just decided to bind. I can see the pc in AD when I do a seach, but when I logon to the PC locally (because I cannot logon to the domain) and check the Directory Utility, My AD Domain show the "server is not responding" message. At times this will show Green and the server is responding but still unable to logon to the domain.
Ben Zvan was able to bind as well:
I thought I'd let you know that I'm experiencing a similar problem to that listed on your site. Under 10.4, I was able to grab a Kerberos ticket from our AD server and then connect to AD SMB shares on our network using that ticket. Now, I'm prompted for a password when I try to mount the shares. One of our other tech areas is working on it, but they don't have 10.5 yet.
Suggestion for Leopard AD issue, and more reports of binding problems | Top of Page |
Readers continue to report problems with Leopard binding to Active Directory networks. One reader got it to work after multiple binding/unbindings. Another reports seeing it with Micrsoft's Services for Unix. One reader saw the same problem with the Leopard betas.
But first, Erik Ableson has a suggestion:
I've had no problems joining an AD domain after the Leopard update. I did have to delete the original AD Directory Services entry after upgrading and rejoin later since it really didn't like not being able to resolve the domain since I did the upgrade from home. General recommendation would be to leave the domain before upgrading and rejoin after the update.
if this worked for you.
Rick Shields had it working until he moved it to a mobile user account. Then he got it to work after multiple binds and unbinds:
Everything at first was perfect. I did a clean install and within minutes had the machine logged into AD 2 days. (I hadn't set it up to be a mobile user yet either.) Today, I decided that it looked good enough and moveed it to a mobile user account. I went to the directory utility and unbind. No issue. Made the change to allow the mobile account when connecting. Rebind. All lookd well, but I couldn't log in.
The window showed that the AD server was responding correctly and everything looked normal. But it didn't work. I could unbind/rebind with no issues, but no user could log in, not even my domain admin account.
Now, after multiple bind/unbinds and restarts it has started working again. I get my AD users to log in. Suggests to me that there is something holding onto something or something on the Mac when you unbind/bind.
Josh Warren blames the new Active Directory plugin:
I am just writing to confirm that I, too, have run into the problem of trying to get a 10.5 OSX (Leopard) iMac and Mac Book Pro to bind to AD. I don't think it matters whether it is a clean install or an upgrade. I want to say it is just an issue with the new AD plug-in Apple has issued with the new OS.
Carl sees the problem with the Macs accessing Services for Unix on the Windows server:
I'm also experiencing this. I however, am using MS Services for Unix and so have Directory Access in Mac OS X treating AD as regular LDAPv3 server. It worked great with Tiger, but after the upgrade to Leopard I can no longer find any AD users. It has something to do with its search path (I think) since the Directory Access program says the server is responding fine.
An anonymous reader saw this problem with the Leopard Beta. He also describes the symptoms:
I submitted a bug report on Leopard beta regarding AD binding and account creation months ago. This was for Leopard 9A559 and before, and it looks like it still exists in 9A581, the Golden Master shipping version. Apple knew knew full well that AD binding is not working.
Go back to Tiger 10.4.10. This is the very reason we are not on Leopard and won't be until Apple fixes this.
Here's the bug: you can indeed bind to AD via the Directory Utility. It reports as "AD Server Responding Normally." Log out or restart, it does not matter. You get the "Red Ball" at the OS X Login Window (meaning you have no connected directory servers, AD or OD, it should be a green ball).
You go to login with your AD user name / password and the Window just shakes, no dice, no login, never creates your AD network account (which is really local).
Reader says Leopard AD binding fails during step 5
Wednesday, January 9, 2008
Mark Staben is another reader whose Leopard Macs can't bind to Active Directory. He sees the same error message as another reader did:
I can't believe this isn't fixed yet. With regard to Rob Groome's "unexpected error," "Unable to access domain controller. This computer is unable to access the domain controller for an unknown reason."
This is exactly what I get when I attempt to bind. It happens at Step 5 during the binding process. It worked perfectly in Tiger.
I have about 100 machines waiting for Leopard and I bought the licenses the day it was released. Unfortunately, those machines will be sticking with Tiger until this is fixed.
More bugs with Leopard on Active Directory and a workaround for slow login (turn off Bonjour) | Top of Page |
Wednesday, November 7, 2007
Readers are reporting more buggy behavior with Mac OS X 10.5.0 Leopard on Active Directory networks. Many readers have previously reported problems with binding to Leopard to Active Directory. Today, we have readers reporting some other strange behavior surrounding AD binding.
Leslie Wong verified a previous report of very slow AD connections, but offered an odd workaround. She also reports a problem waking from sleep:
I have two Macs in a Windows Server 2003 environment (a ".local" domain) and was able to bind to the AD after a clean install of Leopard. But logins, like Alan Auman's, were "horrendously slow." Also, any operation that required administrator authentication were similarly slow.
I found, in the Apple discussions, that turning off Bonjour immediately stopped the problem. Logins were as fast as they were in Tiger. But turning off Bonjour caused other problems, such as not being able to start Aperture.
I also noticed a problem that when the Leopard machine wakes from Sleep, it was not always able to communicate with the domain. The Directory Utility would indicate that the ADD was not responding normally and a reboot was required for it to be "responding normally" again.
Justin Rummel found a way to log in using a mobile account:
My AD experience with Leopard has been interesting. After a clean install on my MacBook Pro, I was able to bind to AD but forgot to select "mobile account" check box, thus not being able to use the MBP at home. I returned to the office the following day, checked the box and was working fine until I restarted. My username and password (both as entry fields) never authenticated. It wasn't until I used my local admin user (that was established on install) and used "Switch Users" that I was able to login successfully. The difference, the username was preselected for me. I switched the login form to be a list of users so I only have to type in a password. Everything is working as expected.
Eric Lukens said that Leopard does not authenticate accounts that are in sub-domains, which he suspects is a bug:
We've identified that Leopard does not authenticate accounts that are in sub-domains. We have a main domain forest with several sub-domains. The computer can be bound to any of the sub-domains or the main forest, but only accounts in the main forest will successfully log in. We've looked at the Directory Service debug logs, and the Leopard machine seems to find the account in the sub-domain, but doesn't not complete authentication. Also, Directory.app will only show names from the main forest, not the sub-domains.
So far we've been successful with accounts that are part of the top-level forest. Since the option exists in Directory Utility to "Allow authentication from any domain in the forest," I'd say this is a bug that should/will be fixed.
David Troup's discovered an odd bug:
I've just installed Mac OS 10.5 for the second time on the same machine, I can't get it to log onto the AD, even though it creates the computer account.
I've have found a nice little bug though, if you have the Mac connected to the AD and logged into the Mac as a local admin you can't create user accounts, it creates the home directory but not the user; as soon as you disable the AD then you can create as many accounts as you like.
Corwin Ip can't log in with his Windows account info:
On one machine, I did a Leopard upgrade, and could not login with my Windows account info. I logged in as a local admin and had to force unbind. There were no problems binding it back to AD, but still cannot login with my Windows account even though I had to use it to add the machine to the Windows domain.
The second machine was a clean install, same thing as first, except without the unbinding problem because it was never on the domain to begin with.
MGM, a Leopard beta tester, said that Active Directory was broken in the pre-release versions of Leopard:
In Leopard build 9A559, binding to Active Directory 2003 was not totally working. You could bind to AD, in Directory Utility, but it was then useless. Upon logout and when attempting to login/authenticate to AD for the first time and thus create your local profile, no go, the OS X login window just shakes, no login. The bug was filed, let's hope it is fixed in a shipping Leopard.
Jason Sheridan:
I am having this same issue with upgrading and with a clean install.
Current news on the MacWindows home page.
 |
Got Boot Camp? You need MacDrive 7
MacDrive 7 lets you access your Mac OS X partition, and all other Mac disks, from within Windows. Mac disks look and act like standard Windows disks. Windows apps can open and save files directly on Mac disks. Copy files between HFS/HFS+ Mac disks and NTFS or FAT32 disks.
|
The Leopard 10.5.1 update's effect on Active Directory | Top of Page |
Apple did not list any fixes for Active Directory bugs for the 10.5.1 release, and readers didn't see any improvement.
Reader says 10.5.1 doesn't help AD problems, nor does turning off Bonjour
Monday, November 19, 2007
Brad Ong reported that the Mac OS X 10.5.1 updated did not fix Leopard's Active Directory binding problems. Turning off Bonjour, as another reader recommended, also did not help. In his report, Ong describes the procedure he used:
I did update the MBP to 10.5.1. It doesn't help. Brand new MacBook Pro, 2 weeks old. I've been administering Windows since NT4.
When I didn't bind the MacBook Pro to the directory, I was able to use Keychain to see my Windows server shares. Was able to get the MacBook Pro to use my Windows 2003 print server, and I was able to get Entourage to use Exchange to download my mail.
Started binding to AD and set it up according to the common procedures in the forums: Set up Directory Utility services with Create mobile account at login, Require confirmation. Use UNC path, all checked under "User Experience", set the preferred server to my main domain controller under "Administration". Clicked on Bind and the MacBook Pro was added to the domain.
The MacBook Pro showed up in the Active Directory Users and Computers. Showed up in DNS. I had to create a reverse pointer record.
So, the Active Directory plugin is enabled, "domain.local" shows up in the Directory Servers tab, all my computers show up in Finder "Shared." Printers still work well. Windows shares still work. Directory now shows all the users in my Active Directory listings. When using Accounts in System Preferences, the "Allow remote users to login" is checked and the Active Directory user names show up for "Allow these users to login".
Then I log off, click on login and the "Other." The login name shows up as expected.
Here's the problem: I enter all variations of domain\username, username@domain.local, etc. but all I get is the login screen shaking at me.
I tried the disabling of Bonjour as recommended at MacWindows, but that didn't help.
I tried restarting the laptop but that only makes the "Other" login name listing disappear. Then when I try to logon with my local admin account it takes forever. Sometimes I have to hold the power button down to shut off the MBP then power back up. This may allow me to login with the local admin account in a reasonable amount of time.
If I unbind the MBP from the domain, everything gets back to being really quick and snappy.
TIP: a suggestion for 10.5.1 -- avoid binding in 10.5.0
Monday, November 19, 2007
Toni Weurlander of Finland avoided problems with Leopard 10.5.1 by NOT connecting in 10.5.0:
I just installed a new MacBook Pro freshly with Leopard, updated it to 10.5.1 and bind it to our AD. Everything just worked like it did on Tiger. Never tried to bind it with 10.5.0. All SMB shares seem to work as expected.
Reader verifies Leopard 10.5.1 binding to AD: avoid binding in 10.5.0
Thursday, November 29, 2007
Benn Kovco verified a suggestion from another reader for getting Leopard 10.5.1 to bind to Active Directory:
I've managed to get solid, functional AD connectivity after experiencing all of the issues describe in various forums. I finally got it to work by following Toni Weurlander's suggestion at MacWindows.
This worked for me, taking care NOT to even attempt to bind AD while still on 10.5.0. I posted more at the Apple Discussion forums.
Leopard Active Directory problems continue with 10.5.1 update
Wednesday, December 12, 2007
Stephanie Renken reported that Leopard's Active Directory problems were not fixed with Apple's 10.5.1 update:
I upgraded my AD bound Tiger laptop to Leopard, and could not log in after the upgrade unless I unplugged my network cable. I unbound the machine to get past this issue, and have never been able to rebind it using my credentials. I get the "Invalid user name and password combination error. However, another admin user can bind my computer with no error. I'm now running 10.5.1 and still cannot bind this computer using my credentials.
Apple rep recommends lobbying Apple to fix AD-Leopard incompatibilities
Monday, December 17, 2007
Jem Dowse in London was given some advice about getting Apple to fix Leopard's Active Directory bugs:
I asked someone I know at Apple today about the various Active Directory issues that persist with Leopard. His advice is to escalate the problems with AppleCare, especially if you have one of their premium accounts. Chances are everything you say will be a known issue, but escalating it will be another prompt for Apple to prioritize some fixes. I actually got an apology of sorts from him. He said that this is completely new code and problems should be fixed in the next dot-release or two, but couldn't comment on time scale.
Me, I'm waiting for the day when I can bind just one machine to our domain even once. Till then we have 350 machines here that are definitely sticking with Tiger!
The Mac OS X 10.5.1 update did not fix these problems.
Reader says clean Leopard install resulted in performance hit for AD access
Tuesday, February 5, 2008
Frank Ong tried a clean install of Leopard. He didn't have the Active Directory binding problems that a lot of reades have reported but did see another problem:
Just thought I'd let you know that a clean install of Leopard up to 10.5.1 before doing any binding did allow me to bind to my Active Directory and get my logon account to work (my user home directory even showed up). But any process accessing my directory (from using file shares to routing a print job to logging on itself) was sooooooo ssslllooowww that I just gave up and took my Mac off of AD.
If you've seen this
More suggestions for Leopard 10.5.1 (and maybe later) and Active Directory
TIP: Suggestion for Leopard binding to AD points to LDAP, Kerberos issues, in hosts file
Wednesday, December 12, 2007
Hugh Burt did some troubleshooting of Leopard's problems binding to Active Directory that many readers have been reporting. He found that Leopard was selecting different servers for LDAP and Kerberos. He discovered a way to get around it:
With Leopard, the Mac seems to ignore the priority settings for LDAP and Kerberos Services in the DNS, hence it kept selecting the DC that was behind the firewall, rather than a local server. The firewall allows LDAP access, but no RPC, Kerberos, etc. so the process would fall over with the unknown error.
As a work around, we added the name of the firewalled server to the machine's hosts file but with an invalid IP number. This then forced the machine to go off and try another server BUT then the binding would fall over right at the end with an "invalid username" message. A console message also said a password could not be changed.
Using wireshark again, we found out that the machine was selecting different servers for LDAP and Kerberos. It was using LDAP to create the account with one server and then using another server and Kerberos to set the machine's password. This second DC would then fail the process because it was not aware of the account that had been created milliseconds previously on the other server. (AD servers take about 15 minutes to replicate) so hence the slightly ambiguous but correct console message.
As a work around, we added all the local DCs to the host file but all with the IP of a single server. This made the machine use the same server for both LDAP and Kerberos and at last we got the machine to bind. Another workaround would be to manually create the account, wait 15 mins for the DCs to replicate so they are all aware of it, and then bind the Mac.
The sys admin also commented that the binding process "really hammers the DNSs" and that PCs do it much more simply. Also 10.5 does not seem to do reverse lookups which 10.3 and 10.4 did.
Hope this might help some people struggling with AD binding and perhaps someone from Apple may read it as well because the AD plug-in really does need some re-writing.
If you've tried this
Another report on editing hosts file for Leopard/AD issues
Monday, December 17, 2007
Jason Bennett sent us report on his progress with editing host files to get around the Active Directory problems in Leopard:
I saw your post on macwindows.com regarding the 10.5 binding and editing the hosts file. I edited /etc/hosts to force all nine of our domain controllers to a single IP. Then I tried to bind and got the invalid username/password deal. Then I pinged the different domain controllers and they were pointing back to their real IPs.
I restarted the computer and pinged again and everything went to the IP I had in hosts. I thought maybe I was in the clear so I tried binding again and I got the same error. I pinged the servers again and they were back to the real IPs.
So I restarted again and pinged the DCs and they were all going off my hosts file again. Opened a terminal and pinged a server as I was trying to bind and it stayed with the hosts file but the computer didn't bind. Stopping and restarting the ping changed it back to the real IP after the bind failure. I then tried this with all of the domain controllers pinging at once as I tried binding and still no luck.
So that's where I'm at now, trying to figure out why binding to AD breaks free from the shackles of /etc/hosts.
TIP: Use full domain name for Leopard AD bug; A reader hears from Apple | Top of Page |
Wednesday, January 2, 2008
Michael Anderson provide another suggestion for working around problems with Mac OS X 10.5 Leopard binding to Active Directory:
I've seen this in several iterations and with several different symptoms. But it's been easy to fix. The problem is that the Leopard implementation is picky.
- Make sure your time zone is set correctly.
- Make sure your Date/Time are auto set by the system. Or that it is VERY close to what the AD server is set to (if it's off by just a little it won't work).
- Make sure your using your full domain, as in "domain.company.ext." Not just the short name for it.
- Make sure the checkbox to allow domain administrators to administer the box is checked.
That's it. I have had a few different error messages. And if I double-check all four of these things, it has works every time: 18 and counting.
If you've tried Anderson's suggestion
if it worked for you.
Keith Cox reports that Apple told him that the problem is with large networks:
We have the same issues with computers not being able to join the domain. I have talked to Apple and we have been told the issue is related to large domain of more than 64 DC's.
Readers verify " full domain name" tip for Leopard AD bug
Two readers report success with a tip from Wednesday (directly above) on enabling Leopard to bind with Active Directory.
Tom Stovall:
Yes, AD sign-in does work for me if I use a fully-qualified active directory name eg... jrizzo@division.company.ad
Adrian Stancescu focused on Step 4 of Wednesday's tip
With regards to the Michael Anderson's tip, it seems to have worked for me. The only thing I did differently when trying to bind my Mac was Anderson's Step 4, to check the box that allows domain admins to administer the computer.
Everything works now, including accessing the GAL through AdressBook or through the Directory application. I am amazed. I have even managed to log in with my AD account and it worked fine.
TIP: Date, time, DNS setting for Leopard AD binding
Friday, February 15, 2008
We've previously reported several suggestions for overcoming Leopard problems binding to Active Directory, including deleting the original AD Directory Services entry, turning off Bonjour, and editing LDAP and kerberos settings in the hosts file.
Rob Fawcett offers another suggestion that is similar to another previously reported suggestion:
We resolved our binding issues. Try the following:
Ensure DNS is setup correctly, Date and Time is configured to get time from internal AD server. (Change Kerberos Time Sync in Default Group Policy to 180Min)
if this works for you.
Tips for Active Directory binding with Leopard: remove user, uncheck mobile user | Top of Page |
Wednesday, January 23, 2008
Fabien Hory shared a couple of tips for binding Leopard to Active Directory:
Here are a few tips I discovered for Mac OS X 10.5 AD integration.
First of all, if your computer already exists in AD, ask your admin to remove it before trying to reintegrate it and wait until the replication is complete (ask it to your admin).
Another tip that worked for me : after binding the Mac to AD, I wasn't able to login with an AD user. To solve it, I had to uncheck the "create a mobile account" in the AD configuration DialogBox.
If you've tried these suggestions
Leopard AD binding: success with a type of login after security update | Top of Page |
Earlier this week, we had a report that a recent Leopard security update was the cause of problem with ISA proxies. Today, James Perih says that the recent security update helped Leopard's Active Directory binding issues with a certain type of login:
Now I'm *REALLY* confused.
I unbound from the Active Directory, and bound again to the directory: Used my Administrator@domain.local account to login (the whole fully-qualified account sign in) Everything worked peachy.
I logged out.
Logged in as a domain user@domain.local : DID NOT WORK.
BUT, then I logged in just as domain user (without the @domain.local) -- and much to my surprise, IT WORKED. I tried all my users, and it worked.
And I swear, this is what I've done in the past, which did not work. 10.5.1 installed. All updates and security updates installed. Did something in a security update fix this?
I should also specify that:
1) I used the Microsoft Document on how to connect Mac OS X 10.x clients to Small Business Server 2003 SP1, back when our macs were 10.4.x
2) That worked perfect.
3) I always used the option, "Allow Domain Admins to Administer this computer," even back at 10.4.x
4) I did in-place upgrades of the Mac clients to 10.5. Directory lookups worked, Binding and Unbinding worked, but authentication did not work.
5) I followed the instructions I sent you the first time around... unbound, rebinded, etc.
6) Still didn't work.
7) Upgraded to 10.5.1 around Dec15 or so. Did the unbind/bind again -- same pickle.
8) Since then, our Mac clients have received various Software Updates, including the security updates as of late. And, NOW it works fine, as I had previously specified. I cannot pinpoint the updates as the factor that allowed AD Authentication to work, but what I can say, is that a) using fully-qualified account login DID NOT WORK (although during the bind process, I did use a fully-qualified account login for the domain admin), and b) I did the same steps as before Software Updates, and it did not work. But now, suddenly, it does.
If you've seen this
Suggestion for Leopard on Active Directory login problems | Top of Page |
Tuesday, February 5, 2008
A reader called Marbil has a suggestion for using Mac OS X Leopard in Active Directory networks:
I am able to bind and login consistently now on 10.5.1. Binding doesn't seem to be the major issue, but logging into the network accounts seems to be the principal issue. Here is my solution:
Before you begin select "Show advanced settings" in the Directory utility. In the Directory utility under Search Policy I clicked the plus sign and added the specific domain I am currently in. By default, the search path is set to All Domains. Selecting the domain I am in resolved the issue for me. After multiple reboots and different test accounts logging in was still possible.
As a test I also unchecked "prefer this domain server" located in the Services tab > Show advanced options > then select the Administrative tab. After a reboot the settings from the search policy tab still held up.
If you’ve tried this suggestion
The Leopard 10.5.2 update's effect on Active Directory | Top of Page |
With the Mac OS X 10.5.2 update, Apple promised that it fixed problems binding to domains. Some readers reported that the update did fix there problems, while others still had issues.
Leopard 10.5.2 will fix AD bugs
Wednesday, January 23, 2008
Before the update was released, a reader name Jay reported that the unreleased beta of Apple's planned Mac OS X 10.5.2 update addressed Leopard's Active Directory bugs:
I can confirm that on any Mac running Leopard Client version 10.5.1, I have had a high failure rate in binding to AD. The common error message is "You have provided an incorrect username and/or password."
AD bind works flawlessly on Tiger. However, I have downloaded the Delta release of Leopard Client 10.5.2 from Apple Developer site and the sucess rate is virtually 100 percent. I have reported this AD feedback to Apple. So clearly, Apple is aware of the AD issues and has updated DirectoryService as part of the 10.5.2 update. I have not had to make any changes to AD, permissions or user authentication.
As to when 10.5.2 GM [golden master] will be publicly released is still unclear.
Leopard 10.5.2 update fixes some users' AD problems, others not | Top of Page |
Friday, February 15, 2008
While some readers are reporting that the Mac OS X 10.5.2 update helps Leopard's problems binding to Active Directory, other readers are still having problems.
For Brian Jackson, the update did the trick:
Just wanted to let you know that the 10.5.2 update did indeed fix the AD binding problems introduced in Leopard. We were never able to successfully bind to AD on our large network (although I never had any problems binding on smaller networks) so we are finally good to go with Leopard.
Jem Dowse still can't bind:
I was anticipating 10.5.2. as the fix that would take me back to the simple Tiger days of binding to Active Directory. Unfortunately the only thing that has changed is the message that's displayed when I try and bind - it freezes at step 4 for "an unknown reason." Investigation reveals that it's still error -14006 that's tripping it up (this used to be displayed in the error message; now I have to dig in the logs for this information!)
So 10.5.2 fixes nothing as far as my Active Directory binding problems are concerned.
Login Items probles: blank screen, then can't login after logging out | Top of Page |
Friday, February 15, 2008
The 10.5.2 update fixed Andrew Plant's binding problem, but he still has other issues, including joining a wireless network:
I updated my AL PowerBook G4 to 10.5.2 and was able to finally bind to my company's AD. I also was able to actually login with my user account and create a mobile account.
I tried accessing a network drive as well. It mounted; however, it prompted for credentials which points to a problem with single sign on authentication.
There is another issue when trying to access the Login Items for the user under Accounts in System Preferences. When you click on that tab, it hangs for a while and finally a blank screen comes up. Finally, the biggest problem, after you log out, you can't log back in. It seems to try for a while but then it shakes no. I tried changing things in Directory Access with no resolve.
I also still can't get connected to our WPA2 Enterprise wireless network. It tries to authenticate but just assigns itself it's own IP. I'm willing to bet that there is a serious issue with the OS recognizing the user and their permissions because our wireless LAN uses AD authentication. This would explain why I'm seeing issues logging into a network server as well.
whether Leopard 10.5.2 fixed any of these issues for you.
TIP: Workaround for Leopard AD login issue: use last name, first name as the username
Monday, February 25, 2008
Andrew Plant sent an update to his report last week (directly above), offering a workaround:
For kicks, I tried using my last name, first name as the username when logging in and wouldn't you know it, it worked consistently! Also, in our AD accounts, we have drives that are automatically set to mount and they do. However, I still have to enter credentials when mounting other network drives. The other issues I mentioned before are still present though. I guess Apple still has some work to do.
If you’ve tried this suggestion
Reader can't login to AD as admin with Leopard 10.5.2
Wednesday, February 20, 2008
Dave Macrae found a new Active Directory problem after upgrading Mac OS X Leopard to 10.5.2:
I applied 10.5.2 the other night and am able to bind to my Windows 2003 server domain. I cannot login however with an administrator account. The screen just shakes when I try to log in. I've reset the password on the domain. It's the most frustrating thing. I'm at a loss as what to do now except restage my Mac Book Pro and hope for the best.
If you've seen this or have a suggestion
TIP: Edit hosts file to add domanin controller IP address | Top of Page |
Over a period of several months, several readers independently suggested (with some variations) that adding the IP address of the domain controller to the hosts would get AD binding back up.
Advice for AD binding with Leopard 10.5.2: resolve to the IP address of domain Controller
Thursday, February 28, 2008
A reader named Nik describes how he enabled Active Directory binding in Leopard 10.5.2:
After a clean install of 10.5 I upgraded to 10.5.2. I then got the error message "The computer is unable to access the domain controller for unknown reason." I found out that domain must resolve to IP, as described in this blog I found. After applying the suggestion, I was able to bind to Active Directory.
The blog starts like this:
Your domain must resolve to the IP address of a domain controller. This was not a requirement in previous versions, but Apple is apparently making it a requirement.
TIP: Add IP address of the domain controller to hosts file
Although Apple said that the Leopard 10.5.2 update fixes issues with Active Directory, Lisa Madden said she still has problems. She fixed it by editing the hosts file:
I upgraded a cleanly installed 10.5.1 Mac with 10.5.2 and still could not bind to AD. Got stuck on the final step, not able to find the DC. There was no way to specify the domain in Directory Service either.
What finally did fix the problem was adding the IP of the DC and the domain into the /etc/hosts file, rebooting Mac, and trying to bind again. Bind went flawlessly then.
Not sure if this is a problem with how our DCs are configured, or with Leopard, but as long as it's working, that is all I care.
If you've tried this
TIP: Fix disjointed Namespace and AD binding with Leopard Server; add IP of DC to hosts file
Pete Langlois told us how he fixed his Leopard Server/Active Directory binding problem:
We were having a hard time with binding AD to 10.5.2 Server recently. We have a disjointed namespsace in Active Directory, which Apple is aware of having issues. After lots of testing this is how we fixed the issue:
- ADD to /etc/hosts file all FQDN and IP of 2NDDOMAIN domain controllers making sure you cp the file first | I got my list by typing the following in a terminal window "dig any _kerberos._tcp.2NDDOMAIN.com"
- Under Directory Utility/Show Advanced Settings/Services/Active Directory/Advanced Options/Administrative/ UNCHECK "allow authentication from any domain in the forest"
- Under Directory Utility/Show Advanced Settings/Services/Active Directory/Advanced Options/Administrative/ ADD Prefer this domain server (Local DC's IP address)
- ADD TOPLEVELDOMAIN to Search Domains under System Preferences/Network (2NDDOMAIN should already be there if not add it as well)
- Under Directory Utility/Show Advanced Settings/Search Policy/Authentication ADD Active Directory/2NDDOMAIN and REMOVE Active Directory/All Domains (Correct order should be Local, BSD, 2NDDOMAIN)
TOPLEVELDOMAIN has our schema. 2NDDOMAIN has all of our objects. We have numerous 2NDDOMAIN domains but I figured this might help out other users with large enterprise AD in a disjointed namespace.
If this helps you (or not)
Binding problems almost fixed by adding IP of DC to hosts file, but with odd symptoms
Lisa Madden thinks there's a configuration problem with one of her Active Directory domains with Leopard:
I was able to bind a Mac running 10.5.2 to AD if I put the DC IP and fully qualified domain name in the Hosts file. I should not have to do this. Did not have to do this in Tiger. I got same errors, though, as posted below.
Then I wiped Mac and reloaded Mac OS X. This fixed having to put the DC IP etc. in the Hosts file, so one thing solved. However, while I am able to bind to AD and log in with domain credentials, I can ONLY do this one time. If I just log off and log back in, everything is peachy. If, on other hand, I shut down, reboot, what happens is it lets me log in with domain credentials but immediately brings up the Parental Controls screen and says I have one hour. Huh? I never enabled this. Even if you choose rest of day and authenticate with admin account to get past this screen, your user folder is totally locked. You will never log back in with domain account again.
I have tried this on our regular domain used for Tiger binding, and also in a test OU with no policies going to it, with same result. Next test is a different domain entirely to see if this very odd problem persists.
I think it is our ad config as there is no problem if I bind to different domain.
If you have a suggestion
Current news on the MacWindows home page.
|
|
Parallels Desktop 3.0 for Mac Run Mac, Windows programs without switching between Windows and Mac OS X! Launch a Windows app by clicking on a Mac file. Hide the Windows desktop. 3D Graphics hardware acceleration. The best of both worlds. |
More tips and fixes for 10.5.2 AD problems | Top of Page |
This section describes suggestions for fixing several different Active Directory issues with Leopard 10.5.2. They may also work for other Leopard builds.
DNS solutions to 10.5.2 AD problems
Monday, February 18, 2008
Although Apple says the Leopard 10.5.2 update is supposed to fix Active Directory binding issues, readers are still reporting problems. A couple of readers found fixes in DNS. Steven Bandyk offerred this suggestion:
Like Jem Dowse, who you quoted in your post at macwindows.com, the 10.5.2 did not fix my AD authentication. I have the exact same problems he described.
I have found the problem however. With the assistance of the macadministrators list and the UIC United Mac Users list I realized that I had a DNS problem. It appears our DNS (non-Microsoft) lacks DNS RR SVR records which would point the AD domain to a Domain Controller. If you lookup your domain it should resolve somewhere. e.g., say your DC is "dc1.ad.example.com". You should be able to resolve "ad.example.com".
I'm waiting on the campus AD group to understand what I'm talking about. They don't run DNS. In the mean time, I can bind by adding entries for our domains in /etc/hosts.
If you set DirectoryService into debug mode: > killall -USR1 DirectoryService ... you can find the failed lookup for your domain in the /Library/Logs/ DirectoryService/DirectoryService.debug.log
Noah Willamsson got Leopard 10.5.2 Active Directory binding working by keeping the computers time synced and keeping DNS working:
I got this message while trying to bind to AD: "Unable to access domain controller. This computer is unable to access the domain controller for an unknown reason."
I get this both in the Directory Utility GUI and from the command line (dsconfigad). I got things working with my MacBook Pro upgraded to 10.5.2. The AD servers are running Windows 2003. I was connected to my employer's network with Cisco VPN.
First, when working in a Kerberos environment, it's important to keep time in sync on all involved computers. Secondly, DNS must be working properly as well.
I'm trying to Bind to the domain "galax.hd.se" which have the Domain Controller servers dc1.galax.hd.se and dc2.galax.hd.se.
1. I turned on debugging on the DirectoryService process by killing it with the SIGUSR1 signal and watched /Library/Logs/DirectoryService/DirectoryService.debug.log while trying to bind. The error message popped up shortly after "Step 4/5".
In the debuglog, I found that it complained that "galax.hd.se does not resolve - disabled" and then subsequently faild.
2. I tried to force the thing to use a specific DC hostname by checking "Prefer this domain server" and trying to bind with dc1.galax.hd.se or dc2.galax.hd.se. Both failed.
3. I noticed galax.hd.se didn't have an A record in DNS, i.e, it wouldn't map to an IP-address.
I don't know if this is a problem as it was still able to find out about dc1.galax.hds.e and dc2.galax.hd.se according to stuff in the debuglog (not shown).
What I did to get things working now was to add the following line to /etc/hosts
<ip of dc1.galax.hd.se> galax.hd.se
4. Now I tried to bind again and it worked!
So to summarize what worked for me:
- Time must be in sync on all involved computers
- DNS must be working
- The Active Directory Domain you're trying to bind to should have an address record (A-record) pointing to one of the DC servers.
If you these approaches worked for you
TIP: AD binding and login fix for 10.5.2 | Top of Page |
Peter Kloss offers a fix for Leopard Active Directory binding problems:
After my saga with Services for Unix which you kindly posted for me, we have spent a while trying to get the 'native' AD plug-in working in Leopard against our enterprise AD of 10 child domains and around 50 domain controllers. Therefore we have been following with interest the experiences and suggestions of your readers.
Having thought we might have to do most of the painful stuff with debugging Kerberos as described in your reports, we then discovered a blog that held the answers. We had already accidentally discovered that putting the DOMAIN we were trying to bind to into /etc/hosts, eg: an entry like Childdomain.rootdomain.com xxx.xxx.xxx.xxx allowed us to bind and login with a domain admin account. But normal user logons did not work for two out of three attempts to do this.
We followed suggestion (2) in the blog about turning off 'allow authentication from any domain' AND added the target AD domain to the search path - (click on the search path tab in the directory utility and the '+' at the bottom left - it then pops up a list of available domains) - I clicked on 'my' domain in the list, and then put it above 'All Domains' in the search order. Then applied and quit the Directory Utility. We can log in with ordinary user accounts, and quite speedily in most cases without having to turn off bonjour (as others have suggested).
If you've tried this fix
Losing privileges? Turn off IPv6 | Top of Page |
Thursday, February 28, 2008
Matt Short reports that turning off IPv6, which has been reported to help with a number of Leopard problems, also helped him with another Active Directory problem:
Have you had any responses of folks being able to bind to the Active Directory network, mounting a volume, but then losing all privileges as soon as a file is being opened? Let me explain:
- Brand new MacBook Pro, fresh out of the box
- Using Directory Utility I can bind to windows domain terminal can read computer profile in AD
- Server 2003 can "see" computer in AD users & computers
- Connect to a server (listed under "shared" in the panel to the left of a Finder window) with windows network admin privileges
- View a file server, open and mount a shared folder (mounts as a volume on the mac)
- Open a file (so far any Excel spreadsheet)
- Get an error: 'file_name.xls' cannot be accessed....
- Mounted volume disappears
- Windows 2003 server no longer has computer "macbook" listed in AD "computers"
I'm running 10.5.2. I was on the phone with Apple Tech Support for about an hour and half Thursday night. They sent the problem to the Apple Engineers. What seemed to help some is turing off IPv6. At least then, I could open some files, although not all. The biggest problem was Excel documents in Excel 2004 11.3.7. Interestingly enough, some of the smaller spreadsheets would open fine in Numbers '08, but have permission problems in Excel. Word documents, text files, etc were all okay after IPv6 was turned off.
If you've seen this problem
Problem and fix for Leopard AD: First user okay, subsequent users can't login
Stuart Sims reports a problem with Mac OS X 10.5.2 and 10.5.3 logging onto Active Directory. The first user has no problem, but users after that get a "login failed" error message. He also found a fix:
I am seeing an issue when authenticating from an OS X 10.5 client using a Windows 2003 AD for authentication and home directory storage. I've tried this on a few networks now with various configurations including Windows 2000. When logging in with an OS X 10.5 client bound to the AD and to an Apple Server Open Directory the first AD user that logs in follow a reboot is authenticated without a problem and the user logs in as expected. Any subsequent AD users that try to log on receive the error 'Logging into the account failed because an error occurred' and the following error is logged:
05/06/2008 14:35:00 authorizationhost[283] ERROR | -[HomeDirMounter mountNetworkHomeWithURL:attributes:dirPath:username:] | PremountHomeDirectoryWithAuthentication( url=smb://testserver.test.internal/testuser$,
homedir=/Network/Servers/testserver.test.internal/testuser$, name=testuser ) returned
I get the same result with 10.5.2 and 10.5.3.
The Kerberos authentication goes through OK when analyzing packets but for some reason the home directory won't mount for subsequent users unless you reboot, also if the first user that logged in tries to login again they are able to do so, but only them.
With a bit of digging I found that the first users home area is being held open/mounted. Logged on as a local administrator I tried to 'umount -A -f' i.e. umount all volumes, the first user connection was listed but would not unmount.
The Fix:
I resolved the issue by editing the following files as described:
/etc/automount
[[Note: another readers says the above file should be /etc/hostconfig -Ed.]]
Replace AUTOMOUNT=-YES- with AUTOMOUNT=-NO-
/etc/auto_master
Hash out the following lines:
#/net -hosts -nobrowse,nosuid
#/home auto_home -nobrowse
#/Network/Servers -fstab
Basically, as far as I can see this disables all automount features which is fine for AD Integrated setups which don't use any automount features and that have home directories stored on the Windows Servers.
If you've tried this fix for this problem
Reader verifies hostconfig fix for Leopard AD login problem
Tim P verified a previously reported fix for a Leopard problem logging into Active Directory after one user has logged in. The fix involved editing the hostconfig file:
I tried the fix posted by Stuart Sims regarding "Problem and fix for Leopard AD: First user okay, subsequent users can't login" posted on www.macwindows.com/LeopardAD.html. My setup is very similar to what he described: clients are bound to AD, home folders on Win2003 Servers, accessed via SMB, no local homes/mobile accounts created on login. Clients also log in to an OS X Open Directory for Managed Preferences. I had the exact same problem - the first user to log in on bootup was fine, but no other user could log in.
I had used the /etc/hostconfig edit on 10.4 clients to fix a similar problem and had tried it with 10.5, but the key was editing the /etc/auto_master file as well. This solved my problem, thank you very much Stuart! I had been puzzling about this all year.
P.S. On the webpage, the instructions are to edit /etc/automount in order to change the line AUTOMOUNT=-YES- to AUTOMOUNT=-NO-. I believe this is an error: there is no file /etc/automount, but there is a file /etc/hostconfig with the line AUTOMOUNT=-YES- in it.
I'm very thankful for this solution!
Slow Active Directory logins with Leopard, and workarounds | Top of Page |
Apple said that the 10.5.3 update address login delays when logging in to a .local domain. This problem may only apply to 10.5.2 and earlier. If you've seen this in 10.5.3 or later
Logins are "horrendously slow"
Wednesday, October 31, 2007
Alan Auman said that his logins are "horrendously slow:"
While I've been able to bind my Leopard upgrades to AD, the login for an AD user account takes up to 3 minutes to complete. Disengaging screensavers when using an the AD account credentials also suffers from this delay.
TIP: Workaround for slow AD login: Disable Bonjour
Wednesday, November 7, 2007
Leslie Wong verified a previous report of very slow AD connections, but offered an odd workaround. She also reports a problem waking from sleep:
I have two Macs in a Windows Server 2003 environment (a ".local" domain) and was able to bind to the AD after a clean install of Leopard. But logins, like Alan Auman's, were "horrendously slow." Also, any operation that required administrator authentication were similarly slow.
I found, in the Apple discussions, that turning off Bonjour immediately stopped the problem. Logins were as fast as they were in Tiger. But turning off Bonjour caused other problems, such as not being able to start Aperture.
I also noticed a problem that when the Leopard machine wakes from Sleep, it was not always able to communicate with the domain. The Directory Utility would indicate that the ADD was not responding normally and a reboot was required for it to be "responding normally" again.
Another workaround for slow AD login with Leopard 10.5.2
Monday, February 18, 2008
Tim Adams says that Active Directory binding works in Leopard 10.5.2 works, but Tiger was better:
Binding to AD seems to work fine now on 10.5.2 however I still have about a 60 second delay at the login and unlock screens when using an AD account. I have followed others' advice and use the FQDN (username@my.domain) for my username and that seems to make things snappier. So far Leopard is no Tiger in the AD integration space.
If you've seen this issue
More readers report slow AD logon in 10.5.2
Wednesday, February 20, 2008
Several readers responded to Monday's report about slow logons to Active Directory in the Leopard 10.5.2 update. John Malpas in the United Kingdom said:
We are rebuilding (erasing the drives before installing the OS) all the Macs in the business to 10.5.2 using AD (mobile accounts) where the home directories are on an XServe (running 10.4.11). We are seeing the same as most people - it takes ages to log on, if at all. Sometimes you can log in sometimes can't. We're finding it all very frustrating.
Reader named Aj also complained about performance:
I have seen this issue after getting some new iMacs with Leopard 10.5.1 and finding an article about binding them to Active Directory. I followed the article, and it worked, but it was just way too sluggish
I finally abandoned the idea because it just did not seem worth the benefit. While AD integration might be convenient, I thankfully am not in a situation where it is required.
Apple has listed Active Directory binding problems as a problem that the Leopard 10.5.2 update fixed. Leopard has had AD binding issues since 10.5.0.
Verification: Disable Bonjour to fix Leopard's slow AD login
Monday, February 25, 2008
Mark Walsh verified that disabling Bonjour fixes the slow Active Directory login problems with Leopard.
I had a similar problem, was taking about 2mins to authenticate. Disabling bonjour fixed the problem straight away. Check out this link.
If you've tried this
H. Barnes describes having the problem with the 10.5.2 update:
AD integration seems to work very well, except that authentication has like a 1-2 minute delay still (was more like 3-5min before). Tiger is instantaneous, seems silly that Leopard is still having this awful delay after AD supposedly being "fixed."
Jeff Geerling:
I have had this problem as well; all the Macs I've been able to bind to the directory (a few of them with fresh installs of Leopard, and a couple with upgrades from Tiger) take at least two minutes to authenticate a user. This is completely impractical for our situation (a school setting), where students often come to the computer lab to just check their email or print a document.
The PCs in the lab have always logged in in less than 10 seconds, while the Macs always used to take about 20. Now, the Macs take so long that students give up on them and go over to a PC. We'll probably end up reinstalling Tiger on them unless we can find a fix soon.
Theory on Bonjour and slow AD login in Leopard
Thursday, February 28, 2008
We've received more mixed reports about turning off Bonjour as workaround to slow Active Directory login in Leopard.
It worked for H. Barnes, who sent us a suggestion and a theory:
I tried disabling bonjour and it works like a charm. There is a small app called iServeBox (v1.04) for the terminal faint of heart that allows disabling Leopard services.
I did some more research on this and it appears it is actually an issue with OS X use of .local and Bonjour. This conflict only appears in domains that do internal authentication ending in .local (for example, example.domain.local). This has been standard move for many single-site businesses since server 2003 and it seems ridiculous that Apple got blind-sighted by this.
Colin Leyden in the United Kingdom confirmed the workaround:
I can confirm that disabling Bonjour does indeed fix the slow Active Directory login problem. As noted by others, login previously took 2 minutes. This was cut to 5-10 seconds after disabling Bonjour. (Windows Sever 2003, Mac OS X 10.5.2 client)
Turning off Bonjour did not help Jeff Geerling:
When I disabled Bonjour using the instructions linked to in your February 25 posting, I could no longer login using any AD names at all; it would give me the 'no' shake, and I can now only login with the local administrator password. I'll have to re-enable Bonjour and suffer through the long login time.
More on Leopard slow AD binding, Bonjour, and .local
A pair of readers commented on our reports of slow Active Directory logon with Leopard 10.5.2. Jeff Geerling, who has previously reported that turning of Bonjour fixed the problem, also notes the same potential cause in the .local suffix:
It's my hope that someone figures out a solution for everyone. I don't know if this has anything to do with the problem, but our AD server ends in ".local," which is the suffix that is also used by Bonjour.
Daniel Costello also confirmed the workaround:
I can also verify that turning off Bonjour solved the slow login problem. We are faced with figuring this out since some laptops being shipped today are quirky when Tiger is installed (they ship with Leopard). After disabling Bonjour, the 3-minute log ins went to 5 seconds. Also, the 5-minute binding duration dropped to less than 10 seconds.
Current news on the MacWindows home page.
|
|
Parallels Desktop 3.0 for Mac Run native Windows programs without switching between Windows and Mac OS X! Launch a Windows app by clicking on a Mac file. Hide the Windows desktop. 3D Graphics hardware acceleration. The best of both worlds. |
10.5.3 fixes AD problem, adds a minor glitch
Peter Kloss said that the Leopard 10.5.3 update fixed his Leopard Active Directory problem. It also added a small glitch, which Kloss was able to fix:
I wrote to you a little while back about getting 10.5.2 to bind to our multi-child domain AD forest, that we had to modify the hosts file with an entry for our domain (xxx.xxx.xxx.xxx mydomain.com for example) and to uncheck the 'allow authentication by any domain controller in the forest' option. Well it looks like 10.5.3 fixed both those problems on the one test system I've tried so far (took my 10.5.2 out of AD, commented out domain entry in hosts, rebooted, added back in to AD).
However, the add back in to AD was not entirely trouble free. I had put the computer account into another OU than 'Computers.' This caused a problem at the end of the bind process: a box came up and claimed that the OU, entered in the correct case and syntax, did not exist. This was even though it used the path to find an existing computer account and asked to overwrite it earlier in the process! I put the computer account back in to 'computers' and all worked! This could be a one-off, I haven't had a chance to repeat the test.
how the 10.5.3 update affected your cross-platform Leopard-specific Active Directory issues.
TIP: Leopard Server 10.5.3 Open Directory problem and fix | Top of Page |
Khaled Yassin reported a new problem when he updated Leopard Server to 10.5.3. He also found a fix:
The following happened the day I upgraded the Open Directory Server from 10.5.2 to 10.5.3. When any Windows user tried to connect to a Mac OS X file server it didn't authenticate. At first I thought they'd forgotten their password. But when I asked users to change password (that met the password policy). It gave the same result: authentication refused. To solve it, I put in a simple password, such as "abc" or "123," and then asked user to recreate the old password. The surprise that it now works.
If you’ve seen this issue or tried this approach
Reader can't see files with 10.5.3 and ADmitMac
Kent Barnes is having problems seeing files with Leopard 10.5.3 and Thursby's ADmitMac:
I finally got my shared directories from our Windows 2003 server to mount/auto mount in 10.5.3 (using ADmitMac for the auto mounting and joining to the domain).
Yesterday, everything was great. I saw all the files in the Publishing shared directory (probably 125 to 175 individual files and sub directories).
Today, I booted the Mac, signed on to the domain. The Publishing directory mounted, but I can only see one sub directory and three files. I've tried rebooting several times--same thing each time.
I've worked my posterior off finally getting some Macs in this organization (being a Mac user since the mid-80's). But the number of things that are breaking integration/network wise with 10.5.3 is just about to push me into pulling them all off the network and going back to a 100 percent Windows setup.
If you've seen this issue
Readers says 10.5.3 did not fix his AD problem
Although there are reports of the Mac OS X 10.5.3 update fixing some of Leopard's Active Directory problems, Kurt Tappe reports that the update had no effect:
Leopard 10.5.3 did not solve our AD issues. We've been having trouble since 10.5.0 with binding Leopard to our AD. So far, 10.5.3 has made no difference whatsoever. Here are our findings:
1) Unlike Tiger, Leopard will not bind if the AD record pre-exists. Tiger actually required that it exist or it would result in an authentication error while trying to bind. Leopard is the exact opposite--if the record exists, binding results in an "insufficient privileges" error.
This is a problem, because it's difficult in a large AD implementation to be sure a record is completely deleted before trying to bind. Our AD consists of 36 controllers around the globe, and because a "delete" command is given low priority by Microsoft, replication can take many hours. "Delete" should not even be necessary--there are AD commands to reset the password and change any necessary attributes of an existing AD record that Leopard could use instead of having to create the record from scratch each time.
2) Once Leopard is bound, AD authentication does not seem to "stick". If left overnight, AD authentications fail--the workstation cannot be unbound nor can it be logged into using AD credentials. This in spite of it claiming it's bound and it giving a green "Network accounts available" indicator on the login screen.
All of this has been communicated to Apple Enterprise support. We await resolution.
If you've seen these problems
Another reader says 10.5.3 doesn't fix Leopard AD binding problems
Devin Comiskey echos a previous report that the Leopard 10.5.3 updated did not fix Active Directory binding issues:
I'll echo the complaints about 10.5 and AD. There is NO improvement with 10.5.3. This is proving very troublesome for some of our remote users when I'm not around. Luckily each machine has a local admin account I can remotely log in to and re-bind. But often I have to unbind and rebind a few times plus a restart or two before the problems are fixed. I wish I had just installed 10.4.11 on these machines instead.
If you've seen this problem
Reader reports Leopard 10.5-to-10.5.3 update caused AD login problem | Top of Page |
Although Peter Kloss previously reported that the update to Leopard 10.5.3 fixed some problems with Active Directory, he found a new problem with an upgrade straight from 10.5.0:
I've had two of my sites report that a system that is freshly built and updated to 10.5.3 by the Combo updater straight from 10.5.0 (rather than via 10.5.2) has problems with logging in AD users. This is where the portable account option is selected and it is meant to mount the AD specified home share as a network share on logon. One gets the message "you cannot be logged on at this time." If you uncheck the option to mount a share at login then the login proceeds as normal.
On one site I got the login to work by changing the server name part of the AD-specified share to mount. They had recently changed the name and the one referred to in AD was now a secondary name, aliased but not the primary DNS or NetBIOS name of the file server. There is something strange (or unfathomable by normal logic) about the way the AD-specified home share is converted into the name that is used to mount at logon time. On my account AD specifies the NetBIOS short name, but the mount actually displays the fqdn. Changing the AD-specified share server name to use the fqdn causes it to not mount!
If you've seen this
Leopard 10.5.3 SMB mounting fails with Open Directory
Jeremy Bautista can't connect to SMB file shares when logged into an Open Directory domain:
In Leopard 10.5.3, a clean install with no Directory servers configured, SMB connections can be made without problem. After binding the Mac to an AD domain, I can still connect to SMB shares. It's when I connect to my OD domain where I run into trouble. I fail in mounting SMB shares and sometimes get the error code -6602.
If you've seen this problem
Reader's Leopard on AD reports "incorrect password" at login | Top of Page |
Thursday, December 4, 2008
Matt Klusza is having problems logging into Active Directory from Leopard. He keeps getting an error message saying that the username and password are incorrect. He said he checked our Leopard/Active Directory Tips and Reports page and could not find any information. Klusza's report:
I am struggling to fix a small error here related to Leopard 10.5 Directory Utility.
We have a department room with 10 Mac Pros on Ethernet. Each Mac Pro is bound to Active Directory by Directory Utility. No local accounts because students have their Active Directory username/passwords. No LDAP configuration.
A student told me that he couldn't log in. I tried with my username and it won't let me log in, either. I then logged in as a local admin since I am an Apple Technician and clicked on System Preference's Date/Time Pref pane and set up correct time zone and locked it. Next, I opened Directory Utility application and clicked "Services" icon and clicked on "Active Directory". I unbinded this computer ID and re-binded with correct "Network Administrator Required" username and password provided by our ITS Department. The box appeared saying that I entered an incorrect username/password.
I had to ask my ITS Department Network Administrator to remove this specific computer ID off from the server for me to re-bind this. After the removal of this specific computer ID, I attempted to re-bind and it wont let me to due of incorrect username/password. I am completely puzzled.
I also am trying to find a specific folder to clean up Directory Utility's caches. I know we can delete caches from Tiger 10.4's /Library/Managed Preferences folder. But I can't do the same thing with Leopard since Leopard killed "Netinfo". Is there a way for me to clean up the cache on Leopard or any advices would be appreciated.
If you have a suggestion
Reader loses AD login after OS X 10.5.6 update | Top of Page |
Thursday, January 22, 2009
Nick Elniff started having problems with all of his Macs and Active Directory after installing the Leopard 10.5.6
We have about 22 machines running Leopard in an Active Directory environment. They have all been working great for the Fall semester. But ever since the 10.5.6 update we have had problems.
- No network login worked. Every machine had to be unbound from AD and then bound back - adding the proper AD user group with administrator privileges.
- Tablet drivers are no longer loading for some users
- Some users are not able to view their local home folders and can't even make a new folder on the desktop.
- Sometimes it takes a couple logon tries to even get a network login to work
I am Enterprise and Domain admin and have these privilege issues and the tablet drivers do not load. There was one iMac that was skipped and it works flawlessly for everyone. I really do not want to go and re-image every machine if I don't absolutely have to. No settings have changed that previously worked flawlessly.
If you've seen this problem
More readers lose AD login after OS X 10.5.6 update
Several readers responded to last week's report about Mac OS X losing the ability to log into Active Directory after installing the Leopard 10.5.6 update.
Vladimir Paniouchkine also has the problem, and described how he tried to get around it:
I have seen this issue. We have had a problem the similar problem with about 50 Macs in our labs, It started with the update to leopard. Our problem is the following. We deployed the images 10.5.6 to 50 computers using system image utility, and bound the to the AD. They bind just fine and work for a few days maybe even a week. Then they as group stop accepting AD users, the green ball still shows up as everything being connected when I log in with a local admin. To get to work again we need to unbind and re bind them. Tried the following.
- Creating the computers in AD before we bind them.
- Resetting the local KDCs, which I have read somewhere that it should have helped. Along with removing the AD Preference file after deployment.
- Binding them just normally with out creating the accounts before hand.
- Created a brand new image to see if that was the fault didn't help.
- Used dsconfig to bind them.
Nothing has helped.
Walter Huber:
Have this same/similar problem, installed Leopard 10.5.6 on an external disk, a clone of my Tiger boot drive, after which my network login was no longer accepted on the boot drive but is accepted on the external. It does seem to be an issue with 10.5.6 and Active Directory. Since the inception of Leopard there's been one problem after another with AD. I'll have to get the network admin in tomorrow to reset AD, as it seems there's no way for and end-user to solve this snafu.
Santos Ortega reports a variation:
I am having similar authentication issues except that only when I am not connected to the proper network. When the MacBook Pro (10.5.6) is either connected to the wireless or Ethernet authentication works. When it is off campus for some reason it does not realize that a home directory was created and that user exists. In the directory utility application I have Force local home directory on startup disk enabled. Usually this allows my users of Laptops to go home and use the laptops with out problems. Unfortunately not with the current update, for some reason it seems like it does not realize that the local profile was created. Is there something that I might need to try or that I am doing wrong?
If you've seen this or have a suggestion
Leopard losing AD login may be related to forced unbind; problem unbinding
Wednesday, February 11, 2009
Mike Burdett sees the problem of Leopard losing Active Directory login. His Macs are also having problems unbinding. He suspects that forced unbinds may be related to the issue of losing connections to AD. He also asks if it could be related to a corrupted UID. Burdett has these problem with multiple builds of Mac OS X 10.5, not just 10.5.6:
We are having almost every OS 10.5 Mac (so far 10) loses its connection with Active Directory, DC 2003, server. Even Macs with new OS 10.5.6 that are deployed and added to Active Directory are having this problem.
The problem may start after computer has a problem shutting down and is forced. On restart domain account are not authenticated. These AD accounts can login with cached credentials.
I can discover information from the domain but I cannot unbind the computer from the domain without forcing an unbind. If we remove the domain account(s) and try to bind the computer to the domain the computer can't authenticate to the domain to bind to the domain. The only to repair this problem is to re-image the computer or to reinstall the system. However with in weeks or months the problems will return.
Could the problem be the computers UID used to authenticate to active directory is getting corrupted or is changed? Any way to fix this without reinstalling the OS?
If you've seen this problem or can commet on the cause
Current news on the MacWindows home page.
Unbinding/rebinding a workaround to Leopard Active Directory login problems
Wednesday, February 11, 2009
Two readers independently reported that unbinding and quickly rebinding temporarily fixed problems with Active Directory. One reader used the technique for the previously reported problem of Mac OS X 10.5.6 losing Active Directory login. Another found that it helped with a problem logging into Active Directory: the first login doesn't, but binding/rebinding enables login.
Matt Fecteau found the unbinding/binding temporarily worked for the problem of Mac OS X 10.5.6 losing Active Directory login, but that the technique no longer works, and the problem is getting more widespread:
I have experienced this same problem and for a while I was able to unbind and rebind all of the machines as a quick fix. However, lately that problem has not fixed the issue. Sometimes when I unbind a machine it will work but when I attempt to rebind it, it tells me my credentials are incorrect or that I do not have sufficient privileges. I am a domain admin and it used to work just fine.
We are seeing more and more issues across the University where students and teachers alike cannot log in to certain Macs but they can on others. I have not found a fix or any work around as of yet.
If you've seen this
Paul Wynder found that unbinding/rebinding is a workaround to problems logging in with OS X 10.5.6. But the first login still doesn't work:
I've been trying to get a new PowerMac with Leopard 10.5.6 to log in with an AD account. The machine has never been bound to AD before.
Binding took about 30 minutes to work. I was a bit miffed about that, but at least it worked. Stayed on step 1 for most of that. I'm running this Mac on a massive corporate global network, so maybe understandable if the binding process has to go for a long walk around the network. Was much quicker on all out Tiger Macs though.
Not so much fun when I couldn't then get a login with any AD account though!
I tried lots of stuff, including disabling Bonjour. Couldn't get an AD login to work. Once the Mac had been bound, even logging in as root took several minutes each time, though worked eventually (phew!). Only unbinding from AD enabled me to log in quickly (with a local account) again. Oh joy! Another Mac with the same spec has exactly the same problems.
Then I stumbled on a breakthrough. If I logged in after merely logging out, rather than doing the full Restart, hey presto! I could then log in either with a local or AD account, and quickly. I kicked myself as thus far, every time I tried yet another "solution" I'd restarted the Mac (well, that is what they tell us good practice usually!).
Overjoyed as I was about this breakthrough, the problem remains that the first login after a Restart or power-on simply won't work. It shakes within about 10 seconds. Using any local account does let me in, but only after about 15 minutes. Giving them to the users in this state is not an option, so I have to disable AD for now. That's a total pain, to put it mildly! Most grateful (and desperate) for any further light anyone can throw on this.
If you've seen these issues
TIP: Two kerberos-related workarounds for Macs losing AD binding
Thursday, February 19, 2009
Two readers sent in workarounds to the problems of Mac OS X 10.5 Leopard Macs losing Active Directory binding, having problems logging in. Both have to do with kerberos, but are different approaches. (We'd like to
if you've tried these.) The first reader uses the Kerberos Utility to do a slight reconfiguration. The second reader uses Terminal to delete a corrupt kerberos file.
Eugene Brodsky in Ontario, Canada, uses the Kerberos Utility. The unbinding/ binding suggestion from last week didn't work, but this does... Read entire story here
Readers verify, modify Kerberos fixes for Macs losing AD binding
Tuesday, February 24, 2009
A number of readers responded to our February 19 TIP: Two kerberos-related workarounds for Macs losing Active Directory binding. Several readers verified one or the other of the two February 19 tips, some with variations. One reader added some steps to one of the tips. Another reader received an explanation from Apple, as well as a suggestion that was different than the February 19 suggestions. Two additional readers also offered different fixes than those already presented. To summarize, the two fixes previously report are... Read entire story here
Reader question: move Mac AD profile to mobile? | Top of Page |
Chris Cavanaugh asks how to migrate Macs on Active Directory to mobile profiles:
We are in the process of migrating machines into our new Active Directory Environment. The PC migration has gone fairly well, however, management would like us to start binding our Macintosh's to AD so users would use their campus ID and password and adhere to our password change policy. We are successful in binding Macintosh to the domain however, we have not figured out how to move profile settings from a local profile to a network/mobile profile. In the Windows environment, we have been using a 3rd party tool that has worked very well.
If you've seen this issue or have a suggestion
TIP: workaround for Macs dropping off AD every 15 days | Top of Page |
Kurt Fattic passed along a workaround he found for Macs that drop off of Active Directory every 15 days. It's a Terminal command that will get the Mac back on. Fattic reports:
I can't take credit for this, but it was on a listserve. This may help some folks out:
...The issue that we found was that every 15 days the Macs would drop off the AD, this is because it would request a new QUID from our AD server. We have had lots of success with the following:
Dsconfigad -passinterval 0
This is a Terminal command to have the Mac never request a new QUID. Don't know how your systems are setup but this has worked very well in our environment. The only issue here is that when reimage or unbind and rebind you need to remember to type in this command or in 15 days it will again fall right off the wagon.
Another issue we have with our Macs on the AD is the computer account information. When you unbind and rebind to the domain is should ask to rejoin the existing account. If it does not that means that it has created a new account with the same name. Most of the time these duplicate accounts cause problems down the road and is best to start fresh.
-- Steve Rodman
If you've tried this
TIP: Using Deep Freeze and Macs dropping off AD every 15 days | Top of Page |
Chris Hansen responded to a previous report about Macs dropping off of Active Directory every 15 days. Hansen believes it is due to the use of Faronics' Deep Freeze, software that takes a snapshot of the state of a Mac and returns the Mac to that state every time it boots. He also offered a solution:
In our case, the only Macs that dropped off the AD after 15 days were those in our school labs. On those, we use Deep Freeze for Mac, and the machines would request and receive a new machine password after 15 days. After rebooting, all changes are lost to the Mac (great for keeping a lab pristine) but not to the AD. So the Macs would use the previous password, and the Network Accounts would stay unavailable, seen in the login window as a Red Light.
If this is your situation, in Terminal:
Dsconfigad -passinterval n
Where n = number of days before the machine password expires. O will set it to never, 365 will set it to a year, etc. The default from Apple is 15 days, and it is not a problem for us with unfrozen machines.
I first saw reference to this at this blog.
If you've seen this issue with or without Deep Freeze, or tried this approach,
Current news on the MacWindows home page.
|
|
Parallels Desktop 4.0 for Mac Run Windows and Mac apps without rebooting! Now faster, improved Mac OS integration, speech recognition, more notbook battery life, and more.
"In the majority of overall averages of our tests, Parallels Desktop is the clear winner" --MacTech Magazine |
Reader seeks script to check Mac AD connection | Top of Page |
Alex Oumantsev is looking for a script that can check for a Mac connection to Active Directory, similar in function to one for Windows:
I am trying to come up with a script that would check to see if the Mac is connected to AD (i.e. users can authenticate off AD), and if the Mac is not connected, to connect it to AD using the hostname (with some formatting).
So far I found the dsconfigad command, that allows:
dsconfigad -show
However this seems to only show the local setup of the machine, not the real AD connectivity status. My test machine is an example. It was cloned from another machine that is connected to AD, and now it still thinks it is connected to AD, but it will not allow me to log in and authenticate off AD, rather it will only login from a local account.
Is there an equivalent of a Windows command netdom.exe verify "hostname" /d:"domain" which actually checks the connection validity?
If you know the answer
Reader success with article on AD setup for Mac OS X Server | Top of Page |
Charlie Galliher had success setting up Mac OS X Server using the article How to Use Active Directory and Macintosh Clients without Schema Changes:
It was pretty intuitive - I bound it to AD and then set up the server as an OD master, and I can populate my permissions with my AD account users & groups. I also wiped out the config and then rebuilt it - just to see how much trouble we'd be in if an update cracked the binding - seems pretty manageable.
Thanks for the FAQS - they are appreciated!
Leopard 10.5.7 startup problem with AD and Open Directory | Top of Page |
Andrew Ariotti reports having a problem we reported two years ago about Macs that won't start up when clients are configured to connect to both Microsoft Active Directory and Apple Open Directory. Ariotti is using Mac OS X 10.5.7, and found that our two-year-old solution worked.
Like Brad and Justin I am having this issue as well. I'm running the latest 10.5.7 version of Leopard. I've been tinkering with the AD and OpenDirectory authentication integration in OSX for the past few days and things have been working great until this morning. I came in and was greeted with my Mac Pro not wanting to boot. I did some investigation and found a Crash Report that was looping and never stopping no matter how long I waited. The crash report was for the Directory Services process and it was trying to run but then would crash. With the help of a co-worker we were able to find your site and use Brad's solution above and it worked like a charm. It'd be nice to know what causes this to happen.
If you've seen tried this approach
Problem with Active Directory and NFS
Surendra Perera of Sydney, Australia, reports that binding to Active Directory prevents NFS file sharing from working. She said that Thursby Software ADmitMac fixes the problem:
One of the problems I am facing with the Macs is that while using mobile accounts and bound to the Active Directory (Windows Server 2003 R2), via Apple's AD Plug-in, I am unable to browse/write to NFS mounts (Netapp Filer) with permissions 750 or 770 through Finder. In the terminal I am able to with no issue. I have tested this on 10.5.5, 10.5.6 and 10.5.7.
I have found that disabling mobile accounts allows me to access these directories with Finder without issue. We have quite a few Laptop users so Mobile accounts are very useful. I have tested Centrify and AdmitMac. AdmitMac seems to integrate nicely with our environment and fix the issue. I believe the issue to be that the AD plugin is not caching secondary/nested AD groups in a form that the Finder can see correctly. I know that Apple are rewriting the Finder for Snow Leopard, and will hopefully fix these issues, but for now I am looking for a solution that does not involve spending money if Snow Leopard is around the corner.
It is a fairly serious issue for us, and if its something that I am doing wrong then I am open to any suggestions.
Client configuration:
- Active Directory bind - Apple Active directory Plugin - Map LDAP attributes in AD plugin (uidNumber,gidNumber,gidNumber)
- Mobile accounts forced
- NFS mounts via fstab (soft mounts)
When I type in 'id' at the Terminal I seem to get the correct mappings for uid and all group memberships. AD is run off Windows 2003 server with Unix identity management tools installed.
If you've seen this issue
Dual-boot Mac and time drift, logon timing issues with Active Directory
Wednesday, October 21, 2009
Scott McKay's university runs Windows XP in Boot Camp 2.1 and has some problems with time drift in Active Directory and log on problems. He writes:
On our campus, we have a problem with Mac logins on Boot Camp dual-boot Macs running Windows XP in one partition and OS X 10.5.8 (Leopard) in another and authenticating to an Active Directory server from either. On the Mac side, from time to time, users cannot log in the first time, but can generally log in after three tries. Until recently, we could not predict on which computer the problem would manifest itself. The Active Directory server and the clients, Mac-side and Windows-side, are set to the same time-server to prevent any time drift.
Our current assumption is that when one uses Windows XP, the timekeeping method for that computer changes somehow. When one then logs into the Mac side, significant time drift has happened (despite our precautions), which prevents authentication to the Active Directory server. Logins are usually okay after three tries on such a computer. Our observations, while not rigorous, seem to support this assumption: Using a local login on a computer that has just run Windows, we can open OS X's Date & Time System Preference and (if we're watching for it) see the time jump from about when it was logged into Windows to the current time. Then other Mac logins on that computer work just fine.
What we can't figure out is what to do about it. Obviously, a failed login is a serious disincentive to using the computer, so we need to come up with a way to fix it. I have not found a way to force updating the clock when the login window loads, which would be the obvious fix.
If you've seen this problem
Current news on the MacWindows home page.
|
|
Parallels Desktop 4.0 for Mac Run all the applications you need without switching between Windows and Mac OS X! New features include: More 3D Graphics Support, 50% faster, improved Mac OS integration, speech recognition, more battery life on notebooks, and more. Enjoy the best of both worlds.
"In the majority of overall averages of our tests, Parallels Desktop is the clear winner"
--MacTech Magazine
|
|