LDAP Integration Methodology and Workflow


You have learned how Mac OS X stores a set of attributes for every Mac OS X user, such as user name, password, home folder, and user ID. Mac OS X needs the specific data found in these attributes, regardless of the directory-service connection. Integrating Mac OS X with a directory service to provide these attributes is a multistep process.

Open Directory's directory service shares a common communication protocol with directory services from other vendors. Each vendor has the freedom to choose the directory data store of their choice and to build native tools to manage that directory data store. Through LDAP, a standards-based directory-service protocol, different vendors can operate together peacefully.

The rest of this lesson will focus on using Open Directory's LDAP directory-service protocol plug-in and the dynamics of getting the best Mac OS X experience possible from a non-Apple directory service.

By following a five-part LDAP workflow, you will greatly increase your chances of successfully integrating Mac OS X with a third-party directory service. This process helps to break down the mechanics of connecting and should expose common issues administrators face while reducing the guesswork in troubleshooting a directory.

  1. Connect.

  2. Understand.

  3. Supplement.

  4. Configure.

  5. Test.

Step 1: Establish a Valid Connection

To integrate Mac OS X into any directory service, you should first establish a valid connection. There are several utilities available to assist administrators in connecting to a directory service over LDAP, such as LDAP Browser, LDapper, LDAPManager, and command-line utilities. They are all excellent methods of getting immediate feedback from your directory service.

When connecting to a directory service, administrators will have to determine the following:

  • Does this directory service allow anonymous browsing or is user authentication required?

  • Does this directory service require a secure connection with SSL?

  • Is the LDAP server using a custom port?

If user authentication is required for a particular directory service, the user name will be a user's full distinguished name (dn). For example:

cn=John Smith,cn=Users,dc=mainserver,dc=pretendco,dc=com

Once connected, your browser will display output similar to that in the following figure:

If you cannot make a connection to the directory server, then there is no need to proceed further. You must prove a valid connection and be able to view all necessary attributes and their associated values, so check typing, DNS issues, and firewall settings as the first culprits in thwarting your initial attempts at a valid connection.

Step 2: Understand Your Directory

Once a connection has been established, take a look at the data that exists in the directory service. Start by determining where user records exist in the directory service. They may be distributed throughout the entire directory or be completely contained in one part of the directory. This, of course, is at the discretion of the LDAP administrator; therefore, when planning to deploy Mac OS X with third-party directory services, you should meet with the LDAP administrator and understand exactly how the LDAP structure is laid out for that particular directory service.

When configuring Mac OS X, Directory Access will prompt you to specify a search base. This search base is the dn of where the user records can be found in a particular directory service. For example:

cn=users,dc=mainserver,dc=pretendco,dc=com

Inspect the individual user records and see what attributes have been associated with the record. Also inspect the data associated with each attribute.

Remember, for Mac OS X to integrate with this directory service, the attributes listed in the figure must be mapped to user attributes in the directory service. The names of the attributes in the directory service do not have to match. The important thing is that the value for a user's primary group ID is 20 and the attribute gidNumber in the directory has the value 20 associated with it. In Directory Access, the attribute PrimaryGroupID is mapped (in one method or another) to gidNumber.

Upon further review of the user records in the directory, you will discover that certain required attributes for Mac OS X either do not exist or have incompatible data populated. Take note of these deficiencies and incompatibilities as you determine the correct schema for the directory service.

Step 3: Supplement Missing Data

Supplementing directory data is by far the most challenging part of integrating Mac OS X with a third-party directory. Knowing where the deficiencies are with your existing user records will be the key to your success. The missing data must be supplemented in one or more of these three methods:

  • Repurposing existing fields

  • Employing local mappings with static and variable attributes

  • Modifying the schema of the directory

Regardless of the method administrators choose, they must plan their strategy and adequately test it prior to rolling out the solution. The major pros and cons of the three methods, which are detailed in the following sections, are summarized in this table.

Repurpose Existing Unused Attributes

This method involves taking unused attributes that are already part of the current directory schema and putting Mac OS Xspecific data in those attributes.

Repurposing requires cooperation with the LDAP administrator. The primary reason to repurpose is because it does not require any modification to the schema of the directory service. Different directory services and their administrators have different appetites for making schema modifications. In addition, it usually requires less setup time, which is valuable for smaller organizations.

This method is often the most attractive at the beginning and quickly becomes the least viable solution. In the long run, attribute reuse is more difficult to maintain: Not only must system administrators track what attributes were commandeered, but there is the risk of overwriting critical data required by other clients if those attributes are suddenly needed by the LDAP administrator.

In addition, attributes have certain requirements, and one attribute may be unable to store the data that you want to populate. For example, the attribute employeeID may be allowed to store only integers. Any attempt to store a text string such as /Users/myhome would result in an error, as it does not comply with the attribute limitations. Your LDAP browser will not display unused attributes. Each user record consists solely of attributes that contain specific data for that user. To discover all the available unused attributes, administrators usually consult the directory's schema with vendor-supplied tools for that directory service.

In the example in the following figure, two attributes that were not being used, secondaryFax and ipPhone, were mapped to the user attributes UniqueID and HomeDirectory in Directory Access. These steps are still not enough for the Mac OS X login to be successful.

In this case, secondaryFax was populated with 1007 and ipPhone was populated with a value required for a user to have a network home folder:

<home_dir><url>afp://server.pretendco.com/Users</url><path>cscott</path></home_dir>

Notice that these values are unique to each user, and every Mac OS X user record will have to be populated prior to deploying Mac OS X.

Overall, repurposing is not flexible due to the limited number of attributes available, and can impact others with other applications and platforms.

Employ Local Static and Variable Mappings

When limitations with repurposing attributes are too restrictive for organizations, another option is to use local mappings, which are a convenient way, within Directory Access, to hard-code in directory data that would normally exist as an attribute in a user record. This is an attractive option for Mac OS X administrators who may not be able to make changes to the directory service, but still want to integrate into the existing infrastructure as best as possible. Plus, local mappings are quite flexible with variables and don't require any attention from the directory administrator.

Static mappings are effective when each user has an individual computer and when addressing universal mappings that may be the same for all users. Local mappings always begin with a number sign (#) as the first character of the mapping within Directory Access. Note that static mappings may require extra configuration after deploying with Network Install.

The first directory-service example in the following figure does not have an existing attribute populated with data suitable for mapping UniqueID. The solution maps UniqueID #1007 in Directory Access. So everyone who logs in to this computer will have a UID of 1007 with exactly the same access to local files and any files hosted by an NFS server.

The second example in the figure addresses the missing attribute for HomeDirectory. In this case, the goal is for users to have separate home folders. A static value of

#<home_dir><url>afp://server.pretendco.com/Users</url><path>generic</path></home_dir>

will not work. Every user on this computer would have the same home folder called generic on mainserver.pretendco.com. To achieve separate home folders, a variable must be included in the static mapping.

In Mac OS X v10.3.3 and later, variables are included in the mapping by enclosing, or "wrapping," a valid LDAP attribute in dollar signs ($). For example:

#<home_dir><url>afp://server.pretendco.com/Users</url><path>$uid$</path></home_dir>

Note

Though we can't show it properly on the printed page, be sure to type each of these commands as a single line with no paragraph returns.


When a user logs in with this mapping in Directory Access, the home folder path will be dynamically constructed with the data stored in the attribute, uid, for that user. In this example, the user's short name was the data associated with the uid attribute in the directory. When each user logs in, Mac OS X looks for that user's home folder in a folder named with their short name on the server at mainserver.pretendco.com in a share point called Users, thus achieving the desired goal.

Local mappings are also used as a safety net to ensure that user logins are always successful by listing more than one attribute in a particular mapping and leaving the last entry as a local mapping. Mac OS X will search the directory for all of the listed attributes; if no matches are found, the local mapping will be applied. That's good news if your Mac OS X computers could be used by people outside of your immediate department.

Departmental users may have network home-folder information in their user records where nondepartmental users may not have specific Mac OS X home-folder information in their respective user records. They may still need access to your Macintosh lab with a valid LDAP login. To alleviate these two different needs, you could map HomeDirectory to both the valid attribute in the directory and a local mapping of #/tmp/$uid$.

The result is that nondepartmental employees have a functional home when they visit the lab and their data will be erased the next time the computer is restarted, while your departmental employees will still have functional network home folders.

Modify the Schema and Create New Attributes

The most significant step an administrator can take to integrate Mac OS X into an existing directory service infrastructure is to modify the schema on the LDAP server. Only the directory service administrator, who uses tools from the vendors of each directory service to add additional objects and attributes that accommodate the specific needs of Mac OS X user records, can modify the schema.

This is not a trivial taskit requires extensive knowledge of the existing LDAP schema and may be very difficult to undo. Changes should be scripted and tested thoroughly before rolling these changes into a production server. Keep in mind that user attributes are not the only attributes that can be added to the schema. Group account attributes, computer account attributes, managed account settings, and network view settings can also be added.

Note

Do not attempt schema modification without consulting your LDAP server administrator!


In the following figure, the directory administrator has created two new attributes dedicated to host the missing Mac OS X user attributes. Specifically, the attribute unixid will host the value for UniqueID and macuserhome will host the value for the Network home folder.

The newly created attributes still need to be populated with valid data for everyone using Mac OS X in your directory service environment. Verify this step has been completed with an LDAP browser prior to configuring Mac OS X to integrate.

More Info

Apple has a set of Active Directory schema modifications that support most of the Apple attributes. More information can be found at www.apple.com/services/consulting.


Step 4: Integrating Mac OS X With LDAP Directory

Now that you have accounted for each user attribute required by Mac OS X, you can use Directory Access to configure Mac OS X to integrate with the LDAP directory. The process is similar to configuring Mac OS X to connect to an Open Directory server.

Note

While configuring an LDAP configuration may be simple, beware that a single typing mistake can render your configuration inoperable.


Directory Access has three presets for configuring the LDAP plug-in:

  • Active Directory

  • Open Directory Server

  • RFC 2307 (UNIX)

When connecting to a third-party directory:


  1. Use the LDAP plug-in in Directory Access to create a new LDAP connection.

  1. Start with the RFC 2307 (UNIX) preset and then customize the mappings to your specific settings.

    First provide the default search base for your directory to find all records including users, groups, mounts, and other record types. If need be, you can edit the search base for each record type beyond this general setting.

  1. Edit the configuration for your organization's specific needs.

    If your LDAP browser required any connection configuration (such as a custom port, SSL encryption, or required user authentication), make sure to duplicate the working settings from the LDAP browser utility to Directory Access.


  1. Now begin to assign your specific attribute mappings to match up with what you discovered with the LDAP browser utility

  1. Make sure to incorporate mappings that will supplement the directory service

  1. If multiple entries are entered for a particular mapping, Mac OS X will look for the data in the first mapping and work its way through the list of possible attributes until it has found a match.

Tip

The RFC 2307 preset for Directory Access does not include the user attribute HomeDirectory. If your configuration is going to employ network-based home folders, you will need to add the HomeDirectory attribute for the user record mapping. Do not forget to configure the attribute once you have added it.


Step 5: Add Directories to the Authentication Path and Test

Now you need to add directories to the authentication path, as shown in the following figure:


  1. Any directories that you want to use for authentication will be added to the search path within Directory Access.

  1. You can sort the priority of different directories and Mac OS X will search each directory as they are listed within Directory Access.

Once the LDAP configuration has been inserted into the authentication search path, you can begin to test the configuration. From the command line, you may use either lookupd -d or dscl to see if the configuration is working properly. If it is, you should get output that looks very similar to the output of the LDAP browser.

The final test is to see if your users can log in using the login window. If your users are going to have network home folders, expect an error message regarding the location of the home foldera reboot may be required to initialize the supporting automount.

After you have tested the configuration, you can use the "Write to Server" button in the Search and Mappings pane of the LDAP plug-in to store the mappings in the LDAP directory so that it can supply them automatically to other Mac OS X computers.

Use a dn of an administrator or other user with write permission for the search base (for example, uid=diradmin,cn=users,dc=mainserver,dc=pretendco,dc=com) and the account's password. Also provide a search base to store the mappings. If you are writing mappings to an Open Directory server, the correct search base is

cn=config, suffix

where suffix is the server's search base suffix, such as

dc=mainserver,dc=pretendco,dc=com

So the full line would be

cn=config,dc=mainserver,dc=pretendco,dc=com




Apple Training Series. Mac OS X System Administration Reference, Volume 1
Apple Training Series: Mac OS X System Administration Reference, Volume 1
ISBN: 032136984X
EAN: 2147483647
Year: 2005
Pages: 258
Authors: Schoun Regan

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net