The Cat Convention

One common discussion here at the day job can be summed up with a single statement:

“Why do my Macs keep falling off the Active Directory domain?”

I have a Mac Pro here at the day job that is bound to Active Directory. It’s a really large Active Directory with multiple sites and subnets. As a result, there are different domain controllers in those multiple Active Directory sites. Hey, it’s Active Directory, so the more machines the merrier, right?

After a few days of using the Mac Pro, I would often notice that logins from screen savers or from loginWindow would take longer than they should. That was usually a symptom of what every Mac user fears…

…you’ve fallen off the domain again.

There can be multiple reasons for falling off the domain. There’s a lot of data out there about how Macs do not like to renew their machine account passwords. Sometimes it has something to do with kerberos. Sometimes it has something to do with the moon.

In my case, I notice that when it happens to this Mac Pro:

• Logins take forever at the screensaver (already noted)
• Logins at loginWindow take forever (already noted)
• Kerberos tickets are not granted or renewed (error about unable to reach a kdc for the requested realm)
• winbindd keeps throttling and restarting every minute (note this in the console log)
  • 1/21/11 11:49:58 AM com.apple.launchd[1] (org.samba.winbindd) Throttling respawn: Will start in 10 seconds
    1/21/11 11:50:08 AM com.apple.launchd[1] (org.samba.winbindd[1006]) Exited with exit code: 1

    1/21/11 11:49:58 AM com.apple.launchd[1] (org.samba.winbindd) Throttling respawn: Will start in 10 seconds1/21/11 11:50:08 AM com.apple.launchd[1] (org.samba.winbindd[1006]) Exited with exit code: 1

• other random failures that require AD lookups

In the past I had a ritual. The ritual involves a force unbind and rebind of the machine to the directory. This would work for a while but it was only a matter of hours or days before it happened again. Finally I went to an extreme and reformatted the machine in hope that it would shake something loose.

Within 48 hours it happened again.

I often have to use a VPN to connect this Mac to a different network to perform some administration. In the Active Directory world this means I connect to a whole new set of domain controllers that are located in another Active Directory site. These AD sites are usually carved out by subnet and firewalled. Therefore if you connect to another AD site and cannot communicate with your old domain controllers for some reason you might drop off the domain.

I noticed that when I was connected to the VPN, DirectoryService seemed to work okie. The winbindd restarts stopped and the domain would start reporting correctly. I disconnected the VPN and watched the console log. There was a log about the network change notification, which was expected… then DirectoryService appeared to try to communicate with the Active Directory. It seemed to work, but if you look in the Directory application you’d discover that it’s fallen off the domain once again.

Connect up to the VPN – see the network change event… voila, everything works again.

Aha. So the Mac wasn’t detecting the change in Active Directory site properly. Interesting.

I conferred with another fellow here that works on the standard load for Macintosh systems in the environment. He mentioned that I should take a look and see what was written in the file:

/Library/Preferences/DirectoryService/ActiveDirectoryDynamicData.plist

…under the node “AD Domain Node List.”

We took a look and discovered that the domain controllers for the site on the VPN network were listed there. When I disconnected from the VPN, the file was not rewritten to include the domain controllers for the regular network as it should. Therefore, when the Mac tried to communicate with the domain controllers it was looking in this file and trying to connect to the domain controllers on the VPN AD site. That’s the wrong answer.

The theory? Well, it would appear that during some network change events the ActiveDirectoryDynamicData.plist file is regenerated properly with the domain controllers for the new AD site. However something is making it stick. After disconnecting from the VPN or returning to the home network this file is not regenerated properly.

To resolve, I did the following… after returning to the home network or disconnecting from the VPN and experiencing a failure with communication to Active Directory, you need to tell DirectoryService to regenerate the file:

cd /Library/Preferences/DirectoryService
sudo mv ActiveDirectoryDynamicData.plist ActiveDirectoryDynamicData.plist.old
sudo killall DirectoryService

Note that you’ll have to be an administrator of the machine and use your password for the first sudo command. But you knew that, right?

After a few seconds you should see DirectoryService try to talk to the domain and update the machine password in the console log. Not long after that you should see a new ActiveDirectoryDynamicData.plist file. Chances are good this new “AD Domain Node List” will contain domain controllers for the site/subnet in which you’re now located.

If you’re crafty and have this problem often, you might want to script up something that will automatically shove this file aside and restart DirectoryService on a network change event. It appears that DirectoryService does not always rebuild this file on a network change event by itself.

I hope this helps someone out there. Leave a comment if you have other tips for keeping a Mac alive on an Active Directory network.

Related articles

• Mac IT Guy: Macs and Active Directory (pcworld.com)
• What is a Domain Controller? (brighthub.com)
• Integrating Mac into Active Directory (edugeek.net)

Social Links

Greetings fellow implementers and users…

I know many of you out there have implemented Apple products like iCal, iPhones and iPads within Exchange 2007 and 2010 organizations. I’m seeking information on a very specific problem that rears its ugly head on occasion.

Have any of you witnessed a “meeting hijack” problem with your device? Namely, you are an attendee on a meeting and suddenly you find yourself the organizer. Usually you find this out when you send a decline for whatever reason.

I’m trying to reproduce this issue in a lab environment to document the problem but we’re having a hell of a time pulling the data together. If any of you have data to share, please do so in the comments. Thanks!

Social Links

Let’s get the facts out of the way first. If you’ve not heard this, sit down. Apparently it’s earth-shattering news to Mac users.

Ready?

Apple is going to stop packaging Java and Flash with OS X.

I’ve got more for you.

If they’re going to stop packaging it, that probably means they won’t be delivering updates to those packages to Mac users automatically.

Now I’ll let that sink in. Like I said, apparently, that’s enough to drive Mac users to a coronary. Are you back from the hospital yet? Good. Let’s talk.

Coming from a world of Windows and occasional bouts with Linux, I’ve grown accustomed to installing applications and plugins that I need on my workstations. It’s something of a ritual. When I converted back to Mac in 2006 I was pleasantly surprised to see that Apple delivered Java and Flash as part of the operating system.

Over the past year or so I started to become a little troubled by this. Apple’s updates to Java and Flash seemed very opaque. They provided little information on their site about the updates and the security vulnerabilities covered in the latest bits. Of course I could go look at the Java and Flash vendors’ websites for this information but let’s play the part of mom & pop user here for a moment. If Apple is delivering these updates, I would expect mom & pop to consider Apple responsible for those updates.

…and Apple has been consistently slow to deliver.

Now it seems that reality has caught up with them. The rapid pace of security vulnerabilities and exploits has probably kept them mighty busy. I’m sure they found themselves asking more than once… why are we putting ourselves through this? Better yet, Apple was taking regular criticism from security analysts over it. Sometimes it was because of the opacity of the information Apple provides (which, let’s be real here… none of us like that at all) and sometimes it was due to an unusually long cycle of updates to get these things out the door.

I would imagine there’s a lot of hysteria around this because of Oracle’s manhandling of Sun’s projects post-acquisition and the war of words over Flash. I can handle a conspiracy theory.

But really, folks. I don’t think there’s a lot to read into this. Apple is actually trying to help users stay more secure by sending them directly to the vendor. They’re not banning the technology from the platform (especially Java – boy howdy you people are truly nuts if you think they’re banning Java). They’re merely making Mac users go obtain their own copies of the software if they need it. What’s the problem with that? Everybody else does it.

P.S. Yeah, I know most Linux distributions ship with a version of Java installed. However, most of the time those are hacks of Java that are licensed separately. If you want the “official Java” you have to get it yourself.

Social Links

AFP548.com has posted part 2 of their interesting guide on implementing z-push on Snow Leopard Server to fool your ActiveSync devices into thinking they’re communicating with an Exchange Server.  I want to try this very badly, but limited resources prevent that at the current time.

If you’ve gotten this working and can speak about the experience, we’d love to hear from you!

Social Links

The MobileMe Control Panel has been updated to v1.6.1 and provides support to Outlook when connecting to the new MobileMe CalDAV service. The CalDAV service is currently in beta. To get it operational, you must login to me.com and click on the Calendar, then request an invitation.

Social Links

AFP548.com has posted a very intriguing article on setting up the open source product z-push to implement Exchange ActiveSync on your Snow Leopard server.  This provides Exchange-style push mail for your iPhone after you trick the device into thinking it’s an Exchange server.

Part 2 of the article even claims that they will provide info on how to perform remote device wipe.

I’ve not personally tried these steps yet, but perhaps I shall one day soon.  Proceed with caution and if you get this working, I’d love to hear about it in the comments.

Now this enterprise stuff is getting very, very interesting…

Social Links