[LABS] Testing the Centrify Reports Feature of Centrify Suite 2016

Background
This article describes the steps to install, configure and test the Centrify Reports feature included with Centrify Suite 2016.  You will find this article useful if you're looking to accomplish the following goals:

• Increase the speed of Access and Privilege related reports
• Provide information to your Security or Audit counterparts for Access or Attestation purposes
• Automate Attestation report generation and delivery
• Provide a data source for custom report generation.

Disclaimer:  This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.

What is the Centrify Reports feature designed for?
It's designed to overcome the limitations of existing report generation via LDAP (speed), provide flexibility (SSRS or Bring your Own Reporting), and increase productivity (automate report generation and distribution).

Can you describe an example?
The typical scenario is that depending on your risk or regulatory profile you need to provide user entitlements (who has access to a server or collection of servers in a Centrify zone and  what can they do with Privilege using DirectAuthorize).  For example:

• Who has access to UNIX/Linux or Windows Server? What privileges do they have (dzdo/dzwin)? What AD object grants access?
• Who can access this collection of systems? What privileges do they have (dzdo/dzwin)?

These entitlement reports, are used typically in attestation exercises.  Attestation may be done manually (you get together an ratify that these are the proper people that should have accesss) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool)..  As always, we'll be using the Plan-Do-Check-Adjust methodology.  In the labs, the goal is to test the features to be able to produce an viability assessment of the feature.

Planning
Use these planning steps for your test environment. We'veve added enough information that can be recycled towards production deployments.

Basic Requirements

• Obtain access and privileges reports in a timely fashion (for example, delivered daily, weekly, monthly or quarterly)
• Minimize impact to Active Directory domain controllers
• Automate delivery (e.g. email or shared folder)
• Allow reports consumers to customize reports based on their needs

Potential Stakeholders

• Active Directory Administrator:  To request and set up the account used to replicate AD Group and Centrify zone data to SQL Server.
• IT Infrastructure:  You can set up different distribution methods like file or web server and email.  The infrastructure SME will allocate shares, permission, SMTP relays or web servers.
• Security or Audit Analysts:  These are the consumers of this data.  They provide input on report data/distribution, etc.
• Database (SQL Server) Administrator (optional):  To work to set up a database instance (most likely in production);  if in a test lab, the Centrify bits include SQL Express.
• Reports SME (optional):  Depending on the size of your organization, you may have report developers that can customize the reports based on your security or audit needs.

Technical Requirements
Active Directory and Centrify

• A licensed or evaluation copy of Centrify Suite 2016
• An Active Directory test or production environment with Centrify hierarchical zone data (HZ Zones have RBAC)
• A domain-joined Windows server, ideally 2008 and up
• An Active Directory Service account (or two depending on your setup)
  An account needs the "Replicate changes" right in AD (to be able to read AD data and copy it to SQL)
  An account needs the "logon as a service" right in the system that runs the synchronization
• A Windows administrator or local admin rights to install programs in the test server.

SQL Server

• Versions validated: 2008, 2008R2, 2012, 2014;  Standard, Enterprise or Express (included with Centrify Suite 2016)
  Note:  with SQL Express, you have limitations on scale and capabilities.  E.g. can't do file/email subscriptions.
• If you need to test custom reports, email delivery, scheduling, etc; you'll need a Standard or Enterprise version of SQL
• If you want to test the Centrify-provided reports, you need to deploy SSRS
• If you want to test with a custom tool (e.g. Tableau) you'll need that software.

A Windows Server 2008 and up to install the Centrify Reports Service.  Depending on your deployment model, this may be the same machine as SQL or if it's a production design adhere to your organizational best practices.

Resources

• Centrify Administrator's Guide for Reports
• SQL Server Documentation (or leverage your DBA)
• Social: 
  What rights does “Replicating Directory Changes” actually grant in Active Directory?Please explain: "Replication Synchronization" permission in Active Directory
  Note: depending on the experience of your AD team, they'll know what the rights are used for; this is not unorthodox because it's a common practice when setting Sharepoint, FIM, Office365 DirSync or other services, however as we know you may get push-back based on lack of cognitive knowledge.

Design
Your design is going to be dictated by the capabilities that you with to test and your requirements.  Examples:

• If reports delivered via file-share or email are required and you'll use SSRS, then you need SQL server standard or enterprise.
• If you have your own reporting tool, SSRS is not needed, all you need is connectivity between your tool and the SQL server database instance that was used to sync the AD data that contains the Centrify access control data.

Here are some suggested(*) deployment models:

Note that the common denominators are AD, Centrify Hierarchical zone data and the service account required to sync AD data to SQL server.
(*) Remember that this is a "labs" post and this is a new feature.  Although I have input from beta testers, the true best practices come from our professional services organization.

How frequently should access and privilege data be synchronized between AD and SQL Server?
The answer to this question depends on the attestation requirement.  Examples:

• Some organizations do quarterly user access/privilege attestation exercises.  Perhaps synchronizing every quarter is fine in this organizations.
• Some organizations practice just-in time privileges (e.g. nobody has privileges or knows privilege account passwords) and they need reports daily to make sure there are nobody has any sticky privileges.  Daily reports that get delivered to a security analyst are required in this case, so a daily sync is in order.

The key here is that attestation has a component of comparing the access/privilege data from one time period to another and you have to plan your synchronization based on that.  Technically,  after the first sync or a rebuild, only the delta changes are requested from AD, this ensures that these operations don't negatively impact your Domain Controllers.  In a complex environment, your AD lead should understand that proximity to a Global Catalog will be an important design consideration.

Implementation
Download Suite 2016 from the Customer Support Portal and unzip the bits in an accessible folder on the domain-joined server.

Set up the AD Service Account
This step may be done for you by a Windows administrator.

1. Open Active Directory Users and Computers and navigate where you want the account to be created (OU or container)
2. Right-click the OU, New User and in the form type the First Name, Last Name and User logon name (e.g. centrify-reports) and press next
   
3. Set up a password for the account, depending on your practices, you may set the account's password to never expire, press next and then finish.

Delegate the Rights to Replicate Directory Changes from AD
In my example, I'm delegating at the top level of the domain, depending on the location of your users/groups, this may change.  This step may be done for you by a Windows administrator.

1. In Active Directory Users and Computers, right click the domain (e.g. corp.contoso.com) and select "Delegate Control" and press next on the first wizard page
2. Users or Groups:  Press the add button and find the newly created account, then press OK and press next.
3. Tasks to Delegate: Select "Create a custom task to delegate" and press next
4. Active Directory Object Type:  Keep the default radio button and press next
5. Permissions:  In permissions, scroll down and check the "Replicating Directory Changes" permission and press next and finish.
   

Delegate the Rights for the Account to run as a Service
In my example, I'm using AD Group Policy to grant my user the right to run as a service in that system.  The system is in an OU called Servers.  This step may be done for you by a Windows administrator.

1. Open the Group Policy Management tool and navigate to the OU that corresponds to the server, create or modify a GPO in and link it to that OU, right click it and select Edit (launches the group policy management editor).
   Alternatively, you would do this the Local Security Policy for the system.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment and find the GPO named "Log on as a Service" and double-click it.
3. If not checked, check the "define these policy settings" and press the Add User or Group, click browse and make sure that the "From this location" has the AD domain selected otherwise click Locations and select it. 
4. Type the name of the service account and press check names.  Press OK three times.
   
5. Now you can close GPME and GPMC.

Installation of Report Services
You need administrative rights to install and configure this software.  This may have been granted to you or you're assisted by a Windows administrator.

1. Using Windows Explorer, find the unzipped Centrify 2016 folder and navigate to DirectManage > Report Services and either the MSI or EXE file in that folder (it's the same)
2. EULA Page:  Accept and press next
3. Destination Folder:  Select the proper destination or leave as default and press next and press install.
4. In the final page, leave the Config Wizard box checked.

The Report Services installation package installs 3 key apps:

• Configuration Wizard,
• Report Services Control Panel, and
• Report Services launcher.

Now you have two options for configuration, with SQL Express (included) or with SQL Standard or Enterprise

Configuration for SQL Express or Standard/Enterprise

1. Launch the centrify Report Services Configuration Wizard and press next in the welcome page.  The next steps depend on your setup:
2. If using SQL Express:
   SQL Server Page:  Select the "Install SQL Server Express instance on this computer" and use the default name (REPORTS) or change the name and press next.
   SQL Server Package:  press next or specify an alternative set of bits (must know what you're doing), press next.
3. If using SQL Standard or Enterprise:
   In this step, you're either authorized at the SQL server level login (integrated or mixed) or assisted by your SQL DBA
   SQL Server Page:  Select the "Use an existing instance" and browse to the instance to be used; press next and give it some time to connect.
4. Deploy Centrify Reports (optional):  You can choose to deploy the Centrify attestation reports to the SQL Server Reporting Services website.  This is only optional if you plan to use another reporting tool, press next.
   Note that you may need to run the Reporting Services Configuration Manager applet to determine these URLs.
5. Monitored Domains:  Defaults to the local domain, add any additional (you must have had delegated the account permissions and the proper AD trust direction has to be in place), press next.
6. Sync Schedule:  Select an appropriate frequency based on your reports needs, press next
7. Report Services:  Select "use account" and browse for the AD service account set up.  Type in the password and press next.
   At this point, the wizard will check if the account has the proper permissions in the monitored domains.  If you did not get the correct delegations, this will fail.
8. Press close and then next.
   At this point the installer will perform an assisted installation of SQL Server Express.
9. Once completed, you'll get to the configuration completed page and the check box to do an initial sync will be selected.  When you press finish, the service will do the initial sync.  From that point on, all will be delta synchronizations.

Verification (Check)
The verification steps vary depending on the features you've deployed. However, a key step is to verify that AD roles and rights and principal data is being sent to SQL server in the interval that is set.  For this you can use the Report Service Control Panel.

If you chose to deploy the SSRS reports, you should be able to use the Report Services shortcut and access the sharepoint-based report services.  This grants access to subscriptions, report builder, etc (if you're not running Express).

Here are some verification videos: 

Adjustments
There are may adjustments to be made to this configuration.  Some may or may not be related to Centrify technologies:

• Set up a file share subscription
• Set up a SMTP distribution email
• Use a custom tool for reporting
• Programmatically retrieve reports data

The good news is that all the building blocks already are in place.  Future entries can cover these topics.

Implement strong access controls for Hadoop clusters using Centrify

This 15-minute video also features Centrify Privileged Service



Centrify can help challenges with Hadoop implementations for confidentiality and integration at the OS-level.  No need to stand-up independent MIT Kerberos infrastructure, plus the strongest Access Controls to meet or exceed any security or regulatory requirement.

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (4/5)

This is part 4 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".  (Also relates to PCI DSS 10.2)

CSC 12-11

Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.

Why should you do this?
This is a detective control.  You can't control what you're not tracking.  Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.

What is the typical approach?
On Windows:  Harvest and mine of the Windows event logs.  Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX:  Harvest and mine the UNIX syslogs.

What is the real challenge for organizations?
Data vs. Noise.   How can organizations reconcile all the sources of data into meaningful information?  This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.

Centrify's enhancers:

• Use what's native:  Uses syslog and event logs.  Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
• Enhance to differentiate the data from the noise:  Centrify can be configured to require reference information upon elevation, for example, change control number.
• Contextualize with DirectAudit to "clear the noise":  Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
• Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"

Have a look:

How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:

How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation

How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:

Labs: PCI DSS 3.0 Req # 7 - Implement Strong Access Controls 10-minute Challenge

Challenge Accepted!

In a previous post, we outlined the PCI DSS3 Requirement 7 10-minute challenge.
This entry is to outline current environment, high level steps and verification protocol.

Here's the current environment as of today (excluding the 2-node Hadoop cluster):

Here's what we're adding for the challenge:

The cast of characters

• J. Peterman and Elaine Benes are the PCI Developers
• On Windows - PCI Developers shall perform developer tasks like:
• Opening SQL Server Studio
• Resetting IIS websites
• Control System Services
• On Linux -  PCI Developers shall perform LAMP functions like:
• Control the httpd service
• Elevate to the mysql account (without knowing the credentials)
• Edit the httpd daemon config file /etc/httpd/conf/httpd.conf
• Jerry Seinfeld is a Domain Admin
• George Constanza is the UNIX Sysadmin

Steps to the Challenge - 10 minutes

Planning
- Will use a new zone to prove this concept (may be needed for separation of duties) - name: PCI
- Will reuse the existing ZPA service (provisioning has nothing to do with PCI, will control access with Roles)
- A Combined UNIX/Windows role will be created with the following access:

• Role Properties
• Available 24x7
• Password Login and SSO enabled
• Non-Restricted Shell
• Access Rights
• PAM SSH
• Remote (Windows)
• UNIX Commands
• systemctl (start|stop|restart)*httpd  as root (authenticated)
• su - mysql  as root (authenticated)
• vi /etc/httpd/conf/httpd.conf
• Windows Applications
• iisreset.exe  as local administrator
• services.msc as local administrator
• SQL Management studio as local administrator

- PCI Developers group will be called - PCI Developers

Implementation

On the management station:

1. In ADUC create the PCI Developers role
2. In access manager set up the new zone.
3. Set up the Unix identity properties
4. Set up the UNIX commands
5. Set up the Windows Applications
6. Create the PCI Developers role, set up properties, add the rights
7. Perform the role assignment at the zone level.

On CEN2

1. Unpack the Centrify agent bits
2. Run adcheck
3. Join the zone
4. Run adquery user and dzinfo

On APP2

1. Install the Centrify Agent
2. Join the Zone and Reboot

Test Plan (Check) - 5 minutes

• We'll verify that PCI developers can:
• Only log in via SSH (Linux) and RDP (Windows)
• Perform administrative tasks on APP2 (Win Server 2012 R2)
  Not a member of Local Administrators or Domain Admins
• Perform LAMP admin duties on CEN2 (CentOS 7)
  They shall not know the root account.
• Windows Domain admins should not be allowed to log in to the PCI systems (Jerry)
• Enterprise UNIX admins - should not be allowed to log in to the PCI systems (George)
• Any other users can't access the systems (Soup Nazi)
• The model should work for both Unix/Linux and Windows.

First Video - Challenge Explained (5:03)

Second Video - Implementation (9:40)

Third Video - Verification (6:49)

Security Corner: PCI DSS 3.0 Requirement 7 - Implement Strong Access Controls 10-minute Challenge

Background

The Payment Card Industry (PCI) Data Security Standards (DSS) is a great measuring stick for the security posture of any organization.  In fact, I love it because it's so clear.

Requirement 7: "Restrict access to cardholder data by business need to know" poses an interesting set of challenges, because it requires the enforcement of the principles of:

• Least Access - users shall only access the systems they need access to
• Least Privilege - once in these systems, they shall only do what they're supposed to do
• Implement a Role-Based Access Controls (RBAC) model
• Shall be enforced across heterogeneous platforms (7.2.1)
• Ideally the process is consistent and easy to document and adhere to workflow (7.1.4, 7.3)
• Closed systems - All systems default to deny access unless (7.2.3)

Challenge

1. Implement the technical(1) controls of Requirement 7
2. Multi-platform:  Unix/Linux & Windows
3. Implement it in less 10 minutes or less
4. Prove compliance in 5 minutes or less

The Environment:

1. Active Directory 2012 Domain (based on the Microsoft Test Lab Guides)
2. One Windows Server
3. One RHEL 7
4. Centrify software already loaded on a management server (MMCs) and copied in target systems.

Access Rules

The access rules have to be defined as per 7.1.1.

 The card data environment consists of one Windows Server 2012, a RHEL 7 and an Ubuntu 14.04 servers.  The nature of the work performed is database (SQL Server) and Web (IIS) work on Windows.  The RHEL platform is used for an Apache/MySQL app.  There are two types of roles in this environment:

• Sysadmin (cross-platform)
• Sysadmins shall perform tasks as root in RHEL systems without knowing the root password. (7.1.2/7.1.3/7.2.2)
• Sysadmins shall be able to perform tasks as Administrator on Windows platforms without being a permanent member of the Local Administrators or Domain Admins group. (7.1.2/7.1.3/7.2.2)
• Developer (cross platform)
• Developers shall perform service control of Apache and IIS services  (service httpd start | stop | restart) and iisreset.exe - No root/apache/ credentials or ocal admin rights. (7.1.2/7.1.3/7.2.2)
• Developers shall be able to elevate to the mysql service account and to run the services.msc snap-in in Windows (to stop/start/pause) SQL without the root/mysql credentials or local windows admin rights. (7.1.2/7.1.3/7.2.2)

Additional Guidelines

• Because these are PCI systems, no one than the PCI Sysadmin and PCI developer Role can log in to the system.  This includes any other trusted administrators like Domain Admin. (7.2 - deny-all)
• Access to both roles is restricted to the terminal (SSH on Linux and RDP on Windows) no console access.
• The add/moves/changes process shall be controllable via AD Group membership.  This makes easy for other upstream tools to control workflow and approvals. This makes compliance with 7.1.4 (approvals) and 7.3 (documentation) much easier.

Our next post consists of a set of steps and video challenge. 

Unix/Linux Access Controls: A tale of four audiences

UNIX and Linux Administrator I am worried about not being able to log-in to do my job if Active Directory is not available I am concerned that the integration with AD will be very intrusive to my Unix and Linux systems I am concerned that the privilege management model won't allow me to do things as root when I require it. I am concerned that I won't be able to leverage scripting and automation I'm spending a lot of time to produce information for security attestation I'm concerned that each time I need to do something I will need to go to the Windows guys for permission. Do I need to go changing file ownerships (chown) once this is implemented?

Active Directory Administrator I'm concerned that this solution will require to extend the AD schema I'm concerned that I will need to run services in Domain Controllers I'm concerned that the agent will eat my DCs CPU and Memory with multiple persistent LDAP connections  I'm concerned that now I will have more work since I have to help the Unix group.

Security Analyst I need to make sure only the right people can access the Unix and Linux Systems (least access principle) I also need to make sure that shared accounts (like root) are only used when required I need to make sure accountability is increased I need to make sure people can only have the privileges that they need (least privilege principle) I need to satisfy audit reports and close open audit comments We need to align with Regulations (SOx, HIPAA, PCI, etc) I am not sure that we can really pin-point who did what at a certain point (bad change control, data-breach, etc)

IT Manager or IT Architect I am concerned that we're spending a lot of money in point solutions I'm concerned that the project will not yield results on time I'm concerned that processes like password resets, provisioning, de-provisioning, and attestation are very complex. I'm concerned that any new solution is going to require a ridiculous amount of infrastructure. I'm concerned that even though we have top of the line solutions, it seems it takes a long time to get stuff done.