Binding a Mac OS X 10.4 computer to the Stanford University LDAP directory

The purpose of this document is to give instructions on how to bind a Mac to the Stanford University LDAP directory. There are tips and considerations at the end of this document.

Why would you want to do that? And what does that mean?If a Mac is bound to the SU LDAP1, it means user account information is not on the local machine (what you get when you add a user through, say, System Preferences Accounts). Instead, the computer consults the university online directory instead, called the SU LDAP.

In its default configuration, anyone with a valid SUNet ID can log in and use that computer. In one-to-one deployments, the user gets a unique, private, secure home directory (local to that computer) created at login. With public terminals (like clusters and computer lab machines), the user will typically have her home directory be her AFS space.

What are the benefits?1) Users need only to remember their SUNet username and password.

2) Admins don’t have to deal with “I forgot my password” helpdesk tickets.  Users can change their SUNet password on the web.

3) Users are significantly more vigilant about guarding their SUNet username and password than they are their departmental fileserver.

4) If the user leaves the university, their account is deactivated everywhere their SUNet ID is used.

5) Account passwords are not stored locally on a machine.2

6) A user’s UID within Stanford is universal, whereas their UID on a local NetInfo directory is relative. This doesn’t have immediate benefits, but may down the line.3

7) Single sign-on is made easy. In addition to being able to launch Kerberized apps (Oracle Calendar, Mail.app or Eudora, etc) without authenticating again, users can also use HTTP Request. This will allows for single sign-on for most web apps.

8) With additional server-side configuration, users will also be able to browse to and connect to fileservers without additional authentication (or, portentially, have workgroup fileservers automatically mount at login).

1 “Bound” here means “consults” or “associated.” 2 Unless mobile accounts have been enabled.3 Note that computers authenticating to Active Directory will get an alternative UID.

9) Admins need worry a little less about password length or quality, since the online SUNet tools help to ensure this.

Are there any benefits to binding a Mac OS X Server to SU LDAP?Mac users connect to the server using their SUNet ID. Admins don’t have to create discrete accounts for the server—adding or deleting them as staffing changes. They can just use the LDAP accounts—while still assigning file share permissions accordingly.

What are the differences between binding a Mac to the SU LDAP and binding a Mac to the SU Active Directory?

Although similar in purpose, there are significant differences between the two directories.

Unlike “adding a computer to the domain” we are not modifying the directory by adding a computer object (as we do with Active Directory). We’re merely pointing the Mac to SU LDAP for the purposes of authentication. While it’s possible to add computer objects into LDAP, that’s not something that’s implemented here on campus.

Also, there are no Group Policies per se in LDAP. “Policies” in Windows-speak is somewhat analogous to “MCX” in Mac-speak

When a Mac looks up information in the SU LDAP, it does so with the identity and credentials of the user; when a Mac looks up information in the SU AD, however, it does so with the identity and credentials of the computer. Computers don’t have very many rights in the SU AD.

Group membership is not fully realized or leveraged in SU LDAP, though it is in SU AD.

Mac OS X requires each user who logs into the system to be assigned a unique integer. AD does not support this, so the AD plug-in for Directory Access will derive an unique integer based on an algorithm performed on a unique attribute in the user’s record. In SU LDAP, the client UID is mapped natively.4

4 This UID discrepancy has implications. A Mac user whose computer has been configured to authenticate against a different directory will be recognized as a different user altogether when she or he logs in.

Configure Your Mac

Launch /Applications/Utilities/Directory Access.app. Click on the lock if you need to first authenticate to make changes.

Install MacLeland (or the Stanford Desktop Tools) first, if you haven’t already. See http://macleland.stanford.edu/ for more information.

It’s also critical that your computer’s internal clock is not off by five minutes. Be sure to set your clock to use a timeserver, done in System Preferences Date & Time Set date and time automatically.

There are three tabs: Service, Authentication and Contacts. With the Services tab selected, select LDAPv3 and click “Configure…”. A sheet will roll out. Make sure that “Add DHCP-supplied LDAP servers to automatic search policies” is not checked. Expand the sheet to show options.

Click “New…” to add a new configuration. Click “Manual” (because we use a unique LDAP schema).

Enter a name for the configuration (something like “Stanford LDAP” will do). Enter “ldap.stanford.edu” for the server name. Select “Custom” from the pull-down menu. You’ll be presented with a new dialogue box where you will be entering record types and attributes that match our directory.

Select the preexisting “Default Attribute Types” record. Click the Add… button. From the next sheet, select “RecordName” and click OK. You’ve now added the attribute; on the left side of this dialogue box, click “Add…” and type “cn”. See the screen shot below.

Figure 1: Above, the “Default Attribute Type” is an attribute type; “RecordName” is an attribute and it maps to the value “cn”.

Let’s add one more record type. Select the box on the left side and click “Add…”, make sure the “Record Types” radio button is selected, and add “Users”.

Now, select the “Users” record type in the “Search & Mappings” tab and map it to “posixAccount”, and type in the “Search base” so that it’s exactly “cn=accounts,dc=stanford,dc=edu”. It should look like this screenshot.

Figure 2

There are six attributes to add with the “Users” record type. Select “Users” and click “Add…”, but make sure the radio button selected is “Attribute Types” this time. Add the following:

RealNameUniqueIDPrimaryGroupIDNFSHomeDirectoryUserShellRecordName

After you’ve added those attributes, map them to these values:

RealName cnUniqueID uidNumberPrimaryGroupID gidNumberNFSHomeDirectory #/Users/$uid$ 5

UserShell loginShell 6

RecordName uid

It should look something like the screenshot below.

5 This will put a home directory on the local hard drive under /Users with the SUNet ID of the person logging in. If you were using AFS for home directories, you’d enter the default “homeDirectory” value instead.6 You can enter a static value like “#/bin/bash” if you prefer that over the directory’s shell choice of tsch.

Figure 3

Next, while you still have this dialogue box open, select the Connection tab. Change the “Re-bind attempted in” value to 15 seconds and the “Connection idles out in” value to 1.7 It should look something like this screen shot.

Figure 4

7 We’re not too sure about this setting. Another administrator thinks that a zero value should make the client attach and detach immediately, though the interface is confusing. The tool tip says that a zero value makes for a persistent connection. I compromise and chose 1 for one minute.

The last tab, Security, should be blank.8

Figure 5

8 If you enable the Security Policy options here, you’ll get system logs explicitly telling you, “Required policies not supported”. Since the login process uses Kerberos v5, it’s reasonably secure already.

Now that you have configured all the right variables and options for “Stanford LDAP”, go ahead and save that configuration. This should bring you back to the main Directory Access dialogue box that lists services.

Check LDAPv3 from that list and click “Apply”. Click the “Authentication” tab and choose “Custom path” from the pull-down menu, then the “Add..” button. Choose the Stanford LDAP directory from the pull-down sheet. Click “Apply”. Your window should look like this screenshot below.

Figure 6

Do the same thing for Contacts.

TestingIt should “just work” now. To do a test, launch /Applications/Utilites/Terminal.app and enter id nbfa at the prompt9. It should show you my UID, GID, groups. In this case on my demonstration machine, it shows I’m part of the 37 group, plus the CRC group (which has a GID of 1025). See below.

Figure 7

If you get “id: nbfa: no such user” try rebooting your machine and trying again. If you still don’t get a reliable read-out, review the above settings.

9 You can try your SUNet ID, of course, but if the workstation you’re using now may already have an account in the local NetInfo directory with your SUNet ID, it will show you the information from your local NetInfo directory.

Tips and considerations

Here are some scenarios you may encounter, along with some suggestions.

Are you switching a user’s Mac to now consult the SU LDAP? And do you want him or her to have access to their old home directory?

If users have logged into their machine prior to binding the Mac to the SU LDAP (that is, they have been logging is with the username of “bob” while their SUNet ID is “bjones”), then they will have a new, additional home directory on their Mac, /Users/bjones. You’ll have to copy the files from one home directory to another, then change ownership of those files. One easy way to do this is to use /Applications/Utilities/Terminal, use the cp (or ditto) command, then the chown command.

Are you binding a previously used Mac to LDAP when the old username is the same as their SUNet ID?

If they have been using a username that happens to be the same as their SUNet ID, the local username and password combination always takes precedence. If they log in using their SUNet ID and SUNet password, they will have their old home directory but no access to the files (because technically, they don’t own those files). You will need to reconcile the accounts while preserving their home directory. Delete the local account using /Applications/Utilities/NetInfo Manager and use Terminal to execute the chown command.

Are you binding a laptop to SU LDAP; do you need offline logins? Like, for a laptop user?

Have the user log into their Mac. Open System Preferences Accounts and make their account a “mobile account.” This will cache their credentials so they can use their laptop offline, independent of the LDAP directory (for offline use, for example). An already existing administrator account needs to be used here. Test their ability to log in without network connectivity by turning off Airport and unplugging the network cable.

Did you enable SSH (remote login)?If you allow remote logins (that is, by turning on SSH access) in System Preferences Sharing, you must take extra security precautions. Hand edit /etc/sshd_config to restrict access, otherwise, anyone with a valid SUNet ID and password can SSH in (increasing your risk exposure exponentially.10 To edit /etc/sshd_config, use a text editor like vi, pico or nano from the Terminal and add the AllowUsers directive, along with the shortname of the permitted account (or accounts separated by spaces). For example, add the line “AllowUsers bjones its” to permit

10 Alternatively, you can (and probably should) use SACLs (service access control lists) if you are using Mac OS X Server.

the bjones and its accounts to log in via SSH (and conversely and implicitly, deny everyone else).

You can continue to leave Apple Remote Access on, restricting access to the its account through that interface.