Fix for slow AD logins/joins caused by macAddress query

I’ve been hassling Apple about this issue for quite a while.

Apple has two workarounds for this problem:

1.) Index the macAddress attribute in AD. Even though the macAddress is not part of the Computer class by default, the AD plugin queries on it for joins ( to ensure the the computer that you are adding doesn’t already exist ), and for MCX ( managed client information ). Normally I would frown on any changes to AD since the Enterprise doesn’t like making changes to their infrastructure just to support Macs. However, supposedly in Windows 2008 Server, the macAddress attribute is indexed by default, so at least their is some justification there.

2.) If you’d prefer to make changes on your client machines rather than bother your AD administrators with a Mac-specific fix, remove the ENetAddress mapping from /Library/Preferences/ActiveDirectory.plist. The lines to remove look like this:


The key is the OID for the macAddress attribute in AD.
The string value is the mapping to a native Open Directory attribute, which Apple calls ENetAddress.

You’ll also need to remove /Library/Preferences/DirectoryService/ActiveDirectoryDynamicData.plist as this file also contains the cached mappings.

Then killall -9 DirectoryService or reboot the machine.


Notes on Leopard AD Plugin 10.5.2

The Active Directory plugin is finally usable in 10.5.2, but some environments require workarounds.

1.) 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 as they closed my bug stating that it was a configuration issue with Active Directory since creation of a domain sets up this dns info by default. If your domain does not resolve to an ip, you need to fix it, or as a workaround, edit your /etc/hosts file to point the ip of one of your domain controllers.

for example if you know you have a domain controller at and your fully qualified domain is, you’d add this line to /etc/hosts

2.) Allow Authentication from any domain in forest does not work. Uncheck this box in Directory Utility or using the corresponding flag in dsconfigad. If you don’t do this, the join may succeed, but you won’t be able to lookup or authenticate users or even use dscl on Active Directory. When you uncheck this option, just be sure to add the correct domains to your authentication search path in Search Policy of Directory Utiltity.

3.) Allow Administration by Active Directory Groups does not seem to work. In 10.4, this option seems to nest the AD group you want to allow for administration into the local admin group, so the workaround is to do the same in 10.5 manually using dseditgroup.

sudo dseditgroup -o edit -a “DOMAIN\group name” -t group admin

replacing DOMAIN\group name with your domain and group that you want to give admin access.

This group nesting method gives members of your AD group admin access for both Apple’s Authorization APIs and sudo.

These workarounds got me working, logins are painfully slow, but that may be due to the hosts hack.

Update: Under 10.5.3, most of these problems are resolved. If you are still having slow logins/joins, there are possible workarounds.

Installing Leopard on Unsupported Hardware

I installed Leopard on two older machines that are not officially supported by Apple.

In both cases I resorted to installing from a supported machine with the machine in target disk mode or asr restoring to the drive in the unsupported machine. There may be other ways of getting it installed. I looked at the javascripts that check system requirements in the .mpkg in /System/Installation/Packages of the installer DVD using It is possible that one could edit the OSInstall.mpkg javascripts and build a new installer DVD, but for me it was easier to install from a supported machine.


PowerMac G4 533Mhz 354MB RAM: This machine works okay with 10.5. It is somewhat slow with graphics and the low memory causes it to hit the disk a lot. The most serious issue is waking from sleep, which results in a kernel panic. I tried adding more RAM, removing SCSI card, disconnecting an older drive, but the kernel panics continued. I’ve set energy saver to never put the machine to sleep for now.

iMac G4 1Ghz 256MB RAM: This machine only has half of the required 512MB RAM for 10.5. It seems to run fine, but swaps to disk a lot.

When spotlight first indexes the drive on first boot, the machines crawl because the disk is so busy with swapping and indexing, but once that is finished, the machines are usable.

Attempting to Boot from ZFS…

I spent some time attempting to get Leopard booting from a ZFS volume. I used Apple’s method of Boot!=Root. Boot!=Root basically allows you to boot from ‘exotic’ filesysytems by using a helper partition that is not ‘exotic’ (HFS+) and contains enough information to mount your exotic volume and root off of it. The information includes a kernel, kernel extensions caches, and a plist specifying the UUID of the volume you want to root off of. The machine actually boots from the helper partition, loads the kernel and kernel extensions from cache, waits for the volume with the specified UUID to show up, then switches over to root off of that. Apple has been doing this for some time with helper partitions that allow booting from Apple RAID volumes.

So I created a RAID volume, made it bootable, mounted its helper Apple Boot partition, asr restored the helper partition to another partition to use as a base for my ZFS helper partition. I edited the Boot.plist to point to my ZFS volume UUID. I blessed the helper partition and rebooted in verbose mode. I got an error from the AppleFileSystem kext and got the dreaded “Waiting for root device…” message. Damn.

Apparently the problem is that Apple marks certain filesystem types as allowed to boot from. These seem to be held in the Info.plist of the AppleFileSystem kernel extension. I was going to attempt editing the plist to include ZFS, but when I saw that the kernel extension appeared to be signed, I gave up assuming that I would invalidate the kext by modifying the plist. I downloaded the kext from the darwin site, but it had all sorts of dependencies.

Why would I think it would be that easy?

That is where I left it. A few hours lost. Not a lot gained. Maybe I’ll try again…

Leopard’s bless command references to ZFS?

The bless command in Leopard contains references to ZFS.

kserver:~ pbuffr$ strings /usr/sbin/bless | grep -i zfs
No ZFS container partitions found
ZFS container partition found: %s

Since bless is the command that sets the boot variables in nvram to set your a startup volume, it seems likely that Apple is at least working on boot support for ZFS, if it isn’t already there, but hidden away.  Interesting.