Parallels Desktop
Parallels Desktop 7 for Mac Run Windows applications without switching between Windows and Mac OS X! Best integration of Mac and Windows. Windows apps now work with Lion feaures, including Mission Control, Launch Pad, Resume, and all trackpad gestures. Supports Windows 7 Aero, with peformance even faster than before. Now runs OS X Server in a virtual machine!

"Parallels Desktop 7 beat VMware Fusion 4.0.2 in 74.9% of the general tests we ran, and Parallels was double the speed or more in almost a quarter of the top-level tests."
--MacTech Magazine

Updated June 15, 2009

Deals from Amazon

Office 2011 for Mac
Now includes Outlook for Mac

Windows 7 GoToMeeting - Online Meetings Made Easy
Windows XP for your Mac, for running with Boot Camp, Parallels or VMware

MacDrive 8
Access your Mac OS X partition from
Boot Camp

The New Kindle
Smaller, lighter, faster
Only $139

Snow Leopard Tips and Reports

iPhone and Exchange Server Tips and Reports

Windows Servers and Macs

Windows on Mac

- Virtual PC 7.x
(PowerPC Macs

GoToMeeting - Online Meetings Made Easy

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:

A. Use Kerberos Utility to to "edit Realms"; or
B. Delete this file: /private/var/db/dslocal/nodes/Default/config/Kerberos:YOURDOMAIN.NET.plist

Carib Mendez verified the scond of these fixes:

In response to the two Kerberos tips, I use the latter. I delete the Kerberos:YOURDOMAIN.NET.plist file. I now bind the machine from the command line using dsconfigad. I recently tried the dsconfigad -passinterval 7 (instead of the default of 14) and have now been two weeks without any machines losing AD login ability (knock on wood).

Grant Warkentin used the first tip, then performed some additional steps.
He had to rename a file in a subdirectory of /private/, a file that the second February 19 tip recommended deleting. Warkentin's advice:

I had some binding problems myself OS X 10.5.6. I fixed it like this:

Step one: I did this procedure from your article:

  1. Go to Kerberos utility (/System/Library/CoreServices/
  2. Edit -> Edit Realms (or Command-E)
  3. Add your Kerberos realm by clicking the + sign. Don't forget it needs to be
  4. all caps (e.g. "FOO.COM").
  5. Under "servers" tab, add the address of the KDC (AD domain controller).
  6. Click Apply, OK, etc, it will ask for admin password.

Note: indicated I did have a valid ticket before starting.

Step two:

  1. I removed current Mac binding.
  2. I removed computer account in AD users & computers
  3. I created new computer account in AD U & C
  4. I re-bound the Mac to the domain.

Note: re-binding did ask to rename the old /private/var/db/dslocal/nodes/Default/config/Kerberos:YOURDOMAIN.NET.plist file.

I answered Yes to rename it. Successfully rebound to AD. I also had to remove a DNS server entry on the Mac -- this entry was not pointing to the AD server.

Sam Warren reported that the first tip (Kerberos Utility) did not work, but the second (deleting the file) did:

I have had a few machines (10.5.x) lose the ability to login using domain authentication. Stage 1 - they lose the ability to login while on the network, but if you disconnect the network, the cached credentials work. Stage 2 _Eventually only local accounts work.

I have never seen this happen with 10.3 or 10.4 machines. I had a machine go to Stage 1 after it had been in service for less than 2 weeks.

What DID NOT work for me was to Reset account in AD. This allowed me to login with the network connected, but lost ability for new accounts (because it was no longer bound to AD.) Attempting to rebind gave invalid user password combination message.

So I tried the first suggestion in your article, but it didn't work. To quote:

  1. Go to Kerberos utility (/System/Library/CoreServices/
  2. Edit -> Edit Realms (or Command-E)
  3. Add your Kerberos realm by clicking the + sign. Don't forget it needs to be
  4. all caps (e.g. "FOO.COM").
  5. Under "servers" tab, add the address of the KDC (AD domain controller).
  6. Click Apply, OK, etc, it will ask for admin password.

I could now get a Kerberos ticket, but each time I tried to rebind, I got the dreaded invalid user _ password combination message.

What DID work was the second tip in your article. The following command let me rebind my users desktop to AD:

sudo rm


Peter Kloss received an explanation and some advice from Apple to manually remove and regenerate the persistent Kerberos certificate that Leopard uses:

We had similar problems where Macs would appear to 'drop out' of AD and then no matter what was tried, they could not be put back in, bid failed everytime with a password error to the domain to which they were originally bound - however, they would bind to a new domain they had never been in!

Then one of our staff went to an Apple Integration seminar at Cambridge (UK) where the little known fact emerged that Leopard has a persistent Kerberos certificate which can cause problems with just such things as binding to AD. This is a particular problem if using an image to build multiple machines which are then bound to AD - it is the equivalent of having identical machine accounts on windows. It seems though that this can also cause problems if a machine account goes out of sync, in some circumstances it can block an unbind / rebind to AD.

Below is a copy of a mail I sent to our Mac support staff with a link to the Apple KB detailing the problem and the "solution:"

Dear Colleagues:

Mark Thompson told me about an issue with Mac OS X imaging where the Kerberos certificate, which equates to the machine account in windows, is preserved during the imaging process. This can give rise to problems when joining imaged Leopard systems to Active Directory or Open Directory, as would happen under Windows if you try to join multiple systems with identical machine accounts to AD. This could also be the cause of a problem seen at <site-removed> where one system "forgot" its AD connection, then could not be rejoined as "something" was carried forward from the broken state.

This behaviour is now "fixed" in the 10.5.6 version of the Apple System Imaging Utility. However, if you are using some other method for imaging (such as CCC) you may need to remove and regenerate the Kerberos certificate manually. Also, if having problems joining a system to AD, you may need to run through this process to clear the existing Kerberos certificate before re-running the joining process.

This is documented in Apple Knowledge Base TS1245.

Having read through this article it seems to me that it would be an extremely good idea to delete the Kerberos Certificate on a master image before using it.

Update, Monday, March 2, 2009: Peter Kloss updated his previous report on manually removing and regenerating the persistent Kerberos certificate. This was in order to fix a problem where Macs appear to drop out of Active Directory and can not be put back in. Kloss said:

It seems that has been revised to remove the advice on how to manually remove the Kerberos certificate - in fact it specifically now advises against manual reconfiguration!

My colleague Mark, who was struck by this problem, says that the manual removal / regeneration of the Kerberos certificate didn't work, and that he had to do an archive and install re-install of Leopard to fix it (which negates imaging in the first place).

Chris Ross at Macprofessionals independently sent in the suggestion of deleting the file in a subdirectory of /var/, except he used the Finder instead of Terminal. He has an additional suggestion:

Regarding "Leopard losing AD login may be related to forced unbind; problem unbinding," this is a Kerberos corruption issue and is related to a force unbind. It can be resolved by going to:


You are looking for a file called

Delete this file and you should be able to rebind.

Regarding your article More readers lose AD login after OS X 10.5.6 update. I have seen many problems like this and a majority of the time is a password policy on the Active Directory server. The policy says after so many days the AD server contacts the client and changes the computer account password. For whatever reason (I have seen different reasons) the AD server and the OSX clients don't handle this exchange well. It results with the client still bound but logins not allowed until the machine is rebound and the computer account password is updated.

Sometimes the fix is to use the hidden option in dsconfigad " -passinterval" to force the mac to update the password before the AD server tries.

For example: "sudo dsconfigad -passinterval 10"

This will force the client to change its computer account password every 10 days.

Matthew Fecteau updated his previous report from February 11 (Unbinding/rebinding workaround):

We have figured out our issue regarding authenticating on the Mac OS 10.5.X and OS 10.4.X systems. Here is what we did:

One of our technicians found a fix a couple days ago that is working. Within the Directory Utility we had to modify a few Administrative settings. Under the "Advanced Options" and on the "Administrative" tab we had to make a few changes. We had to uncheck the box that says "Allow authentication from any domain in the forest" and check the one that says "Prefer this domain server". We then entered our domain server (the same one that we bind to) in the box next to this check mark and unbound/rebound and it worked.

After communicating this to some of the network admins they then recalled that just a few weeks ago they had copied the AD usernames over to a test Domain. So, some of the Macs were trying to authenticate against the test domain. This explains why it was working for some users and not for others. Some users must have been hitting the test domain while others were authenticating against the production domain as normal.

That still does not explain why a Mac that is bound to the a certain domain would not at least try first to authenticate against the same domain first and then look in other available domains as a fallback.

If you've tried these workarounds

Leopards losing AD binding: another take on the Kerberos file

Monday, March 9, 2009

Bob Eicher has the previously reported problem Leopard Macs losing Active Directory binding. He tried one of the Kerberos-based tips we've posted, but changed a setting to make it click:

We are still mostly on Tiger (10.4.11) here, but we have a few machines running Leopard (10.5.6). We had one with login issues and I found that it was no longer bound to AD. I had to force the unbind and couldn't get it to bind again. I removed the "/private/var/db/dslocal/nodes/Default/config/Kerberos:YOURDOMAIN.NET.plist" file and was able to get it to bind again, but the logins took three or four minutes. I then unbound it again and unchecked "Allow authentication from any domain in the forest" and rebound it and it seems to be working fine now. I guess we'll see for how long...

If you've tried this approach

Back to the February 19 TIP: Two kerberos-related workarounds for Macs losing Active Directory binding.

(Back to Active Directory and Leopard Tips and Reports and previous workarounds.)

Reader verifies kerberos file fix for Mac AD binding problem

Monday, June 15, 2009

Tommy Birchett verified that removing a kerberos config file solves a problem with Macs losing binding to Active Directory: "We are seeing this problem pop up more frequently now. Deleting the Kerberos file works."

Toast 9 Titanium -- Download Now

Other MacWindows Departments

| Top of Page |

This site created and maintained by

Copyright 2009 John Rizzo. All rights reserved.