With the 16.8 monthly release of Centrify Identity Service and Privilege Service, Centrify is adding the ability for the Identity Platform to act as a RADIUS client.
This will open the opportunity for CIS and CPS users to have
authentication profiles for MFA products that support RADIUS (e.g. RSA,
Symantec, CA, Vasco, etc).
This lab will allow you to set up a Linux server to act as your
AD-integrated OTP+RADIUS server. Then we'll configure CIS/CPS to act as
a RADIUS client and support it as an additional MFA option.
Disclaimers
This is a lab entry. Production designs require planning for people, process and technology.
RSA SecurID, Symantec VIP, Vasco, YubiKey, Google Authenticator,
FreeRADIUS and CentOS are registered trademarks of their respective
owners.
Lab Design
The proposed lab looks as follows:
As you can see, we're using the following components:
Identity Service or Privilege Service (can be the on-premises version of CPS too)
Cloud connector: enabled for AD Bridging and RADIUS client
Centos 6.x System: this system acts as
RADIUS Server > FreeRADIUS configured for PAM
Google Authenticator PAM Module > will provide OTP codes for enrolled users
Centrify DirectControl > Provides AD integration and NSS/PAM based identification/authentication
Active Directory: Provides infrastructure identity services (directory, authentication, policy)
Implementation
In this lab we will not cover the setup of an identity service instance and cloud connector. Some resources:
Configuring FreeRADIUS for PAM a) User and Group for the Radius Daemon
To allow the radiusd daemon to traverse the filesystem to read the Google Authenticator config files on each user's home directory, you have to change the user/group in the configuration file. This may be undesirable in a production environment.
Edit the /etc/raddb/radiusd.conf and find:
user = radiusd
group = radiusd
Change to
user = root
group = root
and save the file.
b) Enable PAM for the Default Site
Edit the /etc/raddb/sites-enabled/default and find:
# Pluggable Authentication Modules.
# pam
uncomment the PAM module and save.
pam
c) Configure Users for PAM
Edit the and find
#DEFAULT Group == "disabled", Auth-Type := Reject
# Reply-Message = "Your account has been disabled."
uncomment and add the line as follows:
DEFAULT Group == "disabled", Auth-Type := Reject
Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM
Tip: To check your work so far
In one session window, run the radius daemon in verbose mode
$ sudo radiusd -X
[truncated]
Ready to process requests.
If there are any issues with the current configuration, you can verify it with the output.
Open another session and create a new user
$ sudo useradd testing
$ sudo passwd testing
New password:
BAD PASSWORD: it is based on a dictionary word
Retype new password:
passwd: all authentication tokens updated successfully.
Now you have a user to test your RADIUS server via PAM.
In that same session, use the radtest utility with the client set for the localhost client.
radtest testing Mysecret123! localhost 0 testing123 Sending Access-Request of id 204 to 127.0.0.1 port 1812
User-Name = "testing"
User-Password = "Secret123!"
NAS-IP-Address = 192.168.81.34
NAS-Port = 0
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=204, length=20
On the first window, you'll see the verbose output somewhat like this:
rad_recv: Access-Request packet from host 127.0.0.1 port 53367, id=204, length=77
User-Name = "testing"
User-Password = "Mysecret123!"
NAS-IP-Address = 192.168.81.34
NAS-Port = 0
Message-Authenticator = 0x8c11ad4b5c1dbd597764716d95d3d9e3
# Executing section authorize from file /etc/raddb/sites-enabled/default
[truncated]
Sending Access-Accept of id 204 to 127.0.0.1 port 53367
This verifies that things are set up correctly so far. Cancel radiusd debug (CTRL+C)
Install Centrify DirectControl and Join AD
We'll use the Centrify Repo and join AD in Workstation mode.
At this point, if you want another sanity check, you can repeat the same debugging but with an AD user credential.
Configure the Radius PAM directives for Google Authenticator
Edit the /etc/pam.d/radiusd perform two modifications.
Add this line on the top of the file auth required pam_google_authenticator.so and comment the auth module.
Here what we'll achieve is to provide the Google Authenticator code as our one-time password via RADIUS. Other combinations of PAM modules can achieve a Password+Code.
The final result should look like this:
#%PAM-1.0
auth required pam_google_authenticator.so#auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-auth
This configuration challenges for the OTP code only and ignores the password.
Enroll an AD user with Google Authenticator
Log in with a test AD user to your Linux system
Run the google authenticator setup (google-authenticator)
Last login: Thu Aug 4 06:22:50 2016 from 192.168.81.11
$ google-authenticator
https://www.google.com/[truncated] <= copy this URL and paste it on your browser
Your new secret key is: ETIQLTKPBQV4TVLH
Your verification code is 2647620
Your emergency scratch codes are:
08703664
[truncated]
Follow the prompts until you complete setup.
Paste the URL in a web browser and use your Authenticator QR Capture function to capture the code. Alternatively you can add the code manually.
Repeat this process for all your test users.
Verify RADIUS functionality with OTP
In a session, open Radiusd in verbose mode. [sudo radiusd -X]
In another browser, test the authentication with the code from the OATH OTP authenticator. radtest [username] [oath otp code] localhost 0 [pharaphrase] In my environment it looks like this:
You have verified functionality.
Set up the Cloud Connector as a RADIUS Client
On the FreeRADIUS Server you have to set up the connector as a client.
If you haven't done so, close the radiusd debugger.
Edit the following file /etc/raddb/clients.conf go to the end and add:
Notes: - You can use the IP address or FQDN of your RADIUS-enabled connector - You must choose a decent complex string as your secret and save it for the next section.
Save the file.
Note: In some Linux systems/versions you may need to set SELinux to permissive. This is to allow radiusd to interact with PAM.
Centrify Identity Service or Privilege Service Setup Overview
Configure the RADIUS Server
Configure Connector for RADIUS
Enable RADIUS in your Policy
Enable 3rd Party RADIUS in your Authentication Profile(s)
Verify Functionality
Modify RADIUS service startup
To configure the RADIUS Server
Go to Cloud Manager > Settings > Authentication > Radius Connections > Servers Tab and press Add Name: A descriptive name (e.g. SecurID PIN+Code) Description: Optional Server IP Address: The IP address of your server Port: Change if not default (1812) Server Secret: Must match the secret you set up in the previous step.
Configuring a Connector for RADIUS
You need at least one connector enabled for RADIUS that can reach the RADIUS server.
Go to Cloud Manager > Settings > Network > Cloud Connectors > [connector] > RADIUS > and Check "Enable connections to external RADIUS servers"
Also make sure that the RADIUS Client service is enabled.
Enable RADIUS in your User Authentication Policy
Go to Cloud Manager > Policies > [click on the policy that applies to the user(s)] > Expand User Security Policies and Click RADIUS. Set "Allow 3rd Party RADIUS" to Yes and Save.
Enable 3rd Party RADIUS in any corresponding Authentication Profiles
Cloud Manager > Settings> Authentication Profiles > [click profile that you want to enable] and check
"3rd Party RADIUS Authentication" and press OK. Repeat with other profiles if needed.
Verify Functionality
Launch radiusd in debug mode (sudo radiusd -X) on your Linux system.
Trigger a Step-up protected event in CIS/CPS (private login, secure access, password checkout) Monitor the debug log for any errors. If everything goes as expected, keep testing with other users.
Tidy-up: Set up the Radius Service for Automatic Startup
$ sudo chkconfig radiusd on
$ sudo service radiusd start
OS X users without administrative rights get challenged each time they need to stop/resume print queues. Organizations looking to implement the least privilege management security model may need to provide ways for users to be "print operators" on a Mac, without granting full administrative rights. The "Printers and Scanners" system preference does not provide granular entitlements.
This issue may cause many calls to the helpdesk
This post covers a way to overcome this issue using AD security groups and the "Map zone groups to local groups" Centrify GPO.
The idea is that you map an AD security group to the _lpadmin and _lpoperator local groups of the system.
What you'll need:
An AD Security Group and the ability to control memberships.
The ability to modify GPOs that apply to your Macs using the Centrify templates and GPMC/GP Editor.
Step-by-step Create and populate an AD group
Use ADUC, PowerShell, request system or any tool of record to
request an AD group. Give it a descriptive name like "mac-print-admins"
Populate the group with the AD users that will be allowed to manipulate queues.
Edit the "Map zone groups to local group" GPO
Open GPMC and browse to the GPO that applies to your Mac. Right click and select edit.
In GP Editor, browse to Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts and double-click the Map zone groups to local group GPO.
Press add and and in local group type _lpadmin, then browse for the
AD group created in the previous step. (e.g. mac-print-admins).
Repeat same process on step 3 with the local group _lpoperator. At the end, the GPO looks like this:
Press OK and close GP Editor and GPMC.
Refresh the GPOs on the Mac and verify your results
Log on to the Mac as a non-admin user that is a member of the AD group created in the first section.
Open a Terminal.
First, refresh the group policies by running the adgpupdate command. (adgpupdate -T computer)
Now verify that the GPO is effective by running adgpresult (adgpresult | grep _lp)
Your user should not be challenged moving forward to pause/resume
print queues, plus the user does not have admin rights, therefore you're
aligned with the least access principle.
Background This is the third 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 the Amazon Root account. In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source.
About Amazon AWS Identity and Access Management (IAM) For those who aren't familiar with Amazon IAM,
it provides capabilities that allow organizations to centrally manage
Users, Roles, Rights and Policies efficiently for all services (compute,
storage, database, application) provided by the platform.
Another Identity Silo Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception. Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider. Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.
The typical tasks include user creation, credential/password/key
management, password resets, group/entitlement management and
attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:
Once
we adopt this "dual-management" we are promoting IT fragmentation, the
potential consequences are complexity, limited productivity and possible
security expose. Finally, depending on the data classification or risk
profile of the assets in AWS,
this identity silo is subject to the corporate security policy
(password policies, user attestation reporting, least access management,
etc.)
In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect.
This
article provides a practical example that not only meets but exceeds
the best practices around Amazon AIM, eliminates dual-administration and
aligns administration with internal policies. Using Centrify CIS & Active Directory to Secure Amazon's IAM In
this post I describe a framework to leverage Centrify Identity Service
to meet and exceed the Identity Management requirements for Amazon AIM
while maintaining the corporate directory (AD) as the single-source of
truth. The
example used in this blog post focuses on Active Directory, however,
those who are familiar with Centrify know that the user sources can be
or any other internal LDAP source, Google Directory, Federated Partner
or even Social Identity providers. The
solution outlined below establishes a SAML federation agreement between
Centrify Identity Service (CIS) acting as the Identity Provider (IdP)
and Amazon AWS IAM acting as as the Service Provider (SP); Since CIS
will be using Active Directory principals as an identity source, AD
continues to be the single-source of truth for the enterprise and AD
group memberships, AWS IAM Roles and CIS roles can be used to manage
entitlements.
Enhanced Objectives
Eliminate duplicated administration efforts and align Amazon IAM users with corporate policy
Leverage AD Group membership (or CIS Roles) for Amazon IAM provisioning (add/moves/changes/deletions)
Leverage AD Group membership (or CIS Roles) and IAM Groups for Entitlement Management
Provide SSO to Amazon AWS with minimal federation infrastructure required
Enforce Advanced Policies: Require Multi-factor Authentication or Enforce Access from the Corporate Network
Limit access to IAM credentials to those with business need-to-know
Planning Stakeholders
Identity and Access lead: Organizes and coordinates the effort.
Security SME: Outlines the security requirements based on policy or risk profile
Infrastructure SMEs: Execute the implementation of the tasks
Planning Discussions Below are planning discussions that can be had around IAM:
What are the services being used in AWS? Will there be a process defined when new services are used?
Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
Will contextual policy be needed? E.g. restrict access to corporate sites, geo-fencing or time-fencing?
What will be the attestation process for AWS users? (e.g. AD Group Management or CIS Roles/Reports)
Will
Multi-factor authentication be required for IAM users? What factors
(Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
Will approvals be required for IAM access? (Request/Approval)
Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration?
Will users be allowed to log in with their AWS password or just with SSO?
How will users be uniquely identified in AWS? (should shortname, email, UPN or another field be used?)
Our Example
The organization uses Amazon EC2 to hosts servers in the cloud
There are two types EC2 of users: Users with Full Access and ReadOnly Users.
Users with full access will be managed via AD Security group Membership (AWS-EC2-FullAccess)
Users with read-ony access will be requested on-demand (must be approved) via a CIS Role;
Another group (AWS-IAM-Managers) can manage IAM in AWS and will approve requests.
All users must provide step-up authentication via Token, Email, SMS or Phone to access AWS
The implementation will use the Centrify-provided SAML template
The Centrify-Provided PKI Certificate will be used for the SAML Assertion
Users will be identified in AWS with their Shortname.
Technical Requirements
Active Directory with security groups created and populated
Centrify Identity Service Tenant
A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles
Implementation This process implies a partial configuration in CIS, followed by the configuration in AWS, finishing-up in CIS again.
Initial Configuration in Centrify Identity Service Add and Configure the Amazon Web Services (AWS) Console: SAML+Provisioning
In Cloud Manager, navigate to Apps > Add Web App
In
the Search Box, type AWS and press Enter, on the results, pick the
"Amazon Web Services AWS Console SAML+Provisioning" template and click
Add.
When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
In Application Settings: - Type your AWS Account ID (if you don't know it, go to "My Account" in AWS) - Click the "Download SAML provider metadata document" link, this will save the XML file in your downloads folder
In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
Skip User Access and Policy (we'll revisit)
In Account Mapping , use the "Use Account Mapping Script" option and type the following:
LoginUser.Username = LoginUser.Shortname
This option will send the user's shortname as the identifier. If there are duplicates, you can switch to mail or UPN.
Press Save, you'll have to return here for adjustments.
Configuration in AWS Create the Centrify SAML IDP
Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
On the left pane, click Identity Providers and press the Create Provider button on the right
Select SAML in provider type
In provider name type a descriptive name like "Centrify" or "CentrifySAML"
In
Metadata Document, browse to the downloads location where the XML file
from step 4 above was saved, press Next Step and press Create.
Configure the AWS IAM Roles for the Centrify SAML IdP
On the Amazon AWS IAM Dashboard, Click Roles > Create New Role The names of the roles about to be created must match the role names in Centrify Identity Service.
Example:
EC2 Administrators - this role grants the ability to manage all aspects
of EC2 instances, therefore a policy that matches that entitlement has
to be tied to the role. Name: AmazonEC2Admins Role Type: Role for Identity Provider Access > Grant Single Sign-On (WebSSO) access to SAML providers [Select] Establish Trust: SAML Provider > Select Centrify > Press Next Step Verify RoleTrust: Press Next Step Attach Policy: type "AmazonEC2FullAccess" and Check the box This corresponds to the administrative role for EC2 instances Review: Press Create Role
Repeat the process for the rest of the roles. Make Sure that you are writing down the names of the Roles.
Finishing the Configuration in Centrify Identity Service Create and Populate the Centrify Identity Service Roles
In Cloud Manager, navigate to Roles > Add New Role
Name: AmazonEC2Admins (must match the name of the corresponding role in AWS)
Members: Populate based on your requirements. For AmazonEC2Admins I'm leveraging AD membership
Press Save. Repeat with any other roles created in AWS
Complete the User Access Section of the AWS Role-Based SSO App
In Cloud Manager, navigate to Apps > Click your AWS SAML App
Go to User Access and check the box on the roles you've created.
Press Save, you are ready to verify.
Verification At
this point you can verify access. If using Active Directory, simply
add a user to any of the AD Security groups that grant access and the
user will get the App automatically. Upon clicking on it they'll be
able pick the role (or roles, in case of multiple entitlements) and
simply press sign-in. They
should only be entitled to the activities allowed by the policies
associated with the role. For example, in the case above the user will
only be able to manage EC2 instances and details, no more than that.
Adjustments Adding Multifactor Authentication , Limiting Access from the Corporate Network and Workflow and Approvals
MFA
is built-in to Centrify Identity Service. All you need to do is check
the box, and provided there's an authentication profile that will
support the step-up methods you will be set. These include and are not
limited to: Centrify's Mobile Authenticator, Phone call, SMS, Security
Question, Email or OATH Based OTP (Duo, Google Authenticator, Amazon
Virtual OTP)
To
limit access based on the corporate IP range, all you need to do is
populate the NAT addresses for the organization and check the
appropriate box.
To
establish a workflow and approvals scheme, a role needs to be
designated as the approver, see the video playlist below or the one
included in part two to view the particulars.
Provisioning of IAM Users There
are instances in which it is desirable to have a provisioned user
inside AWS IAM. What needs to be reconciled is if users will know their
IAM passwords, in that case they can go directly to
the sign-in page and bypass the controls outlined above. We can extend
the SAML template to provide provisioning capabilities as well.
Enhancements of CIS 2016.2 Amazon
AWS provides an virtual MFA capability that leverages OATH. As of
February 2016, Centrify allows you to use any OATH based OTP mechanisms,
this means that you can leverage those mechanisms as well.
