Working With Home Folders and LDAP

Administrators need to decide where their Mac OS X users will store their home folders. Network authenticated users can have a home folder stored either locally on the workstation they are currently using or on a server over the network. Network home folders are an extension of simple automounts, and the data is spread out between user-specific data and generic mount data. Open Directory has built-in support for Mac OS X home folders and makes providing network home folders easy.

Tip

A quick survey of any third-party directory server will reveal that the Apple implementation of network home folders is not part of the standard RFC 2307 LDAP schema and will need special attention to accommodate these specific requirements.

To get network home folders to function properly, you need to address the data for each user record and provide mount records with the associated mount attributes. If your directory does not have mount records as a part of your existing schema or the attributes necessary for mount records, administrators must provide valid mount records and their associated attributes in addition to the Mac OS Xspecific user attributes covered previously.

Supplementing Mount Records

Supplementing your directory's lack of mount records and attributes is similar to the procedure for user records. You can mount records in the local NetInfo database, modify the schema to create new record types and attributes, or use secondary directory to supplement primary directory.

Here's a disadvantage to creating a mount record in the local NetInfo database, though: If the mount address changes, the administrator will have to change that information on each Mac OS X computer with local mount records.

An attractive third alternative may be to supplement one directory with another. This is done by configuring an Open Directory server to host mount records in its own directory. This server will not host any user records and will also be bound to the primary directory server. To configure Mac OS X to use both directories, add the Open Directory server to the custom authentication list in Directory Access. The resulting combination will allow Mac OS X to search both directories for user and mount records. It will find user records only in the primary directory and find mount records only in the Open Directory server.

Additional Concerns for Network Homes

Administrators who are planning to provide network home folders will also need to pick which protocol they prefer to use. The protocol you choose will depend on what features you need most.

Note

Keep in mind how resource forks are handled by each protocol.

If you choose to use Apple Filing Protocol (AFP), you must be aware that to get full functionality out of Mac OS X you must use an AFP 3.x server. Version 3.x of AFP provides two critical features to Mac OS X:

• The ability to automatically reconnect; if a connection is lost or disconnected, the Mac OS X computer will attempt a reconnect when the network connection is resumed.

• The ability to write files with names over 31 characters in length, since many pieces of Mac OS X rely on being able to write files with long names

  

ByHost files are the most common type of file to have long names, as shown in the above figure. One of the most notable ByHost files is the com.apple.Classic. XXXXXXXXXXXX.plist file. If Mac OS X cannot access this file, the Classic environment will not be able to run. Administrators wanting to use their existing investment in Microsoft file servers will either need to give up these features or upgrade their AFP 2.x servers to 3.x with a product called Extreme Z-IP. This replaces Microsoft's Services for Macintosh with an AFP 3.x server. Currently there is no Microsoft Windows software that will share files over AFP 3.x.

An alternative to AFP would be to use NFS. NFS home folders are fully supported in Mac OS X, and most vendors support NFS. There are security concerns with NFS, as it does not rely on user authentication. In addition, NFS homes will exclude users still migrating from Mac OS 9.x.

Two Methods for Managed Mac OS X Clients

Most organizations would like to provide at least some basic amount of management, such as providing a default set of printers. Others prefer to fully lock down the box to ensure the highest level of computer uptime at the risk of hindering the user from being productive. An optimum solution would be to get these abilities while still integrating with a third-party directory.

To get these features, Apple chose to extend the standard RFC 2307 LDAP schema with over 50 new additions. All of these changes are listed in /etc/openldap/schema/apple. schema and can be applied to any directory service. For most directory administrators, this may be too daunting a task.

A simpler solution may be to supplement the primary directory with an Open Directory server. In the same way that you can use an Open Directory server to provide mounts for network home folders, the same server can provide Managed Client for X (MCX) settings for group and computer records. With this solution you can enjoy the ease of use of the Apple tools and their directory with built-in support for client management. When configured correctly, the Open Directory server is able to create and manage groups of users or groups of groups (new to Mac OS X Server v10.4) that exist only on the primary directory server.

User Authentication With the LDAPv3 Plug-In

Having the additional directory servers bound to the Mac OS X computer to provide the array of services previously described raises some authentication questions. Depending on plug-in configuration, Mac OS X will attempt to authenticate the identity of the user using the following methods:

• Authentication authority: If the plug-in is configured to map the user attribute AuthenticationAuthority to a valid attribute in the user record, then Mac OS X will attempt to authenticate the identity with the associated value.

• Kerberos: Mac OS X will use this method if Kerberos is configured correctly with a valid edu.mit.Kerberos file (located in /Library/Preferences) and the login window is configured to use a modified right in the /etc/authorization file. A more flexible authentication authority permits the use of Kerberos for sshd, sudo, and chkpasswd, to name a few.

• Password User Attribute mapping: If mapped, Mac OS X will attempt to authenticate with the crypt user password in the directory stored in the mapped attribute.

• LDAP Bind: If the password mapping is left blank (as should be done with Microsoft and Novell), Mac OS X will use LDAP Bind to authenticate the identity. By default, this technique transmits the password in the clear. To avoid this security risk, LDAP plug-in should be configured to use SSL. LDAP binding will first try Generic Security Services Application Programming Interface (GSSAPI) and CRAM-MD5 before reverting to clear text.

• SSL: Permits all transactions to be encrypted using a certificate. The server and all client computers must have a copy of the certificate in order to communicate over SSL.

Tip

Take time to coordinate with your directory administrator and other members of your IT/IS group to determine the risk and the appropriate steps you should take to authenticate your users securely. Administrators should be aware how and whether Mac OS X users will see administratively defined password policies. The LDAPv3 password policy support varies by vendor and currently does not work with either Novell or Microsoft directory servers.

Administrators may prefer a solution that does not provide supported server-based password policies so that they can enforce their own policies through mail and Web clients. This compromise gets the most features, such as AFP network home folders, allowing users to change their passwords in the Accounts pane of System Preferences.

Although this may be OK for some administrators, Kerberos would give password policy support while maintaining the functionality of the LDAPv3 plug-in. This combination of LDAP and Kerberos can give Mac OS X users a first-class experience with password policy support plus single sign-on (SSO) to all kerberized services. It must be understood that password policies will not work without a Kerberos authentication authority.