adding a machine to workgroup manager

There are three common ways of creating computer records in Open Directory:

1- If you do a "trusted bind" of the client, it'll add a computer record as part of the binding process (very similar to what Windows Active Directory does). The default is to do an "anonymous bind", which doesn't do this; if you want to convert a client from anonymous to trusted, run /System/Library/CoreServices/Directory Utility.app, click the padlock and authenticate as a local admin, double-click the LDAPv3 plug-in, select your server config and click Edit, then click Bind, and finally enter your directory admin name and password and click OK. You should now have a computer record for this client.

You can also do a trusted bind when first binding the client, either by doing the bind in Directory Utility and supplying directory admin name & password as part of the process (if you leave those fields blank it does an anon bind instead), or by setting a server policy to require trusted binding (in which case Accounts preferences will ask for your directory admin password if you use it to bind the client) -- even more like AD.

2) You can manually create computer records in Workgroup Manager. Just click the plus button in the toolbar, then enter a name and Ethernet ID (required so the client can identify its record) for the computer. Then add it to any computer groups etc.

3) While viewing a computer group's member list in WGM, click the "..." button on the right. This will scan the local network for Macs, displaying their computer names and ethernet IDs. Select the computer you want and click Add, and it'll create the computer record (complete with name and ethernet ID), and add it to the computer group, all in a single operation.

There's also sort of a fourth way: if you just want the same settings for all (or most) of your computers, you can create a "Guest Computer". In the Computers section of WGM, select File menu > Create Guest Computer. You can then assign managed prefs to the guest computer account and/or put it in a computer group and assign prefs to that. Those preferences will then be applied to all computers joined to the domain that don't have their own computer records.

Ethernet ID and MAC address are the same thing.
You can check out
http://consultants.apple.com/it/
to find consultants.

I also found the information very helpful - thanks. But I have another issue. I have never bound computers to the server before; just used the "Guest" group. I want to do so now, so as to work out a way to setup different OS machines to get the correct Software Updates from the server. I started doing this, but on the second machine, I got the error message "There is already a computer with that name". This was from a freshly imaged machine. I looked in the WGM Computers tab - there was only one record. Does this mean that when you set up a computer to look to a server for LDAPv3, this creates a computer record that is not visible in WGM? How can I see these records and what should I do regarding the binding? Thanks for your time - much appreciated.

wiren wrote:

Gordon Davisson wrote:
2) You can manually create computer records in Workgroup Manager. Just click the plus button in the toolbar, then enter a name and Ethernet ID (required so the client can identify its record) for the computer. Then add it to any computer groups etc.

This is what I did, I create a computer entry in workgroup manager on the server with the airport MAC address of the server and the set some option into «login». But afterwards even if the client is bound to the server (I can login with OD user and see the green light status) those options were not applied.

The client will look for a computer record by its first ethernet address (en0, generally the physical ethernet port), even if it's connected via to the network via Airport (generally en1). Try putting the ethernet MAC address in the computer record and see if that works (you may also need to reboot the client to get it to notice the change).

pkmusic wrote:
I also found the information very helpful - thanks. But I have another issue. I have never bound computers to the server before; just used the "Guest" group. I want to do so now, so as to work out a way to setup different OS machines to get the correct Software Updates from the server. I started doing this, but on the second machine, I got the error message "There is already a computer with that name". This was from a freshly imaged machine. I looked in the WGM Computers tab - there was only one record. Does this mean that when you set up a computer to look to a server for LDAPv3, this creates a computer record that is not visible in WGM? How can I see these records and what should I do regarding the binding? Thanks for your time - much appreciated.

Are you using trusted binding? If so, it actually assigns three names to the computer record (although only one is visible in Workgroup Manager): the computer's hostname (with a $ on the end), the computer's full domain name (again with a $), and the computer's local Kerberos KDC name (something like LKDC:SHA1.randomhexadecimalgibberish). Depending on how your computers are imaged, they may all have the same LKDC name, and that's what's conflicting.

Most recent imaging tools take care of this by destroying & recreating the LKDC (thus creating a new, unique ID on each imaged computer) -- NetRestore images created with Apple's System Image Utility since 10.5.6 and 10.6.3 [should do this|http://support.apple.com/kb/TS1245], and I know [DeployStudio|http://deploystudio.com/Home.html] takes care of it as well. It is also possible to do the process by hand, but it's a bit messy (it involves destroying and recreating both the local KDC and system keychain) and I don't remember the details offhand.

Gordon Davisson wrote:
Are you using trusted binding? If so, it actually assigns three names to the computer record (although only one is visible in Workgroup Manager): the computer's hostname (with a $ on the end), the computer's full domain name (again with a $), and the computer's local Kerberos KDC name (something like LKDC:SHA1.randomhexadecimalgibberish). Depending on how your computers are imaged, they may all have the same LKDC name, and that's what's conflicting.

Most recent imaging tools take care of this by destroying & recreating the LKDC (thus creating a new, unique ID on each imaged computer) -- NetRestore images created with Apple's System Image Utility since 10.5.6 and 10.6.3 [should do this| http://support.apple.com/kb/TS1245 ], and I know [DeployStudio| http://deploystudio.com/Home.html ] takes care of it as well. It is also possible to do the process by hand, but it's a bit messy (it involves destroying and recreating both the local KDC and system keychain) and I don't remember the details offhand.

Thanks so much Gordon. Now I know the problem - it's me! I started off using Apple netrestore; then moved to DeployStudio. But the images are now so big I started using Carbon Copy Cloner and Disk Utility (just to scan for restore) and the images copied from a USB drive. After reading up on LKDC, I can certainly see why there would be problems. I am not on site; so I can't test if the machines I did via SDAdmin are fine; but my question is: If you create an image using Disk Utility and restore it that way - does it fix the LKDC? I have to go back to scratch now so before I even get to the deployment; I have to make sure the image is good. Btw, I found a cleanup script here: http://managingosx.wordpress.com/2009/01/23/image-cleanup-script/ but it doesn't look too simple. And InsatDMG looks even harder. What method do you recommend if the network is too slow?

Hello Gordon

Hopefully I think this is what you were possibly referring to?

http://discussions.apple.com/thread.jspa?threadID=1830800

The original kb article TS1245 did detail the directions given in the above thread, but Apple changed the kb article to now read like this:

http://support.apple.com/kb/TS1245

Which basically confirms your other advice. DeployStudio, as you quite rightly point out, handles this as well as the other 'crud' (ByHost, Caches etc) that needs to be removed prior to imaging. InstaDMG does a good job of handling most of the 'crud' as well.

HTH?

Tony

It's best to wipe out the local KDC before imaging the prototype computer. This is what both the script you linked and the procedure described in Antonio's link do, but unfortunately I don't think they'll work for Snow Leopard as it has a more complicated way of controlling the configureLocalKDC daemon.

Here's a quick stab at a script to delete & immediately recreate the local KDC on a newly imaged computer. Warning: this has not been thoroughly tested; check the results before handing out computers you've run this on (and if you find any problems, report back so we can sort them out before others run into them).

#!/bin/sh -e
# This script can be run on a newly imaged computer, to delete and recreate
# its local KDC.
# Note that it is not useful for prepping a prototype Mac before imaging, as
# it creates a new LKDC immediately (and you'd really prefer your master images
# to not have a LKDC at all).
if [ $(id -u) -ne 0 ]; then # if we're not already root...
 if [[ " $(id -Gn) " == *" admin "* ]]; then # if admin is in our group list, try to rerun as root
 exec sudo -p "This script needs root access; please enter your admin password: " "$0" "$@"
 exit $?
 else # not an admin? Not gonna happen.
 echo "You must run this script from an administrator account."
 exit 1
 fi
fi
# Leopard & Snow Leopard - delete & recreate the local KDC
# see http://support.apple.com/kb/TS1245, http://www.afp548.com/forum/viewtopic.php?showtopic=20036
/usr/sbin/systemkeychain -k /Library/Keychains/System.keychain -C -f
rm -rf /var/db/krb5kdc
/usr/libexec/configureLocalKDC
echo "Local KDC recreated."

I spent some time yesterday trying to sort out this issue. I am supplied with the images; I can't make them from scratch. So I got the 2 latest versions. A local restore using CCC confirmed for me that these images have not been created "cleanly" for want of a better word. I then tried a few methods involving scripts or terminal commands to clean up the image after deployment - none of these worked either. I did notice when reading http://support.apple.com/kb/TS1245 that it's explicitly mentioned "You should not manually remove Mac OS X system files or security configuration items to try to resolve this issue." I certainly found that to be good advice, although I will admit to not having of the level of expertise required to troubleshoot these methods. So I have imaged 2 partitions on a Macbook with 10.5.8 and 10.6.6. After making some adjustments, I am creating images using System Image Utility 10.5.7 and 10.6.5 respectively. I will now be testing how these restore.

I'm not sure if Apple's tools reset the LKDC when building the image, or when restoring it; so I'm not sure if that'll help. Also, the (few) times I've tried it the delete-and-rebuild approach has worked for me, what problems are you running into? The main thing I'm aware of is that the rebuild LKDC will be missing entries for existing local users, so those users won't be able to use Kerberos authentication; since I've never found anything useful to do with Kerberos for local accounts, I don't consider this worth worrying about.