macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Open Directory and Active Directory, Part 3
Pages: 1, 2

This data can be stored in any unused attribute that supports UTF-8 text and compatible equality rules. We often use userSharedFolderOther. Another choice is to use Apple's apple-user-homeurl, which is defined in the Apple oid space. Once again, use of Apple's schema should be executed cautiously since it is still subject to change.

NFSHomeDirectory: UTF-8 text referring to the file system path where the user's Unix home directory resides. Ironically, it has little to do with NFS or the network at all. This value looks something like

/Network/Servers/Servername/Sharename/Username
	/home/username

Its data is supplied natively by msSFU30HomeDirectory, but by far the least intrusive method for supplying the data for both NFSHomeDirectory and HomeDirectory is to make use of the variable support in static mappings, provided by the third-party LDAPv3 plugin mentioned above.

HomeDirectory's value might also be statically mapped in the case of certain local home directory design goals. Namely, it's common in lab environments to map NFSHomeDirectory to a static value:


Fig 2.4 Directory Access: Static mapping of NFSHomeDirectory.

This directory should restored to a pristine state on logout or login by external means--usually a LoginHook or LogoutHook--so that every user gets an identical, supported desktop environment. You can find directions for this at macosxlabs.org.

Network Home Directories also require a corresponding mounts record. This, however, should almost never be stored in AD, since it requires creation of a new structural class and a number of new attributes. It is far less intrusive to store the mounts record in a shared Open Directory domain or in the local netinfo machine on each client. The mounts record looks something like this:

{
  "name" = ( "mounts" );
  CHILDREN = (
    {
      "vfstype" = ( "url" );
      "opts" = ( "url==smb://AUTH=NO%20USER%20AUTHENT@w2k.example.com/HOMES", "net" );
      "name" = ( "w2k:/HOMES" );
      "dir" = ( "/Network/Servers" );
    }
  )
}

Paste this into a text file (be careful of line wrap; there should be 11 lines) and customize to your own preference or site. Use the niload command to add it to your desired directory. For example,

niload -r /mounts . < edited-mount
niload -r /mounts / < edited-mount

Be aware that this example will replace the mounts directory in the specified domain. Consult the niload man page for further details.

There are many other attributes available to Mac OS X Directory services. These, however, are the most important for directory integration, and in general we operate on the principal of least impact, keeping our additions to the Directory at a minimum. That said, many Mac OS X security policy features are directory based, and these Mac-specific attributes certainly aren't a part of Active Directory natively. When limiting the impact on a directory, you'd seem to be losing these features. This is not the case, though. Managed settings in Mac OS X (collectively known as managed client x, or mcx) can be enforced on 3 levels: user, group, host or a group of hosts.

By limiting our impact on directory schema, we are giving up a few user level management settings. However, in most environments, it's rare and inefficient to actually manage these settings on a per-user basis. More often they are managed on a workgroup or host basis. For example, you might want to ensure that everyone logging into a particular machine in a lab has access to a scanning application. This is not difficult to implement with Mac OS X and Active Directory. All clients are simply configured to get directory data from two sources: your AD and a parallel, Mac OS X Server hosted Open Directory Domain.


Fig 2.5 Directory Access: Multiple nodes in the LDAPv3 plug-in configuration dialog.




Fig 2.6 Directory Access: Multiple nodes (in this case 2 LDAPv3 nodes) in the Authentication path.

All users and enterprise data still resides in AD. Mac specific data- difficult to maintain when stored in AD and often not managed by AD administrators- lives in the Mac specific directory. In this way, management of Mac specific data can be delegated to Mac specific support personnel without having to train them for windows management tasks or create custom management tools. In effect, the Open Directory domain has a one way trust with the Active Directory.

In general, this is accomplished by adding AD users to Open Directory groups or by enforcing these policies on any user that logs into a particular set of machines. For instance:


  1. Scenario: User sadams logs into dtop00.example.com. sadams, an AD user, does not belong to any workgroups with managed preferences. However, dtop00 belongs to a group of machines (NY-office) defined in Open Directory, and a certain set of preferences will be enforced to any user logging into that group of machines (regardless of where their user record is stored: locally, in Active Directory, or in Open Directory). Mac-specific security policy is thus applied to Active Directory users without administrative impact on the enterprise directory.
  2. Scenario: User jdoe logs in to dtop00.example.com. User jdoe exists only in Active Directory. However, mcx.loginplugin searches dtop00's authentication path and determines that jdoe belongs to a workgroup with managed preferences. Since jdoe is logging into a managed client (dtop00 belongs to the NY-office group), he will receive an aggregate of per host and per-workgroup preferences.

Another option for integration involves kerberos and alternate user records. Kerberos authentication in Active Directory happens based on sAMAcountName; what we'd think of as short name in Mac OS X. It's entirely feasible to have a user (jdoe) in Active Directory and a user in Open Directory (jdoe) that both authenticate to the AD's kdc. Most Administrators don't consider this since Microsoft sells AD as a single directory product integrating authentication and authorization. The concepts are quite separate, however, and kerberos is actually designed solely as an authentication technology, specifically for use in conjunction with a directory. The process looks something like this:

  • Create a special user in AD that can search for sAMAcoutnNames
  • Use this user to harvest data for your user list
  • Bulk import this list into Open Directory, creating accounts with a RecordName (name in NetInfo-speak) corresponding to the sAMAcountName. You might want to configure this script so that only differences (additions and deletions) are mirrored. This will mean a more stable directory.
  • Configure clients for kerberos authentication against the AD KDC.

All of these processes allow for full support of Mac-specific user attributes and client management technologies while maintaining a single enterprise authentication authority.

Finally, with Mac OS X 10.2.6 came the ability to leverage NIS. NIS by itself is fairly insecure (and in fact Apple's NIS plugin is incapable of using shadowed maps). However, when combined with Kerberos authentication, NIS begins to look better. With services for Unix installed, Active Directory serves not only as a KDC but also as a full fledged NIS server.

This approach has the added benefit of making group integration with AD much simpler. Active Directory stores group membership according to the users' distinguished names. Unfortunately, the LDAPv3 plugin expects to find group membership according to short name. There are a number of strategies for dealing with this issue, most of which revolve around deriving the RecordName from the distinguished name and dumping a list of short names into one of the group's attributes. However, SFU's NIS server knows how to interpret group membership to Unix clients, thus offering a much simpler solution, and one that involves a lot less work server-side.

In fact, NIS+Kerberos, especially in conjunction with a dual Open Directory as documented above, provides yet another secure, flexible option for leveraging your enterprise directory. In many cases, particularly around the issue of access, this is solution is superior to the LDAPv3 plugin. However, due to its relative newness, we're only aware of a couple sites deploying a solution like this and a high level of testing and auditing is warranted.

Final Thoughts

Cross platform directory services are by nature complex. The right solution for your environment will vary heavily depending on organizational, political, security, and technical requirements. Mac OS X provides a flexible client-side framework to meet these challenges. Because of its reliance on open standards, it's able to be integrated painlessly into existing infrastructures.

Michael Bartosh


Return to Mac DevCenter