Security Kaizen - Part II: System, Roles and Groups + Anomalies
Part I | Part III
In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.
We defined that the goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc. The idea is to Identity-Plan-Implement and Review. For example: If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days); an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.
We also introduced the concept of dimensions. In the past article we focused on the user view, in this article we discuss other dimensions.
Total Centrify-managed systems vs Domain-joined systems
To identify Centrify-managed systems, first you need to identify the existing zones in your environment.
Get-CdmZone | Select Name, Domain, DistinguishedName, Schema
Once you have identified the zones, you can enumerate the number of systems under all active zones. An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"
Another point of concern is if a large number of classic zones are encountered. Centrify best practices since 2010 favor hierarchical zones over classic zones.
The goal in this measurement is to understand which systems are under Centrify management and aren't. For example, you can use these commandlets:
Get-CdmManagedComputer -Zone (Get-CdmZone -Name Global) | Measure Get-ADComputer -Filter * | Measure
to count the Centrified systems and all AD-joined systems. This will give you a ratio of the % of systems that are managed by Centrify. For example, in my test system I have 12 total systems with 5 managed by Centrify.
This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"
Computers that grant more access and computers subject to more assignments
These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments. Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.
Logins by System
This system view complements the "logins by user" metric discussed in the previous article. This one has an interesting twist. Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems. This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs. Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.
Computers subject to more privileges
This is the privilege view of systems. Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.
Privileged Access with most computers in scope
This metric allows you to identify what rights are more prevalent in the computer population. The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent. If you see something like "run as root" or "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.
Privilege Activities by Type
Often you may need to look at a system and find out exactly what the privileges activities are most common. This complements the user view (e.g. most used privileged commands)
Group and Role views
Before moving into groups and roles, let's add some context. In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups; however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers"; these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).
Roles with Most Access
These are the roles that have the broadest scope in a Centrify deployment. Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.
AD Groups with Most Members
Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups. In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.
AD Group Attestation - Access
The picture above provides information about an AD group that is used in a Centrify deployment. Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.
AD Groups with Most Privileged Access
The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report; however there are exceptions, especially when using selective auditing.
AD Group/Role Attestation
This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.
This is a great report to generate if you need to answer these questions:
- What privileges does the "Apache Web Admin" group provides?
- What role(s) are associated with it?
- What is the scope of the role assignment?
- What is the definition of the role (commands) that it provides?
Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory; the others we'll provide some color.
Failed Logins by reason
Users with Multiple Login Failures
Failed Logins over Time
Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.
Denied Privileged Activities over Time
A spike on these could indicate a compromised account with attempts to perform privilege elevation. MFA can help mitigate this risk.
Centrify Software Operations
Because a system that is not under management is easier to compromise, there are several operational activities that we should track:
When a system is not in AD, you lose access control and the Centrify audit trail log.
DirectAudit Agent Service Stoppages
Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it. Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.
- Part I of this article: http://community.centrify.com/t5/TechBlog/Security
- Centrify Server Suite Report Services Guide - https://docs.centrify.com/en/css/suite2016/centrif
- Centrify Splunk App - https://splunkbase.splunk.com/app/3272/
- Centrify Splunk Add-on - https://splunkbase.splunk.com/app/3271/
- Centrify PowerShell Guide - https://docs.centrify.com/en/css/suite2016/centrif
Security Kaizen - Part I
Part II | Part III
To be an effective security analyst, one must employ techniques like the continuous (or constant) improvement process (CIP); this concept is commonly applied in manufacturing, but it has been extended to many disciplines. The idea is to optimize the elements (people-process-technology) of a product, process or service to make it better.
In the security discipline, this requires partnership with stakeholders (infrastructure, application and business leads) to makes sure the process is not about "pointing out what's wrong" but about minimizing risk and working together to constantly align with the best security practices. This means that your stakeholders need to be part of the optimization process. This is not a top/down or policy-based approach; the idea is that everyone understands the risk factors around databreaches and can volunteer information to optimize the current security posture of the organization.
In this article I discuss the metrics provided by Centrify and integrations with third parties to aid in this constant improvement process.
We'll start with the information produced by our Centrify Server Suite (CSS). For those who don't know, CSS provides:
- Centralized administration for UNIX, Linux and OS X leveraging Active Directory
- Streamlined authentication leveraging Microsoft Kerberos
- Strong Authentication (smart card) and MFA for UNIX, Linux, OS X and Windows systems.
- Privilege Management leveraging RBAC for UNIX, LInux, and Windows systems.
- Session capture + replay and access/privilege tracking for UNIX, LInux, and Windows systems.
Centrify Zones - A powerful ally
Centrify Server Suite has been successful due to the introduction of Centrify Zones. This exclusive capability is implemented as a set of AD objects that allow the following capabilities:
- Cross-platform groupings of systems based on a governance model (zones, child-zones, computer roles)
- Access Control enforcement (least access) - only users that are UNIX identified or authorized can access a system
- UNIX identity management - consolidated AD and Local account (user/group) management
- Role-based access control - enforcement of how (what protocol or method) and what (commands, apps, desktops) can be run with privilege: without exposing a password.
This means that we have in Active Directory the definitions for access and privileges, plus the corresponding clients always send the information to the correct place (event log, syslog); making CSS a rich source of information for any security professional.
The Goal: Least Access & Least Privilege Management
Before you can embark in the journey to operational efficiency, you must understand what are the goals and establish baselines; each goal can be an independent program or project; after all, "you can't manage what you can't measure."
The universal goal of privilege identity management (PIM) is to implement least access and least privilege principles. This means that users only can access the systems they require to perform their functions and their privileges don't exceed what's required for them to do their assigned duties. Shared accounts or powerful roles must have limited use, only with approval in a temporary basis.
With that established we can look at access and privileges using 4 dimensions: Users, Groups, Roles and Systems. The reasoning behind this model is simple: in mature environments, access and privileges are not assigned to the individual, but to groups (e.g. AD security groups) and these may be applied in the context of a system. Let's review some user-based metrics that can be gathered using Centrify Report Services (a tool included with CSS Standard Edition) and our integration with Splunk.
User View Metrics
Who are the users with most access on systems?
This is a basic metric because it defines your universe. It allows you to start a conversation about attestation and use the challenge "do you really need access to all these systems?"; another conversation starter is identifying non-IT or business users that have access to systems and why; if the answer is "It takes too long for me to get access" then the optimization is at the process-granting level.
Users with more access roles
This metric allows you to identify users with aggregated roles that grant access. In organizations that have not embraced temporary access control, the reports associated with this metric allows us to identify instances of granting too many access rights. This is also a great opportunity to identify redundancies and problems with the role/privilege design.
Example: note the report above. Diana is already a powerful user, but she has a role-assignment override in the Ubuntu system named engubu14. This is unnecessary because she's already a zone-level cross-platform sysadmin.
Local UNIX Accounts Managed by Centrify
If you are leveraging Centrify Zones to manage local user accounts in your UNIX-like systems, understanding how these fit in the access model is important. The question to be asked is how are the passwords for these local accounts being managed. You can leverage Centrify Privilege Service or your existing SAPM solution.
Who are the users with most privileges? Do they require those privileges?
This is another baseline metric. Now the focus is on privileges and understanding the population of users that have privileges and its context is important. If temporary access control is not being used, then attestation exercises should focus on why the privileges are needed. If the answer is that "app X breaks all the time and I need to reboot from home" then target the root of the problem (the App).
Privileged vs. Access Users
Now we're using the information in Centrify Zones about access and privileges to understand the landscape and profiles of users.
Who are the most active privileged users?
This metric can be used to find out who are really using their privileges. Watch out for users that haven't been active in a 30-day period.
How frequently are the privileged users changing their passwords?
This is a classic identity management metric. Not only this allows to identify poor practices (like account without expiration) but also compliance to policy. Frequent password changes (e.g. within a 2-3 minute threshold) if group policy allows, should also be subject to a security operations alarm.
The report above can be generated with this PowerShell one-liner:
Get-ADUser -Filter * -Properties passwordlastset, passwordneverexpires
| sort-object name | select-object Name, passwordlastset,
passwordneverexpires | Export-csv -Path c:\reports\passwd.csv
User Overview - Attestation Report
Obtaining consolidated attestation reports is a challenge for all organzations. With Server Suite report services, you can get reports that show the user's access across platforms like Windows and UNIX systems; what granted access (role assignment) and the rights contained within those roles.
Logins by User - Organization View
Identifying our most active users (leveraging access rights) will allow us to correlate activity vs. our universe. Make a habit of running this with a 30-day threshold to find out what users fall out of the access report - those are great candidates for temporary access.
User Overview - Most Privileged User Commands (cross-platform)
These types of reports can be generated using different criteria (time period, user, system, etc); These could allow us to identify what are the user's biases and preferences. For example, looks like my sysadmin performs edits of files most of the time.
Making the most of your Centrify Investment
Most organizations have a journey that may or may not have been completed, perhaps it was all about authentication at one time, however Centrify has invested heavily to shift to the needs to control privileges the right way, by promoting the least access and least privilege principles across client/server platforms. Today we continue to innovate by providing multi-factor authentication; as we go to hybrid clouds, you can rest assured that we'll continue to innovate and provide the valuable insight needed to make the right decisions. In the next entry, we'll discuss the other dimensions.
- Part II of this article - http://community.centrify.com/t5/TechBlog/Security
- Centrify Server Suite Report Services Guide - https://docs.centrify.com/en/css/suite2016/centrif
- Centrify Splunk App - https://splunkbase.splunk.com/app/3272/
- Centrify Splunk Add-on - https://splunkbase.splunk.com/app/3271/
ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more. This is the fourth article in the series. We have covered ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and setting-up and configuring Centrify App Request; in this post we'll discuss the steps to set up Centrify Privilege Access Request to leverage the Service Catalog to request login or password checkout of resource accounts in Centrify Privilege Service.
About Centrify Privilege Service (CPS)
CPS is a privileged identity management solution that focuses on shared secrets on UNIX, Linux, Windows, Network devices, AD domains, Oracle or SQL databases and more. The approach is different than Server Suite that is focused on the principle of least privilege. Privilege Service provides a built-in access request system with single and multi-level approvals.
Privilege Service's Workflow vs. ServiceNow Self-Service
We often get questions about what solution to use for self-service and approvals for application or privilege requests. The answer is quite simple: if you already have all your requests in ServiceNow, you should continue to do so, this helps standardization and a unified user experience. The Centrify workflow engine is designed to meet the basic needs for Centrify products and ServiceNow is a full-fledged Service Management solution.
We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology and assumes you have working knowledge of Identity Service and ServiceNow.
What you'll need
- A SaaS instance of Centrify Privilege Service with UNIX, Linux, Windows or Network Devices configured.
Note: You can use an on-premises instance as well, provided that the network (e.g. publicly-facing) and name resolution (publicly-resolvable) aspects of the design are taken care of.
- A ServiceNow Instance that allows you to install apps (non-developer) with federated access to your Privilege Service instance. For details on how to set up SAML federation with the Multi-provider SSO, click here or review the links below.
- Administrative accounts on both systems
During planning, discuss with your infrastructure, operations and security teams about these topics:
- Will you have a single approval or multiple approval groups per resource?
Depending on the resource(s) in question you may have a single group or multiple groups approve. You may also use a default approval group.
- How will the workflow be designed?
This topic is very organization-dependent. Some organizations may chose to have automatic approvals for certain systems and human approvals when the systems host sensitive data or are subject to strong security policy or regulations like SOx, PCI, HIPAA and others.
- Have you identified a Default Approval Group in ServiceNow?
If you chose to have a single group approve all privileged requests.
- Have you created a CIS role and policy set for the servicenow service account?
The servicenow account in Identity Service requires at a minimum the "Privilege Management" right, in addition, a policy that allows for username/password is required since the REST calls used by the app can't answer multi-factor authentication requests.
- Will you have SLAs tied to your application requests?
Although not in the scope of this post, SN offers a lot of flexibility when designing workflows including expiring worfkow requests when they are not approved within a defined duration.
- Create an Identity Service user (the service account that SN will use to authenticate and perform actions)
- Create an Identity Service role with the minimum rights (the role that will be assigned to the service account)
- Create an Identity Service Policy to allow user/password login
- Download and Install Centrify Privilege Access Request app from the ServiceNow App Store
- Configure the Centrify Privilege Access Request app
Create a Service Account
For this integration, you'll need a service account (you should know how to create users to follow this article). To practice least privilege, this account needs to belong to a role with the Privilege Management right. This is to be able grant login or password checkout rights on the accounts on each system. Centrify Directory users are created under Admin Portal > Users
When creating the user, be mindful of options that can cause an outage (like password expiration), and practice proper rotation and complexity based on your internal policy.
Create a Role with the minimum rights
To create a role, you have to go to the Admin Portal > Roles and Press Add role. In the members tab, add the newly-created account and in the Administrative rights tab, select the privilege management right.
Once completed, press the save button.
Create Policy to allow user/password login
This step may require you to create an Authentication profile that only asks for password (Admin Portal > Settings > Authentication > Authentication profiles). The reason being is that Identity Service will (by default) ask for a step-up method for any unknown connections.
- Log on to the Admin Portal with an administrative account
- Go to Policies > New Policy
- In Policy Settings, scroll down and select the "Specified roles" radio button
- Press Add and browse for the role created in the previous step.
- On the left pane expand User Security Policies > Login Authentication and select Yes to enable.
- Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.
- Press Save
- In an incognito window for your browser, try to log in to the service with the newly-created account. You should only be prompted for username and then password.
Important: Make sure that the policy only applies to the members of the role created for this integration.
Download and Install the Privilege Access Request App from the ServiceNow Store
- Go to the ServiceNow app store and search for Centrify.
- Click on the Centrify Privileged Request App
- Click "Get" to make the Centrify Privileged Request app available for your ServiceNow instances.
- Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.
Configure the Centrify Privileged Access Request app
- In the application pane (left) navigate to Centrify Privilege Request > Properties. Populate these three fields
Centrify Cloud Tenant URL: the URL for your identity service tenant. (e.g. https://your-tenant.my.centrify.com)
Centrify Cloud Service Account: the account you created in previous steps
Centrify Cloud Service Account Password: the strong password you created for the user
- Default Approval Group (Optional): now you have a decision to make based on the planning above. Populate the "Default Approval Group" if you decided to use a single ServiceNow group to approve all privilege requests. You have to find the group in ServiceNow (System Security > Groups; find the group, right-click it and "Copy sys_id" and paste it on the Default Approval Group. If you are planning to have approval groups per App, then you leave the field empty and press Save.
- Go to Centrify Privilege Request > Customize API Sync
- Set the Active checkbox
- Select an appropriate interval based on your SLAs (e.g. 1 hour)
- Press Save and then Execute Now.
This process will synchronize the Resources (systems) and accounts available in Privilege Service
If you set up a "Default Approval Group" you can skip this part. At this point you have to have a list of all the apps and the corresponding approval groups. For example, the root account in the CentOS system called engcen7 will be approved by the Team Development Code Reviewers group included with the sample data of the ServiceNow instance and the canned workflow for software.
To verify the functionality of the app, you'll have to run through the workflow of the apps (or independent apps) based on the approval group defined. For example, in my scenario I chose to have independent approval groups. My requester wants to checkout the "api-key" resource under the azure-rh1 resource and the self-service request is automatically approved based on existing ServiceNow rules.
Once the request is approved the app will provide the requester access to the type of request (login for SSH or RDP access) or checkout (for password reveal or clipboard copy). In order to get access to the system or retrieve the password, the requester must switch over to privilege manager and find the system in the resources list or in their favorites. For login they can use the PuTTY or web client and to check-out the password, they can use the system resource on privilege manager or the mobile app.
Security analysts and auditors may require reports of who has been requesting and approving apps, this is easily accessible using the service catalog requests or under the Centrify Privilege Request Access approvals or the Dashboard section.
Centrify & ServiceNow Resources
There are multiple resources available in the documentation and tech blogs:
- Centrify App Access Documentation
- How to set up ServiceNow for SSO with Identity Service and the Multi-provider SSO Plugin
- How to set up Centrify Identity Service automatic provisioning for ServiceNow
- How to set up Centrify App Access for ServiceNow
- Video: Centrify and ServiceNow configuration overview by @Andy-Z
- Video: ServiceNow Application Access Request Overview by @Andy-Z
- Video: ServiceNow Application Access Request Walkthrough by @Andy-Z
- Video: Centrify Privileged Access Request for ServiceNow by @Andy-Z
- [Labs] Integrating ServiceNow Approvals to Centrify-enhanced sudo using the dzdo validator
We've had requests from many customers to document how Centrify can protect RDWeb access with MFA or two-factor authentication. It turns out it's a simple WS-Federation with Centirfy Identity Service, where you enable MFA for your users.
Please continue reading for instructions on how to set it up.Read more...
This article will show you how to deny or allow access to a web application, when certain conditions are met. The conditions include:
- IP Address (Make sure you first configure a corporate IP range to use this option)
- Identitiy cookie
- Day of the week
- Date range
- Time range
- Device OS
1. Log into the Centrify Admin Portal.
2. Edit your web application and select Policy from the left column.
3. In the right pane, click on the Add Rule button. A new window will appear.
a) Click on the Add Rule button.
b) Select the desired filter and condition
c) Click on the Add button.
d) Choose an Authentication Profile to allow, deny or require multi-factor authentication. Click OK.
4. Select a Default Profile to allow, deny or require multi-factor authentication. Click Save.
If you want to restrict web application access to only devices that has been enrolled into Centrify's MDM:
This article will show you how to only allow access to a web application from a device that has been enrolled into Centrify's MDM. Please note these instructions may change in the future.
Enroll your device into Centrify MDM
Configure your web application
1. Log into the Centrify Admin Portal.
2. Edit your web application and select Policy from the left column.
3. In the right pane, select the checkbox to "Use script to specify login authentication rules (configured rules are ignored)"then click on the Load Sample button. A new window will appear.
4. Select the option "require strong auth for unmanaged devices.js"then click on the Load button.
5. In the policy script, change the value for policy.RequiredLevel to 0. This will deny access from devices that are not managed by Centrify.
6. Select a Default Profile to Always Allow or a predefined authentication profile to perform multi-factor authentication to access the web application. This determins if the user is logging in from a managed device. Press Save when your configuration is complete.
To restrict web application access based on time, location, or other device conditions:
Using local MacOS administrator accounts can lead to security and compliance issues such as unauthorized sharing of the administrator password with non-administrators or remote access by a former employee. The secure approach is to grant Active Directory users Mac administrator rights to minimize risk and meet regulatory compliance. This article will show you how to grant Mac administrator rights to Active Directory users through Centrify's Active Directory group policy settings.
1. In Group Policy Management, create a GPO and enable: Computer Settings > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone groups to local admin group
a) Click on the Add... button. A new window will appear.
b) Click on the Browse button. A new window will appear. You can enter manually enter a group name in this window but it is better to browse and select the group to ensure the proper group name is entered.
c) Enter a keyword into the Name field for the Active Directory group that you want to add, then click on Find Now. Make sure you add IT/helpdesk team and any user that needs admin rights on the Mac.
d) Select the desired group name and click OK.
The setting will apply when the user logs out and logs back in.
If your Mac is using Zone mode, use the following article: https://centrify.force.com/support/Article/KB-3049
In part 1 of this series, we described how to configure DB2 Express-C on Linux and how to configure the Centrify DB2 Plugin. In this article we will focus on testing the installation and an example of how to troubleshoot if things aren't working as expected.
Prevent unauthorized access and minimize risk by restricting MacOS login access to specific Active Directory users or groups.Read more...
How to retaining the user's Mac home directory, when a user wants to change their name after marriage or divorce.Read more...
Thank you for choosing Centrify!
Centrify would like to share another feature: multi-factor authentication on Windows workstation login. With the Centrify Identity Service solution, you can enforce multi-factor authentication to users attempting to access Windows workstations, with 2-factor options such as telephone call, email and Centrify's mobile authenticator (TOTP) utility. The solution works in both an online and offline mode, so workstations disconnected from the internet are also able to authenticate with multi-factor authentication to their machine.
This guide is a basic demonstration of how to setup multi-factor authentication for the following use cases.
- MFA at interative login
- MFA on RDP access
- MFA on screen saver unlock
- MFA in offline mode
Configuration time ~ 1 hour
1) Centrify Identity Service license
2) Domain joined Windows machine
Lets get started!
1) Logged in as administrator to your Centrify Identity Service console, start by creating a Centrify role. This role will contain the Windows workstations you want to enforce multi-factor authentication on.
2) Add the workstations you want to enforce multi-factor authentication on by searching for the resource and clicking 'Add'.
3) Under 'Administrative Rights', assign the Centrify role the "Computer Login and Privilege Elevation" right. This allows the service to deliver a multi-factor authentication profile (created in the next step), to the workstations you've added to the role.
4) Next, create an 'Authentication Profiles' that contains the available factors that are appropriate for users to authenticate with.
5) Assign the 'Authentication Profile' to the 'Login Authentication Profile' and 'Privilege Elevation Authentication Profile' fields.
6) Next, download the Centrify agent from the 'Downloads' dropdown within the Centrify Administrator's portal.
7) Download the 'Centrify Agent for Windows' .msi file.
8) Install the Centrify agent on each workstation you would like to enforce multi-factor authentication on. Note: The workstation must exist within a Centrify role for the Centrify Identity Service solution to deliver the multi-factor authentication profile to the machine (refer to step 2).
9) Review and accept the Centrify End-User License Agreement.
10) The Centrify agent can be enabled with 'Audit'; a feature that allows for recording of sessions for future playback. If you have purchased the audit feature, you can enable this feature in addition to the default 'Access' option. If you do not have the audit feature, keep the default settings and click 'Next'.
11) Once the installation is completed in step 10, click 'Next' to continue setup of the agent on the workstation/server.
12) The following step is applicable if you are using Centrify Server Suite, designed for securing privileges and requiring multi-factor authentication at server logins or privilege elevation. If you are a Server Suite user, the following post will guide you through configurations at this step http://community.centrify.com/t5/TechBlog/HowTo-Co
For purposes of this guide, keep the default settings by leaving the 'Join to a Zone' unchecked and click 'Next' to continue.
13) Ensure that the 'Enable multi-factor authentication on Windows login' is selected. You also have the option of enforcing multi-factor authentication for all active directory users or selectd active directory users logging into the machine. Click 'Next' to continue.
14) Click 'Finish' to complete the installation and setup.
15) A restart is required to complete installation and setup of the service.
16) Upon restart, login to the workstation. During login, you will now see a drop down with the multi-factor authentication options required for login. Login to the machine with one of the factors.
Note: The user must have the available attributes in their user profile for the option to be available to them during login. For example, if a user does not have a telephone number in their active directory profile, and the telephone number is selected as one of the available factors, the telephone option will not be displayed to the user in the drop down.
17) After logging into the workstation, 'Setup Centrify Offline Passcode' will display. This allows a user to successfully authenticate, with multi-factor authentication, to the workstation when the machine is offline. Click on the 'Click here to create your offline passcode'.
18) Click 'Next' to setup offline mode.
19) The Centrify mobile application can be leveraged for the creation of a passcode for offline mode. More generally, you can use utilities that supports OATH to also setup your passcode using existing utilities of preference in your organization. Examples of such utilities are the Centrify mobile app and Google Authenticator.
20) Click 'Finish' to complete the offline passcode setup.
21) Test the offline mode by taking the workstation offline and using the offline passcode to log back into the machine.
The following guide is intended to demonstrate the steps required for enforcing multi-factor authentication on Windows workstations using the Centrify Identity Service solution. Centrify strongly encourages deployment and administrative guides along with testing the solution prior to enterprise deployments.
We hope this guide was helpful and welcome questions you may have in this thread.
One of the major strengths of Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects in Centrify Zones. As a consequence, delegation tasks of zone management, are stored in Discretionary Access Control Lists (DACLs) on Centrify Zone objects in Active Directory.
The Zone delegations can be implemented using PowerShell (for example, using the Set-CdmDelegation PowerShell CMDlet, which is included with the Centrify.DirectControl.PowerShell module), or by using the 'Delegate Zone Control' context menu option in the Centrify DirectManage Access Manager console. Either method will provide you with the ability to chose from a list of a granular zone delegation tasks, that can be delegated to an Active Directory user or security group.
As part of an engagement, Centrify Professional Services can aid you to conceive a delegation model using a RACI matrix, and implement the resultant zone delegations. This allows for implementing least privilege, where (for example) the service account for the zone provisioning agent can only add/remove UNIX profiles to/from a zone, but nothing more than that. If the ZPA service account gets compromised, it cannot be (ab)used to modify UNIX authorizations.
A returning question from customers during these engagements is: How can we validate that the delegations that have been implemented, are actually in place?
This article details the methods available to implement zone delegations, and how zone delegations can be validated.Read more...
Customer are seeing great value from Centrify's Server Suite DirectAudit's session capture and replay capabilities. We hear the benefits from customers all the time. Examples of how DirectAudit allowed them to quickly uncover what malicious users did or mistakes honest users made that caused systems and applications to go down. Like in the human world, having a security camera at the system level, with the ability to search and replay is the best way to determine what is happening or has occurred.
Customers who implement DirectAudit should implement a rentention policy and purge audited sessions after a period of time. Doing so allows the Audit Store(s) to remain small which delivers better performance. Their are multiple ways to implement a data retention policy for DirectAudit, including rotating databases every so often as described on page 9 of the Database Management guide. Another option not as well know, and the focus of this article, is that data can be purged after a certain amount of time. For example, delete sessions older than 90 days.
Centrify provides a tool called PurgeSessions documented in Knowledge Base article KB-3394. PurgeSessions can be scheduled to run using the Windows scheduler every 2 weeks to delete sessions older than the retention policy.Read more...
Want to configure wireless settings for your users without having to manually touch each device? With the Centrify Identity Service, WiFi settings can be pushed to Mac, iOS, and Android mobile devices using policy.Read more...
Além de capturar os dados de sessões com o DirectAudit, muitas empresas necessitam que os meta-dados das sessões sejam enviados a uma base de dados centralizada para que os eventos possam ser correlacionados com outras fontes de dados como aplicações, sistemas operacionais, bases de dados, etc., para que por exemplo, possa se ter o rapidamente a informação que determinada aplicação parou de funcionar exatamente quando um usuário executou uma ação específica numa sessão auditada pelo Centrify.Read more...
With the release of Centrify Server Suite 2016 came a new feature for providing zone-based provisioning of local users and groups on UNIX and Linux. Prior to this release, the automatic provisioning of local service accounts and their associated groups was a manual process, usually outside of the scope of Centrify deployments.Read more...
This article describes an approach to integrating Centrify Server Suite for UNIX with a third-party MFA solution. We'll focus on PingID MFA from Ping Identity as our example. This approach is unique in that it does not rely on Centrify Identity Service as the third-party MFA integration point. Rather the target UNIX operating system serves as the integration point. The integration is enabled through a combination of the Centrify Server Suite Unix agent the PingID MFA Unix PAM library. The key points this article conveys are:
- The recommended approach to implement a third-party MFA with Centrify Server Suite is through Centrify Identity Service. Whenever a CSS MFA policy is triggered, CSS UNIX agent calls into CIS which in turn brokers the request to the third-party MFA;
- For customers that don’t want to implement CIS to enable third-party MFA for their Unix systems, it is technically possible to configure a third-party MFA PAM module with the CSS UNIX agent without relying on Centrify Identity Service. However, there are several technical dependencies need to consider. Section 4 addresses some of the risks and issues with this approach.
A Little Mac Testing Help
When I am testing new group policy configurations for the Mac, I like to have the Centrify Mac Diagnostic tool at the ready. Here are the steps that I use to put the Diagnostic tool on the Dock. The MacDiagnosticTool allows the tester to quickly see via a graphical interface the following:
- AD Connectivity and Network Information for the Machine
- Group Policy Settings that are being applied to the machine
- User Information such as their UID, AD Group Membership etc.
- Centrify Debug Information
- And contact information for Centrify Support.
This is an end-to-end guide for integrating Yubikeys with the Centrify Identity Service platform using the OATH-HOT.
HOTP works just like TOTP, except that an authentication counter is used instead of a timestamp. The advantage of this is that HOTP devices requires no clock.Read more...
The attached script can be used with the Deployment Manager to unbind a Mac that is bound to Active Directory via the Apple Directory Services plugin. This will allow mass deployments of the Centrify agent with binding to Active Directory using the Centrify Directory Services plugin.Read more...
Here is a quick primer on the security risks associated stale Window Service Account Passwords and how Centrify’s new "multiplex account” feature helps… Towards the end is an embedded YouTube video demo showing the feature in action.
Service Now : Use Cases with Centrify integration
Currently we have the following modules integrated into Service Now
- Application Access request
- Privilege access
This article is a multipart series. The first part explains what MFA is and the benefits of implementing MFA, especially with a service like Centrify Identity Service. Follow on articles will go through the process of setting up MFA through the Centrify Identity Service.Read more...
Customers with NetApp ONTAP filers are looking to provide consistent level of access across multi-protocol CIFS and NFS shares. To do this, the filers need to obtain Active Directory users and the UNIX identity of those users to provide the unified level of access required. Customers with Centrify deployed can very easily accomplish this. The following guide will show you how to integrate NetApp onTap filers with Centrify.Read more...
This article is an attempt to provide the background information, tools and mechanisms to spot and correct Public Key Infrastructure-related issues for those who are setting-up Centrify Multi-factor Authentication or trying to enroll Identity Broker clients.
Public Key Infrastructure is at the heart of how many Internet and corporate infrastructure services are secured today and Centrify has always provided ways to make PKI simpler for organizations. A big example is adcert, this tool provides support for enterprise trust and auto-enrollment for Microsoft Certification Authority for UNIX, Linux and Mac.
After the introduction of Identity Service and Privilege Service and the advent of high-profile data breaches and industry guidance like PCI 3.2 Data Security Standard (Requirement 8, Sections 3, 10, 11 & 12), many organizations are rushing to implement Multi-factor Authentication. Another big milestone is the popularity of hybrid clouds; Centrify has introduced a new capability called Identity Broker, this new Linux Agent allows organizations to "enroll" in Centrify Privilege Service and to "bridge" multi-source enterprise directories like Active Directory, LDAP, Google Directory and Centrify directory.
All these scenarios make use of Public Key Infrastructure to establish the assurance that clients are talking to the right entity (non-repudiation) and encryption in transit is enforced. An important point to understand about every Centrify SaaS or on premises tenant is that it has an internal certification authority that is used for multiple uses including encryption, non-repudiation, mobile management and authentication.
PKI Trust and Multi-factor Authentication
With Centrify Identity Service and Privilege Service, it's possible for current users of Centrify Express or Centrify Standard Edition to implement MFA in a very quick and effective way; supporting both modern and legacy-based (RADIUS) solutions. In the platform's 16.10 release, Centrify proactively deprecated Integrated Windows Authentication (SPNEGO) over HTTP to exclusively use HTTPS.
The implication for users is that any interaction that used IWA (SPNEGO) required PKI trust in the authentication framework for MFA negotiation.
This means that framework after 16.10 looks like this:
As you can see from the framework above, there are 3 ways you can make sure the PKI requirements are satisfied:
- Enterprise Trust: This is the preferred method. Ideally, an organization has a properly-implemented PKI trust capability. Unfortunately, this is relatively obscure especially in the mid-market. A great benefit to organizations using Microsoft PKI is that Centrify DirectControl agents will take care of the enterprise trust automatically by bundling the Root and Intermediate CAs into the proper UNIX or Linux bundle.
- Public Trust: This was a bit expensive a while back, but the easiest way to make sure that PKI trust works out of the box is to use certificates issued by a public vendor like Verisign or GoDaddy.
- Tenant Trust: Each Centrify tenant will automatically create IWA certificates for all the Centrify connectors in the deployment. This means that customers can either manually, with DevOps or with Microsoft GPOs can set up a trust chain. This can be automated but requires a bit of work.
How to determine if your UNIX/Linux system is ready for MFA
Centrify provides a tool (adcdiag) that will allow users to spot issues with the MFA configuration. For example, in a Centrified system with an AD environment with Microsoft PKI, the root CA certificate is automatically downloaded to the /var/centrify/net/certs folder and appended to the bundle corresponding to the platform.
Here's a sample output from a Centrified system with Enterprise Trust:
This output is favorable because DirectControl (adclient) is making sure a lot of the moving parts are in place including making sure that any root or intermediate CA certificates are in the trust chain. The reason why this "just works" is because a few seconds after joining AD, and if the system is allowed to certificate auto-enrollment, the client will make sure all the proper certs are provisioned to the system and the CA bundle is updated. This makes this process work like plug and play.
In cases when there is no trust, then the ca-bundle has to be updated with the IWA trust certificate from the tenant. When you run the adcdiag, several checks will fail including this one:
If you inspect the file referenced by adcdiag, there will be the following information in this section:
"Error setting certificate verify locations" and this will point to the CA bundle for the platform (e.g. /etc/pki/tls/certs/ca-bundle.crt). There are several ways to solve this issue:
- Enterprise: Appending the root CA certificate in PEM format to the CA bundle file
- Public: Making sure the CA bundle is up-to date
- Tenant: Appending the IWA root ca in PEM format to the CA bundle file.
Fixing MFA CA Trust issues in UNIX/Linux platforms
You'll need to know:
- How to get the certificate in question
- The encoding of the certificate you're receiving
- The location of the bundle for the operating system in question
- For large production deployments, you'll need to use a viable distribution method
adcdiag failed in a CentOS 6 system. The issue is with the /etc/pki/tls/certs/ca-bundle.crt. I am working with a SaaS instance of Identity Service.
Locate the IWA Cert and Determine the Encoding
- In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service and click "Download your IWA root CA certificate"
- Locate the file and try to open it with a text editor. If the text reads "--- begin certificate" you are dealing with a usable certificate.
- Save the file and transfer it to your target system (e.g. IWACert.crt)
Append the certificate to the CA bundle
- In the target system, concatenate the contents of the certificate file to the platform CA bundle. E.g.
$ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crtNote: there are OS utilities like "update-ca-trust" that perform this step the correct way. This is for illustration only.
- Re-run adcdiag and verify the results.
As you can see, the steps above won't scale in a large environment. This is why the preferred method is to have enterprise trust in place. Other ways to distribute certificate settings include scripts, DevOps solutions like Chef or Puppet and in Microsoft PKI scenarios, you can use Group Policy.
How to determine if your Windows system is ready for MFA
Windows systems may be easier to work with when it comes to Enterprise Trust but you have to be skillful to troubleshoot as well.
- Certificates MMC snap-in: This allows you to review all certificate store.
Note that you have to be a local administrator to view the computer certificate store and that Centrify will add certificates in the local store of systems running the Connector.
- Certutil: This is one of the most powerful tools around "certutil -viewstore root" will display the trusted root CAs.
Centrify Access Manager
This Microsoft management console provides the capability to perform an end-to-end testing in scenarios where DirectAuthorize Roles are being used for MFA. You'll need to be at least on version 2016.
This option is under right-click Direct Manage Access Manager > Test Centrify Cloud Connection.
Centrify Logger Service
This component is installed with Centrify Server suite. You can add it to the Centrify Agent for Windows(tm) for advanced troubleshooting capabilities.
The Centrify Agent for Windows will provide you visual feedback when there's a PKI-related issue (see below) but internally it's checking the Certificates directory under \ProgramData\Centrify\DirectAuthorize for the binary blob that represents the tenant's certificate.
In this case, the same solutiona applies, but in this case, we're placing the certificate in the trust store for Windows.
Like we discussed before, in large Enterprises, ideally Enterprise or Public trust is set up with automation tools or Group Policy.
Microsoft provides a great article on the topic: https://technet.microsoft.com/en-us/library/cc7724
Bottom-line: When attempting to configure MFA, don't forget this checklist:
- Is there a PKI trust between the system and the Centrify service?
- Can the system authenticate via Kerberos? (is it joined to the domain natively (Windows) or via Centrify (UNIX/Linux))
- Is the machine added to a Centrify role that allows for Computer Login?
- Are all the ports required for communication cleared (8443 or custom)?
PKI Trust and Identity Broker
Identity Broker is Centrify's newest capability that allows for multi-directory authentication in private or public clouds.
IB also requires trust for operations like enrollment.
Identifying issues with cdebug
Depending on the state of the Linux system (if the ca-bundle is non-existent, modified or outdated) the enrollment operation will fail. Let's look at a failed enrollment log using two PuTTY windows.
Window 1: /usr/share/centrifycc/bin/cdebug on Window 1: tail /var/centrify/centrifycc.log -f
Window 2: cenroll -t tenant.my.centrify.com -c [code] -F all -l Identity-Broker-Users
Window 2: Failed to initialize connection to Centrify identity platform: Failed to connect to Centrify identity platform
Dec 17 18:16:07 engcen6 cenroll: DEBUG <centrify/cloud.post> Failed
to post HTTP request: Post https://tenant.my.centrify.com/health/ping:
x509: certificate signed by unknown authority
This can be further verified with the cURL command:
$ curl https://tenant.my.centrify.com $ curl: (77) Problem with the SSL CA cert (path? access rights?)
In this particular case, my tenant is on-premises Privilege Service, so I can follow the instructions on this KB:
The steps are very similar to the ones outlined above. The strategy depends on the use case Enterprise, Public or Tenant trust is being used.
When trying to enroll, the output is very different:
Verbose: Platform detected: centos_6_6_standard Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy... Enrolling in Centrify identity platform https://bootcamp.my.centrify.com/ using registration code... Starting Centrify agent... Centrify agent started. Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy... Feature enabled: Application-to-Application Password Management Feature enabled: Centrify Agent Authentication Verbose: Restarting Centrify agent after enabled features... You have successfully enrolled in Centrify identity platform: https://tenant.my.centrify.com/ You may need to restart other services that rely upon PAM and NSS or simply reboot the computer for proper operations. Failure to do so may result in login problems for cloud users.
At Centrify capabilities change to provide ease of use and supportability. We hope this article can help you anticipate issues with your testing or setup. Ultimately, at the enterprise level, PKI is a vital capability that has to be taken seriously and designed to balance the people-process-technology triad.
If you're an existing Centrify customer, you may have seen recent news about the capability to support Multifactor Authentication at Windows Login. This article explains how to set this feature up in your Centrify Server Suite and Centrify Identity Service environment.Read more...