This is the the third lab in the series around Strong Authentication. In the previous lab we focused on StrongAuth for UNIX/Linux using PKI Smart Card or YubiKey.
We will be focusing on securing access to Internal web or SaaS apps, shared credentials and privileged sessions using Centrify Identity Service and Privilege Service.
If you're familiar with Identity Service and Privilege Service, they provide built-in step-up authentication like:
- Centrify Mobile Authenticator
- Security Question
- YubiKey (Smart Card) for PKI-based auth to Apps secured by CIS and secrets and sessions secured by CPS
- OATH OTP (TOTP/HOTP) using YubiKey or other OATH compatible Authenticator (e.g. Google Authenticator)
a) Securing access to applications or the Centrify Portal (IDP initiated)
b) Securing access to UNIX & Linux systems
c) Step-up (privilege elevation) for UNIX, Linux and Windows systems
c) Provide RADIUS-based challenges for Cisco, Juniper and other VPN scenarios
d) Securing access to reverse-proxied on-prem applications made available via Privilege Service
e) Secure applications that implement Centrify APIs (e.g. Web, Mobile SDKs)
- Web Apps (on Prem or SaaS) need to be protected with strong mechanisms
- Systems that provide access to secrets (like password managers) and secure session brokers also require strong authentication.
- The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility. There's no need to have a solution to secure servers, secure apps, provide multifactor and other services. This promotes complexity.
- Regulatory frameworks (like the upcoming PCI DSS 3.2) stress the use of Multifactor Authentication in sensitive systems.
- Organizations may have already standardized on OATH or PKI authentication and it may be undesirable for them to adopt new mechanisms or train users.
- Both CIS and CPS support Certificate-based authentication (Smart card) and OATH OTP
- YubiKey simplifies the adoption of both mechanisms in a single form factor.
- Limit application users (on-prem web or SaaS) to strong authentication via Smart Card (YubiKey) or OATH OTP
- Limit privileged users (of shared passwords and secure sessions) to strong authentication via Smart Card or OATH OTP
- Centrify Identity Service or Privilege Service Tenant (start a trial here) with basic knowledge an account with system administrator's rights
- A test user (can be from any source: AD, LDAP, Cloud Directory, Federated or Social Identity)
- A YubiKey4, NANO or NEO and Yubico Authenticator
(alternatively, any OATH-compatible authenticator like Google Authenticator will do fine)
- Active Directory with Certificate Services
- A Certificate provisioned for the user's smart card or YubiKey
To see instructions on how to set this up, check out the Announcement Post that contains the base lab instructions.
- For SSO to work, the system browser needs to be configured accordingly.
See this link to configure your browser
- Define an authentication profile for login that requires Smart Card or OATH OTP for login to the Centrify Portal
This will cover any portal-based access (IDP initiated) or unauthenticated service-provider initiated connections
- Request OATH OTP multifactor authentication to access to an application.
- Define an authentication profile that considers users authenticated with Smart Card as strongly authenticated
Centrify Identity Service (or Privilege Service) Setup for Contractors
- Sign-in to Centrify Identity Service (or privilege Service) and go to Cloud Manager > Policies.
At this point you can either create a new policy or work with a new one tied to an specific role. I am using a Contractors role and tying it to that role.
- Navigate to Policies > Your Policy > User Security Policies > OATH OTP >
Allow OATH OTP Integration: YES
Show QR code for self service: [Select your appropriate setting]
OATH OTP Name: [type a descriptive name]; I used Google Authenticator or YubiKey
OATH OTP has been enabled, now it's time to enable it for an authentication profile.
- Navigate to User Security Policies > Login Authentication
- To configure the policy for login - capture the name of the effective rule (e.g. GlobalAuth High)
- To configure the profile for secure app access - capture the name of the effective policy.
Save the policy.
- Navigate to Settings > Authentication > Authentication Profiles and identify the profiles form Step 3.
For each profile:
In my example, I'm using a single profile that allows for phone call and OATH OTP client, then Password.
This step can be performed in two ways:
- Self-service from User Portal > Account > Actions > Set up "[OATH OTP name]"
- Bulk (this is for larger deployments); from Cloud Manager > Settings > Authentication > Other > OATH Tokens
Use the provided Excel template to perform a bulk import of OATH tokens.
- You can reuse the smart card certificate provisioned to YubiKey in the announcement + lab setup post.
- Upload your PKI trust chain to your tenant using Centrify Support
- Log in to Cloud Manager and go to Policies > [policy that applies to employees] > User Security Polcies > Login Authentication
- Edit the "Other Settings" accordingly:
- Press Save
- Contractor can self-service enroll their OATH OTP using the user portal
the Centrify Identity Service (or Privilege Service portal) requires
OATH OTP, then password (to protect the user's Password).
- Access a designated application (e.g. Amazon AWS) requires OATH OTP.
- Authenticate using your Smart Card or YubiKey
- Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
- Select the Certificate in the picker.
- Type the PIN for your smart card or YubiKey
- Depending on how you set up your policy, Smart Card sessions can be set up to bypass additional controls.
- When using self-service onboarding for OATH OTP tokens, allow for a secondary step-up (like phone call) so the user can enroll their OATH token.
- When using self-service onboarding for OATH OTP tokens,
be careful about allowing access to QR codes. Users have to be educated
that it is a sensitive operation. Centrify provides a policy to allow