[Labs] Using Centrify Audit Trail for UNIX/Linux with AWS CloudWatch

By Centrify Guru I on ‎04-22-2017 10:23 PM - last edited a month ago

Background

As more and more organizations run infrastructure in IaaS platforms like Amazon AWS, there's an increased need to enhance security operations and prove effective implementation of security controls.  AWS provides a solution set that includes CloudWatch.  

 

About CloudWatch

As defined by Amazon "CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time. You can use CloudWatch to collect and track metrics, which are variables you can measure for your resources and applications." 

For more information, check out the Getting Started guide for CloudWatch:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

 

The goal of this article, is to provide some initial guidance to leverage AWS CloudWatch to collect, track and measure Centrify Audit Trail events in UNIX, Linux systems running in AWS.

For a companion article that describes the process for Windows instances, go here: http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-Windows-with-AWS-Cloud...

 

About Centrify Audit Events

Centrify Audit Events (CentrifyAuditTrail) is the cross-platform framework used by Centrify Server Suite to document and provide access, privilege and audit trail event data. When a Centrify-enabled service is invoked, an audit trail event is written to UNIX syslog or Windows event log.  These events are documented in the  Audit Events Administrator's Guide for the current version of Server Suite.  The types or content of the events vary depending on the edition (Standard or Enterprise).

 

For more information, check out the current guide for Server Suite 2017: https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf

 

Pre-Requisites

For this lab, you'll need:

  • An AWS Account with the proper VPC setup, privileges in CloudWatch and IAM
  • Active Directory (run by you or managed by Amazon) and the proper VPC name resolution and communications
  • A Centrify zone, sample users and access/privilege setup
  • At least one Linux system joined to Active Directory and the Centrify zone
  • The Linux system should have some Centrify data (e.g. logins, privilege elevations) present in syslog.

Centrify AWS Lab:  You'll need to be at Standard Edition level to follow this lab, more info here:

http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771

 

Implementation Overview

  1. Set-up your AWS Linux Instances for CloudWatch Logs (use AWS's docs)
  2. Verify Centrify Audit Trail events in the CloudWatch log group
  3. Identify Access and Privilege-related Metrics provided by Centrify
  4. Create the Filters and Assign a Metric
  5. Create a Dashboard
  6. Create an Alarm.

 

Set-up your AWS Linux Instances for CloudWatch Logs

For information on this topic, please review AWS's documentation:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html

Once you have the /var/log/messages logs for your instances, please proceed to the next section.

 

Verify Centrify Audit Trail events in the CloudWatch log group

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Logs > Click on the log group for your Linux instances (e.g. "/var/log/messages"  or the group you are using for your Linux syslog)
  3. Click on Search log group and in filter events, type "AUDIT_TRAIL"
  4. Verify the results
     audit-trail.png
    If you have a system that was joined to the domain via Centrify, there will be event data about access, privileges and other activities.

Now you have verified that your systems are streaming syslog data with Centrify Audit Trail information.

 

Identify Access and Privilege-related Metrics provided by Centrify

Centrify DirectControl provides access control and role-based privileged elevation; this component is called DirectAuthorize.  DirectAuthorize controls how users access the system and what commands they can run. The implementation of privilege elevation leverages Centrify-enhanced sudo.

 

Example 

The metrics that you'll track will depend in your objectives and in your maturity level.  For illustration purposes, let's track successful and unsuccessful access and privilege elevation in my Linux EC2 instances. After reviewing the Centrify Audit events guide, I identify the following events:

 

Access Control

PAM Authentication Granted:  These events are related to the UNIX framework;  the PAM Auth module is used by any PAM-enabled application.  This can be a catch-all for any app using it (e.g. OpenSSH server, Switch User (su), etc);  the Centrify Event Id is 24100.

pamev.png

Centrify SSHD Denied:  My EC2 instances are running Centrify-enhanced OpenSSH.  I'm interested in looking at this metric, especially on instances with public IPs because it may denote attempts to break-in or move laterally. The Event Id is 27101.

 

Privilege Elevation

Centrify dzdo Granted:  Indicates successful privilege elevation using Centrify-enhanced sudo.  Event id: 30000.

Centrify dzdo Denied :  Indicates denied privilege elevation using Centrify-enhanced sudo.  It may allow to identiy attempts for privilege abuse.  Event id: 30001.

 

Create the Filters and Assign a Metric

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Logs and select the radio buttion next to your log group (e.g. /var/log/messages)
  3. Click Create Metric Filter
    • In filter pattern, type: centrifyEventID=24100
    • Press "Assign Metric" 
  4. In Filter Name, type a unique name for the filter
  5. In Metric details, create a new namespace (e.g. CentrifyAuditTrail) or browse for it if you already have it.
  6. In Metric name, give it a descriptive metric.
    metric.png
  7. Press Assign Metric.
  8. Repeat the process for all the metrics you've identified.

Create a Dashboard

Before creating a dashboard, you may want to plan how to visualize the data.  In some instances it's useful to see the aggregate data (# of events), in others it's useful to see a trend (graphs overlapped with time).

Once you have thought of how to visualize the data, it's time to get started with your dashboard. 

 

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Dashboards > Create Dashboard and give it a name, then press Create Dashboard
  3. To add aggregated information, select the Number widget
  4. Select your Namespace, Dimension and check the metric(s) to be measured
  5. Go to the graphed metrics tab, and select the proper statistic and period  (e.g. sum and 1 day) and press Update Widget.
  6. Once you have the Widget in the dashboard, adjust the size and label.

Repeat the process with the trend using with a line or stacked area.

 

Below is a simple dashboard that includes the metrics above.

 

dash.png

Create an Alarm

A meaningful alarm could be based on a pattern outside expected behavior, an availability issue or another event (or aggregation of events) based on the risk that wants to be corrected.  This example is for illustration purposes only.

Example:  The threshold for attempted abuse of Centrify-enhanced sudo is 3 or more attempts within a 5 minute period, when this happens, an email should be triggered to the members of the secops distribution list.

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click Browse Metrics and next to Centrify-dzdo-Denied, click the alarm icon.
  3. In create alarm:
    Name:  Alarm-Abuse-dzdo
    Whenever: is equal or greater than 3 for 1 consecutive period
    Period: 5 minutes
    Statistic: Sum
  4. Actions
    Whenever this alarm state is Alarm
    Create a new list (secops@your-domain.com)

Trigger the alarm

  1. Sign-in to your Linux instance with homer
  2. Type 'dzdo su - root' and press enter
  3. You should get this message:
    [homer@cdctest2 ~]$ dzdo su -
    Sorry, user homer is not allowed to execute '/bin/su -' as root on cdctest2.\
  4. Repeat 3 more times.  This should trigger the alarm.
    alarm.png
  5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified
    alarm2.png

Conclusion

We have only scratched the surface of the capabilities provided by AWS CloudWatch, however in the context of Identity and Access Management, the enrichment of security operations via logs, alerts and dashboards should be done via standard tools; otherwise if each tool duplicates these capabilties, then security operations won't know where to go first.  Centrify provides native plugins for Splunk, IBM QRadar and HP ArcSight.  These tools provide both operational data as well as like the following privilege command pie chart.
most-used.png

 

Related Articles

[Labs] Using Centrify Audit Trail for Windows with AWS CloudWatch:

http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-Windows-with-AWS-Cloud...

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools: http://community.centrify.com/t5/TechBlog/Security-Corner-Reviewing-your-Access-and-Privilege-Manage...  

Setting a Centrify AWS Test Lab: http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771
Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl on EC2 Linux instances: http://community.centrify.com/t5/TechBlog/Labs-Using-AWS-OpsWorks-Chef-12-to-deploy-Centrify-DirectC

Centrify Audit Trail Administrator's guide (2017): https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf 

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.

 

How is access to Amazon Windows AMIs secured today?

 

The AWS Security Best Practices document specifies the following information:

aws-sec-windows.PNG

At a basic level, this just means that beyond providing the ability to decrypt the administrator password based on your private key, it's up to the customer to deploy additional controls (including x.509 authentication, Active Directory or local accounts).

 

For large organizations, both x.509 or local accounts may create an additional identity silo; this means that Active Directory (either an extension of the on-prem directory or an instance running in AWS is the main option).

 

Centrify Privilege Service and Centrify Server Suite provide the flexibility to implement these controls and we'll cover more in subsequent posts, now let's explore the benefits of combining Privilege Service with the Centrify Agent for Windows for Centralized Sessions and Windows MFA

 

Privilege Session Brokering facilitated by CPS provides these benefits:

  • Centralized Identity Source:  You can leverage your existing on-premises Active Directory to authenticate users accessing EC2 Windows AMIs.
    dirsvc.png
  • Centralized Session Initiation:  This control centralizes all RDP sessions from a central management perspective.  With CPS, this capability is enhanced by providing watch and terminate options  (session proctoring) and session recording (capture and replay).
    watch-terminate.png
  • Limited Exposure:  by not using public IP addresses for your Windows systems, you are limiting exposure to attacks.
  • Additional controls:  CPS's ability to implement RBAC, Geo/time fencing can meet or exceed policy requirements.
  • Password Services:  Shared account password management for local Windows and UNIX accounts;  AD accounts, Oracle and SQL databases, Windows services and scheduled tasks.

Multi-Factor Authentication with the Centrify Agent for Windows provides these benefits:

  • You can enforce MFA using different factors like:  Mobile Authenticator, OATH OTP, Legacy (e.g. SecurID), Phone factor, SMS, e-mail or security question.
    methods.PNG
  • Contexts:  You can limit this to login or privilege elevation (if you're using Centrify Server Suite zones technology - will be covered later).
  • Enhanced controls:  If you're allowing direct connectivity, users must provide MFA and authenticate with their AD credentials.
  • Offline Access and Rescue Rights:  Leverate OATH OTP codes for MFA in case there's no access to Centrify services
    offline.png

 

Conclusion

With Centrify Privilege Service + the Windows MFA capabilities enabled by the Centrify Agent for Windows we can secure Windows AMIs by providing ways to leverage your existing AD infrastructure to centralize sessions, provide SAPM services and provide MFA enforced at the local level. 

 

Demo Video

In this demo we show how we can centralize session origination using Centrify Privilege Service, how we can use a shared account or log in manually.   We'll configure Windows MFA for a demo user and we'll demonstrate how the control is enforced via the jumpbox or if the user chooses to connect to the Windows AMI directly.

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS services like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Identity Service (or Privilege Service) to secure the Amazon Account.

 

What's the Amazon account?

The amazon account (or Amazon root account) holds the keys to the AWS Kingdom.  This is the first account set up, most likely used to set up billing, IAM roles and groups, keys, etc.

 

What constitutes a bad practice?

If your organization is sharing the Amazon account with several members of your IT staff and you're not adding additional controls around it, you are going against several security best practices.  

 

What is Amazon's guideline?

Amazon's guidelines are simple:

  • Limit access and usage of the Amazon account
  • Add multi-factor authentication
  • Implement Amazon's Identity and Access Management groups

The basic guideline is to implement a model of least privilege access.   At Centrify that's what we have traditionally preached in the context of Operating Systems and Apps.   Additional complexity is added depending on your AWS deployment model.  This is an except from the AWS Security Best Practices document (August 2016, Pg 16).

 

amazon-root.PNG

 

How can Centrify help?

Centrify Identity Service (and Privilege Serivce) provide a simple-to-use federation engine that allows the implementation of Amazon IAM without the overhead of federation services.  In addition, it provides a powerful policy and multi-factor authentication engine that allows the deployment of controls to secure the account.

 

Enhancements since the previous entry

Last year when I wrote the original post, I outlined how to implement MFA to secure the root account.  The Amazon AWS (User/Password) app is deployed leveraging the password wallet built-in to the platform.  Since the password is securely replayed, users just click on the app link, they don't rely on shared credentials.

 

A big benefit of our approach was flexibility.  In addition to Smart Card or Yubikey for pre-authentication, you could use the Centrify Mobile Authenticator and individual OATH codes for each user, you could use Phone factor, e-mail, SMS and security question as step-up authentication when the application is lauched.  

 

Enhancements since last year

  • Radius Client as MFA - this means that you can use your legacy (or modern) tokens (RSA SecurID, Vasco, Symatntec, DUO, Microsoft) via our platform
  • Workflow and approvals - this means that you can use our existing access request or external worklow like our ServiceNow App Access app for governance and documented approvals
    sn-amazon.PNG
  • Policy at the application level - this was just released, and as announced by @Friedsam this weekend, 16.10 provides application granularity.
    add-policy.png

Example

With Centrify assets, you can deploy controls that limit access to users that have been explicity approved access to the application, and to use the Amazon account they must use multi-factor authentication, only from inside the corporate network and during business hours.  You can have different combinations of controls on different environments (accounts).

 

Conclusion

With Centrify Identity Platform (Identity Service and Privilege Service) not only you can meet, but exceed the Shared Responsibility of securing your  Amazon account. 

 

Demo

In this demo, we implement three controls:

- Documented Approvals (with ServiceNow)

- Secure the shared password (not available/visible)

- Multi-factor Authentication

 

 

 

Related Articles

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

 

Background

This is the fourth article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure Amazon Identity and Access Management (IAM)  by leveraging Centrify Identity Service and your on-premises Active Directory.

In this article we'll discuss how to use Centrify Server Suite to secure your AWS Server instances by leveraging Active Directory (in AWS, on-premises or a mixed environment).  The drivers behind this are:

  • To continue to leverage Active Directory as the source of identity and privileges
  • To eliminate the reliance on SSH keys or fragmented identities
  • To provide a tried and true privileged elevation mechanism (sudo) without the inconveniences of sudoers files
  • To be able to deploy additional controls such as time-fencing and multi-factor authentication for linux
  • To be able to quickly attest who can access systems, their roles, privileges and how the privileges were granted
  • To enforce the principle of separation of duties

Active Directory and AWS

The prescriptions outlined on this article depend on how your Active Directory AWS strategy is designed.  It's even possible that there's no AD in your AWS deployment today, in that case you'd benefit from looking at the next entry in the series (that focuses on session brokering and password management).  Assuming you are using AD in AWS, here are some of the models we've seen with our customers:

 

AWS-CSS-connected model.png

The Connected Model

This model implements some degree of permanent connectivity between AWS and your on-premises infrastructure (e.g. Amazon DirectConnnect, Firewall ACLs, VPNs/Tunneling, etc); the end result in the Active Directory layer is that the following models can be implemented:

  • Account-resource model:  With accounts living on-premises and a resource domain existing in AWS (for example, with a one-way trust).
  • Extended model:  Domain controllers extend to AWS (writable or read-only).

The connected model allows for organizations to extend their AD and Centrify deployments and treat AWS as another site.  As far as Centrify goes, it's like adding another branch or site.

 

The implications of this model are permanent connectivity (and costs), plus the need to implement the network and security components prior to the AWS deployment.  Once it is in place, the administration is simplified.

 

 AWS-CSS-disconnected model.png

The Disconnected Model

This model uses the opposite approach.  It treats AWS as a disconnected entity.  Users connect to AWS through the Internet.  Directory services are separated.

 

In this scenario, independent AD forests exist on premise and in AWS.  The benefits of this model are:

  • Faster-to-production because there's no need to wait for dedicated connectivity to be set up.
  • No need to architect a security model around AD.

The obvious drawback of this model is dual administration.

 

Commonalities and Customer Inquiries

When communicating with prospects and customers on the field, these are the commonalities that I have observed:

 

  • They want to extend the Centrify Server Suite benefits to these environments
  • They have questions about their AD architecture (the two models below hint at how things would be designed and managed)
  • They have questions about the instance lifecycle:
    • How can I automate Centrify client deployment?
    • How can I automate AD joins when systems are launched?
    • How can I automate AD leaves when systems are terminated?
  • They have questions about management frameworks  (e.g. Scripts, DevOps, Amazon OpsWorks)
  • They want to automate privileged operation leveraging PowerShell
  • They want to deploy additional controls (like multifactor authentication or time-bounding)
  • They have miscellaneous questions about pre-validation and the use of DirectAudit (session capture and replay)

 

Fortunately the building-blocks for all the questions asked above are scattered in the Tech Blogs and the Centrify Knowledgebase.  Instead of using the Plan-Do-Check-Adjust model in this article (because of the combination of scenarios), I will speak about each bullet-point individually.

 

Extending Centrify Server Suite to Amazon Web Services

This one is straightforward.  CSS requires Active Directory and there are several avenues that you can use.  This all depends on the access and privilege model to be implemented. 

  • If status-quo will be maintained and the same user population retains the same rights to AWS
    • You may only need to create a child zone or a computer role in your existing zone structure.
    • Active Directory design principles are maintained: 
      - AD Sites and Services (subnets/sites) need to be created and maintained. 
      - Global Catalog location needs to be accounted for, especially if Universal or nested groups are used.
    • If RODCs are in use, adjust your instance provisioning model based on the prescriptions of the Server Suite planning guide (pg. 205).
  • If there's a different access model being implemented
    • If there will be a completely new governance model within the same forest, then a parallel zone may need to be created and delegated to the proper group.
    • If a brand-new forest with a 1-way trust is created, then a zone in the resource domain will have to be created and principals from the trusted domain have to be added to provisioning and role-granting groups.

EC2 Instance Lifecycle

The EC2 lifecycle (Launch, Stop, Terminate) has implications depending on the use cases.  In permanent environments, systems are expected to be there for a long time;  in elastic environments systems may be alive for a few weeks while an app is tested, or may be scaled-up or down depending on load or business seasonality.

Aspect that require planning include naming conventions, properly deprovisioning systems and using the analyze wizard to make sure things are tidy.  Some resources:

Deploying the Centrify Software and Joining (or leaving) AD automatically

Deployment depends on the approach.  I've seen customers that bake the software into their private AMIs (this allows for them to test and validate any corporate software) or I've seen the use of repositories and configuration management software.  The guidance here is consistent:  If you want the system to participate in your AD, you must align your hostname with your naming convention,  specify the domain name, and automate the AD join (using a krb5.conf file and a service account keytab).

Baking the software and utilities to an image makes things more predictable; however using a DevOps framework is the way of the future (given the testing orientation). 

AWS-CSS-sequence.png

 

This article shows how to create these building blocks: [HOWTO] Use Centrify Tools for Public/Private Cloud Automation Activities

The Termination sequence is relatively the same:  retrieve utility files, run kinit and instead of adjoin, run "adleave --remove" this will remove the computer from AD and Centrify, freeing-up the license.

 

DevOps Frameworks

Amazon AWS provides a great set of tools based on Chef (OpsWorks).  If you choose to use this framework, you need to have your recipes and underlying infrastructure in place (e.g. an APT/YUM repo, or Chef infrastructure) to host the dependencies.  If you are looking at the DirectControl, DirectAudit or CLI toolkit as an app, you have to sequence the triggering of the script based on your design (e.g. user-data, setup/configure/deploy/undeploy/shutdown). 

 

Here are some avenues:

User Data field:

AWS-CSS-userdata.png

OpsWorks:

AWS-CSS-userdata.png

These articles show the same sequence using Chef or Puppet:

 

AutoScaling, OpsWorks and Automation Resources

 

Automating Access and Privilege Operations with PowerShell

Amazon AWS provides a powerful toolset that has been implemented in PowerShell.  This is very aligned with Centrify's efforts (both Centrify Suite Standard and Enterprise edition provide PowerShell management tools). 

AWS-CSS-powershell.png

The subject of PowerShell is very broad, here are a few resources:

 

Securing Windows Servers in AWS

Some of you are also using Windows servers in AWS and ask us how we can help.  The windows security model has been challenged by modern threats like PtH and the dependency on high-privileged accounts (like Administrator) and groups (like Administrators and Domain Administrators).  Centrify DirectAuthorize provides a powerful mechanism to control access and privilege elevation.

 

This article goes to length to explain the process for Windows:  http://community.centrify.com/t5/Community-Tech-Blog/HOWTO-Eliminate-the-use-the-shared-Root-UNIX-Li...

 

Automation: In Suite 2016, Centrify added the ability to join zones automatically with the dzjoin command.  This can be combined with the EC2Config tasks for your Windows based AWS systems.  The User's Guide for Windows describes dzjoin in detail.

 

Advanced Controls and Reporting

Depending on the data classification or risk profile of the systems hosted in AWS, organizations may want to deploy additional controls to provide the assurance that only authorized users are accessing these systems, in addition, these systems may be subject to attestation requirements just like on-premise systems.  We will explore other controls in part 5, however Centrify Standard Edition provides multi-factor authentication for access and privilege elevation as well as several mechanisms to obtain access data.

 

Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel