| Intro | LDAP to AD Part I |
| LDAP to AD Part II | LDAP to AD Part III |
| LDAP to AD Part IV | LDAP to AD Part V |
| Misc | ADmitMac |
| -- Home Directories: The End Of The Quest-- |
I'm hoping everyone has at least completed the work started in parts I, II, and III. Part IV is optional but its essential that you've gotten the first three parts to work on your test rig since I'm going to be referencing all of that to get homeDirectories to work. First, a little background:
Back in the day when OS X was still NextStep the way networked homeDirectories were handled was via NFS. NFS mounts were encoded into NetInfo under an entry titled Mounts. Whenever you logged into the machine it would read the mounts entry from NetInfo and would attempt to automount whatever was there. Part of your user account configuration would specify that your homeDirectory resided on one of the shares being automounted. So, if your NFS mounts worked the operating system would now to look on one for your homeDirectory.
Now, when Apple got its hands on NextStep they appear to have extended this mechanism. You can now use AFP to automount your directory instead of NFS. In fact, OS X Server will allow either choice for mounting homeDirectories over a network. When you setup user accounts in this fashion the OS X Server admin tool will actually create the NetInfo mounts entries for you.
Its important to understand that making homeDirectories work properly requires both proper configuration of a Mounts entry as well as the user account. If you make a mistake in configuring either the homeDirectory won't mount. On top of this, you also have to worry about getting the LDAP mappings right as well.
| -- Configuring The One True Active Directory -- |
First thing we need to do is add some more items to the ActiveDirectory schema. Load up the schema editor, right click on Attributes and select Create Attribute and create the following attributes:
Common Name: aplVfsdir
LDAP Display Name: vfsdir
X.500 OID: 1.3.6.1.4.1.63.1000.1.1.1.8.1
Syntax: Case Sensitive String
Common Name: aplVfstype
LDAP Display Name: vfstype
X.500 OID: 1.3.6.1.4.1.63.1000.1.1.1.8.2
Syntax: Case Insensitive String
Common Name: aplVfsopts
LDAP Display Name: vfsopts
X.500 OID: 1.3.6.1.4.1.63.1000.1.1.1.8.3
Syntax: Case Insensitive String
Multi-Valued (click the checkbox in the lower left corner to
set this)
Common Name: aplUserHomeUrl
LDAP Display Name: MacHomeDirectory
X.500 OID: 1.3.6.1.4.1.63.1000.1.1.1.1.6
Syntax: Case Sensitive String
You don't have to use the names I've supplied but if you do use something different make a note of it. After you create these attributes you might want to go back and add comments to them. Check the attribute list pane for the entries you made, get properties, and type up a comment. But, what does it all mean? Well there are few other things I haven't mentioned yet but what we have is this:
VFSDir - part of the mount record entry we'll be creating. It tells OS X where to mount the share we want automounted. Just like NFS, the mounted network share will appear to be a subdirectory on your hard drive. I've also seen this listed as VFSLinkDir but I'm calling it VFSDir to make things a bit simpler.
VFSType - part of the mount record entry we'll be creating. This identifies how the mounts information is to be interpreted. For AFP its always "url" but for nfs its "nfs" (I think).
VFSOpts - part of the mount record entry we'll be creating. This is the good stuff. The two pieces of information that go into this property tell OS X what server and share it will be automounting.
MacHomeDirectory - This is going to be added to the users auxliary class just as we did with UniqueID. MacHomeDirectory is an additional parameter used when a homeDirectory is coming from a network share. It provides OS X with information concerning what share, what directory, and what protocol to use in getting access to the homeDirectory. Both this parameter and NFSHomeDirectory work together though I've had no problem working without NFSHomeDirectory but Apple says we should use them both so I'm not arguing.
Only a few more schema changes to go. Next we need to create a Mounts class into which we can bundle the assorted VFS attributes we've created. A Class is an object that allow us to collect attributes under one roof. When you create a user account in Active Directory it references the user class which in turn lists all the attributes to be associated with a user account like Name, Password, and Office. In the schema editor, right click on the Classes folder and select Create Class. Enter the following:
Common Name: aplMounts
LDAP Display Name: Mounts
X.500 OID: 1.3.6.1.4.1.63.1000.1.1.2.8
Class Type: Structural
Leave the Parent Class field blank. Click Next to set attributes. Click the Add button for the Mandatory section and add cn to the Mounts class. In the Optional section click the Add button and add VFSType, VFSOpts, and VFSDir so that all three attributes are shown in the Optional section. Click Finish to complete the class. Check the classes pane, find your new class, get properties, and add an appropriate comment to it. Click the Relationship tab and click the Add button for Possible Superior. Find and add the Container and Organizational Unit classes, click Ok, and then close the dialog window by clicking Ok. This is important as you won't be able to create a mounts object until you supply a Possible Superior to the Mounts class. Finally, get properties on the Users auxliary class. Click the attributes tab. Click Add and add in the MacHomeDirectory attribute created earlier.
| -- One Directory To Rule Them All -- |
Now that we have a nice and proper schema we need some data to go into it. Its generally pretty easy to figure out but getting the details perfect can be tricky. So, first, let me describe my setup so the values I supply make sense. I have a test server called Lilith. Lilith is part of the Absynthespad.com domain. On Lilith I have a Mac share called Users. Inside that share is a user directory "ricore" for the ricore account I'm using to test LDAP with. In short:
ServerName: Lilith
ServerFullyQualifiedName: lilith.absynthespad.com
Domain: Absynthespad.com
ShareName: Users
UserAccount/Directory: ricore
Now, open up ADSI Edit and connect to your domain. Right click on the domain server object (Domain DC [my.server.com]) and select Update Schema Now. This will allow the changes made to properly show up for our next set of tasks. (You may also need to load the schema editor, right click on the Active Directory Schema object, and select Reload the Schema. After which use Update Schema Now from ADSI Edit.) Right click on the domain (e.g. DC=myserver,DC=com) and select New -> Object. From the list select Container (or Organizational Unit if you want that instead) and click ok. Name the container Mounts and click Next followed by Finish. If you did it right it the Mounts container should be at the same level as your Users container as seen below.
When OS X authenticates it will first look for the user account contained in the Users container. If it succeeds, the next thing OS X will do is check for automounts by looking for entries in a Mounts container located within the same context as the Users container. In other words, if Mounts and Users are not together under one object (in this case DC=absynthespad,DC=com) then OS X won't find Mounts and you won't have any shares automounted. (However, if you have multiple LDAP/Open Directory servers configured I believe it is possible to grab a user account from one and the Mounts information from another.)
Right click on the Mounts container and select New -> Object. Hopefully, your schema changes have been recognized and you can now pick Mounts from the list. Click next and give it a name. Any name will do but if you want to follow the OS X naming used internally it looks like <server name>:\<share name>. So for my setup, its "lilith:\Users". Click Next then Finish. Now, right click on your newly created mounts entry and select properties. For this to work you need to set three properties, VFSType, VFSOpts, and VFSDir. Click on the drop down for "Select a property to view" to set the value for each property. The values for these properties in my rig appear as:
VFSType: url
VFSDir: /Network/Servers
VFSOpts: net , url==afp://;AUTH=NO%20USER%20AUTHENT@lilith.absynthespad.com/Users
What values should you use for your setup? For VFSType and VFSDir you should use exactly as I have done. For VFSOpts you need to enter TWO values. Enter one value, click add, then enter the second and click add. Now, one of those values should be "net" just like my configuration. The part you will need to change comes in the second value that begins with "url==". Keep everything the same as mine but replace everything after the @ sign with your fully qualified server name and the share you have exported containing the home directory you want automounted. So, the full url statement should be one of:
url==afp://;AUTH=NO%20USER%20AUTHENT@ServerFullyQualifiedName/ShareName
Next we need to add a few values to the user account that will be grabbing its homeDirectory from this automounted share. Using ADSIEdit, open the Users container, find the account you're testing with, right click on it, and select properties. Two properties need to be modified and they are MacHomeDirectory and userSharedFolderOther. In my test setup they are set as follows:
MacHomeDirectory: <home_Dir><url>afp://lilith.absynthespad.com/Users</url><path>ricore</path></home_Dir>
userSharedFolderOther: /Network/Servers/lilith/Users/ricore
The first property, MacHomeDirectory, contains quite a bit but what its actually doing is telling Finder that we are going to get a homeDirectory, via AFP, from the server lilith.absynthespad.com. From that server, we want the Users share, and within that share is the folder ricore which is a homeDirectory. Obviously, you'll need to make a number of changes to get this working in your setup but the formula is one of:
<home_Dir><url>afp://ServerFullyQualifiedName/ShareName</url><path>UserDirectory </path></home_Dir>
I've used itallics to indicate what you should modify and bold for what remains the same irregarless of your setup. The second property, userSharedFolderOther, provides information on where the homeDirectory is mounted in the file system. You'll notice that it looks similar to the value set for VFSDir in the mounts record. It should. This property takes what we started with VFSDir and extends the path all the way to the user homeDirectory. So, for your setup follow this:
/Network/Servers/ServerName/ShareName/UserDirectory
That should do it. Now, onward to the client!
| -- And One LDAP To Bind Them! -- |
Back on OS X, open the DirectoryAccess application. Click on the LDAPv3 item and click configure. Select your LDAP server and click Edit. Click on the Search & Mappings tab. Open the User record, find HomeDirectory and remove the mapping already there. In its place add "MacHomedirectory".
Click on the Mounts records record and where you see the line "search base" near the bottom of the dialog, change ou=Mounts to cn=Mounts. However, if you used an organizational object to contain your Mounts then don't change anything here.
Click Ok until you've closed all the dialog windows. You'll notice that in your LDAP server listing the LDAP Mappings now reads "Custom". Since we've deleted the original HomeDirectory entry this causes the mapping template we used to change from ActiveDirectory to Custom. This is a good thing since the default mapping for homeDirectory uses the ActiveDirectory HomeDirectory value. The problem with this is that PCs use different path conventions than Macs. Should you want this account to work on both PC and Mac you'll need to need to keep the Mac and PC homeDirectory values separate as we've done here.
Logout (or possibly reboot) from the Mac and try out your AD account. If all goes well you'll have a GUI, and a homeDirectory. Clicking the Home button in Finder should point to the share you've automounted from the server. If you have the path drop down item added to your Toolbar you should see the path to the server share when you click on it. If your homeDirectory isn't working I have a few things to suggest:
lookupd -d. Lookupd is how OS X
grabs information from the NetInfo database but it will also send queries
to services you configured in DirectoryAcess, like LDAP. Enter userWithName
(Yes, its case sensitive) a space, and then the AD account you want to use.
Hit Return. If all the values you've entered are not showing up make sure
you have them appropriately mapped in the LDAPv3 configuration. I haven't
drifted too far from the defaults but if you used different names for the
mounts record you'll need to change them in the LDAPv3 configuration. Should
you find missing entries double-check your LDAP mappings and spellings.lookupd -d. Type
allMounts and press return. If you get no
objects returned then there is a problem with your LDAP mappings to the
mount record. Either your Mounts container is in the wrong place, or the
LDAPv3 is misconfigured. If you do see an object check that all the values
returned are mappend and correct. A proper response to the lookupd query
would look something like this (Note that we have dir, name, opts, and vfstype
all of which correspond to what we created in AD.):
| -- The Quest Is Not Over -- |
If you made it this far congratulations but there are still a few more things to clean up that I'm looking into.
In our scenario; we have all the home folder residing on the w2k server; thus it is using services for mac to provide afp for sharing the home folders etc. This is the cause of Classic not working; the version of afp (2.1) provided by microsoft only allow filenames of 34 chars or less; and as the preferences for Classic have a much longer name, this stops Classic from running. Other thing which dont work is being able to set the printing prefs & plugins for broswers. There is a 3rd party version of afp called extremez-ip which will solve all this. We have found through experimentation for our purposes that if all the shares were changes to smb from afp and all the client machines were X clients then the Classic, printing,plugins etc would all work.
Email: Chuck Simciak