Multiple MAC addresses (Ethernet IDs)

Only the built-in Ethernet address is used for computer identification, regardless of the interface that's actually used to connect.

--Gerrit

If Im not mistaken, the Ethernet ID (MAC address) in the context of OD/MCX is not used for networking or payload at all, its just a reliable unique identifier to use that is specific to each computer object and computer record. It doesn't matter if that interface is active or not as long as it can be referenced by the OD client for purposes of identification. If the desktop Mac has 2 NICs, use the MAC from the "en0" NIC (Ethernet port #1 of 2). Likewise for Airport. USe the MAC from the Ethernet NIC for ID purposes, not the Airport MAC address, regardless if you connect via wi-fi or not.

Yes, I know it seems counter-intuitive, but this is the way it works: the Ethernet ID of the first built-in Ethernet port is used as a unique identifier, just as Daniel has said.

--Gerrit

I am guessing what happens is that when an OD client computer detects an active network connection (on any of its network interfaces), it attempts to communicate with the OD server. In this initial communication with the OD server it sends the MAC address of en0 to the OD server. The OD server looks at this MAC address and searches for a computer entry with a matching MAC address. If the MAC address is found the OD server responds back to the client computer with whatever managed settings are configured for the computer.

Well, maybe this will clear things up:

First off, the dsAttrTypeStandard:ENetAddress attribute is used for +more than just MCX+, so the server's setup assistant populates that that value for the server's computer record automatically.

But here's how the client/server communicate using the first built-in Ethernet address:

+... the Directory Server needs to be able to identify that machine...+

You're assuming that the client connects and the directory server then just pushes the information that the client needs. That's not what happens, though. Instead:

The client can read the entire directory after it has been connected to the directory server via Directory Utility. If you bind, a computer account is created and the client connects to the directory using that account; otherwise (without binding), your OD server's directory is read-only for any connection to it.

At login time, the managed client application maintains an updated MCX cache in the client's local directory at /Local/Default/Config/mcx_cache (/NetInfo/DefaultLocalNode/Config/mcx_cache for 10.4). It is able to update this cache by consulting the Computer and Computer group (list) records of all directory domains in its authentication search path (as set in Directory Utility). The client looks for a computer record with dsAttrTypeStandard:ENetAddress that matches its own first Ethernet port, and reads the MCXFlags and MCXSettings attributes from that record. In this way, the client simply compares the value of dsAttrTypeStandard:ENetAddress to the value of its first Ethernet port, regardless of the network interface used to connect. Thus, it's just an identifier.

In fact, you can prove this to yourself in the following ways:

1. Don't bind a computer to the directory, or bind it and then deliberately change the value of its ENetAddress attribute in its computer record to something that's wrong (like 00:00:00:00:00:00). Now, back on the client, use dscl from the command line to navigate into the authentication search path and read any computer record there. (See *man dscl* for more on how to use the tool.)

2. Apply managed client settings to the "all other computers" computer account, which is a guest computer account. In the absence of a computer account with matching ENetAddress, the client reads from this guest account, which has no value for its ENetAddress attribute.

--Gerrit