Background
Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway). This "jumpbox" supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.
Goals of this Lab
- Identity Consolidation:
- Leverage existing Organizational Directory Services.
- Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
- Usability: Provide secure access to systems running the SSH Service without visiting the Centrify portal.
- Access Control: Align with best practices for security access controls, like:
- Identity Assurance via Multi-factor Authentication.
- Adherence to the Least Privilege principle (users shall only access systems and accounts that they have a business need to access).
- Auditability:
- Event tracking (who, what, when).
- Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
- Simplicity and multi-use: Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).
Requirements
- A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
- A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
- A handful of test systems running the SSH Service.
- SSH and sFTP client software.
- If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
- Familiarity with Centrify Infrastructure Services.
- Policy and Authentication Profiles.
- A configured "Corporate IP Range."
- Familiarity with CPS Roles, Permissions and Sets.
- Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22). Note that these ports are customizable.
- Understading of Infrastructure Services Role-based Access Control.
Conceptual Diagram
This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.
Diagram for this Lab
High-level Implementation Steps
AWS
- In this implementation, I'm using an AWS VPC as my "corporate HQ" it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain. This will allow me to have different user populations.
- I am leveraging an existing Active Directory and DirectAudit infrastructure.
- Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group, that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
- For internet name resolution, I created a CNAME record in the rpdemo.net DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
- Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
- Installed Privilege Service (on-premises) in single-master mode (no HA);
Note: The single-master configuration does not provide HA or allows for upgrades. This is for testing purposes only. - Added a Centrify connector with the adproxy and SSH gateway services.
- Configured Privilege Service to use my ISP's IP address as part of the corporate IP range. This is to provide the assurance that only I can access it.
- Configured 2 roles: An Administrator, and a Least Access role.
- Configured Workflow for the resources.
- Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed. - Launched existing Windows and Linux systems.
Test Matrix (Success Criteria)
| Category | Description | Result |
| Identity Consolidation | Users from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway. | Pass |
| Identity Assurance with MFA | Users must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway. | Pass |
| Policy | Users can only access from a specific subnet. | Pass |
| Least Access | Users can only access the systems based on business need to know via Web Portal or SSH Gateway. | Pass |
| Access Request | Users must request temporary access to shared accounts. | Pass |
| Monitoring (real time) | SSH/RDP – Sessions can be monitored in real time. SFTP – Active sessions can be tracked. | Pass |
| Advanced Auditing | Sessions can be reviewed after the fact (indexing, replay, etc.) | Pass |
| Infrastructure Simplicity and Reuse | The same components can be used for other capabilities (e.g. RDP, etc). | Pass |
Test Videos
Identity Consolidation and Assurance with MFA
Policy, Least Privilege and Access Request
Real-time Monitoring + Session Capture and Replay
Infrastructure Simplicity and Reuse
