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, and , these chapters are available only to ; see  for details.
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.
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 and—since some aspects of user management are easier if you mange groups of users—we’ll talk about how to .
The chapter concludes with a topic about how to, a procedure that a typical reader of this book won’t need to complete, but I’ve included it for completeness.
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 .
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  and make sure your DNS is set up correctly.
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.
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.
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.
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.
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.
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.
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 Settingsmenu. 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).
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!
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 ), 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.
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.
There are four places you can create users when running OS X Server in Mavericks: the Server app, Workgroup Manager (available as), 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.
Assuming the server is an Open Directory master, which it will be if you followed the steps above in, 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 plusbutton. Server asks for information about the new user (Figure 8).
Enter the account information, keeping these pointers in mind:
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.
With at least one local network user account created, you can manage it from within the Users pane as follows:
Notice that the gearpop-up menu has more account-related commands, such as Edit Mail Options, which I cover in Chapter 8, “Mail Services”)
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, earlier in this chapter).
To create a new group, click Groups in the Accounts section of the Server app sidebar.
In the Groups pane (Figure 10), choose Local Network Groups from the pop-up menu, and click the plusbutton.
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.
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.
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 gearpop-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:
In the edit group dialog, add members, keywords, and notes:
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:
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:
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.
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:
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.
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: Chapter 12 |  |  |  |  |  |  |  |  |  |  |  |  |  |