3839 Views 9 Replies Latest reply: Dec 6, 2007 10:24 AM by Daniel Stranathan
I have a similar setup too. My Macs are being upgraded to Leopard. My Mac servers are running Leopard already. All my Macs are bound to AD 2003 and will soon be in OD too (for the purpose of managing policies on the Macs via MCX)
I would like to know how you are "seeing" Mac computer objects in AD via WGM and not adding them manually in OD? It seems to me that the process of binding a Mac to OD and the associated back end Administrator work required in WGM (i.e.; adding the Mac by MAC address etc) is tedious and clunky and prone to human error. There has to be a better way in the "Magic Triangle".
Can you go into detail how you are adding computers from AD into OD please? Is this documented in Apples admin guides? I dont see it in the 10.5 server guides. I assume you are simply dragging the AD computer objects over from the pop out tray in WGM (assumed you are authenticated in both OD and AD domains etc)? If so, then please answer this: If you can add Mac computers into OD from AD, then does that also mean that you do NOT have to mess with manually adding the Mac's MAC (Ethernet ID) address into WGM too? I would LOVE to avoid having to keep track of all my Macs MAC addresses. This is a difficult task.
Looks like you and I have similar questions regarding the step of adding a MAC address to each computer object in OD.
BTW: I have noticed the same thing you are seeing regarding not being able to add a computer in OD if the name already exists in AD (at first I thought it as a bug or a DNS thing!). To keep things simple, I make the Macs host name (i.e.; computer name) and its AD computer object name the exact same name for consistency) Being forced to make the OD computer name the same is a GOOD THING in my opinion. I would hate to try and manage 200 Macs and have 3 different names for each Mac to keep track of (and an MAC address too - yikes)
Message was edited by: Daniel Stranathan
If you are using the 10.5 Server tools, and are in WGM, click on the computers tab on the left to view the list, then in the "viewing" popup directly above select the AD domain you should be presented with a list of machines bound to AD.
As you said, Im simply creating a computer group and dragging the computer objects from AD into that OD computer group. The mac sharing and host names are matched to the AD bind names on our machines also, but basically Im also asking about the MAC address issue too, because AD computer objects do not have the MAC address and instead pass the GeneratedUID to OD in computer groups. When I saw the new AD computer object listing I was overjoyed also about not having to add the Macs individually, but being able to push policy to them like we do with actual user accounts.
Also we're still in the testing phase of implementing 10.5 Client because of some severe issues with Apple's current AD plugin (many Mac OS X 10.5 machines are not able to bind to the AD realm (see http://discussions.apple.com/thread.jspa?threadID=1210802) so I would make sure you've thoroughly tested AD binding with a decent group of machines before pushing out 10.5 to make sure you dont run into similar issues.
You mentioned binding a mac to OD, Im not sure if you mean adding it to OD manually or actually binding it via the Directory Utility. If you are using AD you do not want to actually bind the macs to OD, just add the OD reference. Binding apparently causes a kerberos conflict between the two and can result in users being unable to authenticate to AD or gain Managed Preference settings (struggled with that here at first), THOUGH I've not tested this in 10.5... and things may have changed since OD is smart enough to disable kerberos internally if you already have the server bound to AD when you create the OD master.
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.)
+[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.1135220.127.116.11 (http://msdn2.microsoft.com/en-us/library/ms675514.aspx)
desktopProfile with ID 1.2.840.113518.104.22.1686 (http://msdn2.microsoft.com/en-us/library/ms675493.aspx)
altSecurityIdentities with attribute ID 1.2.840.113522.214.171.1247 (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 126.96.36.199.188.8.131.52 with string value of "dsAttrTypeStandard:ENetAddress." Change the key name (not the string value) to 1.2.840.1135184.108.40.206, which is the attribute ID for displayName.
c2. Similarly, locate the key named 220.127.116.11.18.104.22.1680.1.1.1.1.10 (string value is MCXFlags), and change the key name to 1.2.840.113522.214.171.1246, the ID for desktopProfile.
c3. Lastly, locate the key named 126.96.36.199.188.8.131.520.1.1.1.1.16 (value is MCXSettings), and change the key name to 1.2.840.1135184.108.40.2067, 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.
Ahh sounds like this could get messy. So there's no way to get machines to auto populate the custom fields in the second solution? The first wouldn't really work for us as we make use of SSO between the services offered on the Xserves and AD. Going to be rough to configure this for 600+ machines but it should be something not too difficult to set up on the new 10.5 deployment image after Apple's worked the AD binding bugs out.
Excellent info Gerrit. Thanks for the details.
Here’s a OD MCX question for ya:
I thought it would be a good idea to make the Mac computer (host) name, the AD computer record name and the OD computer record name all the same name for simplicity and my sanity. Our computer names are based on the last 7 characters of the serial number and a “M” or “W” is appended to the beginning to flag it as a Mac or Windows PC. A “P” is appended to the beginning if its a portable, too.
m00ac67f62 = Mac desktop
mp0ac52d77 = Mac laptop
w0a0b61ef2 = Windows desktop
So, I have decided to use the exact same name convention when binding to AD. That way I can quickly look in my AD tools, ARD, and DNS for any given Mac on my LAN and be confident that I know exactly what Im looking at. Now that we are planning on doing the AD/OD “Magic Triangle”, I decided that If I have to create yet another computer record in OD for the Macs, I might as well use the same name again to keep them all straight. Right? Do you think that’s a good idea? Of course it wont work because OD sees a conflict with names (see below)
Here’s the gotchas I have found in Leopard:
I have found Leopard server to be fairly vague when it comes to OD and MCX. Lots of people claim that you no longer have to create a new computer record in WGM/OD from scratch - you can use the existing computer records in AD (assuming your Macs are in AD of course). While this sounds pretty cool, I cant seem to figure out how to push MCX policies to those Macs when using the AD record. OD cant write to AD as discussed in the posts above. This has been established. On the other hand, when I try and create a Mac computer record in OD from scratch, OD complains that the record already exists (in AD) - which it does (assuming I uses the same unique ID described above in my example).
My biggest problem lies in trying to give WGM the Macs MAC (Ethernet ID). AD doesn’t store this info, so you have to manually add the MAC address in OD. But if the record is in AD you can add the MAC address because you cant write to AD (as mentioned by Gerrit), and if you try and create the entire record from scratch (including the name and MAC address, then I get a conflict in record names since the computer name already exists in AD). I just want a way to managed the Macs in a simple way and keep track of as few names as possible to avoid confusion and cluttering up AD, OD, etc...
Based on the info above, I think that I will have to have 2 names for each Mac desktop (Grrrr) . 1 name can be used for the host (computer name) - for DNS, ARD ,etc, and the same name can also be used in AD for the computer record, but for OD I have to come up with a whole new unique ID for the computer record so that it doesn’t conflict with the existing AD computer record name. DO you think I should just take the existing Mac computer name and append characters to them in OD like this for example:
mcxm00ac67f62 = Mac desktop
mcxmp0ac52d77 = Mac laptop
I added the characters "mcx" to the beginning to keep the original AD and DNS host name, but added "mcx" for the sake of keeping the computer records in OD unique but still readable by humans when needed.
Any comments or suggestion on naming conventions?
WHy the heck do we need a MAC address info anyway, isn't there a better, more intuiative way for OD clients to bind to an OD server and automatically assign a unique ID? (similar to how AD binding works)
Message was edited by: Daniel Stranathan
Regarding MAC addresses in WGM (OD)
Does the MAC (Ethernet) address of the OD Mac client computer have to literally be the active network port? I have several Macs that have 2 Ethernet ports (mainly on newer Mac Pro towers). If I setup a record using port 1 and the end user moves the Mac to port 2 without telling IT, will his Mac no longer be in OD? Or for example, if a laptop user decides to use our WLAN and not our LAN (And thus uses a different MAC address than expected) will he no longer be bound to OD?
Or is the required MAC address in OD simply a unique identifier and not literally used for networking purposes such as discovery, etc?
Regarding the OD clients IP address:
Since all my Macs clients are suing DHCP address, do I HAVE to enter an IP address in WGM when setting up new OD records? THus far I have just been adding a MAC address and skipping the IP address field. IS that OK?
WHen adding new computer records in OD via WGM...
Can I make the short name and the long name the same name without any problems? I don't need to have 2 names for each Mac and WGM wont let me leave the name fields blank. Will I have problems if both the computer record long name and computer record short name are the same in OD?