Mac OS X Extras: Using Centrify and AD GPOs to Manage File Vault 2 Disk Encryption

Background

Apple protects data at rest using symmetric encryption (AES-128) for OS X systems. File Vault 2 was introduced in OS X Lion and support for GPO Management with Centrify was released with version 2013.2 (5.1.1).  This post will document the steps to set up FV2 management leveraging Centrify's AD GPOs.

What are you gaining by doing this?
FV2 provides the mechanisms to generate an Institutional key to be distributed to systems.  With Centrify and leveraging GPOs this can be done centrally.  This way you can distribute the certificate and provide a mechanism for recovery in case an user can't decrypt their drive.

More Resources:
Brian does a great job here and John in the Centrify for Mac online CBT.  Thanks to both since I used their materials as research for this post.

Planning

Pre-Requisites to use Centrify GPOs with FileVault2

• The system hostname has to match how the computer was joined to active directory.
  To verify, on a terminal, type the hostname command and compare it with the joined as name in AD (adinfo --name).  Alternatively you can use the adquery user -A computername$ command too.  The command sudo scutil --set HostName your-hostname can update the hostname if needed.
  $ hostname
  mac109.local
  $ adinfo --name
  mac109.corp.contoso.com
  $ adquery user -A mac109$
  dn:CN=mac109,OU=Corporate,OU=Mac,DC=corp,DC=contoso,DC=com
  samAccountName:mac109$
• Ideally, the system is configured for Dynamic DNS; DNS is well-maintained or you issue the addns command.
  $ sudo addns -U -m
  Password:
  Updating host records for mac109.corp.contoso.com on 10.0.0.1.
  Updated host records mac109.corp.contoso.com.
  Updating reverse lookup records for mac109.corp.contoso.com on dc1.corp.contoso.com.
  Updated reverse lookup record  210.0.0.10.in-addr.arpa.
  
  $ ping mac109
  PING mac109.corp.contoso.com (10.0.0.210): 56 data bytes
  64 bytes from 10.0.0.210: icmp_seq=0 ttl=64 time=0.044 ms
  64 bytes from 10.0.0.210: icmp_seq=1 ttl=64 time=0.067 ms


• The Mac must have the recovery partition installed - this is required to boot and request the password to decrypt the disk.  You can use the diskutil list command to enumerate partitions.
  $ diskutil list | grep Recovery
  3:    Apple_Boot Recovery HD             650.0 MB   disk0s3
• Institutional Account - you need a mobile-enabled (see my video on how to do this with GPOs) AD account that can be used as the "Managed by" field in the computer object.

Other things to plan for:

• Assurance around the handling of the institutional certificate.
• Lifecycle management of the Certificate (usually good for a year but not checked by OS X)
• Securing the Institutional Account's password.
• Computers with File Vault 2 enabled by the end-user  (10.9 has improvements on this)

Implementation and Verification

First, we need to use a Centrified system as the "template" to create the FileVault2 Master Password with in turn will create a Certificate and a Keychain.

1. Sign-on to the template Centrified system with the Account to be used for Recovery.
2. Go to System Preferences > Users and Groups and unlock the Padlock
3. Click on the Gears under Login Options and Select "Set Master Password"
   
4. Navigate to /Library/Keychain and you will see two files: 
• FileVaultMaster.keychain
• FileVaultMaster.cer
  Double-click the FileVaultMaster.keychain, this will open KeyChain Access.
5. Right-click the FileVaultMaster Certificate and Select "Export FileVault Recovery Key" and save it as a .cer in a known location.

Note:  Make sure you delete all copies of the keychain, certificate and secure the .cer file after you have used it.

Now we need to setup the "Managed By" attribute in Active Directory for the computer object corresponding to the template system.

1. Open Active Directory Users and Computers (ADUC)
2. Navigate to find your MacOS template computer, right click and select properties.
3. Go to the Managed By tab and click Change.  Select the Recovery account.
   
4. Press OK and close ADUC

Next, we need to enable the GPO for File Vault 2.

1. Open GPMC and navigate to your Mac GPO, right click and select edit.
2. Navigate to Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security and Privacy  and select "Enable File Vault2" 
3. Enable the GPO and click select and browse to find the FileVault2 Certificate generated from the Master Key in the first section.
   
   Note the expiration of the Certificate.  You need to update the master keychain password and get the certificate renewed and the GPO updated in time (or not, given that OS X does not check validity)

Finally, we refresh the group policies and review the effective changes. This way the Centrify agent will distribute the certificate via GPO and set up File Vault 2 for you.

1. Log on to the Centrified Mac and open Terminal.  Run adgpupdate.  This will refresh the GPOs.
2. Log out.  This will prompt a synchronization of the mobile configuration.  Attempt login and you'll be prompted for the user's password.  This will enable FileVault2 and you'll go to firmware boot.  The user will be prompted for the password to decrypt FV2 and continue the boot process.
   
3. At this point you can verify that FV2 is being enabled by looking at System Preferences > Security and Privacy > File Vault 2.
   

At this point all we need to do is add additional users that can decrypt the FV2 disk, by using the Enable Users button.  This window will list all users with Mobile Accounts that can be added.  In this case, since this computer will be used by Fred Thomas and Diana Wirth, I enabled their accounts as well as the local admin Centrify SE.  You will need to type in each user's password or the user has to be present to type those credentials.

When users type in their AD password, they can continue to boot and their session is automatically logged in.

From now, all Centrified OS X computers joined to the target will be enabled for FV2 automatically and the AD account will be able to serve as recovery.

Adjustments

Here are some adjustment categories:

• Differences between OS X versions
• Automating the Master password/Keychain/Cert using a script
• Automatically adding mobile users to decrypt drives
• Helping an AD user with recovery
• Vaulting and cycling the recovery account
• Different recovery accounts by business unit using an OU, etc.

Videos

Mac OS X Extras: Using Centrify and AD GPOs to Manage Portable Home Directories

Background

In OS X it is possible to set up a mobile user account that provides synchronized home folders, one on your Mac and one on the network account server. With Centrify, these "portable home directories" can leverage the user's existing Windows home directory to consolidate information.  Centrify allows the use of AD Group Policy to manage Portable Home Directories.

Assuming you have a Centrified MacOS X system:

Planning

At a high level, these things need to be thought out:

• Windows home directories:  There are countless resources on this topic.  Home folders have to be created, and then assigned to users.  Keep in mind permissioning as well.
• Understand the version(s) of OS X in your environment and the mobility settings behavior:  Apple has modified the implementation of mobile accounts over several versions.  The advantage is that Centrify provides a GPO that considers multiple versions of the OS:
  
• Correct GPO scoping:  In this example we use loopback processing, however, based on your deployment, you may have multiple GPOs that apply to different AD principals.

Implementation

1. Open GPMC and edit the Centrify GPO for OS X systems.
2. On the left pane, navigate to "Computer Configuration > Policies > Centrify Settings > Adclient Settings" and in the right pane double click the "Enable Auto Zone user home directory (Mac OS X)"  and enable it.  This GPO modifies the auto.schema.use.adhomedir parameter in the /etc/centrifydc/centrifydc.conf file.
3. Navigate to "User Configuration > Policies > Centrify Settings > OS X Settings >   Mobility settings" and in the right pane double click the "Use version specific settings" GPO and enable it.
4. Based on the version of OS X that you have (in my example Mavericks 10.9) go to the corresponding folder (e.g. Mac OS X 10.8/9 settings) and enable the "Configure mobile account creation" - set it to enabled and check the "Create mobile account when user logs into the network"  check-box.
   
5. To make sure the GPO is refreshed on the Mac OS X client, just run the adgpupdate command.

Verify

1. On a Windows system with Active Directory Users and Computers (ADUC), open your test user account's properties and go to the Profile tab.  Make sure the home folder is set up appropriately for your environment.
2. Sign-in to your Centrified OS X system, you'll see the following:

   

   Upon login, the user is prompted to create their portable home directory.

Adjust

Adjustments will be based on your environment.  Here are some general items:

- What happens when accounts expire?  (should mobile home directories be deleted?)

- Home folders:  what items will be skipped? What items will be explicitly synchronized?

- Synchronization settings:  By default every 20 minutes automatically.

- Preference Sync rules, etc.

Lab Video

Business Cases - Web-Mobile SSO Planning Session II: Apps

Planning for Applications

When we plan for Applications (Web or Mobile), we need to think about different strategies.  These types of questions arise:

• How will the application be published?  
  Centrify provides the user portal, however, depending on your environment, you may have an intranet or content management platform that is used as a hub for applications.
  
• What is the policy to access these applications?
  Apps can have different assurance requirements.  Maybe certain portions of the HR app are for intranet-only access with step-up (or two-factor) authentication.  Maybe your Netsuite-based ERP should only be available from inside of the United States.
  
• Who should be entitled to access each app?
  Your security team may want to grant access based role or job function.  Centrify User Suite uses AD or Cloud Directory principals for app visibility.
  
• What are the authentication capabilities of the app?
  Modern (especially cloud-based apps) provide federation technologies (like SAML, etc) but legacy apps don't have those capabilities or aren't available in the current version.  Also (and unfortunately) not all apps may be looking at the corporate directory (e.g. AD) as the identity repository (which can enable Kerberos or NTLM).  CUS offers the flexibility of password-vaulting and replaying.
  
• How is the application provisioning model?
  This topic impacts the bottom-line of the business because the timely deprovisioning of cloud apps can impact the billing depending on how the application provider is metering the usage of the application.  In addition, some apps need to have entitlements provisioned as well for the purposes of role-based access.
  
• What is the strategy for on-premise apps?
  Are these apps accessible via an existing VPN infrastructure (e.g. CheckPoint, Cisco, Microsoft's DirectAccess or others) or will you make use of the Centrify App Gateway (VPN-less access)?
  

These are high-level categories, there are advanced topics like timeouts, attribute-mapping, provisioning of certificates for federation trust, etc; but we will cover each scenario individually.

We will start by publishing these Web applications:

• On-premises SharePoint (as a shortcut)
• On-premises Apache or Java-based apps (leveraging NTLM, Kerberos & ADFS-less WS-Fed apps)
• Google Apps
• Salesforce
• Office365.

Later we'll move on to Mobile apps on the Google Play and Apple App Store.

Labs - Web-Mobile SSO Planning Session I Videos

The videos below correspond to the first planning session for the Web-Mobile SSO use cases.

Lab 1 - Centrify User Suite Branding and Domains



Lab 2a - Cloud Connectors and Active Directory Integration



Lab 2b - Cloud Connectors and Active Directory Integration



Lab 2c - Exploring the AD Integration using Centrify Cloud Connectors



Lab 2d -  Understanding Login Suffixes

Business Cases - Web-Mobile SSO Planning Session I - Global Settings

In a previous post, we discussed the requirements for the Web and Mobile SSO use case, and although our labs are aimed to help with testing or proofs of concepts, we typically address the planning.  Many of the topics in the requirements are huge (like o365 or GoogleApps migration), but we'll do the best we can to outline some of the key parts of planning.

Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.

What this means is that you need to have multiple cloud tenants a test and a production tenant.  Ideally, you will have a test environment that mimics your existing infrastructure.  My advice is that you use a rolling wave when it comes to IdaaS as well.  Scenarios like switching how people access your CRM (e.g. Salesforce) or ERP (e.g. Netsuite) can affect the bottom-line.  I won't be implementing this, but keep it in mind when implementing any cloud service.

Marketing - Branding and imaging should be maintained.

Organizations pay a lot of money to establish a brand identity;  your Cloud-based solutions should allow you to maintain that branding.  Centrify offers the ability to implement logos for the self-service portal, email invitations, mobile enrollment, etc. In addition, the main corporate color can be implemented as well.  This means that ahead of time you need to collect:

• The Pantone color code for your organization (main color) for the portal ribbon
• The corporate logo in several sizes:
• 137x35 to be used as the login image
• 160x36 to be used as the portal image

Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex)

From an accounting perspective, organizations prefer to shift costs to the capital expense category due to tax benefits;  in addition, clouds allow for commoditization of IT infrastructure services that in the traditional way would require space, power, cooling and personnel to support those solutions. The biggest example is email; HOWEVER, this has to be reconciled with security requirements.

Access to these applications has to be granted to Active Directory users, but there are instances in which partners need access as well (who won't have AD accounts).  

A lot is stated in this paragraph.  In the context of Centrify User Suite this means:

• Deployment of Cloud Connectors (CC):  CCs are Windows computers that use the service bus to talk to the Centrify Cloud Service and internally to Active Directory.  They provide many capabilities, but the main one is the avoidance of explicit replication of data to the cloud. When planning for Cloud Connectors
• Keep in mind the requirements:  As you add more users, keep in mind that the cloud connector's cache will grow.  At the time of this writing Cloud Connectors require a 64bit system with a multicore processor and 8GB of RAM with 4GB dedicated for the cache.
• Availability requirements:  You need at least two cloud connectors for basic load-balancing and fail-over.  If you are in a multi-national organization, placement of the cloud connectors should be based on the data-center location in the cloud.
• Internal placement:  Like any AD services, the closer you are to a global catalog domain controller the better.
• If using the Microsoft CA, make sure that you place the cloud connector near an issuing CA.
• Connectivity:  Although cloud connectors only perform OUTBOUND connections, there are certain domains that need to be reachable.  A list is here.
• Active Directory permissions:  Although no changes will be made to AD (in terms of schema extensions or services) the computer running the cloud connector will be able to access AD.  Permissions are required for this operation.  The instructions are here.
• Allowing MDM capabilities from Active Directory Users and Computers (ADUC) and Group Policy Management:  You must plan which administrators will provide helpdesk-assisted MDM capabilities using ADUC or which AD admins will be allowed to edit Mobile-related GPOs.
• Use of the Centrify Cloud Directory:  In those instances in which third parties (contractors, partners) need access to internal apps, but can't have an AD accounts, this will be the preferred method.

These users may access using rich clients (browser) or mobile devices (iOS/Android browser and mobile apps);  connections can be centralized via a portal, directly initiated or via intranet shortcuts.  In the case of Office365, users will continue to use their full clients (Outlook, Lync, etc) on their Windows and Mac workstations.

This paragraph also contains major implications.

• Mobile Access:  This means that corporate information may be accessed from devices that aren't under the control of IT.  Fortunately User Suite provides Mobile Device, Container and Application management for iOS and Android.
• iOS:  Managing iOS devices means that an APNS certificate needs to be configured in the cloud service.  In addition, if apps are purchased by corporate or devices are running in kiosk mode
• Portals, Direct Connections and Shortcuts:  Centrify provides the cloud portal for self-service of apps, mobile and AD/cloud directory; however it's possible that users may access apps directly, in that case, users will be redirected to be authenticated by Centrify if they don't have an active valid session.  Shortcuts can be deployed in the intranet as well.
• The topic of Office 365 migration is huge, however, from a rich client perspective, this means that the lowest version of office has to be Office 2010 with the latest and greatest service packs.

Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

As of this writing, Centrify relies on a robust infrastructure (Microsoft Azure) to provide high performance, high availability and redundancy.  Stats on the availability of the service can be viewed at http://www.centrify.com/cloud/service-status.asp 

Disjointed Namespace - The solution should accommodate for a different domain (for AD) than the business name (Internet DNS name).  It uses corp.contoso.com internally, vs. centrifying.net outside.

This is very common;  typically the Active Directory suffix of the UPN (user principal name) is different than the DNS suffix commonly used to do business  (typically the suffix of the email address);  this means that a company may do business as na.ad.company.com;  but users of that region use @na.company.com as the common suffix.  Centrify User Suite provides settings to accommodate this scenario.

Go to Session I Lab Videos:  http://centrifying.blogspot.com/2014/12/labs-web-mobile-sso-planning-session-i.html

Cloud Lab # 0 - Signing-up for a Centrify Cloud Tenant

In a previous post, I discussed the capabilities of the Centrify Cloud Service.  Unfortunately this post will become obsolete because Centrify adds capabilities and tweaks the service every month, but as of December 2014 (v 14.10), here are the high-level capabilities:

To register for a Centrify cloud tenant you'll need an email address.  Follow these instructions:

1. Go to http://www.centrify.com/lp/trial/centrify-solutions.asp and request a trial.  Alternatively, you can register for an Express account via www.centrify.com > Free Products > Centrify Express for SaaS > Request a Trial.  After 30 days, the premium features will be disabled.  Fill out the form:
   
2. You will receive an email from Centrify on the email address specified. Click on the validation link:
   
3. Upon validation you will be assigned a tenant ID.  Press the button to log in to Cloud Manager
   
   You will also receive an email with your initial credentials.
   
4. When you attempt to log in to the cloud manager with your password, you'll be asked to provide an additional authentication method - since e-mail is the only option, you'll receive an email to your account, click on the link and you'll be signed in.
   
5. Upon login, you'll be welcome by the configuration wizard.
   

What happens when a tenant is created?
The Centrify Cloud service runs in Microsoft Azure platform;  note that when the tenant was created, you had the chance to create your tenant in different places based on your region.  In the background, these tasks are created:

• Multiple copies of the service and basic data are created inside the cloud (for redundancy)
• Sets of different encryption keys are created (for encryption services)
• An internal dedicated Certificate Authority is created.
• The initial login suffix is created based on the user's email address.
• The tenant is branded with Centrify's logo and colors.

This is obviously a simplified list, but it's important that they are understood for future posts.  This lab contains no videos.

Next-up:  Initial setup and customization.

Business Cases - Web/Mobile SSO Case Requirements

We will start a series focusing on the Centrify User Service and to give it the right context, just like we did a year ago with Server Suite we are basing this in a set of business requirements.

Here's a summary of the requirements:

Web and Mobile SSO
Our organization currently uses Salesforce, Office365, Google Apps, Sharepoint (internally), has Apache/Java (internally) and they need SSO;  some of these apps are SAML, WS-Fed, User/Password or may be using the Centrify on-premise app plugins.

Access to these applications has to be granted to Active Directory users, but there are instances in which partners need access as well (who won't have AD accounts).  These users may access using rich clients (browser) or mobile devices (iOS/Android browser and mobile apps);  connections can be centralized via a portal, directly initiated or via intranet shortcuts.  In the case of Office365, users will continue to use their full clients (Outlook, Lync, etc) on their Windows and Mac workstations.

Security Requirements
Confidentiality - no synchronization of personal identifiable information off premises; encryption in traffic and at rest is required.
Access Control - the security department wants to have the flexibility to set policies that allow to control access based on time/day, network or geographical location (to limit apps to be intranet accessible only, not via the web);
Step-up Auth - One-time-passwords (two-factor) should be an option for sensitive use cases.
Governance -   Entitlement management and separation of duties should be enforced.
Availability
Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

Infrastructure Requirements
Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex);
Self-Service - the solution should provide flexible self-service options to minimize calls to the help-desk.
Office 365 - all features (rich or web clients) should be supported, ideally without added infrastructure complexity.
Decrease VPN usage - ideally this solution should provide alternatives to VPNs for internal-only apps.
Disjointed Namespace - The solution should accommodate for a different domain (for AD) than the business name (Internet DNS name).  It uses corp.contoso.com internally, vs. centrifying.net outside.

Other Requirements
Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.
Marketing - Branding and imaging should be maintained.


Go to Planning Session I:  http://centrifying.blogspot.com/2014/12/business-cases-web-mobile-sso-planning.html