Authenticated AFP Mount at Login

Question

Hi All,
   I posted this question on Apple's UNIX Discussion, Authenticated AFP Mount at Login, but I wanted to run it by the specialists here. Hopefully everything I'm going to tell you is in the other thread but I would like to make this post self-contained so that you don't have to read the other post if you don't wish to.
   I have client computers and an AFP server, all of which run 10.4.7. The AFP server is running the server version of OS X with an unlimited license and the clients are running the client version of OS X, all completely up-to-date. I haven't used Open DIrectory. They are all domain joined machines in our Active Directory domain and as such, they are configured as Kerberos clients of the Active Directory domain. All users except the administrator are users of this domain and they have Windoze home directories that are on an SMB share. I would also like them to have shared AFP Mac home directories.
   I like the way that OS X handles the Windoze home directories, putting them in the Dock. If I add a listing in AD for Mac home directories, will OS X still do the same thing with the users' Windoze home directories? I assumed that it wouldn't and so for my domain users, I checked the option to have local home directories created. Then I made /Users a symlink to the mount point of the AFP share. The problem is that I want the mount to be an authenticated mount, using Kerberos for authentication.
   I've tried mounting the share with a LaunchAgent and with a LoginHook. I don't remember whether I got an authenticated mount with the LaunchAgent but I am consistently able to get an authenticated mount with the LoginHook. However, neither of these are executed early enough in the login process. My experience has been that access to home directories is needed seconds before the LoginHook is run. In fact, I had a new home directory created for a user and then the AFP share was mounted on the directory containing the new home directory.
   The only way I could find to have the share available when home directories are first accessed is to automount it. However, I've been unable to make the automounter authenticate. I'm wondering if the Kerberos ticket is even available at the time the home directory is first accessed. Whatever the reason, every attempt to force authentication has simply resulted in a failure of the mount. Of course I was trying to force the issue on the server. If I could configure the client to insist on authentication, maybe the login process would wait until the Kerberos ticket is acquired. Does anyone know how to so configure the client?
   My current solution is a combination of the two methods above. It works surprising well but it's a kludge and I don't trust it to be stable. What I do is to configure the automount and /Users is a symlink to a mount point in /Network/Servers. Then, when the LoginHook runs, not only does it mount the same share (authenticated) in /Volumes, it deletes the /Users symlink and creates a new one that points to the authenticated mount point of the share in /Volumes. Naturally, processes that run early in the login obtain open file descriptors to user files in the unauthenticated mount. Mdimporter is one such process but I assume that such file descriptors are soon closed due to lack of permissions to read and write. After that, I've seen no other problems. When the user logs out, the symlink is restored to point into /Network/Servers and the authenticated share is dismounted.
   My question is whether there are better alternatives to this kludge. I'm loathe to change Active Directory because it would mean also changing our account creation scripts and applications. However, that is possible if that's the only way to do what I want reliably. Any thoughts would be appreciated.
Gary
~~~~
   <SilverStr> media ethics is an oxymoron, much
               like Jumbo Shrimp and Microsoft Works.
   <MonkAway> not to mention NT Security

Answer 1

Actually, there's a much simpler way to use your Mac OS X Server to host home directories for your AD users.
First of all, I would recommend configuring your Mac OS X system as an Open Directory Master then use Directory Access to bind it to Active Directory. Configure the server's authentication search path (policy) starting with /NetInfo/root (closest), then /LDAPv3/127.0.0.1 (Open Directory), then /Active Directory/All Domains.
Next, use Workgroup Manager to define a share point and create a dynamic mount for it (to /Network/Servers/servername/...path.../share) using the Network Mount tab in Workgroup Manager/Sharing. Define the permissions of this home directory share point such that all users can read only. I recommend root:staff, 755. Ensure that AFP Guest Access is enabled for the share and that AFP Guest Access is turned on for the AFP process in Server Admin. (This share point will be mounted dynamically and will be authenticated when doing so. You shouldn't have to allow guest access but it's often required because the dynamic automounter wants to create a mount point for the home directory share upon startup, where it acts as a static automount.)
Be absolutely certain that your server has a valid DNS hostname so that the /Network/Servers/servername field remains the same. Plus, you'll need that for Kerberos anyway.
Third, you'll need to figure out how to store the dsAttrTypeStandard:NFSHomeDirectory (home) and dsAttrTypeStandard:HomeDirectory (home_loc) attributes in user accounts in Active Directory. You can use Apple's schema (published in the User Management Admin Guide for Mac OS X 10.4) or you can repurpose existing unused attributes in user accounts already in AD. If you're repurposing, you'll need to use the AdsiEdit.msc snap-in to do so, and each attribute should have a single value of UTF-8 (Unicode) string.
If you're repurposing: On your server, you'll need to "tell" the systems about the repurposed attributes by manually editing the ActiveDirectory.plist file. In Property List Editor, open the file (change its permissions so that you can write first), expand the AD Attribute Mappings Table, then expand the dsRecTypeStandard:Users array. Look for items whose values are dsAttrTypeStandard:NFSHomeDirectory and dsAttrTypeStandard:HomeDirectory and change their names to the appropriate numeric ID of the AD attribute that you're using to store the respective information.
Either way, when populating the attributes for NFSHomeDirectory and HomeDirectory for each user account, use the following syntax:
NFSHomeDirectory is the path to the home from the client's point of view: /Network/Servers/homeserver.somewhere.com/Volumes/ServerHD2/Homes, for example.
HomeDirectory contains the AFP URL and path to the user's home like: <homedir><url>afp://homeserver.somewhere.com/Homes</url><path>joey</path></homedir>
Fourth, on your home directory server, you'll want to make sure that it's joined to the same Kerberos realm as the Active Directory domain controllers.
You can bind your clients to either the Open Directory domain, Active Directory Domain, or both. If you bind them to AD, you'll have to make the necessary edits to the ActiveDirectory.plist file if you're repurposing unused AD attributes.
--Gerrit