OS X users without administrative rights get challenged each time they need to stop/resume print queues. Organizations looking to implement the least privilege management security model may need to provide ways for users to be "print operators" on a Mac, without granting full administrative rights. The "Printers and Scanners" system preference does not provide granular entitlements.
This issue may cause many calls to the helpdesk
This post covers a way to overcome this issue using AD security groups and the "Map zone groups to local groups" Centrify GPO.
The idea is that you map an AD security group to the _lpadmin and _lpoperator local groups of the system.
What you'll need:
An AD Security Group and the ability to control memberships.
The ability to modify GPOs that apply to your Macs using the Centrify templates and GPMC/GP Editor.
Step-by-step Create and populate an AD group
Use ADUC, PowerShell, request system or any tool of record to
request an AD group. Give it a descriptive name like "mac-print-admins"
Populate the group with the AD users that will be allowed to manipulate queues.
Edit the "Map zone groups to local group" GPO
Open GPMC and browse to the GPO that applies to your Mac. Right click and select edit.
In GP Editor, browse to Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts and double-click the Map zone groups to local group GPO.
Press add and and in local group type _lpadmin, then browse for the
AD group created in the previous step. (e.g. mac-print-admins).
Repeat same process on step 3 with the local group _lpoperator. At the end, the GPO looks like this:
Press OK and close GP Editor and GPMC.
Refresh the GPOs on the Mac and verify your results
Log on to the Mac as a non-admin user that is a member of the AD group created in the first section.
Open a Terminal.
First, refresh the group policies by running the adgpupdate command. (adgpupdate -T computer)
Now verify that the GPO is effective by running adgpresult (adgpresult | grep _lp)
Your user should not be challenged moving forward to pause/resume
print queues, plus the user does not have admin rights, therefore you're
aligned with the least access principle.
In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:
a) Eliminates identity silos
b) Implements strong access controls without interfering with the user experience
c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)
d) Promotes operational efficiency
e) Provides strategic value, rather than tactical solutions
Organizations come to Centrify for privileged identity
management or privileged user management because of combinations of the
following challenges or circumstances:
Overall: They want to increase accountability
and implement strong privileged user identity and access controls based on a common identity repository.
They have Active Directory and multiple
platforms, but primarily for UNIX, Linux and Windows
They have a traditional (on-premise only) or
hybrid (public/private cloud) enterprise
They want to eliminate the use of shared
credentials or persistent administrative accounts (root, administrator, “-a”,
etc)
Their existing solution does not provide
flexibility on grouping systems based on a security governance model
They might have chosen to implement a
password-centric approach as their unique strategy and they’ve come to realize
that their users are less productive (or supportive), that they’ve duplicated
identity silos and that ultimately, their systems (the main goal) aren’t
protected by it.
On UNIX: They understand that using
sudo/sudoers, although it’s mature may not be enough for high-risk,
highly-regulated enterprises; they are tired of the complexities of managing a
sudoers file and want more granularity and flexibility
They want a higher-degree of control on how their
users access systems (beyond just granting/denying access) cross platform.
On Windows, they want to eliminate the problem
of the Local Administrator, are conscious of the “pass the x” attacks and want
to eliminate the “camping” issue with “-a” accounts.
They need to provide separation of duties
(operational rights vs governance rights)
They need timely reporting of who has access to
what system(s), what are their privileges, and what granted them access to do
this.
They don’t want to deviate from existing
processes or realized that by implementing point solutions or “best of breed”
they ended-up fragmenting their IT in the context of processes.
They have regulatory requirements that they need
to meet or exceed.These may be SOx, PCI
DSS, HIPAA, NERC, FERC, etc.
They want to solve the Shared Account Password
issue, but they want a solution that reflects the state of modern trends (they
hybrid datacenter, IaaS, mobile-first, etc)
They have high-security requirements like FIPS,
solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
They hate having to invest in multiple solutions to enforce the same basic security principles. Each time they do, this may mean: - Evaluate a product - Invest or procure new hardware or software - Add additional infrastructure - Train or hire specialist - Maintain the solution down the road - Manage the vendor relationship
Here's a technical demonstration on how Centrify delivers this value:
The key differentiation areas are:
AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
Centrify Zones - unique patented way to create groups of systems in Active Directory
Granularity of Access Controls - control HOW users log in to systems
Granularity of Privileges - no need to know the privileged account password.
Simple privilege elevation: sudo-like tool in UNIX/Linux, shell and command line on Windows.
No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
Quick attestation and robust reporting - the data is in AD.
Separates the operational tasks versus the governance tasks - to enforce SoD
Works in multiple core platforms: UNIX, Linux and Windows
Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.
Finally, the end user experience is not affected, no identity silos are created and your AD infrastructure, processes and technology are reused. We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.
In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).
Organizations with traditional (on-premise) and hybrid (private/public cloud) with Active Directory, come to Centrify
because:
They have diverse platforms (UNIX, Linux,
Macs) in their enterprise (on-premise and in the cloud).
They are looking to Centralize the
administration (or implement effective controls) for user access in those
different platforms. Their reasons may
be due to security, regulation, operational efficiency or simply because they
are reacting to an audit or other event.
They are also looking to leverage the secure
authentication methods provided by Active Directory.
They are looking to find a way to effectively
manage UNIX identities by using Active Directory, but preferably, they don’t
want any schema extensions to AD or software loaded in Domain Controllers.
Some other organizations (and this is quite
common on the Mac side) are looking for a more robust way to support AD
integration and are also looking to use a common management framework (like
Active Directory Group Policies) to enforce security policy or configuration
management policies.
Other organizations are looking to focus on
their core competencies because perhaps they invested a lot of engineering
cycles using open source software (like Samba/Winbind, RedHat’s SSSD, OpenLDAP
with MIT Kerberos) and realized that the speed of requirements and diversity of
platforms does not align with their goals.
(E.g. a Financial organization spending hundreds of man hours on
“manual” identity and access controls rather than portfolio analysis). These types of organizations are ready for a
solution that “just works”
Organizations want solutions that are friendly
to private/public cloud scenarios; this means a toolset that promotes
automation.
The organization may have high-security
requirements like smartcard authentication, FIPS encryption or common-criteria
certified solutions
Finally, some organizations tried to wait as long
as they can keeping the status quo; and a compelling event has made them change
like:
Change of leadership
A merger or an acquisition
A new technology (like BigData)
Acknowledgement that advanced persistent threats
can’t be ignored
Another solution isn’t providing timely updates,
proper support or their future is uncertain
An audit or data-breach
Perhaps there’s an old infrastructure (e.g. NIS,
LDAP) that found fresh blood that isn’t afraid of “touching the server, who
knows what will break” <= yes, this
sadly happens.
Everything I outlined above is core of what some analysts
call “Active Directory Bridging” but when you look at it is much more; it is
the basis for implementing critical access controls and a management framework
that is based on reuse of existing infrastructure and processes rather than
point solutions. It’s also the
foundation of making sure users can do their work, without interrupting their
flow.
Here’s a technical demonstration on how Centrify provides value:
A very unique capability that is exclusive to Centrify is the zones technology. Nobody else can do what Centrify does to group systems in a hierarchical way while consolidating UNIX identities for Users, Groups and NIS Maps.
Note that also, a large number of "born-in-the-cloud" organizations are coming to Centrify for Web Application SSO and Enterprise Mobility. We will cover that in other entry.
In the next post, we'll focus on how Centrify builds on their AD bridging capabilities to provide Privileged User Management on UNIX, Linux and Windows and how it uses it's Identity Platform for secure access and shared account password management.
Requirement
In case
of an Active Directory catastrophic failure, a limited set of trusted
administrators shall be able to log in to UNIX, Linux or OS X systems
and perform the actions defined in their privileged management roles.
Scenario
Contoso
has 3,000 servers and many of them on branch deployments and public
clouds, there are no DCs in the branches. WAN connectivity can be lost
and a mechanism to allow trusted administrators to perform actions
should be available. It's highly unlikely the set of trusted admins
have logged in to all systems. This is why Centrify implemented the account prevalidation feature.
Target Group:
Account prevalidation can be assigned to users or groups. Ideally this
would be assigned to groups so the management can be delegated to the
Helpdesk, or front ended by an ITSM or Worfklow solution. This means that an AD Group should be requested. Sample Name: Centrify-Prevalidated-Admins
Process: Onboarding:
When senior UNIX, Linux or Mac OS X administrators are onboarded, the
user template or form should be updated so they are added to this group
by default. One-offs: When critical projects are going on
and stakeholders need to be added to this group, our ITSM tool will
front end a workflow request that ends on a PowerShell action that adds
(or removes) the user from the target group. Attestation: This group does not have any additional rights, however it has to be attested as part of the disaster recovery plan.
Implementation What you'll need
Centrify Standard Edition or Centrify Identity Service Mac Edition (licensed)
A Windows system with Group Policy Management and the Centrify Group Policy Extensions (GPOE) installed
An Active Directory group pre-populated with the users that will be prevalidated
A GPO tied to the OU of the target UNIX, Linux or OS X systems.
Rights to edit the GPO
Centrified system in the OU that has the GPO linked to verify.
First, Gather information about the members of the group
From a Centrified System
$ adquery group -A Centrify-Prevalidated-Users | grep members
members:centrifyimage.vms/Staff/IT/Diana Wirth
From Windows with PowerShell
PS > get-adgroupmember Centrify-Prevalidated-Users | Select-Object samaccountname
samaccountname
--------------
dwirth
rpimentel
Second, Configure the GPO
Open Group Policy Management
Create or edit the GPO in the corresponding forest/domain/OU.
In group Policy Editor, navigate to Computer Configuration > Policies > Centrify Settings(*) > DirectControl Settings(**) > Account Prevalidation.
In the right pane, double-click on "Specify allowed groups for
prevalidation" select Enabled and populate the dialog box with the group
predefined for this purpose and press OK and close Group Policy Editor. (*) If you don't see a Centrify Settings section, you don't have the Centrify GPOE installed. (**) If you don't see a "DirectControl Settings" folder, you need to add the template.
Third, Add the Preval SPN to the members of the group and commit the changes in the Centrified system
a) To add the SPN
# From Windows with the setspn utility
C:\> setspn -A preval/rpimentel rpimentel
Checking domain DC=centrifyimage,DC=vms
Registering ServicePrincipalNames for CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms
preval/dwirth
Updated object
# From Windows using PowerShell
PS > Get-ADUser dwirth | Set-ADUser -ServicePrincipalNames @{Add="preval/dwirth"}
# From a Centrified System Using adedit
## Authenticate as someone who can edit the target object
$ kinit administrator
Password for administrator@CENTRIFYIMAGE.VMS:
# Open adedit, bind to domain and use the add_object_value function
$ adedit
>bind centrifyimage.vms
>package require ade_lib
1.0
> add_object_value "CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms" serviceprincipalname "preval/dwirth"
1
> exit
# Manually using Active Directory Users and Computers
Open ADUC
In the View menu, check "Advanced Features"
Open your target user > Attribute Editor > servicePrincipalName
Click add, and type preval/<user>, press OK twice.
b) To verify the SPN was added succesfully # from a Centrified system using CLI
$ adquery user dwirth --attribute servicePrincipalName
preval/dwirth
# from Windows using PowerShell
PS > Get-ADUser dwirth -prop ServicePrincipalNames | Select-Object Name, ServicePrincipalNames
Name ServicePrincipalNames
---- ---------------------
Diana Wirth {preval/dwirth}
c) To commit the changes to a system for the purposes of testing
## flush the cache - only if you want this immediately (will happen automatically after cache flush interval + gpo refresh
$ dzdo adflush
DNS cache flushed successfully.
Authorization cache store flushed successfully.
GC and DC caches expired successfully.
DA name cache flushed successfully.
DA installation information cache flushed successfully.
## perform a group policy update - again, this happens on the GPO refresh.
$ adgpupdate
Refreshing Computer Policy...
Success
Refreshing User Policy...
User Policy disabled on this machine.
## verify that the GPO inserted changes in the config file
$ adgpresult | grep Centrify-Prevalidated-Users
adclient.prevalidate.allow.groups = Centrify-Prevalidated-Users,
Notes: This process can also be implemented with a Management tool like Chef, Puppet, Spacewalk, etc. Ultimately the parameter that will be adjusted is the "adclient.prevalidate.allow.groups" in the /etc/centrifydc/centrifydc.conf file. This can also be part of a master config file that is enforced across the board, but watch out for conflicts with GPOs. You must pick a tool.
Verify and Test
To verify prevalidation you'll need a recently centrified system OR a system that you know one of your test subjects has never logged in. You will also have to switch the agent to offline mode. There are two ways to do it:
a) If this is a VM, go to the hypervisor console, and disconnect the network; OR
b) Force the agent to go offline by adding all your DCs to the dns.block parameter.
E.g. if I have 2 DCs (dc1.corp.contoso.com and dc2.corp.contoso.com), the parameter would look like this:
c) If you have console access, you can also disable the network interface momentarily.
This video explains the installation and testing process:
Adjustments
There are several areas of improvement for this process:
Automation
A really cool improvement has to do with the automation of the prevalidation SPN. For example, you can implement both in a Centrified UNIX/Linux system or with Windows PowerShell script that checks if new users are added to your target group, and automatically will add (or remove) the preval SPN.
Service Management and Approvals
If you have an ITSM (like ServiceNow) or an IdM with workflow/approvals, you can front-end this process by adding references and approvals to be able to answer these questions:
Secure access to Wifi or Ethernet networks is a goal of any security conscious IT infrastructure team, however diversity of platforms makes this goal very hard to achieve, especially when organizations are looking to standardize but have diverse client platforms.
In a Windows world, capabilities such as Active Directory Certificate Services, Group Policies, the Network Policy Service and Windows clients make this goal relatively simple. The popularity of Mac Workstations has forced many organizations to face this challenge.
The good news is that Centrify has worked very hard to make sure that IT Infrastructure folks can leverage their existing Windows infrastructure to solve this challenge on the macs.
The challenge for any technical lead is that the expertise required just to meet the prerequisites is going to be scattered all over the organization; this means that it's time to flex the ability to coordinate and get people to work together. Hopefully this post provides a lot of clarity.
How easy is it to implement?
It is as easy as enabling one of the Centrify-provided GPOs for Mac OS X. Specifically the "Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1x Settings" and you can pick your flavor:
Enable Machine Ethernet Profile
Enable Machine Wi-Fi Profile
Enable User Ethernet Profile
Enable User Wi-Fi Profile
However, this entry would not be useful if I just show you that you can enable the GPO, perform a policy refresh and just like magic: network access.
What I've noticed from prospects or customers that are looking to test these capabilities is that they don't understand all the moving pieces that need to be in place in order for this to work.
In this post we'll use a checklist to make sure that you understand what needs to be in place to be successful.
Note: If you already have 802.1x EAP-TLS running with your Windows infrastructure today, you are very well-positioned for success.
Active Directory and Windows Services: There are several ways to accomplish this goal, but in this particular instance, because our goal is to consolidate processes, knowledge and infrastructure, we are leveraging Windows capabilities like Active Directory, AD Certificate Services and the Network Policy Service. AD Groups will be key to provide access controls; OUs will determine the scope of GPOs to be used.
Public Key Infrastructure: PKI is needed to provide the encryption, non-repudiation and authentication between the back-end infrastructure (Active Directory) and the client (Ethernet or Wifi). The key here is the certificate life-cycle management, this is where Windows PKI uses Group Policy. PKI Disclaimer: PKI is not joke. Any proper implementation needs to provide the assurances that PKI is aligned with your security policy. If your organization does not have a policy for PKI (general assurances, handling of private keys, policies, templates, Root and SubCAs) consult an expert.
A Policy/Configuration Management Engine: Group Policy provides the rules and the enforcement for configuration items and even provides certificate auto-enrollment - a way to manage the certificate lifecycle (issuance, renewal, revocation, etc); in addition, GPOs will be the way that Centrify will provide the Apple profile information.
Network Policy Service: The NPS service on Windows provides the services like Remote Authentication Dial-in User Service (RADIUS) and the policy rules to enable 802.1x. The NPS Service interacts with Active Directory to leverage groups and attributes.
802.1x-Capable Network Devices: Any modern switch or access point supports 802.1x EAP and RADIUS.
Centrify Agent for Mac OS X: This use case showcases the power of the Centrify agent. Not only it leverages its ability to integrate with AD, but to use advanced services and perform this cohesively within the MacOS platform. Key capabilities: Certificate Auto-Enrollment, System Profiles, GPO Engine.
The Lab
For AD and PKI: Modified Microsoft Test Lab Guide: Provides the corp.contoso.com domain with a running Microsoft CA. The RootCA (corp-DC1-CA) certificates are deployed using GPOs. Translation: A common Certificate Authorithy with the proper Certificate Revocation publication methods needs to be provisioned. I did not set APP1 as a SubCA.
For RADIUS and Policies: I'm piggybacking on my APP2 Windows 2012 server
Network Devices: I'm using Cisco small business (300 series) switch and a TPLink (TL-WA90x) Wireless Access Point.
Mac Client: Old Macbook running 10.7 and Centrify 5.2.1
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.
Sign-on to the template Centrified system with the Account to be used for Recovery.
Go to System Preferences > Users and Groups and unlock the Padlock
Click on the Gears under Login Options and Select "Set Master Password"
Navigate to /Library/Keychain and you will see two files:
FileVaultMaster.keychain
FileVaultMaster.cer Double-click the FileVaultMaster.keychain, this will open KeyChain Access.
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.
Open Active Directory Users and Computers (ADUC)
Navigate to find your MacOS template computer, right click and select properties.
Go to the Managed By tab and click Change. Select the Recovery account.
Press OK and close ADUC
Next, we need to enable the GPO for File Vault 2.
Open GPMC and navigate to your Mac GPO, right click and select edit.
Navigate to Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security and Privacy and select "Enable File Vault2"
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.
Log on to the Centrified Mac and open Terminal. Run adgpupdate. This will refresh the GPOs.
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.
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.
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
Open GPMC and edit the Centrify GPO for OS X systems.
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.
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.
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.
To make sure the GPO is refreshed on the Mac OS X client, just run the adgpupdate command.
Verify
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.
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.
As you know, Centrified systems can process group policies (basics here). However, did you know that there is a group policy object named "Copy files" that can be used to:
Distribute files
Make sure config files stay consistent
Deploy software
and many many more creative uses.
The copy files GPO
It's located under Computer Configuration > Centrify Settings > Common UNIX Settings
How does it work?
The copy-file GPO uses the Centrify agent's GP engine along with adsmb and the computer credentials to connect to the AD SYSVOL (or an alternate share) and obtain the files and it will place it in the target folder of the Unix/Linux or Mac system.
Copy-file GPO options
Because adclient is a privileged process the destination file can be manipulated (permissions, ownership, etc.). The file gets copied under two conditions:
If enabled, when the group policy refresh interval is met (every 90 minutes by default with a random offset of 30 minutes.
When the adgpupdate command is triggered.
Considerations when using this GPO (and group policies in general):
Perl needs to be installed. (5.8 minimum as of 9/2014)
The sysvol or alternate share have to be reachable, therefore the requirements to make a CIFS connection are in play. This may be undesirable in firewall scenarios.
When writing to sysvol, an appropriate AD account needs to be used.
Group Policy Objects for users are not enabled on *NIX by default, they are on the Mac.
In a previous post, we discussed a UNIX/Linux scenario with Centrify Enterprise Edition; in this post and in an upcoming playlist, we'll be integrating a couple of Mac OS X systems. On-premise (or Enterprise) systems tend to have different requirements from BYOD (Bring Your Own Device) Macs.
Requirements for On-Premise Mac Systems
AD Integration
Allows all Domain Users to access Mac OS clients with their AD Credentials
Leverages AD natively, no schema extensions or software in domain controllers
Solution does not synchronize identities or passwords
Mac users can be controlled from AD (enabling/disabling, logon hours, etc.)
As per Wikipedia: "Group Policy provides the centralized management and configuration of operating systems, applications, and users' settings in an Active Directory environment" but what does this mean:
For the IT Administrator: It allows the enforcement and management of computer and user settings to be much easier. It's also easier to achieve standardization from a central administrative place.
For Security: It allows for security policy definition in a single place, with enforcement in multiple endpoints.
For End-Users: It means that the two parties above can control my experience. :-) All joking aside, group policies can make the user's experience more consistent.
For IT Management: Group Policies promote better compliance, more standardization and operational efficiency.
Centrify provides Group Policy objects for the UNIX/Linux (including GNOME), Mac OS X and in the user suite for iOS, Android, etc.
How does group policy work?
In a Windows network, client reads a special share in the SYSVOL share of a domain controller and based on the scope (Site, Domain, OU), the processing rules and security settings they may or may not be processed. They can change computer settings (upon reboot) or user settings (upon login) or after the gpupdate command is issued.
But UNIX/Linux systems are not Group Policy capable? Yes, this is true. Unless the system has been Centrified. The section below explains how Centrify can process group policies.
Note: Group Policy processing is available on the licensed versions of Centrify for UNIX, Linux and Mac OS X, with the exception of the Password and Kerberos policy that can be enforced in the Express (community) version. This blog does not cover Centrify Express, but the reason why this is possible is due to the shared objects that comprise the Account PAM module provided by Centrify.
How does Centrify enable Group Policy for UNIX/Linux and Mac Systems?
There are several components that allow group policies to be processed in UNIX systems.
On the Windows side: Group Policy templates and definitions (.adm and .xml) files provided with the Centrify Suite. A trusted administrator links and configures the GPOs, which in turn are copied in the SYSVOL share of the domain controller (and replicated in the domain).
On the UNIX/Linux/Mac OS X system side: The Centrify agent (adclient), mapping files, the mapper process, a virtual directory and config files.
The simplified process works like this:
At the group policy refresh interval or when the adgpupdate command is issued, adclient reads the SYSVOL share of the current domain controller.
The client determines which group policies apply according GP processing rules.
The group policies are interpreted and implemented by the mappers process
The corresponding changes are made to the configuration files in the system.
For example, the Windows logon banner, specified in the "Interactive logon: Message text for users attempting to log on" GPO under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options is mapped to the text in the /etc/issue file in the UNIX/Linux system.
Other very important GPOs are verified by the PAM Password Module, like these options on the "Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy" Section:
Enforce password history
Maximum password age
Minimum password age
Minimum password length
Password must meet complexity requirements
Process Reuse: This means that all the password policies can be reused in the UNIX, Linux and Mac OS X systems that are joined via Centrify commercial editions!!!
Video Chalk-talk
For a deeper dive on group policies provided for Mac OS X by Centrify, take a look at this chalktalk:
The adgpupdate command is the equivalent to the gpupdate command in Windows. What it does is described above.
usage: adgpupdate [options]
options:
-T, --target <Computer | User>
Only refresh the computer or user policy (default both).
-V, --verbose Print debugging diagnostics to stderr.
-v, --version Print version information.
-h, --help Print this help text.
Sample output:
$ adgpupdate -V
session opened
Refreshing Computer Policy...
Success
Refreshing User Policy...
User Policy disabled on this machine.
To view the settings processed by group policy, inspect the gp.report file under /var/centrifydc/reg/machine (and /user if the system is a Mac or if it was enabled for GNOME policies)
adgpresult
In the 2015 version of the Centrify DirectControl agent (5.2.2), the adgpresult command has been introduced. This command works just like the Windows gpresult tool. It shows all the group policies processed locally by the agent in a very neat output.
$ adgpresult --help usage: adgpresult [options] e.g. adgpresult -a or adgpresult -m -u uname1 -u uname2 ... options: -a, --all Dump both gp settings for machine and current user. Default option if no option is given. -m, --machine Dump the machine's gp settings. -u, --user <name> Dump the specified user's gp settings. -h, --help Print this help information and exit.
Kerberos is a protocol that leverages DNS, cryptography, a distributed client-server model, clients and time synchronization and ticket exchanges to provide secure authentication.
From a Security perspective, Kerberos resolves the following:
Enforces confidentiality because it makes sure that passwords are not in the clear over the network.
Protects integrity of the transaction by making sure that exchanges are not tampered with during transit
Provides high-availability (if properly implemented) by allowing for it to be deployed in a distributed fashion
For Kerberos to work,
DNS name resolution needs to be working correctly
There has to be a Directory Service to store service principal names (like LDAP) and service principals need to be registered in the proper attributes of the directory
The Key Distribution Server needs to be available
Time between clients and servers can't be skewed more than 5 minutes (time servers have to be implemented)
Client software needs to support Kerberos and the Kerberos environment has to be properly configured.
Active Directory can solve all these issues. As a matter of fact, any Working windows network today (that has Windows 2000 and up) has a working Kerberos environment. Kerberos is used by millions of people every day:
a) Bob signs into his Windows computer in the morning.
b) As he signs in successfully, a Ticket Granting Ticket (TGT) is issued for him with a duration of 10 hours.
c) When he opens his email (Outlook) and is able to start work on pending tasks.
Note: In a normal configuration he does not need to type-in his password again to open the program; because the "Kerberized client" (Outlook), the "Kerberized Server" (Microsoft Exchange), the Directory, Key Distribution Server, Policy Server and DNS server (the AD Domain Controller) take care of the rest.
Notice all the functions performed by Active Directory
Function
Provider
Provides name resolution
AD Domain Controller – DNS Service
Issues, validates tickets
AD Domain Controller - KDC
Provides encryption services
AD Domain Controller- AES 256
Defines and enforces Kerberos policies
AD Domain Controller - Group Policy Engine
Directory Services
AD Domain Controller - LDAP
Provides time synchronization
AD Domain Controller - win32 time service
Provides high-availability and standard configuration
AD Domain Controller - replication
Kerberized Client
Windows 7, Microsoft Outlook
Kerberized Server
Microsoft Exchange
Notice the fragmentation on UNIX/Linux
Function
Provider
Provides name resolution
BIND
Issues, validates tickets
Kerberos KDCs (MIT or Heimdal)
Provides encryption services
LDAP (SSL or TLS)
Kerberos (for auth only)
Defines and enforces Kerberos policies
Configuration files
Directory Services
OpenLDAP(& other packages)
Provides time synchronization
Network Time Service (NTP)
Provides high-availability
Multiple solutions:
-LDAP Sync (for OpenLDAP)
- BIND master/slaves
-Kerberos Master/Slaves
-Filers and export shares for configuration
files
Kerberized Client
Many available, but not all support Kerberos
This is not important in the context of this conversation
This is not important in the context of this conversation
Notice the variety of products, and now think: What's in a capability?
People-Process-Technology
This example illustrates a phenomenon that plagues many organizations today: IT Fragmentation. For each of these solutions organizations require specialists (people), deviations in how things are done (process) and as you can see above, different solutions (Technology)
This is why, in my previous post, the IT manager is concerned about costs and organization agility.
Service Principal Names
SPNs are the "names" associated with a service. The service (like a web server, host, file server, etc) executes in that security context. Better definition here.
The syntax is: <
service type
>/<
host name
>:<
port number
>
In a practical sense, the meaning is this, if a service (let's say Apache, or httpd) wants to use Kerberos authentication, not only it has to be Kerberized, but the host of the service has to have an SPN for that service in the Directory service. For example, for the host web.contoso.com, the http running on port TCP 8080 service's SPN is: http/web.contoso.com:8080
Not specifying a port, basically assumes the default port. In our example, port TCP 80.
Troubleshooting Kerberos
Troubleshooting Kerberos takes a lot of practice and will be revisited later, but here are a basic set of steps. Just ask yourself:
Is the service Kerberized?
Is name resolution working? Can DNS resolve by FQDN or short name?
Is the time synchronized between the client, server and KDC (DC in AD)
Are the correct SPNs registered (remember that you can do short names and FQDNs)?
Finally, the fact that you can authenticate, does not mean that you're authorized!!!
