OK, you're on the right path. Since Managed Preferences are combined/overridden/inherited in the following order, management at the computer group level would be best:
MCX attributes in user account > attributes in computer account > attributes in computer group > attributes in user group
Regardless of the account into which the Managed Preferences are stored, the MCX system requires three attributes in order to work properly:
1. A unique identifier (
dsAttrTypeStandard:ENetAddress): the Ethernet address of the first built-in Ethernet port.
2.
dsAttrTypeStandard:MCXFlags: An XML property list that tells the MCX client to expect managed data. This attribute also contains some options for client behavior.
3.
dsAttrTypeStandard:MCXSettings: Typically, a multi-valued UTF-8 attribute containing the managed preference information in special XML property list form.
In the case of computer and computer group (computer list) accounts, the following is true:
1. All computer accounts must have an attribute for
ENetAddress, regardless of whether MCX data is stored in the individual computer account or the computer group account.
2. In the case of Managed Preferences being stored in a computer account: the
MCXFlags and
MCXSettings should be attributes of that account.
3. In the case of Managed Preferences being stored in a computer group account: the
MCXFlags and
MCXSettings are kept in the computer group account; however, certain computer-specific MCX behavior settings may appear in a separate
MCXFlags attribute in the computer account. (Computer accounts are made members of the computer group by addition to the
dsAttrTypeStandard:Computers attribute within the computer group account.)
Your observations:
+[computer accounts in AD] do not have a proper MAC address entry+
That's exactly why the MCXSettings for the group won't apply. In order to overcome this, I would suggest one of the following workarounds:
1. + I have noticed that 10.5 server sees computers listed in AD now+ Based on this, I'm assuming that your Open Directory Master is also a member of the Active Directory domain. Strictly speaking, this does not have to be true if your sole use of the Open Directory Master is for Managed Preferences.
In other words, you +don't have to bind+ your OD Master to AD at all. This would, of course, is a little unusual, and would entail the following restrictions:
a. You would have to create computer accounts (records) for your computers on the OD Master manually. At this point, you could also create a computer group account and then manage preferences at the computer group level.
Alternatively, you could create a
guest computer account. Workgroup Manager calls this "all other computers," and any MCX settings that are defined for it would apply to any computer otherwise lacking a computer account and bound to the OD Master.
b. On the client side, ensure that each is bound to both AD and OD, and that OD is first in each client's authentication search path.
2. +which is actually great because I wont have to add them to OD manually+ OK, now for something much cooler. You
can use existing AD computer accounts, add them to an OD computer group account, and manage the preferences at that level. This doesn't immediately work, but it can be done:
a. This option is more standard; your OD Master needs to be bound to AD, and your clients need to be bound to both as well.
b. Next you need to pick three attributes in all of your AD computer accounts that you're *not using*. Each should accept a UTF-8 string, and one needs to accept multi-valued UTF-8 strings. See where we're going? 🙂 We're going to map three AD attributes to the required three OD attributes for MCX. The three I'll use for this example are:
displayName with ID 1.2.840.113556.1.2.13 (
http://msdn2.microsoft.com/en-us/library/ms675514.aspx)
desktopProfile with ID 1.2.840.113556.1.4.346 (
http://msdn2.microsoft.com/en-us/library/ms675493.aspx)
altSecurityIdentities with attribute ID 1.2.840.113556.1.4.867 (
http://msdn2.microsoft.com/en-us/library/ms675221.aspx)
All three accept a UTF-8 string, so we don't have to worry about differences in Mac/Windows Roman encodings; also, the last attribute accepts multi-valued strings. We're going to map these attributes to Open Directory attributes in this way:
displayName will hold data for
dsAttrTypeStandard:ENetAddress
desktopProfile will hold data for
MCXFlags
altSecurityIdentities
can hold strings for
MCXSettings (not required; more on this later on)
c. We have to make some adjustments to the
ActiveDirectory.plist file in /Library/Preferences/DirectoryService on your server and clients. These adjustments will "tell" Open Directory about the attribute repurposing.
On the server, log in as root so that you can edit the ActiveDirectory.plist file with the GUI-based Property List Editor. (You can also copy and edit, then replace if you don't want to log in as root.)
Open ActiveDirectory.plist in Property List Editor, and navigate through the following dictionaries: expand the
root dictionary, then the *AD Attribute Mapping Table* dictionary, then the dictionary for
dsRecTypeStandard:Computers. In this dictionary, make the following changes:
c1. Locate the key named
1.3.6.1.1.1.1.22 with string value of "dsAttrTypeStandard:ENetAddress." Change the key name (not the string value) to
1.2.840.113556.1.2.13, which is the attribute ID for displayName.
c2. Similarly, locate the key named
1.3.6.1.4.1.63.1000.1.1.1.1.10 (string value is
MCXFlags), and change the key name to
1.2.840.113556.1.4.346, the ID for desktopProfile.
c3. Lastly, locate the key named
1.3.6.1.4.1.63.1000.1.1.1.1.16 (value is
MCXSettings), and change the key name to
1.2.840.113556.1.4.867, the ID for altSecurityIdentities.
Save changes and restart the server.
To make these adjustments on the client side, simply edit the ActiveDirectory.plist file of an un-bound Mac (just check Active Directory in Directory Utility to create a clean ActiveDirectory.plist file), distribute them, then bind to AD.
d. Now the server and clients will "know" where to find the ENetAddress, MCXFlags, and MCXSettings in the AD computer records (accounts); however, you may still have to populate the ENetAddress attribute manually:
You can edit the newly-visible ENetAddress attribute for the AD computer account using Workgroup Manager's Inspector section while authenticated to the AD domain as a domain admin - this option may or may not work, depending on your setup; or...
You can populate the displayName attribute for each computer record using the AdsiEdit.msc console snap-in on a Windows box.
e. Once the AD computer records have populated values for ENetAddress (displayName), you can add those accounts to a computer group in OD, and manage the preferences from there.
Strictly speaking, the MCXSettings attribute in the computer account in AD won't be used in this scenario, but I'm mapping it anyway, just for good form. Also note that you could store complete MCX information without an OD Master in this way.
Let me know if you need any more help with this second method. Hope it helps.
--Gerrit
