MacOS X Home Directory Mounting via SMB/LDAP

This tutorial aims at helping out getting MacOS X machines to work with existing LDAP/SAMBA setups for Linux/Windows clients. In our institute, we already had a mixed environment of Linux and Windows clients, authenticated by a central LDAP server. Recently, we migrated the LDAP to the excellent GOSAÂ² front-end, which not only simplifies administration but adds a number of convenience abilities for the individual users like changing passwords, adding personal information etc. To include the growing number of Apple machines in our institute, we wanted to authenticate these against the existing LDAP server, along with the mounting of user home directories via the SMB protocol. Most tutorials on this matter refer to NFS mounting. For security reasons, NFS (prior to version 4) is a debatable choice. Hence, AFP and SMB remain as candidate network protocols for MacOS clients. In order to avoid implementing an AFP (netatalk) server for a minor number of Apple hosts, we chose to use the same protocol used by the existing Linux and Windows clients.

Prerequisites

In further explanations, we assume an already working SAMBA/LDAP combination. See below for references to respective guides.
The necessary changes to an existing setup are confined to the LDAP and (if applicable) it's Web frontend. In principle, MacOS clients can directly authenticate against an LDAP server, where the object classes inetOrgPerson, posixAccount and shadowAccount are active for the users. So a first test would include setting up "LDAPv3" in the Directory Services utility using the address of the LDAP server and RFC 2307 mappings (139.30.208.1 in our example). After setting up the LDAPv3 and marking it as active, the ldap server is to be included into the search path (/LDAPv3/139.30.208.1). The verification can be done by using the dscl utility.

If the mappings are correct for the existing LDAP server, the following call should list all users defined in the LDAP:

dscl /LDAPv3/139.30.208.1 -list /Users

If that step didn't work, check the search base for users, if that one matches the defines in the LDAP server regarding the typical base "ou=people,dc=...." and the constraints in the right-hand side of the "Users" entry. By default, MacOS requires all 5 object classes to be present for valid users (changed to "any" in the example screenshot). After finishing the setup and debugging process, the required object classes should match the actual LDAP setup (in our case, all except extensibleObject).

Of importance to test the readability of attributes and their native mappings for LDAP-defined users is the following example use of dscl:

dscl /LDAPv3/139.30.208.1 -read /Users/bax

If this test works so far, we can continue setting up the LDAP server to serve MacOS clients. Else, a bit of troubleshooting is necessary first. Remember to call dscacheutil -flushcache occasionally on the test MacOS client after performing changes on the LDAP server.

The latest patch level of MacOS 10.4 requires a change in the client hostconfig to enable AFP/SMB mounting. Edit /etc/hostconfig to set "AUTOMOUNT=-NO-"

SLAPD setup

The first addition to the ldap daemon is the apple.schema file. For copyright reasons, that one is not included in the GOSAÂ² distribution. You'll find that file on a Tiger/Leopard machine in "private/etc/openldap/schema/apple.schema". Unfortunately, OpenLDAP does not like the schema file. In some tutorials, it is suggested to disable schema checking in the LDAP server. I chose to patch the schema into a working state. If "slapd" complains about missing "authAuthority" declaration, add the following lines at the top of apple.schema:

attributetype (
1.3.6.1.4.1.63.1000.1.1.2.16.1
NAME 'authAuthority'
DESC 'password server authentication authority'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Depending on the version of the apple.schema file, the attribute of apple-user-homeDirectory is commented out. Remove the comments and add apple-user-homeDirectory to the list of attributes in the apple-user class. This section looks like this in my schema file:

objectclass (
1.3.6.1.4.1.63.1000.1.1.2.1
NAME 'apple-user'
SUP top
AUXILIARY
DESC 'apple user account'
MAY ( apple-user-homeurl $ apple-user-class $
apple-user-homequota $ apple-user-mailattribute $ apple-user-homeDirectory $ apple-user-printattribute $
apple-mcxflags $ apple-mcxsettings $ apple-user-adminlimits $
apple-user-picture $ apple-user-authenticationhint $
apple-user-homesoftquota $ apple-user-passwordpolicy $
apple-keyword $ apple-generateduid $ authAuthority $
acctFlags $ pwdLastSet $ logonTime $ logoffTime $
kickoffTime $ homeDrive $ scriptPath $ profilePath $
userWorkstations $ smbHome $ rid $ primaryGroupID ) )

The apple.schema references a number of attributes in the elder samba.schema (not present by default in samba3.schema). I did not add samba.schema to my slapd but enabled these previously out-commented variables (acctFlags, pwdLastSet, logonTime, logoffTime, kickoffTime, homeDrive, scriptPath, profilePath, userWorkstations, smbHome, domain, rid, primaryGroupID) in samba3.schema. You might want to try enabling both samba.schema and samba3.schema instead of patching. YMMV.

In /etc/slapd.conf, the apple.schema is the last directive in the schema include statements.

include /etc/ldap/schema/apple.schema

Pending any remaining mismatches in the apple.schema file, the slapd should restart without further complaints.

LDAP database additions

The first step in the customized LDAP database is the declaration of mounts. In our GOSA setup, this is important for two reasons. MacOS clients require a definition of available mounts in order to look further into the individual user properties. Furthermore, GOSA relies on existing mounts definitions to enable the netatalk plugin. My mounts ou definiton looks like this (you need to change dc parameters matching the actual LDAP server):

dn: ou=mounts,dc=int,dc=uni-rostock,dc=de
objectClass: organizationalUnit
ou: mounts

After installing the mounts ou, you are ready to define the exporting servers. In my example, intserver.int.uni-rostock.de is a samba server, which will be mounted to "/Network/Servers".

dn: cn=intserver.int.uni-rostock.de,ou=mounts,dc=int,dc=uni-rostock,dc=de
objectClass: mount
cn: intserver.int.uni-rostock.de
mountDirectory: /Network/Servers/
mountOption: net
mountOption: url==smb://;AUTH=NO%20USER%20AUTHENT@intserver.int.uni-rostock.de/
mountType: url

I added these two entries manually using "ldapadd".

Manual User setup and testing

In the GOSA environment, these steps are not necessary, since the netatalk plugin should now offer you to enable the respective extensions. Any user that should be enabled to login on MacOS clients needs the "objectClass: apple-user" installed. The two attributes for mounting shares are apple-user-homeurl and apple-user-homeDirectory. The home directory entry defines the mount point in the client system (example for user ahrens on intserver: /Network/Servers/intserver.int.uni-rostock.de/ahrens). The apple-user-homeurl is embedded in an XML fragment. Please note a potential pitfall in the syntax. While AFP examples divide between server address and user path, the SMB variant expects the full path in the url and seems to ignore path additions. For my example server, the apple-user-homeurl looks like this:

<home_dir><url>smb://intserver.int.uni-rostock.de/ahrens</url><path></path></home_dir>

By now, the relevant changes to the server are complete. On the client side, mappings from HomeDirectory to apple-user-homeurl and NFSHomeDirectory to apple-user-homeDirectory need to be defined in Directory Utility. These will be automatically available when configuring the LDAP client in OpenDirectory mode (don't forget to re-apply the changes noted in the prerequisites section).

A user with manually added apple-user class and attributes should be able to login with his home drive.Caution: MacOS does not support local/remote logins via command line tools (so don't bother to try "login" or "ssh"). As of this writing, I got the mounting of home directories only to work by using the MacOS login window. Fast user switching is your friend here.

Now, if the manual addition of apple-user-homeurl and apple-user-homeDirectory yielded the desired functionality, it's time to get a convenient Web frontend up and running.

GOSA plugin patching

As of this writing, Debian Lenny offers GOSA 2.5.16 packages, which are installed on our LDAP server. When following this guide including the addition of mounts to the installed slapd, the GOSA web frontend should have the installment of "netatalk extensions" button enabled. For the purpose of SMB based home directory mounting, the netatalk plugin needs to be patched.
In lines 250-251 of /usr/share/gosa/plugins/personal/netatalk/class_netatalk.inc, the following commands are replaced

$this->apple_user_homeurl_xml = '<home_dir><url>afp://'.$host.$dir . '</url><path>'.$this->apple_user_homepath_raw.'</path></home_dir>';
$this->apple_user_homeurl = base64_encode($this->apple_user_homeurl_xml);

by:

$this->apple_user_homeurl_xml = '<home_dir><url>smb://'.$host.$dir.'/'.$this->apple_user_homepath_raw . '</url><path></path></home_dir>';
$this->apple_user_homeurl = $this->apple_user_homeurl_xml;

The reason for exchanging the first line is obvious: SMB instead of AFP. The second line is IMHO a bug in the plugin, where a BASE64 encoded path is passed to the PHP-LDAP routine (which doesn't know that this string is BASE64 and doesn't tell the LDAP server to store this string with the appropriate BASE64 type).
Another change affects line 321, where "afp://" is exchanged by "smb://".
If everything went well, Users for whom netatalk extensions are installed from the GOSA frontend should be able to login properly right now. You can verify the installed extensions on a client Mac by calling

dscl /LDAPv3/139.30.208.1 -read /Users/ahrens,

where the output (truncated example below) should include the defined paths:

dsAttrTypeNative:apple-user-homeDirectory:
/Network/Servers/intserver.int.uni-rostock.de/ahrens
dsAttrTypeNative:apple-user-homeurl:
<home_dir><url>smb://intserver.int.uni-rostock.de/ahrens</url><path></path></home_dir>

Store MacOS client configuration on LDAP server

: Write LDAP client configuration to Server (using admin DN and previously defined base for macosx configs)

After the MacOS client being used for testing is working properly, it might be a good idea providing that information for all subsequent clients. One option is to save the settings as template to HDD and importing that one on all newly added clients. A better option is storing these configuration settings directly on the LDAP server. For the settings on LDAP servers, a container needs to be prepared. You might need to uncomment the container class in apple.schema. In our setup, the MacOS specific settings are stored in a dedicated organizational unit (ou=macosx). See below for an example.

dn: ou=macosx,dc=int,dc=uni-rostock,dc=de
objectClass: top
objectClass: organizationalUnit
ou: macosx
description: Holds metadata for OSX client config

dn: cn=config,ou=macosx,dc=int,dc=uni-rostock,dc=de
cn: config
objectClass: extensibleObject
objectClass: container

After adding these prerequisites to the LDAP server, you can save the current settings of a fully working client machine to the server. In the "Search & Mappings" tab of your LDAP server's settings, the "Write to Server" button serves this purpose. In my example, the search base would be "cn=config,ou=macosx,dc=int,dc=uni-rostock,dc=de". As distinguished name, enter the Admin DN (typical cn=admin,dc=...) plus the admin password of your LDAP server.

Conclusion

In this article, hints on integrating MacOS 10.4 "Tiger", 10.5 "Leopard" and 10.6 "Snow Leopard" clients into an existing SAMBA/LDAP setup were presented. Judging from initial tests, the clients worked well in our chosen environment.

I hope that these instructions are somewhat useful in avoiding too much trial-and-error for people attempting similar setups.