OS X Server is an app that runs on a standard Mac. This app is available on the App store and very straight forward to setup. The Server app contains a faux root of the former OS X Server operating system within the app bundle, which contains a number of binaries that should be secured for those that use an OS X Server. It may look similar, but the Server app brings some very different functionality to an OS X Client,. The differences lie in the fact that Mac OS X Server, like most other servers, should be used exclusively to share data. That data is shared across a variety of protocols, according to the type of data being shared. Therefore, it naturally follows that you will need to take additional precautions to properly secure OS X Server on a per-service basis. In this chapter, we’ll primarily focus on the services that are specific to the Server app and how to secure them, paying attention to where the best practices differ from a standard Mac client.

A number of services are included with OS X Server. We will focus on security as it pertains to the most heavily used services: directory services, file sharing, web server services, Internet sharing, user account management, Internet security, and the Messages Server. We’ll start with common security themes that persist across each service. Because many of the other services are dependent on directory services, we’ll then move on to securing Open Directory, an innovation in OS X Server that distinguishes it from OS X Client. Finally, we’ll take a look at each service and the special security precautions that should be taken with each.

Limiting Access to Services

A key aspect of OS X Server is its ability to determine which users can access specific services, as well as its ability to delegate management control over each service to the appropriate users. The granularity of control in OS X Server is much finer than a client not running the Server app. When securing file sharing, for example, you can control which share points each user can access per protocol. And you can create a support user who has the capability of starting and stopping the service while removing their ability to access the data shared by that service. Or, if you’d rather not make a configuration change that restricts a specific user from mounting a share point, you can also set a control that denies access to certain services, or protocols, for specific users.

Service access control lists (SACLs ) allow administrators to limit access to services for certain users. To configure SACLs, open the Server app, and click on Users or Groups in the sidebar. Open one of the users and then click on the cog-wheel icon at the bottom of the screen. Click Edit Access to Services… to bring up a list of services. Here, uncheck the box for each service that you do not want to provide access to this specific user or group, as shown in Figure 16-1.

You can also use the configuration options for each service to configure access to resources. To do so, click on the service that you would like to restrict access to and then click on the Edit Permissions… button if available. Then, click on on the “only some users” option in the “Allow connections from” field. Click on the plus sign (+) to add a user and provide a name for a user or group in the field, as seen in Figure 16-2. Once added, click on OK to edit each of the groups.

Each SACL is a group. By editing each SACL, you will edit the group membership for that group. For example, there’s a group called _jabber. Members of that group get access to the Messages service. You can also edit SACLs by manually adding users to groups. You can use the dsmemberutil command to do so, or show hidden users in the Server app. To show these accounts, click on the View menu and select Show System Users, as seen in Figure 16-3.

Once you can see System Accounts, you’ll be able to add and remove members as needed, in order to edit access to services.

The Root User

When you setup your first user, the local administrative user’s password (such as admin or mycompany admin) becomes the password of the root user. Keep in mind that any subsequent password changes to that first administrative account are not replicated when you change its password. In practice, this often leads to a stale password for root if left enabled; in other words, the password does not have any policies applied to it, and can provide an entry point for a potential hack. This is one strong argument for leaving the root user disabled on OS X Server and enabling it only when it’s needed. To disable the root user, use the following command:

dsenableroot -d

Foundations of a Directory Service

One of the most substantial aspects of OS X Server and its impact on a OS X-based network is the ability to run directory services. Open Directory, Apple’s native directory service technology, is built on open standards such as OpenLDAP and Kerberos. Open Directory gives administrators the ability to centralize usernames and passwords for an environment, which increases security. But a directory service also allows for the ability to deploy policies to workstations over the network in a somewhat automated fashion. Using directory services, it becomes possible to lock down client computers with the security settings you want, to enforce password policies to keep users from having simple passwords, and to limit the frequency that passwords are required on the network, also greatly increasing the overall security of your environment.

While we will focus on Open Directory throughout most of our discussions about directory services, it is worth noting that every OS X computer ships running a local directory service. This includes many of the components found in OS X Server, which allows for optimal security among Mac computers without a server. The local directory service can also be used to deploy profiles, or policies, without the use of a centralized server.

Defining LDAP

A directory service organizes information such as users, groups, and computers. The directory service is the interface to the directory and provides access to the data that is contained in that directory. In addition to Open Directory, popular directory services include OpenLDAP, Active Directory, and eDirectory. The one item that nearly all directory service implementations share is the Lightweight Directory Access Protocol (LDAP). LDAP provides access to a centralized data structure commonly used to track information such as usernames, computers, printers, and other items on a network by performing fast queries of the database. LDAP is a popular protocol and allows for a wide variety of uses.

Apple’s Open Directory technology runs LDAP on a Berkley Database (bdb) , which is made accessible via OpenLDAP for storing user account information. Slapd is the process behind Apple’s implementation of the OpenLDAP server. Slapd hosts access to the Berkeley Database where user account information, such as the user ID, is stored. When broken down to their bare components, these accounts are merely sets of attributes. Attributes are fields for a given object that constitute the makeup of a standard user, such as a username, a unique ID, a home directory path, and a password slot. Think of it this way: if you were to print out all of your attributes then the data set would resemble a spreadsheet.

Kerberos

Kerberos is a highly secure computer network authentication protocol developed at MIT that allows individuals, communicating over an insecure network, to prove their identity to one another in a secure manner.

Kerberos helps prevent eavesdropping to discover passwords or replay attacks (resending packets to obtain similar results from the original transmission) and ensures the integrity of the data. It provides mutual authentication much like a client-server model, where both the user and the service verify each other’s identity. Let’s dive into how Kerberos authenticates its users.

Kerberos Deconstructed

In OS X Server, Apple has modified Kerberos to handle communication with the Apple authd and accountsd services. All of these keep the passwords encrypted internally on the server, but Kerberos allows computers from the outside to communicate securely with the server.

Kerberos is divided into three components: the Kerberos key distribution server, the Kerberized service, and the Kerberos client. This trio communicates with a Kerberos network known as a realm. Kerberos guards your passwords and enables single sign-on to configured servers. Kerberos does this by identifying each user and server with a principal. A principal is then assigned a time-sensitive ticket or (TGT) to submit credentials over the network rather than sending passwords, establishing a session. Kerberos relies on a series of challenges and session keys that then allow a user or server a TGT assigned to the user’s principal. The TGT contains the time stamp used by the key distribution server to verify its authenticity.

The TGT is issued as an authentication token to gain access to additional service tickets during the TGT’s lifetime. This can be illustrated by logging in at the loginwindow as an Open Directory or Active Directory user, which authenticates you to the directory server and provides a TGT placed in a shared credentials cache. Other services such as file sharing will then provide single sign-on based on the TGT.

One of the most critical aspects of Kerberos configuration is time synchronization. If a client or server is more than five minutes apart from its Kerberos KDC server, then authentication will fail. This value is normally best synchronized using the Network Time Protocol (NTP). By default, the network time server is time.apple.com. You can use a custom network time server using the systemsetup command, along with the –setnetworktimeserver option followed by the name of a network time server, as follows

sudo systemsetup -setnetworktimeserver time.krypted.com

To then enable the network time service, use the systemsetup command along with the –setusingnetworktime option to on, as follows:

sudo systemsetup -setusingnetworktime on

Another important consideration for Kerberos is DNS. Prior to setting up an Open Directory master or replica, make sure that the server’s DNS is accurate in both forward and reverse DNS resolution. To do so, run the changeip command with the -checkhostname option, as follows:

changeip -checkhostname

Kerberos is frequently called the “keys to the kingdom,” on an OS X Server. An improperly configured Open Directory service can give way to those keys. If a Kerberos system is deployed on an OS X Server, it’s important to make sure the services on your Open Directory servers are properly patched and securely locked down. Let’s discuss the proper ways to do just that.

Configuring and Managing Open Directory

Because directory services give such a boost to the security of larger environments, we will spend the first part of this section discussing how to set up and bind to Open Directory. Once you have a solid Open Directory environment, we will then show you how to secure Open Directory, more than it is secured in the stock implementation of OS X Server, by disabling anonymous binding and implementing LDAP ACLs. Anonymous binding allows unauthenticated users to be able to enumerate your directory structure, whereas LDAP ACLs control what is visible to unauthenticated users and specified groups for authenticated users of the directory.

To start setting up Open Directory, open the Server app, and click the Open Directory service. Next, click on the ON button, shown in Figure 16-4.

You’ll then be prompted for how Network Users and Groups should be configured (see Figure 16-5). This is just another way of defining how Open Directory is setup. Here, you’ll have the choice of the following:

• Create a new Open Directory domain: This will setup a new Open Directory master and build a domain. The Open Directory master is automatically the first server setup in a domain and can be transferred to other servers in an emergency. Other Open Directory servers will be replicas to this server.
• Join an Existing Open Directory domain as a replica: Sets up a second, third, fourth, etc Open Directory server. Use this to balance the load between your servers.
• Restore Open Directory domain from an archive: If you have a backup, you can use this option to restore that backup into a new Open Directory master.

For the purposes of this example, we’ll go ahead and setup a new Open Directory domain, which is the default option. So click the Next button.

Next, provide credentials for the account that administers the Open Directory service. In Figure 16-6, we provide diradmin as a username and a password. This password should be very secure, as it can manage all of the shared accounts on the directory domain.

You’ll then be prompted for the Organization Name and Admin Email Address. These will be used in the SSL certificate for the server (see Figure 16-7).

At the Confirm Settings screen, confirm that the information provided in the previous screens matches the settings to use for setting up the Open Directory service (see Figure 16-8). Provided that the settings are correct, click Set Up.

The Open Directory setup is then complete (see Figure 16-9). You will see the name of your server in the Servers: field.

Once setup, you can create an Open Directory Replica, create accounts in Open Directory and each service created on the master and any replicas will also leverage the shared accounts. And these accounts will use Kerberos to authenticate, if the service is integrated with Kerberos.

Securing Open Directory Accounts by Enabling Password Policies

Password policies include server-side rules that limit the age and strength of passwords that can be used in your environment. Some password policies are available only globally (network-wide, while others are available on a per-user (or per-account) basis. To see global policies, open the Server app, and click on Users. To edit password policies, click on the cog wheel icon and then click on Edit Password Policy… (as seen in Figure 16-10).

Here,

Two types of global password policies exist: Disable Login controls when accounts are able to log in, and Passwords Must controls various requirements for a password to be allowed. We strongly recommend using as many of these as possible, because they provide a substantial amount of Open Directory security. However, keep in mind that the harder a password is for a user to remember, the more likely they are to write it down, so a certain amount of balance between complexity and ease of remembrance should be practiced here.

Let’s briefly discuss each:

• Disable Login: Allows logins to be disabled when the following criteria are met (per policy choice in Server Admin):
  • On specific date: Disables the account on a set date. Disabling accounts that could still be active can be an administrative burden, but it can be helpful for environments with a large number of temporary or freelance users.
  • After using it for: Disables new accounts after they have been active for a determined number of days.
  • After inactive for: Disables new accounts after they are dormant for a definable number of days. For most environments, a number between 7 and 30 is a suitable amount of inactivity for an account before it should be considered dead. This option helps for environments where the sheer number of accounts makes it difficult to keep track of account activity.
  • After user makes ___ failed attempts: Disables accounts after a definable number of failed attempts have occurred. For most environments, a number between 3 and 10 is a suitable number of failed attempts.
• Passwords Must: Allows password policies to be made, including the following:
  • Differ from account name: This option keeps the password from being identical to the username.
  • Contain at least a letter: This option forces an account to have at least one character from the alphabet (a to z) in the password. This enforces a policy that avoids passwords such as 1234.
  • Contain both uppercase and lowercase letters: This option requires at least one letter be uppercase and at least one letter be lowercase. Passwords are case sensitive.
  • Contain at least one numeric character: This option forces a password to have a number in it. An example of an allowable password would be 1paSsworD1. Passwords should typically have at least one lowercase letter, at least one uppercase letter, and at least one numeric character.
  • Contain a character that isn’t a letter or a number: This option forces a password to have a special character in it, such as a $, *, &, ^, !, or #.
  • Be reset on first login: This is a good option for new accounts or accounts that have had their passwords reset. This will keep administrators from knowing their users’ passwords (a policy that protects the administrator as well as the user). This will provide a certain level of comfort to users that the administrator is not snooping through their personal data. If you need access to an account, then you should be forced to reset a password to obtain it.
  • Contain at least: This option allows you to define the minimum length of a password in characters. The minimum length of a password is something debatable in any environment. For many, eight is a good number, but this is not as much a technical decision as it is a management decision.
  • Differ from last: This option allows you to force users to change their passwords to something different every time they change their password for as many times as you specify. Some administrator’s think 3 is enough, others say 18 is better. This is a decision that should be made on a management level in many cases.
  • Be reset every: This option allows you to force your users to change passwords at specific times and to define the number of days, weeks, or months that can transpire before a new password must be set. Passwords should also be changed as often as management will allow.

Securing LDAP by Preventing Anonymous Binding

In the previous section, we discussed the Require Clients to Bind to Directory option, but it is important to note that it affects only automatically configured clients. When this option is enabled, no changes are made to the running LDAP process (slapd). This option enables a preference key in the Open Directory client configuration container cn=config. This preference key will be enforced on Mac OS X clients that read this record (but not on most flavors of Linux or Unix). You can view this client configuration record using dscl:

dscl /LDAPv3/127.0.0.1/ -read Config/macosxodpolicy

When the setting is enabled, you will see the Binding Required key set to true when you review the output of dscl. However, because only Mac OS X clients read this configuration, they are the only LDAP clients that are actually “required” to bind. In other words, you are not restricting access to your LDAP server; you are in fact requiring binding only for clients that use the Max OS X LDAP plug-in. A standard LDAP browser from a rogue machine can anonymously bind even with this option enabled. If you wish to restrict access to only authenticated users, you must add the bind_anon option to the top of the OpenLDAP configuration file stored at /private/etc/openldap/slapd.conf.

Once connected, test that your binding is working by running the following command:

dscl localhost list /LDAPv3/127.0.0.1/Users.

The above dscl command should output a list of all users in your Open Directory domain. If it doesn’t then return to Directory Access, and make sure your binding username and password are correct. Once you have verified that your server can access your authenticated LDAP server, you can disable anonymous binding. To do so, edit the slapd configuration using your favorite text editor:

sudo nano /private/etc/openldap/slapd.conf

Add the following disallow bind_anon near the top of the file:

#
# See slapd.conf(5) for details on configuration options.
#
# This file should NOT be world readable.
#
disallow bind_anon

Next, save the configuration file, and restart the LDAP service by sending it a HUP signal using the following command:

sudo killall -HUP slapd

Securely Binding Clients to Open Directory

Once you have securely configured Open Directory on your servers, you can then bind the individual client workstations and non-directory services servers to Open Directory. At this point, all of the password policies are enforced, and many of the services’ communications will be Kerberized. So, why bind clients? If client workstations are not bound, then workstation policies will not be enforced. This includes pushing out Software Update Server settings, mobility and network home folder settings, and any of the managed preferences you may have defined (or will define). Also, usernames and passwords for workstations would not be centralized, which is a key to effectively managing and securing larger numbers of systems as is required in most enterprise environments.

You can distribute managed settings using profiles, Profile Manager, or third party patch management solutions. But being able to use a layered approach to deploying policies is an important aspect of enterprise systems administration.

To bind client workstations, you will need to authenticate as an administrator and use the Users & Groups System Preference pane on the client workstation. This is achieved in different ways on different versions of OS X. In 10.11, the Directory Utility is found in /System/Library/CoreServices/Applications. At the Users & Groups System Preference pane, click on Login Options and then click on Edit… in the Network Account Server field. Here, click the plus sign (+). Enter the name of the Open Directory master that you setup in the Server field, as you can see in Figure 16-11.

By default, you will then be prompted that “This server does not provide a secure (SSL) connection. Do you want to continue?” This means that the server does not secure communications with an SSL certificate. Click Continue to complete the binding process, as seen in Figure 16-12.

You can then choose the appropriate items that correspond with the setup of your Open Directory master using the Security Policy section of the Open Directory screen (see Figure 16-13), which is accessed using the Directory Utility and opening the connection to that server. You will want to match these as closely as possible on the client side.

Further Securing LDAP: Implementing Custom LDAP ACLs

An access control list for LDAP is a way to manage security for the OpenLDAP database. This is secure, because it enforces who can access and change things in the LDAP database. ACL policies are enforced at the server level. If ACLs are not configured, you can use LDAP data to access information about network layouts, users, and other information without authentication. One example of this methodology is to use the “Force Clients to Bind” option in the Open Directory policy settings in Server Admin. For most of these configurations, however, you will need to jump into the command line to create these ACLs.

To restrict bound users from viewing attributes of other users, add the following to your /etc/openldap/slapd.conf:

Access to dn=".*,dc=your dcname,dc=.com" attr=userPassword
    by self write
    by * auth
Access to dn=".*,dc=your dcname,dc=.com"
    by * read

To fully disable anonymous reads, use this series of commands:

Access to dn=".*,dc=your dcname,dc=.com"
    by dn"uid=nssldap,ou=people,dc=dcname,dc=com" read
    by * none

To restrict access to an LDAP database and allow users to change their own LDAP information in the shared address book, you’ll need to add an LDAP ACL to your slapd.conf file. To do this, add the following series of lines (we will go into further detail on LDAP ACLs later in this chapter):

access to
attrs=mail,sn,givenName,telephoneNumber,mobile,facsimileTelephoneNumber,street,
     postalAddress,postOfficeBox,postalCode,password
by self write

Creating Open Directory Users and Groups

Now that you have Open Directory set up securely, you might want to start building out the users and groups for your server. Later you can log into client systems using these accounts, but for now you’ll need to set up accounts securely so they can log into the server and access services. You can create users and groups in the LDAP database in OS X Server by using the Server app in the /Applications directory.

To create your first user, open the Server app from the Open Directory master, and click on Users (see Figure 16-14) and then click on the plus sign icon towards the bottom of the screen.

At the New User screen, provide the name of the user (see Figure 16-15), a password and optionally enter an email address, a quota for how much space on the server the user can access, choose a path for the home folder (network home directories are beyond the scope of this book), keywords to help you find the account in the future and any notes about the account that you choose to include. Then click on Create. The account is then created.

To create a new group, click the Groups option in the Server app and then click the plus sign (+), shown in Figure 16-16.

At the New Group screen, provide a name for the group. As you can see in Figure 16-17, you can also optionally provide information for email groups at this point, but that’s beyond the scope of this book. Click on Create.

Once created, double-click on the group (see Figure 16-18) and click on the plus sign (+) to add members to the group. When you are satisfied with all of the settings for the newly created account, click OK.

Securing Kerberos from the Command Line

Kerberos is a powerful application, and the options you have in the GUI are fairly limited. These settings can be accessed by opening the Ticket Viewer tool from Keychain Assistant. Here you can add and remove Kerberos tickets and view existing tickets. While a GUI tool is provided for Kerberos configuration, the command line gives you far more options to help further secure and test connectivity for it. The command-line tools available to further secure Kerberos include kinit, klist, kdestroy, and many others.

• kinit is used to establish and cache Kerberos connections. This is useful when troubleshooting Kerberos errors and looking to initiate Kerberos communications. Options for the kinit command include the following:
  • -F: Makes tickets nonforwardable
  • -f: Makes tickets forwardable
  • -P: Makes tickets nonproxyable
  • -v: Forces validation
  • -R: Renews tickets
• klist lists tickets. This is useful when looking to list all of the Kerberos service principals that a user is authorized to access. Options for klist include the following:
  • -4: Lists only Kerberos 4 tickets
  • -5: Lists only Kerberos 5 tickets
  • -A: Lists all tickets
  • -s: Runs silently
• kdestroy: Removes tickets from the cache. This is useful in troubleshooting Kerberos/KDC issues. The following is the option:
  • -a: Destroys all tickets

Some command-line applications available for the Kerberos server include the following:

• kdcsetup creates the first admin account.

Managed Preferences and Profiles

The ability to manage preferences is one of the most powerful aspects of directory services. In previous sections, we showed you how to set up Open Directory to have a centralized repository of usernames and passwords. You can further secure the server itself (and any other servers in our environment) using Kerberos and password policies. We have also shown you how to secure Open Directory accounts by enabling password policies and restricting the types of communications with the server. Now, we’ll cover enforcing policies, known as managed preferences, on client systems and user accounts. These policies are enforced using a technology known as Profiles. Profiles are property lists, which enforce policies.

Although you can perform these tasks on OS X Server in a distributed management environment using Profile Manager, we’ll focus on creating profiles using a tool called Apple Configurator to create the profiles. But keep in mind that while profiles are an excellent way to lock down computers, an actual Mobile Device Management (MDM) platform that supports OS X such as Profile Manager, the Casper Suite, FileWave MDM and others are better suited to the task much of the time, as you can send new profile changes over the air, using Apple’s Push Notification service (APNs) , which is the same technology that puts a red badge on apps in the dock when they have information waiting for them.

To get started with Apple Configurator, first install the tool from the Mac App Store, by opening the App Store, search for Apple Configurator and then clicking Install or Get (according to whether you have used the tool previously with the Apple ID you’re logged in as). Once installed, open Apple Configurator and click on New Profile from the File menu.

At the new profile screen, you will need to provide a name (in this case Passcode Policy) for the profile, as well as a unique identifier (in this case, com.krypted.passcodepolicy) as you can see in Figure 16-19. In the sidebar, you will see a list of options that can be configured. These policies, or manifests, include the following:

• General: The name of the policy as well as how the policy can be removed.
• Passcode: Specifies what passcodes are allowed. For example, whether you are required to use special characters and how long the passcode is.
• Restrictions: Disables certain features of the operating system, such as the iTunes Store.
• Global HTTP Proxy: Force devices to use a proxy server for HTTP traffic.
• Content Filter: Whitelist and blacklist Internet traffic.
• Wi-Fi: Configure Wi-Fi settings on devices, including 802.1x if you use a secured network.
• VPN: Setup connections to a VPN server.
• AirPrint: Install printers automatically.
• Mail: Automate the setup of IMAP and POP email accounts.
• Exchange ActiveSync: Automate the setup of Exchange, Kerio, and Google Apps accounts.
• Calendar: Automate the configuration of CalDAV calendars from a server.
• Contacts: Automate the configuration of CardDAV contacts from a server.
• Web Clips: Put links to websites into LaunchPad or as icons on an iOS device.
• Fonts: Install font files automatically.
• Certificates: Embed certificates in the profile (useful for 802.1x and self-signed certificates to talk to OS X and other types of web servers.

As you can tell from the types of profile settings, you have a lot of options you can automate the configuration of in OS X. Here, we’ll look at the Passcode Policy we discussed earlier. The example will configure a passcode of at least 8 characters, with at least one number, one letter, and one special character. The passcode will need to be changed every 30 days and the computer will automatically require the passcode after 5 minutes of inactivity.

Once you have created the profile, use the Save… option under the File menu. This will bring up a dialog (Figure 16-21) that allows you to place the profile wherever you’d like for distribution on clients.

Once saved, to install the profile simply open it on a Mac or iOS device and the profile will install. Once installed, you will see a new System Preference pane called Profiles, which you can use to remove the profile if needed.

The features available in a profile (and therefore via MCX) include access to removable hard drives, how the drives appear to users, login items, and Finder settings. However, local administrators of each machine can remove these profiles if they wish. A custom-managed preference can also be pushed to client systems and will enforce custom policies for third-party software or settings that Apple didn’t include in the default policies (primarily using property list options available to the defaults command).

If you would prefer to use managed preferences without profiles, then Workgroup Manager can be run on a Mac client. Workgroup Manager is how policies were managed up until 10.8 and official support was dropped after 10.9; however, you can still download the Workgroup Manager application from Apple. You cannot install the application on 10.10 or 10.11; however, you can extract the application bundle from the installation package using Pacifist and run the app. As you can see in Figure 16-22, the options are far more limited.

although you can manage custom preferences and manifsts, making managed preferences extensible and able to be managed using the directory service without MDM or custom profiles. However, managed preferences are no longer officially supported, so your mileage may vary.

Active Directory Integration

The Apple Active Directory service plug-in (AD-Plug-in) is an extension that Apple added to its DirectoryService API to enable OS X Client or OS X Server to bind to Active Directory, making interconnectivity between Apple’s Open Directory and Microsoft’s Active Directory easier. The Active Directory plug-in also supports Kerberos autoconfiguration for clients bound into Active Directory using DNS entries known as service (SRV) records. The Active Directory plug-in is configured using the Users & Group System Preference pane or by using the dsconfigad command line tool .

When you use the Active Directory plug-in to bind to Active Directory, you can set up Open Directory to connect to an Active Directory domain controller and have items accessible to Open Directory from Active Directory. Because you are connecting to an existing Active Directory service, you will more than likely have all the policies for binding and passwords in place in your current directory services environment. This architecture is known as a dual-directory environment .

Using the AD-Plugin

When binding to Active Directory, you will need to know the forest (top-level directory structure) and domain name to which you are trying to bind. All Windows Active Directory setups include at least one domain and one forest. A forest is the top level of any Active Directory infrastructure, and a domain is a logical segmentation of a forest. In a basic Active Directory setup (and most Active Directory environments are a basic setup), you will have only one domain in a forest and will often simply use the same name for the domain and the forest.

You would bind to Active Directory in much the same way that you would bind to Open Directory. Simply open the Users & Groups System Preference pane, click on Login Options and then click on the Edit… or Join… button (according to whether you’ve already use the directory services options in the past). Then click on the plus sign (+). At the dialog, provide the domain name in the Server: field (see Figure 16-23). When you tab out of the field, the domain information will be filled into the dialog and you will be able to click on the Bind button to complete the binding process.

Provided the system finds the server, click Bind and when prompted, provide credentials with the access to bind to a client in the provided fields. The client is then bound to the Active Directory domain.

Setting Up Network Homes with Active Directory Clients

A universal naming convention (UNC) is used for mapping drives within the Windows operating system, resulting in drives with lettered mappings (for example, the UNC path of \servershare can be mapped to the S: drive). These folder mappings can then be used to provide synchronized profiles, known as roaming profiles, for Windows clients. The Use UNC Path from Active Directory to Derive Network Home Location option in Directory Utility will allow you to use the Active Directory profile location as a UNC path for network home folders, the OS X equivalent to roaming profiles.

By default, a home directory is not created in this scenario; however, in a Windows environment, many organizations enable this home directory in order to ensure that the users’ data is stored on the server for the centralization of sharing, permissions, and auditing, as well as the decentralization of end user, or edge, backups. The option offered here will allow you to keep that structure in the Apple environment as well, preserving the Active Directory–planned file and folder structure for profiles to be preserved across platforms.

The “Network protocol to be used” option allows you to then choose one of two protocols from the drop-down menu: SMB or AFP. If you are using Windows servers, then you will likely select SMB, although if you have a solution such as Extreme Z-IP then you may be running AFP off of your Windows servers. This option determines how a home directory is mounted on the desktop. Server Message Block (SMB) is the default protocol used by Windows to communicate with other Windows computers when accessing shared resources (including printers, files, and serial ports). The SMB option here will allow Apple workstations to communicate with the Windows server using the native protocol that Windows uses to communicate with its files and directories. Unix variants can communicate in the same manner using Samba.

Using the AD-Plugin from the Command Line

It may become necessary to bind a Mac to Active Directory using the Active Directory plug-in from the command line . Perhaps you need to force the binding, you want to use a setting not available in the GUI, or you want to use the Active Directory plug-in in a server script. In these circumstances, you will need to turn to the command line. You’ll find the command dsconfigad to be very handy in performing these tasks. dsconfigad does not require root privileges to run for all of its options to be enabled and it can be used from the command line to force certain aspects of directory services to work even when the GUI will not bind clients as needed. These include the following:

• -enableSSO enables Kerberos authentication for services, such as AFP, by generating Kerberos principals (commonly used with the magic triangle, described in the next section).
• -ggid maps group ID information.
• -mobile automates the enabling of mobile accounts.
• -preferred enables the use of a preferred server.
• -localhome places the home folder on the local system rather than using a server shared home.
• -f forces the command to run (which is useful when forcing an unbind).
• -packetsign enables packet signing when communicating with domain controllers.
• -namespace enables the use of multiple domains within a forest.
• -packetencrypt enables encryption of data being transmitted between Active Directory and the client system.
• -passinterval configures the number of days between each iteration of the machine password within Active Directory.

These options become very helpful when scripting server bindings, as they allow for easy mass deployment and for the scripting of specific options to be pushed out to clients for binding. A script can also be told to run on the first access of an imaged system. This type of programmatic interfacing between Active Directory and Mac OS X clients and servers is one of the primary focuses of the Enterprise Mac Admin title, also from Apress.

Integrating Open Directory with Active Directory: Dual Directory

Setting up a dual directory involves the administrator building an Open Directory infrastructure, binding it to an Active Directory infrastructure and binding managed clients to both Active Directory and Open Directory. It is a common way in the Mac OS X Server community to get Mac management policies and still use centralized Active Directory-based directory services. This seemingly awkward setup results in Active Directory handling password authentication and Open Directory handling policy management, giving administrators a fairly simplistic way to manage their Mac systems, even within the confines of Active Directory. It is also possible to extend the Active Directory schema to include managed client preferences that can be used to provide the managed preferences covered earlier in this chapter on Mac workstations.

To set up a dual directory, first bind the server into Active Directory, as described in previous sections of this chapter. Then, promote your first server to an Open Directory master (also covered earlier). When you perform the promotion though, provided that you have already bound to Open Directory, you will have an option to leave the Active Directory binding and supplement the promotion with that existing Active Directory binding. Once the Open Directory server is a master and has been bound into Active Directory, it is possible to re-enable single sign-on functionality. To do this, run the following command:

dsconfigad -EnableSSO

Finally, bind Mac clients into both directory structures (using the same steps for both Open Directory and Active Directory that were mentioned previously). Active Directory will now process user credentials, and Open Directory will now process system policies for the Mac clients.

Web Server Security in OS X Server

The default web server in OS X is Apache. Apache is the most commonly used web server for the Unix, Linux, and Apple platforms and so is constantly being improved by security researchers and the open source community. By default, the Apache implementation in OS X is pretty secure. But there are things you can do to further secure the solution.

Using Realms

As discussed in Chapter 14, using htaccess files is the traditional way to password-protect a folder in Apache. However, htaccess can get rather complicated and, if not configured correctly, could cause more security headaches than it solves. Instead, if you have OS X Server, try using realms to limit access to specified directories. In OS X Server, when discussing the web server, a realm is a password-protected folder that uses a username and password in OS X to share files. Realms use WebDAV, a protocol designed with this exact purpose in mind, and a protocol which Apple has integrated with Kerberos in OS X Server. With WebDAV you will be using a password from your directory service rather than one stored in an htaccess or passwd.

To use realms, first create a site using a subdirectory you would like to password protect. Create the users and groups who will need to access the directory in the Users and Groups sections of the Server app. Then click on Websites in the sidebar. Here, you’ll see a list of all the sites hosted on this server. As seen in Figure 16-24, all servers will by default have two sites installed: Server Website and Server Website (SSL). These contain OS X Server’s built-in websites that are used to drive the Wiki and Profile Manager services. These cannot be removed, and are used for all traffic that doesn’t have a site otherwise defined.

Double-click on a site to see the site screen (Figure 16-25). Then click on the Who Can Access field to see the options for who can access the site. Here, you can select the following options:

• Anyone: Anonymous access is allowed on the site (a traditional web site).
• A specific group: Restrict access to this site to a group, which we created earlier in this chapter.
• Limit access by folder: Allows you to assign a group that can access each directory of the root directory of a site.

Click OK to save the settings.

SSL Certs on Web Servers

If you are doing any form of e-commerce, you should be using an SSL certificate (in fact we think that you should be using SSL for every service that has an option to do so). Many would argue that if you are trading any information with a client computer, such as a web form for submitting a support request, you should also be using SSL to encrypt the traffic. To enable HTTPS Access (SSL) on the web server, you will first need to create and install an SSL certificate (we will discuss implementing SSL on OS X Server later in the chapter). Then from the Server app, you will click the Websites service and click the plus (+) sign to add a new site.

Click in the Domain Name field (see Figure 16-26) and enter the appropriate domain name. By default, the port will be 80; enter 443 (the default port for SSL) in the Port field.

To assign the appropriate certificate, click on the SSL Security field and select the appropriate SSL certificate, and click Create to complete the setup.

File Sharing Security in OS X Server

File Sharing is more mature in OS X Server than on a standard client system, and thus has a more unified security context across services. For example, to view all the shared folders on a system, first open the Server app, and click the File Sharing button in the Services section of the sidebar. Here, you will see a list of the shares that are provided to other clients through the File Sharing service, along with who is allowed to access those shares, which is shown in Figure 16-27.

Double-click on a share (or click the plus sign to create a new share). Here, you will see a number of options displayed in Figure 16-28. These control different behaviors of that share and include the following options:

• iOS: Shares files to iPhone and iPad.
• SMB: Enables file shares over SMB (the native Windows file sharing client).
• AFP: Shares files over AFP, the native Mac file sharing client.
• WebDAV: Shares files over WebDAV, a typical option found within Apple apps such as Keynote.
• Guest Users: Allows guest (or unauthenticated users) to access a share.
• Only allow encrypted connections: Forces using SSL to connect.
• Home Directories over: Define the protocols to provide home directories over, if you are using Network or Portable Home Directories.

Once you have configured the options for each share point, click in the Permissions section to configure who can access the data shared by the share point. The Users & Groups floating window will appear when you click on the plus (+) sign. ACLs are listed above POSIX permissions, indicating their prioritization; when you drag a user or group into the Server Admin window from the floating users and group window, a blue line will appear indicating that dropping the object into the screen will apply it. Each user and group can then have custom permissions, roughly mirroring custom permissions available on Microsoft Windows servers.

Keeping a server secure also means not allowing users to fill up hard drive space on these shared volumes, which can not only reject other user’s ability to save files on the server, but also cause the server to become unstable or even unresponsive. This often means implementing quotas on the volumes. To implement quotas, click on each user and provide the desired quota. Only users with home folders on the volume can be configured for quotas using the Server app. Make sure to issue warnings to your users. They might not be accustomed to the idea of quotas and it may take some time for users to get used to them.

A Word About File Size

One of the challenges of life as a OS X Server administrator is that Mac users (who are often artists and designers) generally work with large files. In the most extreme cases, single files can be in the hundreds of gigabytes. Mac users accustomed to files normally 100MB in size are less likely to notice that they are sending files to each other that are too big for emailing. So, limit files, but make sure to communicate what’s appropriate with the users in order to reduce support calls. Explain when to use FTP or file sharing and when not to use it.

AFP

The AFP service in OS X Server is similar to that in on a standard client system. However, OS X Server has a myriad of other features that can be used to further secure the server that increase performance for the AFP service. As we covered AFP in OS X in Chapter 13, we will be picking up where Chapter 13 left off by investigating unique aspects of the AFP service in OS X Server.

Disable Masquerade As Any User

One of the more dangerous options in file sharing is the ability to masquerade your login as any other user. This means that you can log into a standard user account using any administrative password. While this setting was once in the Server Admin app, when that was retired, the setting became a command line only setting. While disabled by default, it’s worth checking to verify that it is still disabled. To do so, run the serveradmin command followed by the settings verb and then afp: afp:specialAdminPrivs:

sudo serveradmin settings afp:specialAdminPrivs

If the setting is On, then it should be turned off by running the following command:

sudo serveradmin settings afp:specialAdminPrivs = Off

You will also want to limit the number of users that use AFP to something that is reasonable in order to keep the AFP server from crashing (AFP can only typically handle approximately 350 clients mounting from the volume). To do so, use the serveradmin command again:

sudo serveradmin settings afp:maxConnections = 350

Kerberized AFP

Kerberos authentication, as mentioned earlier, is a superior authentication method to the standard Diffe-Hellman exchange (DHX) authentication scheme. Kerberos authentication can be required for the AFP server, but it is worth noting a few gotcha’s with this configuration:

• When Kerberos authentication is required, only clients with a properly configured edu.mit.Kerberos file can authenticate with the service. This can disable access for any client that is not bound into the Open Directory network.
• Clients must not have a time skew longer than five minutes. This should be configured on the client by using a network timeserver.
• Users within the local authentication database will not be able to authenticate to the AFP server because their passwords are not authenticated using Open Directory. This may prevent the first user created on the system from being able to authenticate because they are created in the local authentication database.

Forcing Kerberos authentication requires AFP clients to use Kerberos to connect to the server, a good way to increase the security of your AFP environment. To force Kerberos authentication, set the authentication type to Kerberos using the serveradmin command. Users that are not in the Open Directory database will not be able to authenticate via Kerberos. This means that those clients with local accounts that do not have proper Kerberos configurations files in /Library/Preferences/edu.mit.kerberos will not be able to authenticate to the AFP server once this setting is enabled. To set the server to only accept Kerberos authentication, we’ll use serveradmin again:

sudo serveradmin settings afp:authenticationMode = "kerberos"

AFP Logging

By default, OS X Server does not log all events. From a security perspective, if there is a compromised server, then you will want as many logs as possible to pull data from, in order to reconstruct the events that transpired on your server.

To maximize logging, use the serveradmin command to configure the AFP service to log more data. Here, we’ll do so using the serveradmin

sudo serveradmin settings afp:activityLogSize = 100000

Limiting Access to a Service

FTP is a pretty old protocol at this point. So we’re going to use FTP as an example for how to limit access to services running on your server. We would recommend looking for a replacement if you are using FTP. Having said that, if you use FTP, you should take some steps to secure your implementation. One way to do so is using chroots. A chroot command is a technique under *nix whereby a process is permanently restricted to an isolated subset of the filesystem. Because there are insecurities within FTP and therefore in OS X, chroot can be used to further secure FTP. One easy way to obtain this functionality without a lot of command-line configuration is to use Rumpus, a web-enabled FTP application.

Another step to take with FTP, which is fairly consistent across all of the services provided is to limit access to the service by user or by location (via IP address). To do so, open the Server app and click on the FTP service in the sidebar. Then click on the Edit Permissions… button (shown in Figure 16-29) for the FTP service.

From the Account Access, Network Access screen, click on the “Allow connections from” field and choose “only some users.” Here, you can provide the accounts of any users known to the server that can access the FTP service. Ad/or, you can click on the “When connecting from” drop-down list and select “only some network” which allows you to define IP address ranges that can access the server. We did both in Figure 16-30, but you might choose to only do one of these.

Once you’re satisfied with who will be able to access the FTP service on your server (or another service if you choose to limit access in this manner to other services), click on the OK button.

DNS Best Practices

Over the years, DNS has had a variety of weaknesses. A common reason for these vulnerabilities is improper security configurations of DNS servers. But most recently there have been attacks against even the best-defended servers. Some of these attacks seem fairly innocuous, such as the act of gaining useless information about an environment, while other attacks have been known to forward data through the DNS responder to arbitrarily execute commands. We suggest keeping public-facing DNS on a server outside your environment (with your registrar perhaps) so that other servers can find your domain for mail and web services while not exposing your environment to hacks.

A good number of other services require DNS to function properly, such as Open Directory, Mail Server, and some Apache modules. If the DNS service is overloaded, other services on other servers that use that DNS service will have problems, and also potentially crash. Therefore, we suggest you maintain a separate internal DNS infrastructure that is not accessible from outside your network. It is also strongly suggested that you customize the resources that the DNS service has available to it using sandbox, a means of separating different running services on your server (more on sandbox in Chapter 6).

SSL

Implementing an SSL certificate on your server to encrypt traffic on OS X Server is an essential security precaution to take if you are going to enable most any service (especially for mail, web and collaborative services). If you want to purchase a certificate rather than use a self-signed certificate (including the one installed by default), open the Server app and click on Certificates in the sidebar. Then, click on the plus sign (+) to create a signing request, choosing Get a Trusted Certificate… from the list of options. At the “Get a Trusted Certificate” screen, click on the Next button. At the Get a Trusted Certificate, provide a name for the site in the Host Name field, an email address for the administrator of the server in the Contact Email Address field, and the name of the organization in the “Company or Organization” field, as you can see in Figure 16-31.

You will also need to fill in the Department field, which contains the name of the department the certificate is for (if you are an organization of 1, this won’t be a big deal), the City the organization is in, the State the organization is in and the country the organization is in. Click Next when you’re satisfied with these settings.

You will then see a bunch of really random looking text. Copy this into your clipboard and then go to a trusted CA, such as Thawte or Godaddy. From there, purchase the certificate and when prompted for a “CSR” provide the next we just copied into the clipboard.

The certificate then shows as pending. Once you receive back a certificate from the CA, use this same screen that shows a list of certificates to click on the certificate you’d like to sign and at the screen shown, drag the certificate from the CA into the Certificate Files section of the screen, shown in Figure 16-32.

The server also comes with a self-signed certificate that can be used. You will know that you’re using a self-signed certificate if client computers require you to accept the certificate when visiting a site or service for the first time.

Reimporting Certificates

If you need to re-import your certificate, you will need to convert it to a PEM certificate by running the command:

openssl x509 -in your.domain.com.cer -inform DER -out
     server.krypted.com.crt -outform PEM

Open the resulting .crt file in a text editor and copy the contents. Then, from Server Admin, choose Add Signed or Renewed Certificate from Certificate Authority, and paste the contents in from the previous step. Next your certificate should show that it has been signed by your CA (if you are using serveradmin on the same machine as your certificate server, then the certificate should be trusted as well).

SSH

OS X Server ships with the ssh service automatically enabled. This service, by default, will allow connections on port 22 by any authenticated user known to the server. This has many security implications, such as the ability for standard accounts to run services on ports 1024 and higher. This means that by default any user of your server has the ability to start a proxy or traffic redirector (such as the Internet relay chat client Bouncer) without admin authorization.

Firewall safeguards should prevent remote access to those services, but even in a full firewall lock down, if port 22 is open, there are still many vectors that an attacker with user credentials could use to cause mischief and mayhem, so disable ssh unless you plan to use it. If you use it, make sure to secure it as described in Chapter 15. An example of this type of exploit of ssh would be the ability for users to send large quantities of spam e-mail through the default mail (postfix) system. Spammers controlling compromised systems often use this technique to send large quantities of unsolicited e-mail.

If you are not using ssh to manage servers, disable ssh in the Server app by clicking the server name in the sidebar, then clicking the Settings tab, and finally unchecking the SSH box, as done in Figure 16-33. If you leave ssh enabled, configure service access controls in the Server app by clicking on Access for Users or Groups and then selecting who has access to login through SSH.

You can also increase security of the SSH daemon by limiting older encryption protocol versions that have known exploits and by restricting access to certain groups. You can do this by editing /etc/ssh/ssh_config to include the following lines:

Protocol 2
PermitRootLogin no

Then type the following:

sudo dseditgroup -o edit -a <USERNAME> -t user com.apple.access_ssh sudo
     killall -HUP sshd

The serveradmin Command Line Interface

OS X Server is a strange beast. On the surface, it’s the greatest gift known to sysadmins, granting admins the ability to perform all kinds of complicated configurations quickly through a nice GUI. It can also dismay many of us who know where Unix-specifics live in the operating system and would prefer to configure things there. So, where are all those settings that override so many of the default Unix configuration files? serveradmin is the command that gives access to much of what you see in the Server app, as well as what you don’t see graphically.

To see all the services you can configure and view, use the command serveradmin list. Or use the serveradmin settings vpn command and check the settings applied to the firewall service. serveradmin use starts out with viewing data on a specific service. For example, type sudo serveradmin fullstatus vpn to see a full status on the settings and use of the VPN service. Then use the command serveradmin start vpn, followed by a serveradmin stop vpn. Stopping and starting services on a server using the command line is incredibly helpful as you can actually issue these commands over an SSH session rather than needing to use a remote management utility such as ARD (Apple Remote Desktop) to connect. This can become invaluable when a bad firewall rule locks you, the admin, out of the Server Admin tool. Just issue a serveradmin stop ipfilter command, and you’re right back in!

You can also configure settings that aren’t available in the GUI. For example, we’ll use VPN to customize where we put our logs.

First, type sudo serveradmin settings vpn. Now, look for the following entry:

vpn:Servers:com.apple.ppp.pptp:PPP:Logfile = "/var/log/ppp/vpnd.log"

To change this setting, type the following:

Serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:Logfile =
"/var/log/ppp/pptpvpnd.log"

Now the PPTP logs will be stored in a separate location than the logs for the rest of the VPN service. This can be done only using the serveradmin command and not with a configuration file. Nifty, huh?

To see all of the useful things that can be done with the serveradmin command, we suggest running a man command on serveradmin.

Messages Server

Instant messaging is one of the cornerstones of modern corporate communication, and it doesn’t show any signs of slowing down. With its heavy presence in the modern workplace, it has become very common for business-related communications to be sent over IM. However, because of its humble insecure consumer upbringings, these communications are often not encrypted at all. Many modern packet sniffers have plug-ins or filters specifically designed for tracking session data such as connection passwords and chat transcripts. Because of IM’s prevalence and its potential for eavesdropping, securing your IM communication by way of an encrypted chat server should be a top priority.

The OS X Messages Server uses the XMPP protocol with an available option to enable SSL. You can use the default SSL certificate created when your OS X Server was first configured, or you can choose to import your own. If you opt not to purchase a SSL certificate from one of the public CAs, make sure to generate your own certificates for distribution to your clients, as covered in the previous section on SSL.

Customizing the welcome message to new users of your Messages Server is a fairly simple task, and from a security context it allows an administrator to push out an acceptable use policy for their Messages environment. For this, we’ll cover the Jabber configuration because Jabber is the open source package on which Messages Server is built.

When you first set up Jabber, the /etc/jabber directory will be created. Inside this folder is a file called jabber.xml. Open the jabber.xml file, and look for the welcome tag. Then, any data between "welcome" and "/welcome" will be the information that is shown in a welcome screen when a new user signs onto the iChat Server.

For this example, we will have all new users receive a message that says “Welcome to the Krypted chat Server.”

To do this, delete or comment out the information between the existing welcome tags, and add the following information:

<welcome> <subject>to our iChat Server</subject> <body> Welcome to the Krypted
    chat Server</body> </welcome>

Save the jabber.xml file, and you’ve now customized the welcome message for your Messages Server.

Securing the Mail Server

The mail server in OS X Server has a few settings designed specifically for security. In Chapter 7 we discussed using the SpamAssassin and ClamAV features to limit mail that SpamAssassin and ClamAV identify as potentially sent from a spammer or system that has been infected with viruses. But what if your server is hijacked and set up as an open relay used to send spam? An open relay is a server that allows any user to relay mail through it. To verify your system isn’t being used as an open relay, use the following command

sudo serveradmin settings mail:postfix:luser_relay_enabled

You should receive a “no” as a response to this command.

Limiting the Protocols on Your Server

To reduce the footprint of mail services, you should also limit the number of protocols in use on your server. To do so, you’ll need to use the command line. For example, many environments will use only POP or IMAP. If you aren’t using one of the two protocols, then disable the other. To disable pop:

sudo serveradmin settings mail:imap:enable_pop = yes

To disable imap:

sudo serveradmin settings mail:imap:enable_imap = yes

If you are using a protocol, then make sure that clear text passwords are not allowed. To disable clear text passwords for pop:

sudo serveradmin settings mail:imap:pop_auth_clear = yes

To disable clear text passwords for imap:

sudo serveradmin settings mail:imap:imap_auth_clear = yes

Finally, you can also disable hashes that you no longer need (check with each mail client you use to see which is required for your environment). The currently supported options are cram-md5, digest-md5, login and plain. To disable one, remove it from the smtpd_pw_server_security_options:_array_index array. For example, if mail:postfix:smtpd_pw_server_security_options:_array_index:3 = "plain" then you can use the following to remove plain:

sudo serveradmin settings mail:postfix:smtpd_pw_server_security_options:_array_index:3 = "plain"

After each of these commands, use the ON/OFF button in the service pane of the Server app to restart the mail service.

Summary

In a Mac client-server environment, you’re only as secure as a properly configured server. With the knowledge of how to securely configuring file-sharing services, directory services, the root user, Kerberos, realms, mail services and the myriad other capabilities of your OS X Server, you have yet another weapon in your arsenal to defend your networked environment against attacks. Now, let’s turn to the next line of defense: network intrusion detection and prevention.