Plugging into Active Directory

A few tips and tricks on using the AD plugin in 10.3. Plugging into Active Directory

�Joel Rennich,

<code>     &lt;/p&gt;
     &lt;p&gt;2 May 2004&lt;/p&gt;
     &lt;p&gt;Mac OS X Server 10.3 brought us the AD plug-in and the ability to play nicer with the dominant operating system�s directory service. However, not everything was sweetness and light. Integrating with a foreign OS is not always easy. Here are a few hints to help you along.&lt;/p&gt;
    &lt;b&gt;  DNS, DNS, DNS &lt;/b&gt;
     &lt;p&gt;Before you can do anything with this plug-in, you need to have a DNS server that knows the windows network. Specifically you need to have service records that show client machines where the AD server is.&lt;/p&gt;
     &lt;p&gt;Your ISP�s DNS will not have these! You'll most likely need to use a valid Windows DNS server. In a healthy AD system, this should already be set up, so just point your Mac OS X machines at what the Windows machines are already using.&lt;/p&gt;
     &lt;p&gt;If your Active Directory isn�t working correctly one way to fix it is to turn on the DNS service on your Active Directory server. Then go into the network configuration for that server and in the DNS section of the advanced networking button for the TCP/IP Settings set the machine to �Register this connection�s addresses in DNS.� Now your server will automatically update its DNS server with all the info about what it can do. Now have your client's use that server for DNS.&lt;/p&gt;
     &lt;p&gt;Once you have joined the Mac OS X client to the AD domain and you are in a pretty simple domain structure you are more than welcome to go back to using your own DNS server. However, AD fail-over services need to be using an AD-aware DNS server.&lt;/p&gt;
      &lt;b&gt;Fill it out right&lt;/b&gt;
     &lt;p&gt;Open up Directory Access and double-click on the AD plugin. You�ll be presented with a few fields that are mandatory. I�ll give an overview of what is usually used here. However, it seems like Microsoft trains AD admins that they have to make each AD system unique in organization, and as such it sometimes quite hard to figure out what�s going on. If at first you don't succeed�&lt;/p&gt;
     &lt;p&gt;The Active Directory Forest is usually the DNS domain that you have set up the AD server to be authoritative for. It is usually not the full host name of the machine. So for example I would use afp548.com here, and not ad.afp548.com, which is the DNS name of the AD server.&lt;/p&gt;
     &lt;p&gt;The Active Directory Domain, in most cases, is the same as the forest. If you are in more complicated setups, these two fields may differ. In that case you're going to need to ask someone that knows.&lt;/p&gt;
     &lt;p&gt;Finally you need to add a Computer ID. This will make an entry in the AD database for your machine. In a perfect world this would be a unique name for each Mac OS X machine that is using the AD plugin. However in practice you shouldn�t run into any issues using the same one for all of your machines. The machine account in AD is used to authenticate the directory services connection before a user logs in, and to apply GPOs to a specific machine. GPOs don�t mean squat to Mac OS X, so the computer account isn�t as important.&lt;/p&gt;
     &lt;p&gt;Now hit the disclosure triangle and take a look at some of the hidden goodies here.&lt;/p&gt;
     &lt;p&gt;Caching the last user will allow you to log in to the client machine while off the network with the last AD user. If you would like to be able to do this with all AD users, you can set them up as mobile accounts. However, you'll need to use an Mac OS X Server to help with that.&lt;/p&gt;
     &lt;p&gt;Authenticate in multiple domains allows you to authenticate to any domain in the forest. Walk through the trees, so to speak.&lt;/p&gt;
     &lt;p&gt;If you don't trust the system to figure out what particular Active Directory server to use, or if you have more than one, you can specify which server to authenticate in the next field.&lt;/p&gt;
     &lt;p&gt;Map UID to attribute allows you to specify an attribute in the user�s AD record to use as a UID. The plugin will automatically generate one for you from the users GUID. However, if you already have a field setup for this, you may want to use that, so enter it here.&lt;/p&gt;
     &lt;p class="alertbox"&gt;Note: The autogenerated UID is based on a number of different attributes in the user's AD record. All OS X machines will generate the same UID for the same user. However, if you change the name of your AD domain or other intrusive configuration changes, it's likely that the UIDs of your users will change.&lt;/p&gt;
     &lt;p&gt;Finally, you can enter in Active Directory groups that will get admin rights on the Mac OS X machine.&lt;/p&gt;
   &lt;b&gt;   Have the rights&lt;/b&gt;
     &lt;p&gt;When you have everything filled out, you can go ahead and attempt to join the AD domain by pressing the �Bind�� button. Now you will need to put in the name and password of a user on the AD server that can add machine accounts. This user does not need to be able to edit anything else in the domain, just add machine accounts.&lt;/p&gt;
     &lt;p&gt;If everything goes right, the plugin will contact the AD server, and look to see if there is already a machine account by that name in the domain. If there is, the plugin will use that one. Otherwise a new one will be created.&lt;/p&gt;
     &lt;p&gt;At this point you have joined the AD domain. A machine account has been created for your Mac OS X client machine. That account�s credentials are stored on the client machine and will allow the client to search the Active Directory server for users whenever one logs in.&lt;/p&gt;
  &lt;b&gt;    Authentication path&lt;/b&gt;
     &lt;p&gt;For the system to fully work, you still need to add the Active Directory server to your authentication path. This is the �Authentication� tab in Directory Access. Select a custom search path and then add the AD connection in.&lt;/p&gt;
     &lt;p&gt;If all went as planned you shouldn�t even have to reboot: just log out and log back in as an AD user.&lt;/p&gt;
      Check out the &lt;tt&gt;man&lt;/tt&gt; page
     &lt;p&gt;New to 10.3.3 is the ability to keep your user�s home folder on a Windows server. Prior to this release you were only able to mount the network home from the Windows machine on the Desktop. The AD user, when logged into the client machine, was automatically given a local home folder.&lt;/p&gt;
     &lt;p&gt;You don�t have to have it that way anymore, but you can�t do it through the GUI. Instead, you�ll need to use the &lt;tt&gt;dsconfigad&lt;/tt&gt; command. Check out the &lt;tt&gt;man&lt;/tt&gt; page for it for more info, including the way to get the home folder URL from the AD server but still use AFP to mount the network home. This makes it very easy to host your user's home folder on an Mac OS X Server but still keep the user in AD without missing out on the goodness of AFP for home folders.&lt;/p&gt;
     &lt;p&gt;The dsconfigad command also makes it easy to script the entire joining of a domain process.&lt;/p&gt;
 &lt;b&gt;     Kick back on a natural&lt;/b&gt;
     &lt;p&gt;Active Directory groups are not like Mac OS X groups. They are a much more tangled web of confusing acronyms. Because of this it may take up to a day or more in very large systems to generate the group list. So don�t get your shell in a bunch if it takes some time to work the kinks out.&lt;/p&gt;
     &lt;p&gt;
     &lt;/p&gt;
  &lt;/div&gt;
</code>

Changelog:

February 18, 2005: Corrected information about UID not being the same across machines.

afp548contributor

More Posts - Website

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Facebook (Opens in new window)

Related