This article originally appeared in TidBITS on 2014-06-09 at 5:08 p.m.
The permanent URL for this article is:
Include images: Off

Take Control of OS X Server, Chapter 4: Directory Services

by Charles Edge

This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from Chapter 1: Introducing OS X Server [1], and Chapter 2: Choosing Server Hardware [2], these chapters are available only to TidBITS members [3]; see “Take Control of OS X Server” Streaming in TidBITS [4] for details.

Directory Services

A directory service is a shared repository of usernames, passwords, network resources, and other information. Mac network clients (and by “client,” I mean a computer) use a directory service to look up various things.

For the typical reader of this book, a directory service is where you’ll create and store user accounts for services including file sharing, calendar, and contacts.

The directory service is at the heart of many large networks. But a directory service is really just a database that lives on a server, along with some underlying technologies that Apple collectively refers to as Open Directory. Some directory services can have roles that are broken out amongst a number of servers, but for the purposes of this book, I’ll assume you need only one directory server (or at most two) to keep this chapter from expanding into a book of its own.

Note: Because we’re focusing on just one or two servers in a small network, we’re going to stay near the surface of the Open Directory ocean. Near the surface, there’s plenty of light, everything is pretty simple, and most things work well. As you dive deeper into Open Directory, everything becomes murkier, what you need to do becomes significantly harder, and monsters lurk in the depths. Get dragged down too far, and you can spend huge amounts of time getting everything configured and working properly.

As you work through this chapter, you’ll set up your Open Directory master and (optionally) create a replica. After that, you can add users to your directory service in Work with Users [5] and—since some aspects of user management are easier if you mange groups of users—we’ll talk about how to Work with Groups [6].

The chapter concludes with a topic about how to Bind Clients [7], a procedure that a typical reader of this book won’t need to complete, but I’ve included it for completeness.

Set Up the Open Directory Master

If you have only one server, it will be an Open Directory master. Should you happen to you have two servers, one will be the Open Directory master and the other a replica. (And, if you have even more servers, the rest of them will be clients to the directory service and so able to use the usernames and passwords entered in the master.)

Before setting up your Open Directory master, verify that the DNS and hostnames are configured properly. To do this, run the changeip command with the -checkhostname option to verify that the IP, DNS, and host name all match, as was covered in Verify That the IP and Hostname Match [8].

If—and only if!—you get The names match. There is nothing to change. can you move on to setting up the Open Directory service. Otherwise, go back to Set Up Host Names [9] and make sure your DNS is set up correctly.

Run the Open Directory Assistant

To set up the Open Directory master, click Open Directory in the Advanced section of the Server app’s sidebar (if necessary, hover over Advanced and then click Show). From here, click the ON button in the upper right of the Open Directory pane, as seen in Figure 1.

[image link]

Figure 1: Turn on the Open Directory Service.

For the purposes of this example, we’re setting up an entirely new Open Directory environment. On the Configure Network Users and Groups screen (Figure 2), select “Create a new Open Directory domain” and click the Next button.

[image link]

Figure 2: Select “Create a new Open Directory domain” to start from scratch.

On the Directory Administrator screen (Figure 3), it’s not necessary to change the default wording in the Name and Account Name fields, although it’s never a bad idea to use something less generic. The Account Name is the username for the directory administrator account. Once you’ve handled the name fields and entered the password twice (and made sure it’s recorded somewhere secure, like 1Password or Keychain Access), click Next.

Note: You could use this administrative Open Directory account on a daily basis at this point. However, I recommend that you use this account only to manage Open Directory. You should manage the server Mac with a local administrator account (such as the one created when you installed Mavericks) and use any services offered by the server from a local network user account that you create for yourself (I explain how later in this chapter). I’ve learned the hard way that this is important advice—you don’t want to accidentally click something and damage the server (which I’ve done many times!).

[image link]

Figure 3: Enter your desired username and password for the Directory Administrator account.

Now, we’re going to configure the Secure Sockets Layer (SSL) information, which requires creating an SSL certificate. The SSL certificate is used to encrypt and therefore secure communication between client computers and the server. Luckily, this isn’t difficult, since the Server app merely asks you a few questions and creates and installs the proper certificate for you.

Self-signed and Third-party SSL Certificates

There are two types of certificates, self-signed certificates, which are what the Server app creates for you, and third-party certificates, which cost upward of $100 per year and are verified by an external certificate authority, or CA.

For home and small office servers whose services are accessible only within a local network, a self-signed certificate is sufficient. More important, if you’re using a fake domain name (as I recommend in Set Up Host Names [10] in Chapter 3), you can only use a self-signed certificate, since you can’t get a third-party certificate for a name like mavericks.pretendco.lan.

If you do have a real domain name and need a third-party certificate, follow Apple’s instructions [11] for creating a certificate signing request, and then work with a CA like Comodo [12] to create and import a certificate. These steps are beyond the scope of this book; they’re highly specific and involved, and it’s easy to make mistakes. If you do venture down this path and have trouble, I recommend calling AppleCare [13] for assistance (OS X Server purchased from the Mac App Store comes with 90 days of unlimited phone support).

On the Organization Information screen, enter a name for the organization in the Organization Name field and a valid email address to be used in the SSL certificate in the Admin Email Address field, as shown in Figure 4. These names are displayed to users if they view the certificate, so make sure they are descriptive enough so as not to confuse people who are accepting the certificate. Click Next.

[image link]

Figure 4: Create the Open Directory certificate.

At the Confirm Settings screen, make sure these settings are okay (click Back if you want to change anything), and then click the Set Up button to let slapconfig (the command that runs the Open Directory setup in the background) do its thing.

When the Open Directory master has been configured, there’s no need to reboot or anything, and the indicator status light for the Open Directory service should appear as in Figure 5.

[image link]

Figure 5: The Open Directory setup is complete. Notice the new server, highlighted in the Servers list.

Configure Password Policies

Once the Open Directory master setup is complete, the server appears in the Servers list. Select it and then choose Edit Global Password Policy from the Settings [image link] menu. This is where you can configure the parameters that passwords must meet in order to be usable on the system.

Check each box that corresponds with your requirements, and then click OK ( Figure 6).

[image link]

Figure 6: Set up your Open Directory global password policy.

Some policies disable accounts or force password changes on scheduled intervals, or make passwords meet certain criteria. Take a moment to consider your global password policy so that you set the right balance between security and inconvenience for your end users. A secure environment is important, but if you make your password policy overly complex, your end users will start recording all their passwords on sticky notes attached to their monitors, and that’s even less secure!

Set Up the Open Directory Replica

Previously, we set up the Open Directory master with SSL enabled. As you work further in this book, you’ll see how numerous services rely on the Open Directory master being available. But what if it isn’t? If you have only a single server, it probably doesn’t matter, since if Open Directory isn’t available, the entire server is probably offline and you have bigger problems.

But if you’re working on a larger network, where there are network services beyond those on the computer running the Open Directory master, you don’t want your users to be twiddling their thumbs while you try to bring the Open Directory master back on line. The solution is an Open Directory replica, which keeps a copy of the Open Directory database available for users even when the master goes offline.

So, skip this section if you have only a single server, but if you have two servers, on the secondary server you want to be your Open Directory replica, launch the Server app, select the Open Directory service and click the ON button to start the configuration process.

When prompted, select “Join an existing Open Directory domain as a replica” and click the Next button.

Now, enter the HostName of the Open Directory master), the directory admin username (the diradmin or custom username that you entered in the Account Name field when you configured the Open Directory master in Run the Open Directory Assistant [14]), and the directory admin password. Click the Next button to set up the services.

At the Confirm settings screen, verify that these settings are okay (click Back if you want to change anything), and then click the Set Up button.

Provided there are no issues with your configuration, the Server app finishes setting up the replica. On both the replica and the master computer, look in the Server app and confirm that the replica server is listed under the master.

Work with Users

Once you’ve set up your directory server, it’s time to create local network users, and after that, groups. Calendar, Profile Manager, and certain other services require local network users.

Types of Users

A directory domain is a repository of account data, which can include two types of users:

  • Local users: These are users local to the Mac running OS X Server, including the user you created when installing Mavericks and any others created in the Users & Groups system preference pane. If, as described in this chapter, you are running an Open Directory master, you should use local accounts only to manage local tasks, such as backups. (If you are not running Open Directory, then all users are local.)
  • Local network users: These users, created in the Server app, can access network services on the server. If you set them up as I recommend, they won’t have home folders on the server Mac itself. When you view users on an Open Directory master, most will be local network users.

When I set up a server Mac, I typically end up with these accounts:

  • Local administrator: This is the account that Mavericks created for me when I installed the operating system. If I want to perform administrative tasks on the server Mac, such as configuring Time Machine backups, I log in with this administrator account.
  • Local network user: For everyday use of services (accessing calendars, files, contacts, and so on) provided by the server, I log in with an Open Directory non-administrative account that I set up for myself. Most users will use an account of this type.
  • Open Directory administrator: This is the account that Open Directory created by default as I set it up. If I want to perform administrative tasks within Open Directory (e.g. add users, reset passwords, etc) then I log in to the Server app with the Open Directory administrator account. This way I don’t ever accidentally click on something and break my server as part of everyday use.

There are four places you can create users when running OS X Server in Mavericks: the Server app, Workgroup Manager (available as a separate download [15]), the Users & Groups preference pane, and the command line. I focus on creating users in the Server app because users created via any of the other approaches won’t have access to network services by default, since the other tools don’t create the access controls required for most services.

To add and manage local network users in the Server app, click Users, in the sidebar, under Accounts. As you can see in Figure 7, the list of users appears, based on the directory domain(s) being browsed. From the pop-up menu, choose Local Network Users. (The pop-up menu also lets you display only local users, or both.) If you haven’t yet created any users (you aren’t skipping ahead, right?), the list will be blank, but we’ll rectify that next.

[image link]

Figure 7: In this screenshot of the Directory Domain browser, you can see our Local Network Users list.

Add a User

Assuming the server is an Open Directory master, which it will be if you followed the steps above in Set Up the Open Directory Master [16], any accounts you create will be local network users, stored in Open Directory. You don’t have to set up all your users now; it’s fine to come back later to add more.

To create a new local network user: click the plus [image link] button. Server asks for information about the new user (Figure 8).

[image link]

Figure 8: Enter the user’s account details.

Enter the account information, keeping these pointers in mind:

  • Full Name: Usually this is the first and last name of the user. It’s easy to come back later and change this name.
  • Account Name: This name, known technically as the short name, is nearly impossible to change later, so you want to get it right here. It is a short representation of the full name with no spaces or special characters. Each account on the server Mac must have a unique short name. When I mistype a short name, instead of changing it later, I delete the account and recreate it. This does erase all the user data for that account, so if you do this, make sure to first back up calendars, contacts, and other data that user may have!
  • Email Address: This is the email address that will be alerted if the account goes over quota or receives calendar invitations. If you’re planning to run the Mail service, this address will also be used for email hosted on the server.
  • Password: The user will use this password to access services on the server.
  • Verify: Type the same password a second time to make sure you got it right the first time.
  • Allow user to administer this server: Select this checkbox to grant the user administrative access to the server. (See Where to Use the Server App [17], just after this list.)
  • Home Folder: Choose None - Services Only unless you are absolutely certain you want local home folders, which I don’t recommend.

Home Folder Choices

There are three choices for the Home Folder pop-up menu, but they require some explanation, since not all will be available if you’re reading this book in order, and I don’t recommend two of them.

  • None - Services Only: With this option chosen, the user will be able to access services like file sharing, calendar, and contacts. However, the user will not be able to log in to a client Mac using these credentials, as with the other two options.
  • Local Only: If you were to choose this option, the user would get a local home folder on the server, and would be able to log in to the server as a normal local user. If the user logged in to a client Mac with the account’s credentials, a new, clean home folder would be created on the client Mac, but there would be no link between the home folder on the server and the one on the client Mac. This requires binding the client Mac to the server; see Bind Clients [18], at the end of this chapter. In most cases, there’s no reason to log in like this, since most users will already be logging in using normal accounts on client Macs.
  • Network home folder: For this option to be available, file sharing must be turned on (see Chapter 6, “File Sharing”), a shared folder must be set up, and the “Make available for home directories over” checkbox must be selected. In theory, if all this is true, and you’ve bound the client Mac to the server (see Bind Clients [19]), when you log in to a client Mac using this account’s credentials, the home folder would be copied from the server to the client Mac, and when you logged out, your changes would be copied back. It sounds cool, but in reality, there are significant performance and reliability problems that make this approach an increasingly bad idea in most environments today. Avoid it.
  • Limit Disk Usage To: This setting appears only if you choose Local Only from the Home Folder pop-up menu, which I don’t recommend. It’s where you define the amount of disk space an account can take up. If you’ve chosen None - Services only for Home Folder, this setting does not appear.
  • Keywords: This optional field provides a place where you can enter keywords that might help you identify users on a large network, such as a room number, building, or department.
  • Notes: Similarly, this optional field lets you record notes about the user that might be helpful in the future.

Tip: You can drag a photo onto the image shown in the New User screen, as I did in the above image, in order to give the user an avatar. Or click the image and choose Edit Picture to assign a built-in image.

Once the account details are set as you would like, click the Create button. The full name associated with the account appears in the list of available accounts.

Where to Use the Server App

One interesting fact about the Server app is that it can control services running on another Mac over your network. So, you could copy the Server app from the server Mac to the Mac you use for everyday tasks. Just make sure you selected “Allow user to administer this server” when creating the user you’re going to use for administration, and then enter that username and password when prompted by the Server app on the client Mac.

That said, I don’t recommend you do this. It works fine, but with one errant click on the wrong button on Server’s login window, the Server app can become a CPU and battery hog even when not running, making it a bit annoying to have on your personal Mac. Instead, stick with OS X’s built-in screen sharing, and run the Server app on the server itself.

Manage Users

With at least one local network user account created, you can manage it from within the Users pane as follows:

  • Edit the account information: Double-click the account in the list; you can change the user’s full name and email address, along with keywords and notes, but not the short name.
  • Reset the password: Select the account in the list and then choose Reset Password from the gear [image link] pop-up menu.
  • Give the user access to services: Select the account, and then choose Edit Access to Services from the gear pop-up menu. (Figure 9). Deselect each service that the user should not have access to. If the service isn’t running, there’s no reason to remove access.
[image link]

Figure 9: Choose which services the selected account should be able to access.

Tip: You can select multiple accounts at once and choose Edit Access to Services to disable services for many users en masse. However, if you have a lot of users, you may want to group them first and then enable (or disable) services on a group by group basis.

  • Add the user to a group: I talk more about this option next, in Work with Groups [20].
  • Disable the account without deleting it: Double-click the account and then deselect the “log in” checkbox. This disables the account from being able to log in to the server but leaves the account in place so you can reactivate it later if needed. For example, if a temporary employee is leaving, you could leave the account dormant in case the employee is rehired.
  • Delete the account entirely: Select the account and click the minus [image link] button.

Tip: If you have give a user a local home folder, deleting the account won’t remove the folder in the Finder; you’ll have to do that manually.

Notice that the gear [image link] pop-up menu has more account-related commands, such as Edit Mail Options, which I cover in Chapter 8, “Mail Services”)

Note: The gear menu also enables you to create a template from a user, and once that’s done, edit the template. This is useful if you’re creating numerous accounts that should have the same access settings, rather than having to configure each one manually in exactly the same way.

Work with Groups

Although you can edit service access for multiple users at once, it’s easier to control access to services by adding users to groups and then giving appropriate access to the group. That way, for instance, you could have a Travelers group whose members are granted access to your VPN service and Temps group whose members you don’t trust to access your network via the VPN.

As with users, it is possible to have both local groups and local network groups, with much the same caveats (local groups are relevant only to the Mac itself; local network groups are what you create to control service access for local network users; see Types of Users [21], earlier in this chapter).

Add a Group

To create a new group, click Groups in the Accounts section of the Server app sidebar.

Note: For the purposes of this discussion, ignore the Workgroup group that appears by default in the Groups pane.

In the Groups pane (Figure 10), choose Local Network Groups from the pop-up menu, and click the plus [image link] button.

[image link]

Figure 10: To add a local network group, open the Groups pane, choose Local Network Group, and then click the plus button.

In the New Group screen, provide a name for the group in the Full Name field. This can include spaces. Then enter a short name—which can’t have spaces—in the Group Name field (Figure 11). Click Create to create the group.

[image link]

Figure 11: When you create a group, the title at the top of the pane becomes the Full Name of the group.

Your new group appears in the Groups list. Even though your group is created, don’t stop now. Continue with the first set of steps for managing your group, next.

Manage Groups

Group management happens in the Groups pane, so if you aren’t already there, select Groups in the left sidebar of the Server app. To manage a group, select it from the Groups list and then click the gear [image link] pop-up menu below the list of accounts. From that pop-up menu, you can edit the group, edit its access to network services, create a template from it (if you plan to create many groups), and edit templates.

In particular, take note of these important options, which you may want to set up immediately after adding a new group:

  1. Double-click the group name. or select it and choose Edit Group from the gear [image link] pop-upmenu (Figure 12).
    [image link]

    Figure 12: When you edit a group, you can specify more details than you can on the group creation screen.

    In the edit group dialog, add members, keywords, and notes:

    • To add a member, click the plus [image link] button and type the username. (To remove a member, select the account name and click the minus [image link] button.)
    • Put a few terms in the Keywords field. If you have many groups, typing a few keywords here now might help you find the group later.
    • For documentation purposes, even if this is a personal server, leave yourself a few notes about why you created the group, and what its purpose is.
  2. Once you’ve made your changes, click OK to save them.
  3. Select the group, click the gear [image link] pop-up menu, and choose Access to Services. Now you can turn on or off access to various services for all accounts in the group. If you aren’t sure which services you want to enable or disable, that’s okay—you can come back here any time. Click OK.

You can also configure the following options for a group, but don’t mess with anything here just yet, since I cover these options in later chapters:

  • Give this group a shared folder: Select this box to create a shared directory for the group, or a group with an ACL (access control list) that grants all group members access. Read more about this in Chapter 6, “File Sharing.”
  • Make group members Messages buddies: Selecting this box adds each group member to the other members’ buddy lists in the Messages client. I cover this in Chapter 7, in “Configure the Messages Service.”
  • Enable group mailing list: Select this box to create an email list where all members receive email messages to an address based on the short name of the group. I’ll explain briefly how to work with the group mailing list in Chapter 8, “Mail Services.” However, I don’t recommend this feature; instead, I suggest that you consider a third-party service, such as MailChimp [22].
  • Create Group Wiki: Click the button to open the interface for creating a wiki for the group. This option is disabled if you haven’t yet enabled the Wiki service. To do so, see Configure Wiki Services [23] in Chapter 10.

Bind Clients

When you “bind a client,” you establish a connection between a computer and your Open Directory master. There are a few reasons to do this, and while there’s no real downside in doing it, binding isn’t necessary if you have no interest in the following features, which are primarily useful in very large networks:

  • Network-based login: As discussed in Home Folder Choices [24], it’s possible to use a local network user account’s credentials to log in to a client Mac, either creating a fresh home folder or using the one from the server. But since I don’t recommend network-based login, it’s not a reason to bind a client Mac.
  • Single sign-on: In a large network, with hundreds of users, single sign-on is huge, since it allows the user to log in using a local network account’s credentials and automatically be able to access multiple services, potentially on multiple servers. On a small network with a single server, a handful of services, and client Macs that are already set up with local users, it’s not worth the trouble.
  • Server-to-server authentication: Again, in that large network with multiple servers scenario, binding servers to Open Directory is essential to enable single sign-on. If you have only a single server, this use case falls away.
  • Policy management: Being able to configure client Macs from the server with policy information is again primarily of interest in large network scenarios, and binding is necessary for that. Policy management is important for two purposes, neither of which is likely to be useful for people reading this book:
    • Configure new clients: Policy management enables you to set the list of available printers, configure Dock location and contents, remove the capability of connecting to external volumes (for security reasons), and so on. That’s a big win when setting up numerous client Macs from scratch.
    • Update existing clients: Similarly, if you add a printer to your network, policy management lets you push the connection details for that printer to multiple client Macs, which is easier than configuring them all manually.

So, if you’re setting up only a single server for file sharing and a few other services and have relatively few client Macs on your network, you can skip binding, as it will only complicate the environment more than it likely needs to. That said, if you do need to bind client Macs, here’s what you need to know.

Tip: If you are setting up OS X Server for a production network at work, I suggest that you bind a test computer first, before those that are in production, or being used by users. If you don’t have a computer for testing, make a clone of yours with Carbon Copy Cloner or another tool on another drive, boot from the clone, and test with that to avoid messing up your Mac.

Note: The name—which you set in the Sharing pane of System Preferences—of any computer being bound to any directory service (including Microsoft’s Active Directory) should be less than 16 characters long and contain only letters, numbers, dashes, and underscores. Other characters in the name of a computer can cause the binding process to fail or be unstable. Additionally, try not to use names in the .local top-level domain (as in computerName.local) as they can also lead to unstable connections once bound.

Binding clients can be done in a few different ways. You can use a script, a profile, or the Users & Groups pane of System Preferences, or, if you’re dealing with a very large network, build binding into the imaging process. For the purpose of this example, we’ll use the System Preferences pane, since it’s the easiest to understand:

  1. On each client Mac, open the Users & Groups preference pane.
  2. Click Login Options.
  3. Click the lock in the lower left of the pane, providing an administrator username and password when prompted.
  4. Next to Network Account Server, click the Join button.
  5. In the dialog that slides down, select the desired server from the pop-up Server menu if the server is automatically discovered via Bonjour, or, if not, enter the name of the Open Directory master (the HostName you set back in Set Up Host Names [25]). (Figure 13)
    [image link]

    Figure 13: Connect to Open Directory by choosing the server.

  6. Assuming you’re using a self-signed certificate (which it is, if you created it using the steps above in Run the Open Directory Assistant [26]), click the Trust button when prompted.
  7. If you’re alerted that the server doesn’t provide a secure SSL connection, click Continue. That happens with self-signed certificates, and it is nothing to be concerned about.

    In some cases, the binding dialog expands to show more options when you enter the host name, although for the purposes of this chapter we’ll leave those as the default, as seen in Figure 14. If your dialog didn’t expand, don’t worry about it.

    [image link]

    Figure 14: In this screenshot, you can see the basic Open Directory binding options.

  8. Click OK to accept the certificate (again assuming that it’s self-signed).

The system finishes binding and a new checkbox appears in the Login Options view, “Allow network users to log in at login window.” Checking this box allows credentials configured on the server to be entered on clients when logging in; a new Other button appears on the Login screen in the list of users, though it may take 5–10 seconds to show up.

Read More: About [27] | Chapter 1 [28] | Chapter 2 [29] | Chapter 3 [30] | Chapter 4 [31] | Chapter 5 [32] | Chapter 6 [33] | Chapter 7 [34] | Chapter 8 [35] | Chapter 9 [36] | Chapter 10 [37] | Chapter 11 [38] | Chapter 12 | Chapter 13 [39] | Chapter 14 [40]

[5]: #WorkwithUsers
[6]: #WorkwithGroups
[7]: #BindClients
[14]: #RuntheOpenDirectoryAssistant
[16]: #SetUptheOpenDirectoryMaster
[17]: #WheretoUsetheServerApp
[18]: #BindClients
[19]: #BindClients
[20]: #WorkwithGroups
[21]: #TypesofUsers
[23]: chap10.xhtml#ConfigureWikiServices
[24]: #HomeFolderChoices
[26]: #RuntheOpenDirectoryAssistant