Working with Macs

This section describes the unique characteristics or known limitations that are specific to using IBM Security Management Services on a Mac computer.

Specifying the Macintosh User’s Home Directory Location

If you configure NFS, SMB, or AFP network file sharing for your Mac OS X computers, you can automatically mount and log on to file shares using Active Directory credentials.

To enable Mac OS X users to log on to file shares when the network is configured with NFS, SMB, or AFP network sharing:

1. Open Active Directory Users and Computers or the Access Manager console.

2. Select the user account for which you want to enable automounting, right-click, then click Properties.

3. Click the IBM Security Profile tab and set the Home directory path to use one of the following formats:

   • /Users/user_login_name to set the user’s home directory to the default home directory location for all user home directories on Mac OS X computers.

   • /SMB/server_name/share[/path] to automount a file share on the SMB server_name you specify. Be certain to use the fully-qualified domain name for server_name, or the IP address. The short name does not work. For example:
     /SMB/myHost.acme.com/Users/isuzuki

   • /SMB/unix_username/server_name/share[/path] to automount a file share when you are using Fast User Switching on the SMB server_name you specify. Be certain to use the fully-qualified domain name for server_name, or the IP address. The short name does not work. For example:
     /SMB/isuzuki/myHost.acme.com/Users/isuzuki

   • /AFP/server_name/share[/path] to automount a file share on the Apple server_name you specify.

   • /AFP/unix_username/server_name/share[/path] to automount a file share when you are using Fast User Switching on the Apple server_name you specify.

     In specifying the remote SMB or AFP file share, you must use the uppercase letters SMB or AFP at the beginning of the path. If you use lowercase letters (smb or afp), automounting fails.

     If you plan to use Fast User Switching to switch between Active Directory users on the same computer, you should use the /SMB/unix_username/server_name/share[/path] or /AFP/unix_username/server_name/share[/path] format to specify the user’s home directory to prevent conflicts between users logging on using the same share. If you want to automount a share on an Apple file server using the Apple File Protocol (AFP), however, you must use IBM Security 3.0.1 or later.

4. In Step 3, if you specified a network directory, make sure the Active Directory user logon name (pre-Windows 2000), also known as the samAccountName, matches the Mac login name (UNIX name). Otherwise, the login is not guaranteed to work on all Mac systems. The name must be eight characters or fewer because the UNIX name is automatically truncated to eight characters and won’t match if the Active Directory name is longer. The Active Directory name is defined on the Accounts tab. To see an example, open the Properties page for a user and select Account.

   

   Then select the IBM Security Profile tab to see the UNIX name.

   

5. For the shared directory you specified in Step 3 (for example, Users), set ‘full’ permissions for authenticated users. See the section, Setting Shared Directory Permissions, for details on how to do this.

6. Verify that the computer on which the shared directory resides is configured on the DNS server with forward and reverse lookup zones by running the following commands in a terminal window:

   nslookup computerName.domainName

   for example:

    nslookup QA1.acme.com  
     Server: acme.com  
     Address: 192.168.1.139  
     Name: QA1.acme.com  
     Address: 192.168.1.139
    nslookup ipAddress

   for example:

    nslookup 192.168.1.139  
     Server: acme.com  
     Address: 192.168.1.139  
     Name: QA1.acme.com  
     Address: 192.168.1.139

   If you get an error message such as this:

   Can’t find server name for address 192.168.1.139

   it means a reverse lookup zone is not configured for the specified server. To configure DNS forward and reverse lookup zones, see the Microsoft Support Article 816518.

Populating the Home Directory on a Network Share

If you configure users to automount a network share when they log on, you must determine whether a home directory already exists on the network share for those users. If the individual user’s home directory does not exist on the network share, Access Manager creates the home directory automatically the first time the user logs on.

For NFS shares, Access Manager cannot create the home directory on the network share, so you must create the directory before users log in for the first time.

For example, assume you have defined the home directory in a user’s IBM Security Profile as: /SMB/demo-dc.acme.com/home/thomas, indicating that there is an SMB share on the server demo-dc and a shared folder named home where the user thomas has permission to list and create folders.

For the server name, be certain to use the fully-qualified domain name, such as demo-dc.acme.com, and not the short version demo-dc.

When the zone user thomas logs on for the first time, Access Manager creates the new home directory thomas and populates it with the standard Mac OS X files and folders.

If the home directory specified in the IBM Security Profile for a zone user exists prior to the user’s first logon, Access Manager assumes that the directory is valid and contains the appropriate files, and it does not populate the directory with additional Mac-specific folders.

Defining a Home Directory in the Active Directory Profile

When you are configuring a network home directory for remote Mac users, the home directory is created automatically when users first log; it should not exist prior to that initial log on unless you want to prevent Access Manager from creating the home directory. Therefore, you should not define a home directory connection point in the Profile properties for new Active Directory users or new mobile user accounts. Instead, you should allow Access Manager to create and populate the remote home directory. However if you need to synchronize a network home directory from a local home directory as part of your migration process, the network home directory must exist prior to migration. If you are synchronizing from a local home directory to a remote share, you can create the remote home directory manually, or click the Profile tab and set the connection path.

Setting Shared Directory Permissions

All users who are set up with a network home or portable home directory must have proper permissions to the shared directory in which the home directories are created. Initially, you can provide access to the shared directory through the Windows built-in security group, Authenticated Users. Later, you can fine tune permissions for this group based on your company’s file-sharing needs. For example, if an administrator pre-creates home directories for each user before they log in, users only need Read access to the shared directory to access their home directories.

To set permissions for the shared directory for network home and portable home directories:

1. On the network share computer, select the directory to share (for example, MacUsers). Right-click, click Properties and click the Sharing tab; then click Advanced Sharing; for example:

   

2. Make sure Share this folder is selected. Click Permissions, then click Add:

   

3. Type auth and click OK to return the Authenticated Users group. Select Authenticated Users, then click Allow for Full Control. Click OK to set permissions for authenticated users, then click OK again to close the properties page.

   

4. Verify that Authenticated Users have proper permissions on the Security tab as well as on Share Permissions. Ordinarily, these permissions are applied automatically because the Active Directory Users group, which includes authenticated users, inherits Full Control to the shared folder, but if permissions were altered on the Security tab and they are insufficient, users may be unable to log in.

   Click the Security tab and select Authenticated Users (or if it is not already in the Group or user names box, click Add to add it).

5. Select Full control and click OK to save and close the Properties page.

   Assigning permissions to Authenticated Users on the network home share directory means that each home folder will inherit permissions that enable logged-in users to access their home directories. It also means that every user will have access to every other user’s home directory. To change this access, you can set permissions on the individual home directories. For information about fining tuning permissions for individual users, see the next section, Limiting Users Access to Other Users’ Home Folders.

Limiting Users Access to Other Users’ Home Folders

The previous section explained how to assign permissions to a network-home shared folder, which are consequently inherited by the home folders created in the shared folder. Because permissions are inherited, each user has equal access to every other user’s home folder. This section explains how to fine tune permissions to limit user’s access to their own home folder.

To limit users access to their own home folder:

1. Select the network share you assigned permissions to in the previous section.
2. Select one of the user home directories in the network share.
3. Click the Security tab.
4. Click Advanced and Change Permissions.
5. Deselect Include inheritable permissions from the object’s parent.
6. Click Remove when prompted.
7. Click Add.
8. Type users and click Return.

9. Select the following permissions for Users:

   • Traverse folder / execute file
   • Read Attributes
   • Read Extended Attributes
   • Create files / Write Data
   • Create Folder / Append Data
10. Click OK, and OK again until you have saved all open dialogs and closed the Properties page.

Enabling Users to Manage Their Print Queues

On Mac computers, IBM Security Active Directory users are unable to manage their own print jobs. For example, if they attempt to pause, stop, or resume one of their own print jobs, they are prompted to supply the name and password of a user in the “Print Operator” group, otherwise, they cannot continue. IBM Security supplies the group policy, Map zone groups to local group, that you can use to enable all Mac users authenticated through Active Directory to manage their printers.

This policy gives members of a specified zone group (an AD group, or AD group that has been added to a IBM Security zone) the privileges that belong to members of a local group on the local group. For example, as explained in the following procedure, mapping an AD group to the local _lpoperator and _lpadmin groups, provides members of the AD group with the privileges to manage print jobs on the local Mac computer when they log in.

To map a zone group to local _lpoperator and _lpadmin groups:

For purposes of illustration, this procedure asks you to create a MacPrint group and then add specific users to the group to provide them with printing privileges on Mac computers. You could also map an existing AD group to the local _lpoperator and _lpadmin groups, or create a new group with a different name.

1. On a Windows computer, open Active Directory Users and Computers
2. Select Users, right-click and select New > Group.
3. Enter a name for the group, such as MacPrint and select Global and Security.
4. Double-click the group and select the Members tab
5. Click Add and select the AD users who you want to provide with printing privileges on Mac computers.
6. Open the Access Manager Console
7. Expand the zone hierarchy as well as the zone containing Mac computers.
8. Expand UNIX Data, select Groups, then right-click and select Create UNIX Group.
9. Find and select the AD group you created (MacPrint) and click OK to add it to the zone.
10. Open the Group Policy Management Editor and select the GPO that you use for Mac OS X computers.
11. Click Computer Configuration > Policies > User Configuration > Policies > IBM Security Settings > Mac OS X Settings > Accounts.
12. Double-click Map zone groups to local group.
13. Click the Policy tab and click Enabled.

14. Click Add and do the following:

    1. In Local Group, type _lpoperator to add the printer operators group.
    2. In Zone Group click Browse.
    3. Find and select the AD zone group you created (MacPrint), then click OK to map MacPrint to the printer operators group.
    4. Click Add again and in Local Group type _lpadmin to add the printer admin group.
    5. In Zone Group, click Browse then find and select MacPrint again to map MacPrint to the printer admin group.
15. Click OK to save the policy.

The first time users attempts to manage their printer, for example by pausing the printer, they will be prompted for credentials for a user in the “Printer Operator” group. They can simply enter their own name and password. Subsequently, they can manage the printer without supplying credentials.

Setting Up Authenticated Printing

In a Windows Active Directory environment that requires authentication for printing services, Mac users who are already authenticated must provide credentials again when using a Windows network printer. To provide single-sign on when using printers, the IBM Security DirectControl Agent for Mac includes an authenticated printer plug-in that enables users to send print jobs to printers on the Windows network without requiring them to enter credentials again. This plug-in uses the user identifier (UID) of the user printing a job to find the user account to authenticate, then validates the user’s Kerberos credentials through Active Directory. If the user’s credentials are not available, the print job will fail.

Understanding Printing on Mac OS X

Mac uses the Common UNIX Printing System (CUPS) to manage printing services. Although you can access the CUPS facility directly to manage printers, in general you do not need to do so. Printers are managed through the Print and Scan system preference, which uses the CUPS facility. For example, when you add a printer through Print and Scan, the CUPS facility does the following:

• Creates a Postscript Printer Description (PPD) file that defines the printer. The file is given the name of the printer and resides in the /etc/cups/ppd directory; for example, /etc/cups/ppd/laserjet2.ppd.
• Modifies the CUPS configuration file, /etc/cups/printers.conf, with information about the new printer.

One method to set up authenticated printing for all Mac computers in your environment is to configure an authenticated printer on one (template) computer, then export the files that CUPS creates to define this printer (printerName.ppd and printers.conf) to each of your Mac computers. You can use group policy to export these files to all your Mac computers.

You can also configure printing directly with CUPS commands.

To set up authenticated printing for multiple printers using the IBM Security plug-in, first identify the printer to configure, including the server that hosts it; for example, HPLaserJet2.@dc01.

1. On the Mac computer that you will use to define an authenticated printer template, open System Preferences > Print & Scan (Print & Fax on older systems), then click the plus sign (+) and select Add Other Printer or Scanner.

2. Double-click the Advanced icon in the toolbar.

   If the Advanced option is not showing, press and hold the Option and Apple keys and right-click in the open area in the toolbar next to the Windows icon and select Customize Toolbar. Drag the Advanced icon to the toolbar and click Done. Then double-click it.

   

3. Scroll in the Type drop-down list and select Windows Printer via IBM Security from the list.

   Note that after you make this selection, the URI scheme in the Device URI window changes to cdcsmb://, which specifies the IBM Security plugin.

4. Type the complete URI specification for the printer in the form:

   scheme://servername/sharename

   for example:

   cdcsmb://printserver.acme.com/hplaserjet2

   A URI specification does not accept spaces. If the printer share name contains spaces, you must replace them with %20 (ASCII code for space); for example, to specify the HP Color LaserJet 4 printer:

   cdcsmb://printserver.acme.com/HP%20Color%20LaserJet%204

5. Type a name for the printer; for example HPLaserJetMac.

   When you type the URI for the printer, the first part of the name automatically appears in the Name field. You can change that name now. This is the name that will appear in the list of printers in the Print and Scan system preference and in the list of available printers when a user prints a document. It is also the name of the PPD (Postscript Printer Description) file that the CUPS facility creates for each printer that is added to your Printer preferences.

   Type an optional description in Location to assist users in locating the printer.

6. In the Print Using window, specify the type of the printer, which enables you to properly manage the printer.

   For example, if you have drivers installed for the printer, click Select Printer Software and select the appropriate item such as HP Laserjet 4300, then click OK.

   You can also specify Generic Postscript Printer, or click Other to browse for drivers or printer software.

   Click the Add button to add the printer to the list of available printers.

7. Repeat this procedure for as many printers as you want to make available for authenticated printing.

You can now use the Copy Files group policy to copy the new printerName.ppd file and updated CUPS configuration file (printers.conf) to the appropriate locations on each of your Mac computers in the domain.

To copy printer files to other computers:

1. In the Finder on the Mac template computer, navigate to the /etc/cups directory by clicking Go > Go to Folder, then type /etc/cups and click Go.

2. Select printers.conf and copy it to the desktop. When prompted, enter your administrator password to copy the file.

3. Open the ppd folder (/etc/cups/ppd). Select the files for all the authenticated printers you defined in the previous procedure and copy them to the desktop.

4. On the desktop, change the file permissions for the printers.conf and *.ppd files so you can copy them to sysvol:

   1. Select the files and click File > Get Info.
   2. For each open dialog box, expand Sharing & Permissions, then click the lock icon and provide administrator credentials for making changes. Set the permissions for everyone to Read only.
   3. Reset the lock and close all the open dialogs.

5. On the Windows domain controller create a sub-directory for the printer file in SYSVOL.

   SYSVOL is a well-known shared directory on the domain controller that stores server copies of public files that must be shared throughout the domain. You can use it to copy the printer definition and configuration files to all Mac computers that join the domain.

   SYSVOL is located at:

   C:WindowsSYSVOLsysvoldomainName

   For example, assuming the domain is acme.com, and using the name MacPrinters for the directory, create the following directory:

   C:WindowsSYSVOLsysvolacme.comMacPrinters

6. On the Mac computer, copy the files from the desktop to SYSVOL on the Windows domain controller. If you are connected to the domain, you should see the domain controller in the Finder. If the domain controller is not visible in the Finder, connect to it:

   1. Click Go > Connect to Server and select the domain controller.

   2. When prompted select SYSVOL; for example:

      

   3. Navigate to the MacPrinters directory you created, for example by clicking acme.com then MacPrinters.

   4. Drag the printer files to MacPrinters.

7. Configure the Copy Files group policy.

   1. On the Windows domain controller, open the Group Policy Management Editor and select the GPO that is used to manage Mac computers.

   2. Navigate to Computer Configuration > Policies > Common UNIX Settings and double-click Copy Files.

   3. In Copy file policy setting, select Enabled.

   4. Click Add, then Browse. Double-click to open the directory you created for the printer files in Step 5 (for example, MacPrinters).

   5. Select the printers.conf file. Filename now shows MacPrinters/printers.conf.

   6. In Destination, type /etc/cups. This group policy will copy printers.conf to the /etc/cups directory of each computer that joins the domain.

   7. Select Use destination file ownership and permissions. The file will be assigned the default ownership and permissions:

      owner: root (0)

      group: lp (26)

      permission 0600 (rw- --- ---)

   8. Select OK to add the printers.conf file.

8. Click Add again and browse to MacPrinters to add the PPD files.

   1. Select one of the PPD files you copied to the MacPrinters directory.

   2. In Destination, type /etc/cups/ppd.

   3. Select Use destination file ownership and permissions. The file will be assigned the default ownership and permissions:
      owner: root (0)

      group: lp (26)

      permission 0644 (rw- r-- r--)

   4. Click OK to add the file.

9. Repeat the sub-steps in Step 8 for each of the PPD files that you have defined, then click OK to enable the policy.

   This group policy will copy each printerName.ppd file to the /etc/cups/ppd directory of every computer to which the policy applies and that is joined to the domain.

10. Run the adgpupdate command on each target Mac computer to trigger an update of group policies and execute the new Copy Files policy.

    By default, group policies are updated automatically every 90 minutes, so you can skip this step and wait for the automatic update if you wish. You should also log out and back in again on each computer to update the printer configuration dialogs.

Removing a Printer Definition from Client Computers

This section explains how to remove printer definitions that you created for Mac computers in the domain. It assumes that you set up the Copy Files group policy to add printer definitions to each of your joined Mac computers, as explained in Setting up Authenticated Printing.

To remove a printer definition from computers in a domain:

1. Identify the name of the PPD file to delete in /etc/cups/ppd; for example, laserjet4300.ppd.

2. On the Mac template computer (the computer on which you originally defined the authenticated printer), open System Preferences > Print & Scan. Select the printer to delete, click the minus (-) button, then click Delete Printer.

   Deleting the printer removes the printer from the list, updates the /etc/cups/printers.conf file by removing the definition of the deleted printer, and removes the printerName.ppd file from the /etc/cups/ppd directory.

3. Copy the updated printers.conf file to the desktop and change the permissions to everyone: Read only.

4. Copy the updated printers.conf file to the SYSVOL and replace the existing file; also remove the PPD file for the deleted printer.

   SYSVOL is a well-known shared directory on the domain controller that stores server copies of public files that must be shared throughout the domain. When authenticated printing was set up, the CUPS configuration file, printers.conf was placed in the SYSVOL/acme.com/MacPrinters folder.

   SYSVOL is located at:

   C:WindowsSYSVOLsysvoldomainName

   If you are connected to the domain, you should see the domain controller in the Finder. If the domain controller is not visible in the Finder, connect to it:

   1. Click Go > Connect to Server and select the domain controller.

   2. When prompted, select SYSVOL; for example:

      

   3. Navigate to the directory you created (domainName/subdirectory), for example by clicking acme.com then MacPrinters.

   4. Drag the printer configuration file to this directory.

   5. Remove the PPD file for the deleted printer.

5. Remove the deleted printerName.ppd file from the Copy Files policy.

   1. On the Windows domain controller, open the group policy editor and select the policy to edit, such as Default Domain Policy.
   2. Navigate to Computer Configuration > Policies > Common UNIX Settings and double-click Copy Files.
   3. Select the file to delete and click Remove.
   4. Click OK to save the updated policy.

6. Configure the Specify commands to run group policy to remove the deleted printerName.ppd file from all the Mac computers in the domain.

   1. In the same folder of the group policy editor (Common UNIX Settings), open the Specify commands to run policy and select Enabled.

   2. Click Add.

   3. In Run command, enter a command similar to the following to remove the printerName.ppd file from the /etc/cups/ppd directory on each computer:

      rm /etc/cups/ppd/*printerName*.ppd; for example:

      rm /etc/cups/ppd/laserjet4300.ppd

   4. Click OK to save the policy.

The next time group policy is updated on computers in the domain (every 90 minutes by default), the following occurs:

• The Copy Files group policy copies the updated printers.conf file to each computer.
• The Specify commands to run group policy removes the specified PPD file on each computer.

Setting Up Local and Remote Administrative Privileges

IBM Security provides two group policies to set administrative privileges on the local computer

• Map zone groups to local admin groups allows you to specify one or more zone groups to map to the local admin group. Members of the specified group are given administrative privileges on Mac computers managed by Access Manager.
• Enable administrator access groups allows users in the zone group ard_admin to access a computer via Apple Remote Desktop with full privileges.

This section shows you how to use these policies together to enable local and remote administrative access to Mac computers.

To enable remote and local access for a group:

1. Create an Active Directory group, for example, My_Mac_Admins, and add users who you want to have administrative privileges.

2. Create an Active Directory group that is a Domain Local Security group. For convenience, name it ard_admin.

3. Add My_Mac_Admins as a member of ard_admin.

4. Create a IBM Security zone group, My_Mac_Admins and map it to the Active Directory group My_Mac_Admins.

   If the local computer is connected to the domain through Auto Zone, you cannot create a zone group because there are no zones. However, all Active Directory groups are valid for the joined computer, so you can map any group, such as My_Mac_Admins, to the local admin group, but you need to know the group’s UNIX name, which you can retrieve on the local computer, by using the adquery command, as follows

   [root]#adquery group -n

   For example, the following shows an adquery command and the name it returns:

   [root]#adquery group -n |grep -i Mac_Admins my_mac_admins

5. Create a zone group, ard_admin, and map it to the Active Directory group ard_admin.

   This zone group must be named ard_admin.

6. In the Group Policy Editor, edit the group policy for the domain, then click Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone groups to local admin group.

7. Open the policy, select Enable, then click Add. Enter My_Mac_Admins (or the name retrieved from the adquery -n command in Step 4), then click OK.

   This step maps My_Mac_Admins to the admin group on the local computer and gives members of My_Mac_Admins all privileges.

8. Click Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Remote Management > Enable administrator access groups.

9. Open the policy and select Enable.

   This step allows members of ard_admin to access a computer via Apple Remote Desktop with full privileges. In Step 7, you effectively gave members of My_Mac_Admins administrative privileges. Since My_Mac_Admins includes members of ard_admin, members of ard_admin now have full local and remote administrative access.

Querying User Information for Active Directory Users

When you run commands or use applications that look up user information in the directory, the local Mac directory service is always consulted first before the look-up request is made to Active Directory. If a local user exists with the same name as a UNIX profile name that has been defined for the zone, a lookup request such as id username will return the UID and GID associated with the local user account from the local directory service rather than the information associated with the UNIX profile defined in Active Directory.

For example, if you have a UNIX profile in Active Directory for the user mia with the UID of 10024 and the user’s primary group is mia with the GID of 10024 and the user is also a member of the Active Directory group users and GID of 10001, running the id mia command returns the following information from Active Directory:

uid=10024(mia) gid=10024(mia) groups=10024(mia), 10001(users)

However, if there is also a local user account with the same user name of mia, but with a UID of 502 and a primary group named mia with a GID of 502, running id mia returns the information for the local user retrieved from the Mac directory service, then any additional group membership information retrieved from Active Directory. For example:

id mia

uid=502(mia) gid=502(mia) groups=502(mai), 10001(users)

Because the Mac directory service is queried first, the information for the local user mia takes precedence over the information defined in Active Directory. To avoid retrieving the information for a local user instead of the UNIX profile defined in Active Directory, you should make sure that the UNIX profile user names in Active Directory are different from the local user or disable local user accounts.

Migrating from Open Directory to Active Directory

If you install the IBM Security DirectControl Agent for Mac in an environment where existing Mac users and computers are managed with Open Directory, you may need to migrate the account information and home directories for those users from the Open Directory environment to IBM Security Active Directory. Open Directory and Active Directory support three types of users:

• Local users
• Network home users
• Portable home, or mobile home, users

For example, you may need to migrate existing mobile user accounts from Open Directory to Active Directory or migrate local home directories to a network share.

To migrate users with existing mobile accounts from Open Directory to Active Directory:

1. Create a copy of the user’s local home directory in a temporary location if you have enough disk space to do so. This copy can serve as a backup to restore the user’s home directory if you run into any synchronization problems.

2. Log on to the Mac client as an administrator.

3. Disable the LDAP service.

   Open the Directory Utility and select the Services tab; then deselect LDAPv3 and click Apply.

4. Open a Terminal window and run the following Directory Service command to delete the user’s record:

   dscl /Local/Default -delete /Users/userName

   where userName is a local user; for example, to delete the record for cain:

   dscl /Local/Default -delete /Users/cain

5. Navigate to the /Users/user_name/Library/Mirrors directory and delete this folder.

6. Join the Mac computer to an Active Directory domain and restart the computer to shut down and restart services.

7. Create an Active Directory user account for the Open Directory user account, if one does not already exist.

   If you are creating a new Active Directory user, use Active Directory Users and Computers to add the user account.

8. Add the Active Directory user to the Mac computer’s zone and define the IBM Security Profile for the user:

   • Use the same user name, UID, and GID as the Open Directory user account. You can change this information later with the adfixid program, but for migration you must use the same values.

   • Set the home directory for the user to the appropriate network share using the /SMB/share/path or /AFP/share/path syntax. For example, /SMB/cain/server2003.myDomain.com/Users/cain.

     For synchronizing new mobile user accounts, the empty home directory must exist on the network share. If the user home directories are on the same network share as you previously used with Open Directory, logging on with the new Active Directory account should not affect the files available on the share.

     Because GID values of 0 to 99 are usually reserved for system accounts, you may see a warning message when you save the user’s profile if the user’s primary GID value is less than 99.

If you have Open Directory users that do not have mobile accounts or portable home directories and you want to synchronize their local home directories with their network home, you should first use the Workgroup Manager to create mobile accounts for those users to establish a portable home directory. You can then follow the steps above to synchronize the portable home directories with their network home directory. If you don’t want to synchronize the local home directory with the home directory on the network share, you can simply create Active Directory accounts for the Open Directory users and remove the local user records.

Changing the IBM Security UIDs and GIDs

To change the UID and GID values in IBM Security Active Directory to match the existing values:

1. Log in to the Mac computer as a local administrator.

2. Open a terminal session.

3. Open the user’s home folder and type:

    ls -ln total 32  
    -rw-r--r--@ 1 505 505 3 Mar 26 2007 .CFUserTextEncoding  
    -rw-r--r--@ 1 505 505 6148 Mar 26 2007 .DS_Store  
    -rw------- 1 505 505 74 Mar 26 2007 .bash_history  
    drwx------@ 3 505 505 102 Mar 26 2007 Desktop  
    drwx------@ 3 505 505 102 Mar 26 2007 Documents  
    drwx------@ 19 505 505 646 Mar 26 2007 Library  
    drwx------@ 3 505 505 102 Mar 26 2007 Movies  
    drwx------@ 3 505 505 102 Mar 26 2007 Music  
    drwx------@ 4 505 505 136 Mar 26 2007 Pictures  
    drwxr-xr-x@ 4 505 505 136 Mar 26 2007 Public  
    drwxr-xr-x@ 5 505 505 170 Mar 26 2007 Sites

   The third column shows the UID (505 in this example) and the fourth column shows the GID (also 505).

4. On the Windows workstation, open the Access Manager console. Expand the zone, expand users, and double-click the user to open the property page.

5. Type 505 for the UID.

6. To change the GID, you need to either change the GID of the group to which the user belongs (which will change for all users who belong to that group) or create a new group. To create a new group:

   • Open ADUC. Then right-click Users > New > Group. Enter a name for the group and click OK.
   • In the Access Manager console, right click Groups > Create UNIX Group. Search for the group you created. Change the GID to the desired value (for example, 505) and click OK.

7. To change the GID of the existing group to which the user belongs, expand Groups and double-click the group name. Change the GID to the desired value (for example, 505). Click Yes on the warning message.

Modifying the Mac UID and GID to Match AD

To change the existing UID and GID to match the values in Active Directory depends on whether you have a local home directory, a network home directory, or a mobile home directory.

To change the existing UID and GID if you have a local home or network home directory:

1. Log in to the Mac computer as a local administrator.

2. Open Applications > Directory Utility > Services. Double-click Active Directory, then click Unbind. Enter your administrator name and password if necessary.

3. Use the ADJoin tool (either the GUI or the command-line version) to connect to an Active Directory domain.

4. Open a terminal session and type the following:

   id userName

   Note the primary group. For example:

   id cain

   ...

   gid=10000(support)

5. Type:

   chown -R userName:primaryGroupName /Users/userName

   For example, for a local home directory:

   chown -R cain:support /Users/cain

   For example, for a network home directory:

   chown -R cain:support /SMB/Users/cain

To change the existing UID and GID if you have a mobile home directory:

1. Be certain the local home directory is synchronized with the network home directory.

2. Log in to the Mac computer as a local administrator.

3. Open Applications > Directory Utility > Services. Double-click Active Directory, then click Unbind. Enter your administrator name and password if necessary.

4. Use the ADJoin tool (either the GUI or the command-line version) to connect to an Active Directory domain.

5. Open a terminal session and type the following Directory Service command to delete the cached local user:

   dscl . -delete /Users/userName

   For example:

   dscl . -delete /Users/cain

6. Then type the following commands to remove the home directory so that it syncs again from the network and remove the local copy of mcx so you are prompted to create a mobile account:

   rm -rf /Users/userName

   rm -rf /Library/Managed Preferences/userName

7. On the Windows Active Directory computer, set the User Configuration > Policies > Centrify Settings > Macintosh Settings > Mobility Synchronization Settings group policies.

   Mobile home directory synchronization is no longer supported since macOS 10.12.

Converting a Local User to an Active Directory User

Although local user accounts can co-exist with Active Directory user accounts, in some cases, you may want to convert some or all of your local accounts to Active Directory user accounts. Converting local users to Active Directory users simplifies account management, but requires you to take some steps manually.

On Mac computers, the local account database is always checked for authentication before Active Directory. If a local user has the same username as an Active Directory user, the local user account is used for authentication. If the local user’s password is different from the Active Directory user’s password whether logging on using the Mac login window, or remotely (for example, using telnet or ssh), the local user password is required for authentication to succeed. Although authentication succeeds, Access Manager will generate a username conflict warning.

In most cases, you should remove or convert local user accounts to avoid conflicts between Active Directory and local user accounts and to ensure Active Directory password and configuration policies are enforced. If you need to keep local user accounts, you should ensure the logins are distinguishable from Active Directory accounts. For more information, see the Planning and Deployment Guide.

To convert a local Mac user to an Active Directory user:

1. Open a Terminal window and run the following Directory Service command to delete the user’s record:

   dscl /Local/Default -delete /Users/userName

   where userName is a local user; for example, to delete the record for cain:

   dscl /Local/Default -delete /Users/cain

   Although the user record is deleted, the home directory for the user (/Users/cain), including all sub-directories and files, still exists. When you create an Active Directory user with the same name, this user will have access to everything in the existing local home directory.

2. On a Windows computer, use Active Directory Users and Computers to create an Active Directory user account for the local user account (for example, cain), if one does not already exist.

3. In the Access Manager console add the Active Directory user to the appropriate zone and define the IBM Security Profile for the user. Set the home directory for the user:

   The default home directory for Mac users is the /Users directory, unlike most UNIX systems where /home is the default by convention.

   • To a local home directory: /Users/userName; for example, /Users/cain.
   • To an appropriate network share using the /SMB/share/path or /AFP/share/path syntax. For example, /SMB/cain/server2003.myDomain.com/Users/cain. See Configuring a network home directory.
   • To a network home directory. If you wish, you can create a mobile account for the user and synchronize the user’s folders the next time the user logs on.

4. Reboot the Mac computer, then log in as the new Active Directory user.

Migrating a User from Apple’s Active Directory Plugin to IBM Security Active Directory

When you create an Active Directory user by using the Mac Directory Utility Active Directory plug-in it creates numeric user (UID) and group (GID) identifiers. When you migrate a current Active Directory user to IBM Security Management Services for Mac, the Access Manager console creates a UID and GID that are different than the current UID and GID. When an Active Directory user attempts to log in after the agent is installed, the changed UID and GID cause ownership and permission problems with the user’s home directory.

There are two basic approaches to solving this problem:

• Changing the IBM Security UIDs and GIDs
• Modifying the Mac UID and GID to Match AD

Using Apple’s Scheme to Generate UIDs And GIDs For Mac Users

By default, IBM Security uses a different scheme than the Apple Active Directory plugin to generate numeric user (UID) and group (GID) identifiers for Mac users added to Active Directory. If you use the default IBM Security scheme to generate identifiers, you must resolve UID and GID conflicts after migrating users. For example, after migrating you can change ownership on the existing files (see Modifying the Mac UID and GID to Match AD otherwise users have IBM Security-generated UIDs whereas their files belong to Apple-generated UIDs so users will be unable to access files and folders in their home directories.

On the other hand, IBM Security allows you to use the Apple scheme, rather than the default IBM Security scheme, to create UIDs and GIDs for migrated users. This method ensures compatibility with Mac tools, such as ExtremeZ-IP, that require UIDs and GIDs generated with the Apple scheme, not the IBM Security scheme.

This section explains how to create Apple-generated UIDs and GIDs for Mac users who you are adding to Active Directory with IBM Security Management Services for Mac when a computer is connected to IBM Security Active Directory through Auto Zone.

If your computer is joined to a zone, however you are adding users to the zone, you can choose to use the Apple scheme to generate UID and GID values. For example, you can specify the Apple scheme with adedit, with the Zone Provisioning Agent, and in the Access Manager Console.

IBM Security provides the auto.schema.apple_scheme parameter to enable use of the Apple schema for generating UIDs for new users. The recommended way to set this parameter is by way of group policy so that you can set it for a group of computers. You may also set the parameter on individual computers by editing the IBM Security configuration file

To use group policy to enable the Apple scheme for generating UIDs and GIDs:

1. If you are generating new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, back up the UIDs and GIDs on the computer where the share resides by executing a command similar to the following:

   adquery user > olduid

   You do not need to perform this step for Samba shares.

2. On a Windows computer, open the Group Policy Management Editor and edit a group policy object that applies to Mac computers.

3. Expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Direct Control Settings > Adclient Settings, and double-click Generate New UID/GID using Apple scheme in Auto Zone.

4. Select Enabled and click OK to set the policy.

To edit the configuration file and enable the Apple scheme for generating UIDs and GIDs on a single computer:

1. If you are generating new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, back up the UIDs and GIDs on the server where the computer resides by executing a command similar to the following:

   adquery user > olduid

   You do not need to perform this step for Samba shares.

2. Log in to a Mac computer.

3. Edit the IBM Security configuration file: /etc/centrifydc/centrifydc.conf.

4. Find the following parameter, remove the comment and set its value to true:

   auto.schema.apple_scheme: true

You may also enable the Apple scheme to set the primary GID for users if you wish.

You may set the primary GID in this way only if the parameter auto.schema.private.group is set to false. Otherwise, the primary GID is set to the value of the user’s UID.

To enable the Apple scheme for generating the primary GID:

1. If you are generating new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, back up the UIDs and GIDs on the computer where the share resides by executing a command similar to the following:

   adquery user > olduid

   You do not need to perform this step for Samba shares.

2. In the Group Policy Management Editor, edit a group policy object that applies to Mac computers, expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Direct Control Settings > Adclient Settings, and double-click Set user’s primary gid in Auto Zone.

3. Select Enabled.

4. In Set user’s primary gid in Auto Zone, type -1.

   The primary GID for each user will be generated by the Apple scheme, as specified with the “Generate New uid/gid using Apple scheme in Auto Zone” group policy, which you enabled in the previous procedure.

5. Click OK to save the setting.

After setting these policies, run adgpupdate to update the group policies you just set, and flush the cache on each joined computer to update the UID and GID values for any existing users.

To flush the cache on each Mac computer:

1. Log in to a Mac computer and open the Terminal application.

2. Execute the following command as root:

   adflush

New users who you migrate to Active Directory from the Apple Active Directory plug-in will automatically keep the same UID, GID, and primary GID values that they had before migration, and their home ownership will work properly.

After you flush the cache, any existing users and groups will have their UID, GID, and primary GID values changed from the IBM Security scheme to the Apple scheme. However, ownership of files and folders in home directories will still belong to the IBM Security UID and GID. To change ownership to the new UID and GID generated by the Apple scheme, run the fixhome.pl script as explained in the following procedure.

To correct file ownership by running fixhome.pl

If you generated new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, the fixhome.pl script does not have permission to change UIDs and GIDs in the share, and you must manually update the UIDs and GIDs on the server where the share folders reside. In this scenario, skip to Workaround for AFP and NFS Mounted Shares below and continue from there.

For Samba shares and local UIDs and GIDs:

1. Log in on a Mac computer for which you have changed UID and GID values to the Apple scheme.

2. Execute the following command as root:

   /usr/local/share/centrifydc/sbin/fixhome.pl

The script changes ownership of files and folders in the home directory of all Active Directory users from the IBM Security-generated UID or GID to the Apple-generated UID or GID.

The script uses /Users as the root for all home directories. You may specify a different home root if necessary by using the --dir option. Use the --help option to see a list of options that you can specify with this command:

/usr/local/share/centrifydc/sbin/fixhome.pl --help

For example, you can run the command in test mode to see the changes that will be made, but without committing the changes:

[root]#/usr/local/share/centrifydc/sbin/fixhome.pl --test

User Home UID Map GID Map

user1 /Users/user1 796918879=>558948313 20=>5287576209

Or you could update specific users rather than all users:

[root]#/usr/local/share/centrifydc/sbin/fixhome.pl --include user2

Workaround for AFP and NFS Mounted Shares

For AFP and NFS mounted share folders (or remote file systems), fixhome.pl does not have permission to change the UID/GID of files in the folder. Perform the following steps to work around this issue:

1. On the server where the share folders reside, open the UID/GID backup file to have access to the old UID/GID strings.

2. On the server where the share folders reside, change the old UIDs and GIDs to the new UIDs and GIDs one at a time by executing commands similar to the following:

   find ShareFolder -user previous_uid -group previous_gid -exec chown new_uid:new_gid {} ;

To enable the Apple scheme for mobile users:

Additional steps are required to enable the Apple scheme for mobile users. After enabling the Apple scheme as described in the preceding sections, you must ensure that the UID and PGID for the mobile user’s local user record match the UID and PGID used by the DirectControl agent.

1. Change the UID and PGID in the local user record so that they match the IDs used by the agent:

   1. Open Users and Groups.
   2. Right-click the mobile user account.
   3. Choose Advanced Options, and change the UID and PGID so that they match the IDs used by the agent.
2. After changing the UIDs and PGIDs of mobile users, run the fixhome.pl script as described above in To correct file ownership by running fixhome.pl.

To use the Zone Provisioning Agent to enable the Apple scheme for generating UIDs and GIDs:

1. Ensure that the Zone Provisioning Agent is configured as described in the section “Configure the Zone Provisioning Agent” in the Planning and Deployment Guide.

2. Ensure that zone provisioning groups are created and configured as described in Chapter 8, “Preparing the Environment for Migration of Existing Users and Groups” in the Planning and Deployment Guide.

3. Start Access Manager.

4. In the console tree, expand the Zones node.

5. Select the top-level parent zone, right-click, then click Properties.

6. Click the Provisioning tab.

7. Click Enable auto-provisioning for group profiles.

8. Click the Find icon to search for and select the primary group (typically the Domain Users group) as the Source Group.

9. Select Generate using Apple scheme as the method for assigning a new GID to new UNIX group profiles.

   This method generates group GIDs based on the Apple algorithm for generating numeric identifiers from the Active Directory group’s objectGuid. This option is only supported for hierarchical zones.

10. Select a method for assigning a new group name to new UNIX group profiles:

    • SamAccountName attribute generates the group name for the new UNIX group profile based on the samAccountName value.
    • CN attribute can be used if you verify the common name does not contain spaces or special characters. Otherwise, you should not use this option.
    • RFC 2307 attribute can be used if you have added the RFC 2307 groupName attribute to Active Directory group principals. Otherwise, you should not use this option.
    • Zone default value to use the setting from the Group Defaults tab for the zone. In most cases, the default is a variable that uses the sAMAccountName attribute.
    • By default, all UNIX group names are lowercase and invalid characters are replaced with underscores.

11. Click OK to save your changes.

Configuring Auto-Enrollment

IBM Security uses the Microsoft Windows certificate auto-enrollment feature to make certificates available to UNIX and Mac computers. If auto-enrollment is enabled, when a UNIX or Mac computer joins a domain, certificates are requested from the Certification Authority based on particular templates, and the certificates are installed on the joined computer

To enable auto-enrollment:

• Enable auto-enrollment for the group policy.

• Create a certificate template with auto-enrollment enabled.

  As of MacOS Big Sur (11.0), Apple no longer allows silently adding root certificates to Keychain with a trusted setting. If there are some root certificates installed from your domain by the IBM Security Agent, the IBM Security Certificate Trust Setting Tool will open automatically. Please follow the instructions to set certificates as trusted.

Configuring 802.1X Wireless Authentication

This section explains how to configure Active Directory and Mac to authenticate Active Directory users by using a Microsoft RADIUS server with the 802.1X PEAP (MSCHAPv2) protocol over a wireless network from a Mac computer.

On Mac OS X, 802.1X wireless authentication does not rely on IBM Security Access Manager or Apple's Active Directory plugin but is configured primarily through group policies that apply to the Windows server and the Mac computers.

System Configuration for 802.1X Wireless Authentication

The following table summarizes the environment that is needed for 802.1X wireless authentication:

Environment	Components / Configuration
Windows side	Windows Server 2003 R2 Enterprise Edition Domain Controller (supports PEAP) with Internet Authentication Service (IAS) installed; on Windows server 2003, RADIUS server is part of IAS. or Windows Server 2008 R2 Enterprise Edition Domain Controller (supports PEAP/TLS) with Network Policy Server (NPS) installed; on Windows Server 2008, Radius server is part of NPS.
	Active Directory on the Windows Server
	Group Policy Management Console (GPMC), which is required to configure 802.1x group policies and deploy certificates.
	Certificate Services, which is required to obtain the required certificates.
	Access Manager console 5.1.x or later, which is required to set group policies that apply to Mac computer.
Mac side	DirectControl agent 5.0.1-171 or later to enforce group policies on the Mac computer.
Wireless access point device	Supports 802.1x wireless authentication through one of these protocols: * WPA Enterprise WPA2 Enterprise 802.1X WEP (the name can be different, for example, RADIUS)

Although it is possible to configure other RADIUS servers for 802.1X wireless authentication, or use other protocols, this document focuses on the Microsoft RADIUS server and the PEAP and TLS protocols.

These instructions assume that you have a RADIUS server properly configured for 802.1X wireless authentication, so that you can now proceed to configure your Mac environment. For a description of how the RADIUS server must be configured to support 802.1X wireless authentication on Mac OS X, see the section below named Confirming that Windows Server Supports Certificate Auto-enrollment. Click a link if you have questions about whether your RADIUS server is configured properly with regard to any particular item:

Of course, there are other configuration steps that are required to set up a RADIUS server, such as configuring the RADIUS client and configuring a remote access policy, however, the important consideration for Mac 802.1X authentication is that the specified certificate and private key have been created and deployed to the domain. When a Mac computer joins a Windows domain, Access Manager automatically finds certificates on the Domain Controller and adds them as trusted certificates to Keychain Access on the Mac computer.

Once you are certain that the RADIUS server is properly configured, you can configure your Mac environment; see the following section for instructions on configuring OS X 10.7 or later.

Configuring Mac OS X 10.7 or Later for 802.1X Wireless Authentication

Mac OS X 10.7 changed the way to create and manage profiles such that configuring 802.1X wireless authentication varies significantly between 10.7 and earlier versions of OS X. This section explains how to configure a Mac OS X 10.7 or later computer for 802.1X wireless authentication.

Before configuring your Mac environment, be certain that the RADIUS server is configured as described above in the section, System Configuration for 802.1X Wireless Authentication. This configuration includes a domain root CA certificate or RAS/IAS server certificate, as well as a private key that are required to be trusted on the Mac computer.

However, there are no manual steps that you must perform to trust these certificates on your Mac computers. As mentioned previously, when a computer is joined to a domain, Access Manager automatically looks for certificates on the domain controller, and adds these certificates and the private key to the system Keychain on the Mac computer.

Through group policy settings you can use these certificates to create two different types of system profiles

• To create a system profile that allows users to authenticate to an 802.1X-protected ethernet network, see the next procedure, To configure Mac OS X 10.7 or Later to Create an 802.1X Ethernet Profile.
• To create a system profile that allows users to authenticate to an 802.1X wireless network, see the procedure further down, To configure Mac OS X 10.7 or Later to Create an 802.1X WiFi Profile.

The certificate template — as well as a certificate chain file and private key — are pushed to /var/Centrify/net/certs on the Mac computer when it joins the domain. Before you configure the group policy for the Mac computer, if you want to verify that auto-enrollment is operating correctly, you can open a Terminal window on the Mac computer and run a command similar to the following to check that the certificate has been downloaded to the computer:

admin$ls /var/Centrify/net/certs |grep -i auto_

...

auto_TemplateName.cert

auto_TemplateName.chain

auto_TemplateName.key

You should see three auto_ files as shown in the example.

To configure Mac OS X 10.7 or later to create an 802.1X Ethernet profile

1. On a Windows computer, open the Group Policy Management Editor and edit a group policy object that applies to Mac computers.

2. Expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Settings, and double-click Enable Ethernet Profile.

3. Select Enable, then click Add.

4. Type the name of the auto-enrollment machine certificate that has been pushed down from the Windows domain server.

   When pushed to a Mac computer, certificate names are prepended with auto_; for example:

   auth_Centrify-1X

   This group policy runs a script that looks for the specified certificate template in the /var/Centrify/net/certs directory (which contains the certificate templates pushed down to Mac when they join the domain) and creates a WiFi profile from this certificate.

5. Click OK to save the profile information and OK again to save the policy setting.

   This group policy will take effect at the next group policy update interval, or you can run adgpupdate in a terminal window on the Mac computer to have the policy take effect immediately.

When the group policy takes effect, it runs a script to create an ethernet profile for the computer from the certificate template and private key downloaded from the domain controller. This policy supports the TLS protocol for certificate-based authentication. The Mac computer is now configured for access to the radius access point.

On the Mac computer you can view the profile in System Preferences.

To configure Mac OS X 10.7 or later to create an 802.1X WiFi profile

1. On a Windows computer, open the Group Policy Management Editor and edit a group policy object that applies to Mac computers.
2. Expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Settings, and double-click Enable Wi-Fi Profile.
3. Select Enable, then click Add.
4. Enter the following information for the Wi-Fi profile:

   Select this	To do this
   SSID	Type the SSID for the wireless network.
   Template name	Type the name of the auto-enrollment machine certificate that has been pushed down from the Windows domain server. When pushed to a Mac computer, certificate names are prepended with auto_; for example: auth_Centrify-1X This group policy runs a script that looks for the specified certificate template in the /var/Centrify/net/certs directory (which contains the certificate templates pushed down from the domain controller) and creates an ethernet profile from this certificate.
   Security type	Select the Security type from the drop-down list.
   Other options	Select one or more of the following options: Auto join: Select this option to specify that the computer automatically join a Wi-Fi network that it recognizes. Do not select this option to specify that the logged in user must manually join a Wi-Fi network. Hidden network: Select this option if the Wi-Fi network does not broadcast its SSID.

5. Click OK to save the profile information and OK again to save the policy setting.

   This group policy will take effect at the next group policy update interval, or you can run adgpupdate in a Terminal window on the Mac computer to have the policy take effect immediately.

When the group policy takes effect, it runs a script to create a WiFi profile for the computer from the certificate template and private key downloaded from the domain controller. This policy supports WEP or WPA/WPA2 security with the TLS protocol for certificate-based authentication. The Mac computer is now configured for access to the radius access point.

On the Mac computer you can view the profile in System Preferences.

Confirming that Windows Server Supports Certificate Auto-enrollment

This section describes how the RADIUS server must be configured to support 802.1X wireless configuration for Mac computers.

Internet Information Services (IIS) Supports CertEnroll and CertSrv URLs

IIS must support the CertEnroll and CertSrv URLs to enable web-based access to certificate tasks.

To verify that IIs supports the CertEnroll and CertSrv URLs

1. On the Windows Certificate Authority server, click Start > Administrative Tools > Server Manager to open Server Manager.

2. Expand Roles > Web Server (IIS) and click Internet Information Services (IIS) Manager.

3. In the right, Connections pane, expand Sites > Default Web Site and you should see CertEnroll and CertSrv:

   

Windows Public Key Group Policies are Set to Trust the Root Certificate Authority and Enroll Certificates Automatically

Through group policy settings, the root certificate must be imported into the Trusted Root Certification Authorities group policy and set to enroll certificates automatically.

To verify that Windows public key group policies are set to trust the root certificate authority and enroll certificates automatically

1. On the Windows Certificate Authority server, click Start > Administrative Tools > Server Manager to open the Group Policy Management Editor.

2. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and select Trusted Root Certification Authorities.

   You should see your root certificate:

   

3. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and double-click Certificate Services Client - Auto-Enrollment.

4. In Configuration Model select Enabled.

5. Select both boxes, Renew expired certificates and Update certificates that use certificate templates.

6. Click OK to save the policy.

A Certificate Template is Configured to Automatically Enroll Domain Computers

To automatically enroll domain computers, you must have a certificate template that supports auto-enrollment for domain computers.

To configure a certificate template to automatically enroll domain computers

1. On the Windows Certificate Authority server, open an mmc console that contains the Certification Authority and Certificates snap-ins (Start > Run >mmc.exe).

2. If snap-ins for Certificate Templates, Certificates, and Certifications Authority are not displayed under Console Root in the navigation pane, add them now. To do so, click File > Add/Remove Snap-in.

   1. Select Certificate Templates and click Add.
   2. Click Certificates and click Add.
   3. Select Computer Account and click Next.
   4. Select Local computer and click Finish.
   5. Select Certification Authority and click Add.
   6. Select Local computer and click Finish.
   7. Click OK.

3. Select Certificate Templates (domainController) in the navigation pane.

4. In Certificate Templates, duplicate the Workstation Authentication certificate. Right-click Workstation Authentication and select All Tasks > Duplicate Template.

5. Perform the following steps in the Properties of New Template dialog:

   1. In the General tab, type a template name of your choice (for example, Mac Auto-Enroll Certificates) in the Template name field (do not use special characters such as brackets and asterisks). Type the same name in the Template display name field so that the template displays by that name in the Certificate Templates list.

   2. In the Extensions tab, select Application Policies > Edit. In the resulting dialog, select Add > Server Authentication and click OK.

   3. In the Extensions tab, verify the Client Authentication is already in the application policy list. If it is not, add it in the same way that you added the Server Authentication policy.

   4. In the Subject Name tab, select Build from this Active Directory information. In the Subject name format field, select Fully distinguished name. In the Include this information in alternate subject name list, select User Principle Name (UPN).

   5. In the Security tab, select Domain Computers (domainController) and ensure that the template is enabled for Enroll and Autoenroll.

      

   6. Click Apply and OK to save your settings.

6. Verify that the new template has been added to the certification authority.

   Expand Console Root > Certification Authority > domainController and select Certificate Templates. You should see that the certificate template that you have configured for auto-enrollment is contained in the certification authority for the domain:

   

   If the new certificate template is not contained in the certification authority, add it now:

   1. In the navigation pane, right-click Certification Templates under Console Root > Certification Authority > domainController.
   2. Select New > Certificate Template to Issue.
   3. Scroll to the newly created template, select it, and click OK.

7. Enable the following group policy:

   • On Windows 2008: Computer configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment Settings.

   • On Windows 2012: Computer configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment

     To enable a group policy, open the Group Policy Management console by selecting Start > Administrative Tools > Group Policy Management. In the Group Policy Management console navigation pane, expand Group Policy Management >ForestName> Domains > DomainName > Group Policy Objects. Right-click Default Domain Policy and select Edit. In the resulting Group Policy Management Editor, navigate to the group policy described above and double-click the group policy. In the resulting dialog, select Enabled in the Configuration Model field.

8. On the Mac computer, download the certificates by executing the following commands in a terminal window:

   sudo adflush

   adgpupdate

9. Verify that the certificates were downloaded:

   1. On the Mac computer, open Keychain Access and verify that the certificates are there.
   2. On the Mac computer, verify that the certificates are in /var/Centrify/net/certs.
   3. On the Windows Certificate Authority server, open the Certification Authority console (Start > Run > certsrv.msc) and verify that the certificates are in the Issued Certificates folder.

A Certificate Template is Configured to Automatically Enroll Domain Users

To automatically enroll domain users, you must have a certificate template that supports auto-enrollment for domain users.

To configure a certificate template to automatically enroll domain users

1. On the Windows Certificate Authority server, open an mmc console that contains the Certification Authority and Certificates snap-ins (Start > Run >mmc.exe).

2. Verify that the snap-ins described in Step 2 are present under Console Root in the navigation pane. If they are not, add them now as described in Step 2.

3. Select Certificate Templates (domainController) in the navigation pane.

4. In Certificate Templates, duplicate the User certificate. Right-click User and select All Tasks > Duplicate Template.

5. Perform the following steps in the Properties of New Template dialog:

   1. In the General tab, type a template name in the Template name field. Type the same name in the Template display name field so that the template displays by that name in the Certificate Templates list. For Mac, you can specify a name of your choice (do not use special characters such as brackets and asterisks). For mobile devices, the template name must be User-ClientAuth.
   2. In the Security tab, select Domain Users (domainController) and ensure that the template is enabled for Enroll and Autoenroll.
   3. Optionally, in the Subject Name tab, select Build from this Active Directory information. De-select the Include email in subject name and E-mail name check boxes. If you perform this step, Active Directory users do not need an email address.

6. Verify that the new template has been added to the certification authority as described in Step 6. If the new certificate template is not contained in the certification authority, add it now as described in Step 6.

7. Enable the following group policy:

   • On Windows 2008: Computer configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment Settings.

   • On Windows 2012: Computer configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment.

     See Step 7 for details about how to enable the group policy.

8. On the Mac computer, download the certificates by executing the following commands in a terminal window.

   As the local Administrator:

   sudo adflush

   As an Active Directory user:

   adgpupdate

9. Verify that the certificates were downloaded:

   1. On the Mac computer, open Keychain Access and verify that the certificates are in the Login keychain.
   2. On the Mac computer, verify that the certificates are in ~/.centrify/:

ls -l ~./centrify/

Configuring Single Sign-On for SSH and Screen Sharing

On OS X 10.10 and later, you can change configuration settings to allow single sign-on for SSH and Screen Sharing using Kerberos. Kerberos authorization for SSH and Screen Sharing allows you to establish an SSH or Screen Sharing connection to configured target machines joined to the same domain within the same single sign-on (SSO) session. In addition to authorizing SSH or Screen Sharing for the currently logged in user, you can authorize SSH or Screen Sharing for a different smart card user (for example, an admin user) by obtaining that user’s Kerberos credentials.

To configure SSH SSO

Smart card authentication for SSH sessions across different forests or domains is not supported.

1. Verify that all client and target machines are joined to the same AD domain.

   See Joining an Active Directory Domain for more information.

2. Enable GSSAPIAuthentication and GSSAPIDelegateCredentials in the /etc/ssh/ssh_config (/etc/ssh_config on OS X 10.10) file on both the client and target machine.

   GSSAPIAuthentication yes

   GSSAPIDelegateCredentials yes

3. Enable GSSAPIAuthentication and GSSAPIKeyExchange in the /etc/ssh/sshd_config (/etc/sshd_config on OS X 10.10) file on both the client and target machine.

   GSSAPIAuthentication yes

   GSSAPIKeyExchange yes

   As of macOS 10.12, Apple's built-in ssh server no longer supports as the target machine. You can still use SSH SSO to login to other server machines, such as Linux/UNIX machines.

4. Enable adclient.krb5.autoedit on the target machine.

   The easiest way to do this is enabling the DirectControl Settings > Kerberos Settings > Manage Kerberos configuration group policy.

5. Restart IBM Security Management Services on the target machine.

   $ sudo /usr/local/share/centrifydc/bin/centrifydc restart

   The logged in user can now open SSH connections to the target machine using a FQDN.

   $ ssh hostname.domainname

To configure Screen Sharing SSO

Single sign-on for Screen Sharing requires Mac OS X 10.11 or higher.

1. Verify that both the client and target machines are updated to at least IBM Security Management Services 5.3.1.

   $ adinfo -v

   adinfo (CentrifyDC 5.3.1-xxx)

   If an update is necessary, refer to Upgrading the IBM Security DirectControl Agent for Mac for instructions and best practices.

2. Open System Preferences > Sharing, then select Screen Sharing and specify which users can initiate Screen Sharing sessions in the Allow access for: list.

   

   Only Screen Sharing supports SSO, as Remote Management can not allow access for network users.

   The logged in user can now open Screen Sharing connections to the target machine using a FQDN.

   $ open vnc://hostname.domainname

To obtain Kerberos credentials for a smart card user for SSH or Screen Sharing SSO

1. Complete all the steps in To Configure SSH SSO and To Configure Screen Sharing SSO above.

2. Insert the user’s smart card into the reader.

3. Obtain Kerberos credentials from the smart card currently in the reader and use those credentials to authorize SSH.

   For multi-user PIV cards or multi-user smart cards:

   $ /usr/local/bin/sctool -a unixName

   For all other smart cards:

   $ /usr/local/bin/sctool -k userPrincipalName

   Refer to Understanding sctool for more information about the sctool -a and -k options.

   After unlocking the smart card, you can now open SSH or Screen Sharing connections to the target machine using the obtained Kerberos credentials.

Configuring FileVault 2

FileVault 2, available in OS X 10.8 and later, allows encryption of an entire drive to keep data secure. Although you can enable FileVault 2 through System Preferences on your Mac computers, using IBM Security Management Services for Mac to configure FileVault 2 through group policy provides the advantage of creating an institutional recovery key for each of your Mac computers. Two different recovery key approaches—institutional and personal—guarantee that you will always have access to all of your encrypted computers, even if users forget their passwords.

For more information about FileVault 2, see the following Apple Knowledge Base article: “OS X: About FileVault 2".

How Filevault2 Protection Is Enabled by IBM Security

IBM Security relies on two features to enable FileVault 2 protection

• The "Managed By" user setting, which specifies an Active Directory user who can manage and unlock an encrypted disk.

  You specify the “Managed By” user in Active Directory Users and Computers on the domain controller. The "Managed By" user is associated with the Mac computer object, so it is possible for each computer to have its own "Managed By" user.

• The FileVault recovery key, which can be either one “institutional” key that is applied to multiple Mac computers, or computer-specific keys which are generated individually for each Mac computer.

  • If you choose to use one institutional key, you first create a FileVaultMaster certificate, which is applied to Mac computers through the Enable FileVault 2 group policy.

    When you enable the Enable FileVault 2 group policy, the FileVaultMaster certificate is applied to Mac computers automatically at the next scheduled group policy update interval. Or, you can apply the FileVaultMaster certificate immediately by executing the adgpupdate command.
    

  • If you choose to use computer-specific keys that are unique to each Mac computer, you do not create a FileVaultMaster certificate.

    Instead, the key is generated automatically when the “Managed By” user logs into the Mac computer for the first time and then logs out. The key, which is the “Managed By” user’s personal key, is then stored in the computer’s computer object in Active Directory.
    >**Note**: Enabling the Enable FileVault 2 group policy does not enable FileVault 2 protection on the Mac computers to which the group policy is applied. Instead, FileVault 2 protection is enabled on Mac computers as described in the remainder of this section.

The following list describes the overall process that results in FileVault 2 protection being enabled on a Mac computer.

1. The “Managed By” user is set in ADUC for one or more Mac computers.

2. The Enable FileVault 2 group policy is enabled.

   • If you select the Use Institutional Recovery Key option in the group policy, the FileVaultMaster certificate is applied to Mac computers. In this situation, all of the Mac computers to which the group policy was applied use the same key.
   • If you did not select the Use Institutional Recovery Key option in the group policy, a recovery key is not generated until the “Managed By” user logs into a Mac computer.

3. A user logs into a Mac computer. If FileVault 2 protection is not already enabled on the computer, the user’s Active Directory credentials are checked to verify that the user is the “Managed By” user. For this step to complete successfully, one of the following conditions must exist:

   • The Mac computer must be able to communicate with the domain controller (that is, it must be in connected mode), or
   • If the Mac computer is disconnected from the domain controller, locally cached AD user credentials must be available in the IBM Security cache.

4. When the user is verified to be the “Managed By” user, one of the following actions takes place:

   • If you selected the Use Institutional Recovery Key option in the Enable FileVault 2 group policy, the FileVaultMaster certificate data is used to enable FileVault 2 protection on the computer.
   • If you did not select the Use Institutional Recovery Key option in the Enable FileVault 2 group policy, a personal recovery key is created for the computer and stored in the computer object in Active Directory. The personal recovery key is used to enable FileVault2 protection on the computer.

FileVault 2 Configuration Overview

Configuring a Mac computer for FileVault 2 protection requires configuration steps on both the Mac computer and the domain controller (or any Windows computer on which you can configure Group Policy on the domain controller). The following is a list of the major steps in the process, with links to each procedure that you must complete.

1. Create FileVault master keychain. The master keychain contains a private key that can be used to unlock the encrypted disk.

   This step is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific (“personal”) keys, go to Step 4.

2. Export certificate from FileVault master keychain and upload it to a domain server. Uploading the certificate to a domain server allows you to select it when you enable the “FileVault 2” group policy.

   This step is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific (“personal”) keys, go to Step 4.

3. Enable BitLocker Recovery Password Viewer in Active Directory.

   This step is required only if you are using computer-specific (“personal”) keys. If you are using one institutional key for multiple Mac computers, go to Step 4.

4. Assign an Active Directory user who is authorized to manage an encrypted disk. FileVault 2 requires that you specify one or more “Managed By” users who can manage the encrypted disk, including the ability to lock and unlock it.

5. Enable the Enable FileVault 2 group policy. Enabling the “FileVault 2” group policy applies the FileVaultMaster certificate to Mac computers.

6. Set up and verify FileVault 2 protection. After FileVault 2 protection is enabled, the disk encryption process begins after the FileVault-authorized user logs off the computer.

Before You Begin Configuring Filevault 2

Be aware of the following requirements and limitations when configuring FileVault 2 through IBM Security group policy:

• The Mac computer must be running OS X 10.9 or above.

• The Mac computer must have a recovery partition — generally, this partition is created by default during Mac OS X or macOS installation.

• FileVault 2 must not be enabled on the Mac computer (through the Security & Privacy System Preference).

  If it is already configured, configuring FileVault 2 through IBM Security Management Services for Mac will have no effect.

• Enabling FileVault 2 protection disables auto log on for the Mac computer.

• FileVault 2 protection does not support smart card authentication at start up of the computer.

  The Apple technical white paper, "Best Practices for Deploying FileVault2" provides more information about using FileVault 2; specifically, the section “Two Factor Authentication” discusses the limitations of using FileVault 2 with alternate authentication methods such as smart cards.

Create Filevault Master Keychain

The procedure described in this section is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific (“personal”) keys, go to the section below, Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk.

On the Mac computer, you create a FileVault master keychain, which contains a private key that can be used to unlock the encrypted drive on the computer.

You can create the master keychain through the Mac user interface, or by executing commands in the Terminal application. Instructions are provided for each procedure.

If the computer already has a FileVault master keychain, you can skip this procedure and go to Export certificate from FileVault master keychain and upload it to a domain server.

To create a master keychain through the user interface

1. On a computer running OS X 10.9 or above, log on with an administrator’s account and open System Preferences, then double-click Users & Groups.

2. If necessary, click the lock icon and enter credentials to authenticate.

3. Select an administrator’s account, then click the service icon () and select Set Master Password from the pop-up menu.

   

4. Create a master password by typing it in Master password and re-typing in Verify.

5. Click OK to save the master password.

Setting a master password creates a keychain file in the following location:

/Library/Keychains/FileVaultMaster.keychain

This file contains the private key required to unlock the encrypted disc and is the only recovery method you will have for encrypted disc recovery. Store FileVaultMaster.keychain in a safe location, such as an external drive or an encrypted disk image on another physical disk.

To create a master keychain by executing commands in the Terminal application

1. On a Mac computer, open the Terminal application.

2. Run the following command:

   sudo security create-filevaultmaster-keychain

3. Enter the password for the root account when prompted as follows:

   To proceed, enter your password or type Ctrl-C to abort

4. Enter the master password to create when prompted to do so:

   password for new keychain

5. Retype the new master password when prompted to do so:

   retype password for new keychain

   You will see a message that the new password is being created:

   Generating a 2048 bit key pair; ...

Setting a master password creates a keychain file in the following location:

/Library/Keychains/FileVaultMaster.keychain

This file contains the private key required to unlock the encrypted disc and is the only recovery method you will have for encrypted disc recovery. Store FileVaultMaster.keychain in a safe location, such as an external drive or an encrypted disk image on another physical disk.

Export Certificate from Filevault Master Keychain and Upload it to a Domain Server

The procedure described in this section is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific (“personal”) keys, go to the section below Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk.

After you create a master password, as explained in the previous section, you must export the certificate associated with the master keychain to make it available for upload to the domain controller.

You can export the certificate by using the Mac user interface, or by executing commands in the Terminal application. Instructions are provided for each procedure.

To export the certificate by using the Keychain Access utility

1. On the Mac computer, open the Keychain Access utility, or double-click the FileVaultMaster.keychain file, which is at the following location:

   /Library/Keychains/FileVaultMaster.keychain

2. Enter you password if prompted to do so.

3. In Keychains, select FileVaultMaster.

   

4. Select the certificate, FileVault Recovery Key in the right pane and expand it; then right-click and select Export “FileVault Recovery Key”.

   

5. Enter the following information for saving the certificate:

   

   • Save As: Type a name for the certificate, such as “FileVaultMasterCert”.

   • Where: Navigate to a folder in which to save the certificate.

   • File Format: Select Certificate (.cer) from the scroll-down list.

     The certificate is now available for upload to a domain controller.

6. Copy the certificate to a location on a server that is accessible from the computer that you use to configure Group Policy for the domain.

   Later, when you enable the group policy to turn on FileVault 2 protection (see Enable the Enable FileVault 2 Group Policy below), you must be able to access this certificate from the domain controller on which you are running the Group Policy Editor.

To export the certificate by using Terminal commands

1. On the Mac computer, open the Terminal utility application.

2. Run the following command:

   sudo security export -k /PathToKeychain -t certs -f x509 -o /PathToCert

   The sudo command is required only if FileVaultMaster.keychain is owned by root.

   where:

   • PathToKeychain is the path to FileVaultMaster.keychain; for example:

     /Library/Keychains/FileVaultMaster.keychain

   • PathToCert is the path to the location in which to export the certificate; for example:

     /Documents/FileVaultMaster.cer

   • The certificate is now available for upload to a domain controller.

3. Copy the certificate to a location on a server that is accessible from the computer that you are using to configure Group Policy for the domain.

   Later, when you enable the group policy to turn on FileVault 2 protection (see Enable the Enable FileVault 2 Group Policy below), you must be able to access this certificate from the domain controller on which you are running the Group Policy Editor.

Enable Bitlocker Recovery Password Viewer in Active Directory

The procedure described in this section is required only if you are using computer-specific (“personal”) keys. If you are using one institutional key for multiple Mac computers, go to Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk, below.

To enable the BitLocker Recovery Password Viewer feature in Active Directory

1. On the domain controller, open Administrative Tools > Server Manager.
2. In the navigation pane, right-click Features and select Add Features.
3. In the Add Features wizard, expand Remote Server Administration Tools > Feature Administration Tools, select BitLocker Drive Encryption Administration Utilities, click Next, and click Install.
4. After the BitLocker Drive Encryption Administration Utilities are installed, click Close.

5. To verify that the BitLocker Drive Encryption Administration Utilities are installed:

   1. Open Active Directory Users and Computers.
   2. Navigate to domaincontroller > Domain Controllers.
   3. In the right-hand ADUC pane, right-click the domain controller and select Properties.
   4. If the BitLocker Drive Encryption Administration Utilities installed correctly, the Properties dialog contains a Bitlocker Recovery tab. On that tab, a “No items in this view” message displays. That message is normal, and does not indicate a problem with the BitLocker Drive Encryption Administration Utilities installation.

Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk

Before enabling FileVault 2, you must assign a user account that is able to open the disk for the Mac computer after it is encrypted by FileVault 2. This setting specifies the “Managed By” user for a computer.

Enabling the “FileVault2” group policy, as explained in the next section, encrypts the entire disk for the computer. The user account that you assign in the current procedure will be authorized to access the disk during boot up so that this account will be able to log on. You can later add other accounts, but for now, this is the only account that will be able to log on to this computer.

The “Managed By” user account must be an Active Directory mobile user account.

After you enable a user account to open an encrypted disk at start up, you cannot remove that account from the list. If you no longer want this user account to be able to unlock the disk, you can delete the account from Active Directory. Before doing so, be certain that you have at least one other account that can unlock the hard disk on this computer, otherwise you will no longer be able to access this computer.

To assign an account that can unlock the encrypted disk

1. On a domain controller, open Active Directory Users and Computers

2. Expand the domain object and navigate to the container that contains the Mac computer, for example, Computers.

3. Select the Mac computer that you plan to encrypt, right-click and select Properties.

4. Click the Managed By tab.

   

5. Click Change.

6. Enter the all or part of the name to search for (make certain that User is selected in Object Type) and click Check Names.

   

7. If the name is correct, click OK then OK again to save your changes.

Enable the Enable Filevault 2 Group Policy

Next, enable the “Enable FileVault 2” group policy to encrypt the disk. When you enable this group policy, you select whether to use one institutional key for multiple Mac computers, or computer-specific (“personal”) keys.

To enable the Enable FileVault 2 group policy

1. On a Windows computer, open the Group Policy Management Editor.

2. Select a Group Policy Object that applies to the Mac computer you are planning to encrypt, then right-click and select Edit.

3. Open Computer Configuration > User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy, then double-click Enable FileVault 2.

4. Click Enable.

5. Specify whether to use one institutional key for multiple Mac computers, or computer-specific (“personal”) keys:

   • To use one institutional key for multiple Mac computers, select Use Institutional Recovery Key. Then click Select to select the FileVault keychain certificate that you created earlier as described above in Create FileVault Master Keychain. If you select this option, the FileVaultMaster certificate is distributed to all of the Mac computers to which the group policy applies. Go to Step 6 and continue from there.
   • To use computer-specific (“personal”) keys, leave Use Institutional Recovery Key unchecked. In this situation, a personal recovery key is created for the Mac computer and stored in the computer object in Active Directory. The key is created and sent to the computer object in Active Directory after the “Managed By” user reboots the Mac computer (or restarts the agent), logs in, logs out, and provides the user password as described below in Set Up and Verify FileVault 2 Protection. The personal recovery key is used to enable FileVault2 protection on the Mac computer. Go to Step 8 and continue from there.

6. In the Explorer dialogue, navigate to the folder in which you uploaded the certificate.

7. Select the certificate and click Open.

   

8. Click OK to enable the group policy.

   This group policy will automatically take effect at the next group policy update interval. To have it take effect immediately, run the following command in the Terminal application on the Mac computer:

   adgpudate

   If you selected Use Institutional Recovery Key in Step 5, the FileVaultMaster certificate name, a thumbnail, and the expiration date are displayed in the Group Policy.

   

   The expiration date is not important because OS X does no revocation checking on this certificate.

   The selected certificate should have the following usages: “Digital Signature”, “Key Encipherment”, “Data Encipherment” and “Key Certificate Sign”. If the certificate does not have these usages, an error message will appear:

   

Set Up and Verify Filevault 2 Protection

FileVault 2 protects a Mac computer by encrypting the entire hard drive when a FileVault-authorized user (the “Managed By” user) logs out. To set up FileVault 2 for the first time, you must log on to the Mac computer as the “Managed By” user, then log out, as explained in the following procedure. After FileVault 2 is set up, only a FileVault 2-authorized user may start up the Mac computer. You may add more authorized users if you wish, or maintain a single account.

Although starting up the Mac computer requires a user account that is authorized to decrypt the start up disk, after the computer has started, this user account may log out to allow other user accounts to log in.

To set up FileVault 2 protection

1. Log on to the Mac computer with the “Managed By” account that you specified above in Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk.

2. Log the “Managed By” user out of the Mac computer, and when prompted, enter the user’s password to set up FileVault 2 protection.

   

   The system displays a message that it is enabling FileVault protection, and when finished, restarts the computer.

   

3. Log back on to the Mac computer with the “Managed By” account.

   The log on screen will show the FileVault 2-authorized user alone, because this is the only user authorized to open the start up disk.

4. Open System Preferences, click Security & Privacy and click the FileVault tab to verify details about FileVault protection.

5. Log out the FileVault-authorized user.

   The log on screen now shows all users who are authorized for the computer.

A FileVault-authorized user is always required to start up the computer because the start up disk is encrypted. However, after the computer is running, any authorized user can log on to the computer. At this point, you have specified a single authorized account. To add more FileVault-authorized users, see the next section, Adding FileVault-Authorized Users.

Adding Filevault-Authorized Users

You can assign only one user as the “Managed By” user for the computer in Active Directory. If you want to authorize additional users to manage FileVault 2 protection, you must do so on the Mac computer by performing either one of the following procedures.

To authorize FileVault 2 users by using System Preferences

1. On the Mac computer, open System Preferences > Security & Privacy.
2. Click the FileVault tab, and if necessary, unlock the padlock.
3. Click the Enable Users button and an account list pops up.
4. Click Enable Users to add and enter password of that user.

To authorize FileVault 2 users by using Terminal commands

1. On the Mac computer, open the Terminal application.

2. Run the following command:

   sudo fdesetup add -usertoadd user1

   If prompted, enter the sudo password.

3. When prompted, enter the primary FileVault-authorized user name — this is the user who you specified to manage FileVault 2 (in the section above, Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk).

4. When prompted, enter the password for the primary FileVault-authorized user.

5. When prompted, enter the password for the new user who you specified on the command line (user1 in this example).

Changing FileVault 2 Settings

After you enable FileVault 2, the settings that you are most likely to change at a later time are the “Managed By” user and the FileVaultMaster certificate.

To change the “Managed By” user on a Mac computer

1. Disable FileVault 2 manually on the Mac computer as described below in Disabling FileVault 2 Protection.
2. On the domain controller, change the “Managed By” user as described in the section above, Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk.
3. Ensure that the Mac computer can communicate with the domain controller (that is, it is in connected mode) so that it can fetch the new “Managed By” user information from Active Directory.

After you complete these steps, FileVault 2 protection is enabled on the Mac computer the next time the new “Managed By” user logs into the Mac computer.

To change the FileVaultMaster certificate

The procedure described in this section is supported only if you are using one institutional key for multiple Mac computers (that is, if you selected Use Institutional Recovery Key in Enable the Enable FileVault 2 Group Policy, above).

1. Disable FileVault 2 manually on each Mac computer that will use the new FileVaultMaster certificate. In most situations, this includes all computers to which the Enable FileVault 2 group policy is applied.

2. Specify a new FileVaultMaster certificate in the Enable FileVault 2 group policy as described in Enable the Enable FileVault 2 Group Policy, above.

3. Execute the adgpupdate command to have the Enable FileVault 2 group policy implement the new FileVaultMaster certificate on the Mac computers.

   If you do not execute adgpupdate, the old FileVaultMaster certificate is used until the next scheduled group policy update interval.

After you complete these steps:

• All Mac computers on which you disabled FileVault 2 (in Step 1) will use the new FileVaultMaster certificate the next time the “Managed By” user logs in.
• FileVault 2 protection is enabled on a Mac computer the next time the “Managed By” user logs into that Mac computer.

Disabling FileVault 2 Protection

The only way to disable FileVault 2 protection is manually on the Mac computer. You cannot disable it by disabling the Enable FileVault 2 group policy.

You can disable FileVault 2 protection through the Security & Privacy System Preference, or by issuing commands in the Terminal application — view one or the other of the two sets of instructions that follow.

To disable FileVault 2 protection by using Security & Privacy preferences

1. On the Mac computer, open System Preferences > Security & Privacy and click the FileVault tab.
2. Click the padlock and enter authentication information to unlock System Preferences.
3. Click Turn Off FileVault.
4. Click the padlock to secure the changes.
5. Restart the Mac computer.

The disk is no longer encrypted and all authorized users, not just FileVault-authorized users, should be visible on the log on screen.

To disable FileVault 2 protection by issuing Terminal commands

1. On the Mac computer, open the Terminal application.

2. Enter the following command:

   sudo fdesetup disable

3. Enter the root password when prompted.

4. Enter the password for the user account that is authorized to lock or unlock the disk.

   This is the password for the user who you assigned in Active Directory to manage the Mac OS X computer.

5. Restart the Mac computer.

The disk is no longer encrypted and all authorized users, not just FileVault-authorized users, should be visible on the log on screen.

What Happens if the Filevault-Authorized User’s Password is Reset?

If the password is reset while the computer is off or not connected to the domain, the password will not be immediately updated so the user must first log in with the old password, then back in with the new password.

For example, follow these steps for a sample set up such as the following:

• The Mac computer is turned off.
• FileVault 2 is enabled.
• user1 is the primary FileVault 2 authorized user.

1. An administrator changes the user1 password in Active Directory Users and Computers (through Reset Password), and informs user1 of the change.
2. You start up the computer, log on as user1, and enter the new password, which fails.
3. Enter the old password, which works.
4. Restart the computer, log on and enter the new password, which should be successful.

Restoring the Filevault User List After Adflush

In Verify Privilege Server Suite, if your FileVault 2 user list contains mobile users from another forest with one-way trust (that is, cross-forest mobile users), it is possible that those users will be removed from the FileVault 2 user list after you execute adflush or adflush -f.

After you upgrade to release 2015.1 or later, perform the following steps to ensure that cross-forest mobile users are added to the FileVault 2 user list permanently:

1. Execute the following command:

   adflush -f

   Executing this command removes the 2015-format, temporary GUID from cross-forest mobile users.

2. Execute the following command for each cross-forest mobile user that you want to add permanently to the FileVault 2 user list:

   adquery user -guid cross-forest-mobile-user-name

   Executing this command assigns a new, permanent GUID to each user that you specify.

3. Execute the following command for each cross-forest mobile user that you want to add to the FileVault 2 user list:

   fdesetup add -usertoadd cross-forest-mobile-user-name

   Executing this command adds the specified user to the FileVault 2 user list.

4. Execute the following command to verify that the users are added to the FileVault 2 user list:

   fdesetup list

How to Recover an Encrypted Disk

If a user forgets the password for their encrypted disk, you can unlock the disk for them using the institutional recovery key that you created. See the following two Web articles for information:

• Apple Support: “OS X: How to create and deploy a recovery key for FileVault 2”.

  Note that you have already created the recovery key — you only need to read the information in the “Recovery” section.

• “Unlock or decrypt your FileVault 2-encrypted boot drive from the command line”

Deploy Configuration Profiles to Multiple Computers

This section explains how to deploy mobile configuration profiles to multiple computers by using a group policy setting (Install mobileconfig Profiles).

You can create mobile configuration profiles in a number of ways, for example by using the iPhone Config utility or OS X Server Profile Manager. This document assumes that you have already created a profile that you want to deploy, but does not show you how to do so.

You can deploy either computer or user profiles. For computer profiles, this feature requires OS X 10.7 or higher. For user profiles, this feature requires OS X 10.9 and higher.

The process for deploying a mobile configuration profile is as follows:

1. Create the mobile configuration profile.
2. Create a subdirectory in SYSVOL on the domain controller and copy the mobile configuration profile file to this directory. SYSVOL is a well-known shared directory on the domain controller that stores server copies of public files that must be shared throughout the domain.
3. Enable the “Install mobileconfig Profiles” group policy and specify the name of the file that you copied to SYSVOL.
4. The mapper script for the group policy runs on each Mac computer controlled by the GPO (when a user logs in or runs adupdate), downloads the profiles from the Active Directory server, and installs them in the Profiles system preference.

To create a subdirectory in SYSVOL:

1. Log in to the domain controller.

2. Change to the SYSVOL directory.

   For example, go to this directory:

   C:WindowsSYSVOLdomain

3. Create a new folder named mobileconfig.

   Be certain that the name of the folder is exactly as shown in the step above. The group policy setting allows you to specify the name of the file but it always looks in SYSVOL\mobileconfig. Likewise, do not create sub-folders — the group policy does not look in sub-folders.

To copy configuration files to SYSVOL on the domain controller:

1. In the Finder on the Mac computer navigate to the folder that contains the profile to copy.
2. Select the file, for example, settings_for_all.mobileconfig and copy it to the desktop. When prompted, enter your administrator password to copy the file.

3. On the desktop, change the file permissions for settings_for_all.mobileconfig as follows, so you can copy it to SYSVOL:

   1. Select the file and click File > Get Info.
   2. In the dialog box, expand Sharing & Permissions, then click the lock icon and provide administrator credentials for making changes. Set the permissions for everyone to Read only.
   3. Reset the lock and close the open dialog.

4. On the Mac computer, copy the file from the desktop to SYSVOL on the Windows domain controller. If you are connected to the domain, you should see the domain controller in the Finder. If the domain controller is not visible in the Finder, connect to it:

   1. Click Go > Connect to Server and select the domain controller.

   2. When prompted select SYSVOL; for example:

      

   3. Navigate to the mobileconfig directory you created, for example by clicking acme.com then mobileconfig.

   4. Drag the settings_for_all.mobileconfig file to mobileconfig.

To configure the “Install MobileConfig Profiles” group policy:

1. On the Windows domain controller, open the Group Policy Management Editor and select the GPO that is used to manage Mac computers.

2. Navigate to Computer Configuration > Policies > Mac OS X Settings > Custom Settings and double-click Install MobileConfig Profiles to install a machine profile.

   To install a user profile, navigate to User Configuration > Policies > Mac OS X Settings > Custom Settings and double-click Install MobileConfig Profiles.

3. Select Enabled.

4. Click Add, then enter the name of the file that you copied to SYSVOL, for example, settings_for_all.mobileconfig.

   Be certain to include the .mobileconfig suffix.

5. Click OK to add the settings_for_all.mobileconfig file.

6. Click OK to enable the policy.

   This group policy will copy the settings_for_all.mobileconfg file, and install the profile, on every computer to which the GPO applies and that is joined to the domain. Note that after the profile is installed, it is deleted from the Mac computer.

7. Run the adgpupdate command on each target Mac computer to trigger an update of group policies and execute the new Install MobileConfig Profiles policy settings.

   By default, group policies are updated automatically every 90 minutes, so you can skip this step and wait for the automatic update if you wish.

Note the following about this process:

• If you add a profile file to SYSVOL, but do not specify it in the group policy setting, the profile will not be installed. Likewise, if you specify a file in the group policy that does not exist in SYSVOL, the profile will not be installed.

• If you add new files to the existing list in the group policy, those profiles will be installed — existing profiles will not be touched.

• If you remove a file from the group policy list (after the profile for the file was installed), the profile for that file will be uninstalled from the managed Mac computers.

• If you modify a file, the corresponding profile will be reinstalled.

• If two or more profile files have the same payloadIdentifier attribute, only one of them will be installed.

• If you change the group policy to “Disabled” or “Not Configured”, all existing profiles that were installed previously by the group policy will now be uninstalled from the managed Mac computers.

  The "Install MobileConfig Profiles" group policy only supports macOS 10.15 and lower.