If you want to use the Centrify Mobile Authenticator without enabling the Mobile Device Management, you can configure this in the Policy section of your tenant.

Users will be able to use the Centrify application on their mobile device for application access and two factor authentication. 

 

 

Read more...

Enforcing CIS Apple OSX 10.11 Benchmark with Centrify

By Centrify Advisor I on ‎12-14-2016 02:02 PM - last edited 3 weeks ago

Center for Internet Security (CIS) Security Benchmarks are consensus-based security configuration guides both developed and accepted by government, business, industry, and academia. The benchmarks are used by organizations worldwide to help meet compliance requirements for FISMA, PCI, HIPAA and more. The CIS Apple OSX 10.11 Benchmark, provides prescriptive guidance for establishing a secure configuration posture for Apple OSX 10.11. Centrify enables the ability to manage these security settings on the Mac through Active Directory Group Policies

 

Note: Be sure to test and review the settings before deploying into production. Some settings may interfere with normal operations.

 

1.2 Enable Auto Update

See instructions 

 

1.3 Enable app update installs

See instructions

 

1.4 Enable system data files and security update install

See instructions

 

1.5 Enable OS X update installs

See instructions

 

2.2.1 Enable "Set time and date automatically"

Centrify will automatically configure the Mac to use your domain controller for the NTP service when the Mac is bound to AD through the Centrify agent.

 

2.3.1 Set an inactivity interval of 20 minutes or less for the screen saver

See instructions

 

2.3.3 Verify Display Sleep is set to a value larger than the Screen Saver

See instructions

 

2.4.1 Disable Remote Apple Events

See instructions

 

2.4.2 Disable Internet Sharing

See instructions

 

2.4.4 Disable Printer Sharing

See instructions

 

2.4.5 Disable Remote Login

See instructions

 

2.4.8 Disable File Sharing

See instructions

 

2.4.9 Disable Remote Management

See instructions

 

2.5.1 Disable "Wake for network access"

See instructions

 

2.5.2 Disable sleeping the computer when connected to power

See instructions

 

2.6.1 Enable FileVault

See instructions

 

2.6.2 Enable Gatekeeper

See instructions

 

2.6.3 Enable Firewall

See instructions

 

2.6.4 Enable Firewall Stealth Mode

See instructions

 

2.7.1 iCloud configuration

See instructions

 

2.7.2 iCloud keychain

See instructions

 

2.7.3 iCloud Drive

See instructions

 

4.3 Create network specific locations

See instructions

 

4.4 Ensure http server is not running

See instructions

 

4.5 Ensure ftp server is not running

See instructions

 

5.2.1 Configure account lockout threshold

The domain account lockout threshold policy will apply when the Mac is bound to Active Directory.

 

5.2.2 Set a minimum password length

Domain password policies will apply when the Mac is bound to Active Directory.

 

5.2.3 Complex passwords must contain an Alphabetic Character

Domain password policies will apply when the Mac is bound to Active Directory. 

 

5.2.4 Complex passwords must contain a Numeric Character

Domain password policies will apply when the Mac is bound to Active Directory.

 

5.2.5 Complex passwords must contain a Special Character

Domain password policies will apply when the Mac is bound to Active Directory.

 

5.2.6 Complex passwords must uppercase and lowercase letters

Domain password policies will apply when the Mac is bound to Active Directory.

 

5.2.7 Password Age

Domain password policies will apply when the Mac is bound to Active Directory.

 

5.2.8 Password History

Domain password policies will apply when the Mac is bound to Active Directory.

 

5.6 Enable OCSP and CRL certificate checking

See instructions

 

5.8 Disable automatic login

See instructions

 

5.9 Require a password to wake the computer from sleep or screen saver

See instructions

 

5.10 Require an administrator password to access system-wide preferences

See instructions

 

5.12 Create a custom message for the Login Screen

See instructions

 

5.13 Create a Login window banner

See instructions

 

5.14 Do not enter a password-related hint

See instructions

 

5.15 Disable Fast User Switching

Fast User Switching is disabled by default, but the setting can be managed by Centrify through group policy. To learn more see instructions.

 

5.16 Secure individual keychains and items

See instructions

 

5.19 Install an approved TokenD for smartcard authentication

A TokenD module is automatically installed with the Centrify Mac Agent. See instructions for configuring smart card authentication.

 

6.1.1 Display login window as name and password

See instructions

 

6.1.2 Disable "Show password hints"

See instructions

A security researcher from Segment has discovered a vulnerability in Microsoft Remote Desktop for Mac that allows a remote attacker to execute arbitrary code on the target machine. The advisory indicates the affected versions are 8.0.36 and "probably prior". Until Microsoft provides a patch, a suggested mitigation is to temporarily disable Microsoft Remote Desktop Client for Mac. 

 

Using Centrify, enable the following group policy settings to block Microsoft Remote Desktop from being launched on the Mac.

 

Step 1. Enable: Computer Configuration > Policies > Administrative templates > System > Group Policy > Configure User Group Policy loopback processing mode.

 

Loopback.png

 

Set the policy to Enabled and the mode to Merge.

 

LoopbackMerge.png

 

Step 2. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to applications. For Access mode, select User can open all Applications except these.

 

Prohibit applications.png

 

 

Step 3. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to the user-specific applications.

 

User-specific applications.png

 

Click Add and enter com.microsoft.rdc.mac.

 

The policy will apply the next time the user logs out and logs back in. When the user attempts to launch Microsoft Remote Desktop the following dialog boxes wll appear.

 

RDP restricted.png 

[HOWTO] Setting-up Centrify App Access for ServiceNow

By Centrify Guru I on ‎12-08-2016 03:50 PM - last edited a week ago

Background

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 third article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and in this post we'll discuss the steps to set up Centrify App Access ServiceNow to add workflow and approvals to Centrify Identity Service applications.

 

Centrify's Access Request vs. ServiceNow Workflow

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 Centrify Identity Service Instance with some published apps assigned to roles
  • 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

 

Planning

During planning, discuss with your infrastructure, operations and security teams about these topics:

  • Will you have a single approval or multiple approval groups per application?
    Depending on the application(s) in question you may have a single group or multiple groups approve.  Or have approval groups per app as well.
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for simple apps and human approvals when the apps require a license or will add access to sensitive data.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve access to all apps.
  • Have you mapped all Apps to ServiceNow groups for the purposes of approval?
    E.g. the "twitter" app is approved by the Social Media group;  the "O365"  app is approved by the manager and then the security department.
  • 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 "Role Management" and "Application Management" rights, 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.

 

Implementation

Overview

  • Create an Identity Service user
  • Create an Identity Service role with the minimum rights
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify App Access from the ServiceNow App Store
  • Configure Centrify App Access

Create an Identity Service user

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 two rights:  Application Management and Role Management.   This is to be able to modify role membership and application attributes.

sn-create-serviceuser.png

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 an Identity Service role with the minimum rights

When you create the role, grant the two rights illustrated below and add the previously-created user to this role.

sn-svc-acc-rights.png

 

Create an Identity Service Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (Settings > Authentication > Authentication profiles).   The reason being is that Identity Service will (by default) ask for a step-up method for any unknown connections. 

 

  1. Log on to Identity Service with an administrative account
  2. Go to Policies > New Policy
  3. In Policy Settings, scroll down and select the "Specified roles" radio button
  4. Press Add and browse for the role created in the previous step.
  5. On the left pane expand User Security Policies > Login Authentication and select Yes to enable.
  6. Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.
  7. Press Save
  8. 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.

policy-summary.png

Important:  Make sure that the policy only applies to the members of the role created for this integration.

 

 

Download and Install the Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
    sn-app-access.PNG
  2. Click on Centrify App Access
  3. Click "Get" to make the Centrify Identity Service app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Configure Centrify App Access

There are three configuration tasks required.  Properties, API Sync and Applications.  The third category is only needed if you are using individual groups as approvers for each app.
Properties
  1. In the application pane (left) navigate to Centrify App Access > 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
    sn-app-access-conf1.png 
  2. 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 application 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.

API Sync

  1. Go to Centrify App Access > Customize API Sync
  2. Set the Active checkbox
  3. Select an appropriate interval based on your SLAs (e.g. 1 hour)
  4. Press Save and then Execute Now.
    sn-api-sync.png
    This process will synchronize the CIS Apps and Roles available with ServiceNow.

Applications
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 "Amazon as root" app will be approved by the Software group included with the sample data of the ServiceNow instance and the canned workflow for software.
sn-req-approval.png

 

Verification

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 (Stewie) will request the app and this request has to be approved by ITIL user.

 

sn-app-workflow3.png

Once the request is approved (and the underlying task) the app will perform the provisioning of the role that grants access to the application and the icon will show up automatically.

 

Documented Approvals

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 App Access approvals section.

 

Improvements

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In the previous article, I outlined the steps to set federation with ServiceNow using Multi-Provider SSO.  In subsequent posts we'll discuss how to add ServiceNow workflow and approvals to apps and shared accounts using the Centrify ServiceNow store apps.

 

We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:

 

What you'll need

  • A Centrify Identity Service Instance with some published apps
  • A ServiceNow Instance that allows you to install apps from the ServiceNow app store
  • Administrative accounts on both systems

 

Planning

During planning, discuss with your Infrastructure, Operations and Security teams about these topics:

  • What are the source directories for SN users?
    It's possible that there will be AD, LDAP or other directories involved, based on user populations this adds complexity.
  • Will role mapping be used?
    This feature allows the provisioning of the user's ServiceNow role in addition to account creation
  • Are the target Roles created in ServiceNow?
    ServiceNow has several canned groups, however it's possible that your organization needs custom roles for different entitlements.
  • Are the source groups created in the corresponding source Directories?
    Group management simplifies the provisioning on each target Directory.  For example, adding a user to an AD group can simplify the provisioning process.
  • Are the Centrify Roles created based on the information gathered?
    sn-cis-roles.PNG
  • Is the UserID field correctly identified for mapping?  Will any transformations be needed?
    In some implementations it's preferred to use the email address as the unique identifier.
  • What will be the provisioning behavior? Overwrite existing entries or leave as is?
    Sometimes this may or may not be desirable.
  • What will be the deprovisioning behavior? Disable or Delete the user?
    In instances in which important data is left behind on systems, it's better to disable the account instead of deleting it.
  • What will be the behavior when users are removed from a ServiceNow group?
    Users may change functions, therefore this behavior has to be defined beforehand.

 

Implementation

Overview

  • Download and Install the Identity Service App from the ServiceNow App Store
  • Update the State field in the ServiceNow User Role Table
  • Create a ServiceNow User and Assign it a special role
  • Configure Provisioning on the Centrify ServiceNow App

Download and Install the Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click the Centrify Identity Service app.
    sn-app.PNG
  3. Click Get to make the Centrify Identity Service app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Update the User Role table

  1. In the left pane, search for Tables and select System Definition > Tables
  2. In the tables lab, make sure the Go to picker says name, and search for sys_user_has_role
  3. In the User Role table, click the State field, scroll down to choices and press New.
  4. Add a new field with Label Inactive and Value inactive, then press Update.
    sn-state-inactive.PNG

Create a ServiceNow User and Assign Role

You need to create a service account that will be assigned one of the roles created by the Identity Service app.  This role contains all the entitlements needed for provisioining.

  1. In the left pane, go to System Security > Users and Groups > Users and press New. Then set:
    UserID: username
    Email: username@domain.com
    Active: checked
    Password: type a complex password
    Other fields: are optional
    Press Submit when complete.
  2. Click the user you just created in the list of users.
  3. Scroll down and click Edit in the Roles section.
  4. Search for x_cenr3_centrify_u.centrify_admin and select it.
  5. Click > to add it to the Roles list.
  6. Click Save.

Configure Provisioning on the Centrify ServiceNow App

  1. Log in to Identity Service with a user with at least the Application Management right
  2. Go to Apps > ServiceNow Web - SAML + Provisioning > Provisioning
  3. Check the "Enable provisioning for this application" box. Ideally you'll start with Preview Mode
  4. Configure the connection details:
    Account Name - type the ServiceNow instance ID
    Admin Name - type the name of the previously created SN user
    Admin Password - type the password for the previously created user
    sn-verify-prov.PNG

Other Provisioning Options

The following configuration items respond to the planning section. For example, in my test environment
I've decided to have 3 distinct Identity Service roles that mapped to different ServiceNow roles:
sn-role-mappings.PNG
I chose not to delete users when they are deprovisioned (just disable them) and to do sync overwrites:
sn-prov-options.PNG

Finally, for more complex scenarios, there is the possibility to use custom scripting for transformations and other options:
sn-transform.PNG

Verification

Centrify Identity Service provides several options to verify that provisioning will work as expected.  In the previous section you saw the Preview Mode option.  Using the Admin Portal > Settings > Users > Provisioning gives you the option trigger a sync on all or an individual app.  Once you trigger the sync, you have the option to see the activity.
In my example, I added an AD User (stewie.griffin) to ServiceNow Admins role, and these are the results.

sn-track-job.PNG

Once you have determined that all the provisioning actions are working as expected, you can enable live mode and verify the results in the ServiceNow side.

 

Enhancements

There are different ways to enhance this implementation with additional controls like Multi-factor authentication, controls to have ServiceNow only accessible from inside the corporate network, geo-fencing, etc. Explore Identity Service's policy features.

 

Centrify-ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In this post we'll discuss how to use Centrify Identity Service to secure ServiceNow by using the Multi-provider SSO plugin.  In subsequent posts we'll discuss provisioning, protecting shared credentials, using the Centrify ServiceNow store apps.

 

Why secure ServiceNow with Federated SSO?

There are multiple security and operations-related reasons to implement federated identity and SSO for ServiceNow.  A key reason is related to the fact that SN is a SaaS platform, this means that the enterprise is extended and information is accesible outside the enterprise datacenter.  Using federated SSO, allows the use for on-premises identity and access control to secure assets outside the enterprise.  This provides the assurance that only authorized internal users can access those assets.  Another reason is usability with SSO there's no need to duplicate passwords; finally there is the gains in operational efficiency by using a process (like adding a user to an AD group to provision access) or simply disabling the AD user account will disable access to ServiceNow automatically.

 

We'll use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:

 

What you'll need

  • A Centrify Identity Service Instance
  • A ServiceNow Instance or a Developer Instance (Fuji, Geneva or Helsinki)
  • Administrative accounts on both systems

Planning

Here are some planning topics for your ServiceNow/Centrify Identity Service Integration

  • What are the user populations that will have access to ServiceNow?  (e.g. AD, LDAP, Google Directory, etc.)
  • What will be the uniquely-identifying field to be used with the SAML assertion?
  • What will be the name for the CIS Role?  (e.g. SN Users)
  • Is the Multi-provider SSO plugin activated in the instance?
  • Will you use the Centrify-provided x.509 certificate?
  • Will the assertion be encrypted?
  • Will provisioning be used?  Are the SN groups created?
  • Will the MPSSO with Centrify be set as default?  Will passwords be eliminated?
  • Will ServiceNow be accessible from inside or outside the enterprise?  Will time or geo-fencing mechanisms will be implemented
  • Should ServiceNow access be protected with multi-factor authentication?

 

Implementation

Overview
These are the high-level steps to configure Centrify Identity Service as a provider for SSO.

  • In Identity Service: Create a Centrify Role that will be assigned the Centrify App
  • In ServiceNow - Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin.
  • In Identity Service - Onboard  the  "ServiceNow - SAML + Provisioning"  template
  • In ServiceNow - Import the x.509 Certificate for the SAML assertion
  • In ServiceNow - Set-up, configure and enable the Identity Provider
  • In Identity Service - Configure the ServiceNow App

Create a CIS role with the ServiceNow users

  1. Log in to the Centrify Identity Service Admin Portal with a user with at least role management rights.
  2. Go to Roles > Add Role; in the Description tab, give it a name.
    sn-role.png
  3. In the Members tab, select the users from the target directory or directories, then press Save

 

Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin

  1. Log into your ServiceNow instance with an administrative user
  2. In the Application Navigator (left pane), use the search feature and type "Plugins", this filters System Definition and click Plugins.
  3. Now in the right pane, next to System Plugins, in Name type  "Integration - Multiple"
  4. Click on "Integration - Multiple Provides Single Sign-On Installer"  (should be set as inactive, if it's not, skip to the next section)
  5. Under Related Links, Click "Activate/Upgrade" and Click Activate
    sn-activate.png
  6. After activation, the "Multi-Provider SSO" Application will be activated in ServiceNow.  This app contains these sections:  Getting Started, Identity Providers, Federations and Administration.
    sn-mp-sso.png

 

Onboard the  "ServiceNow - SAML + Provisioning"  template

  1. Sign-in to Identity Service with a user that at least has the Application Management right.
  2. In the Ad0min Portal go to  Apps > Add Web App, then search for "ServiceNow SAML + Provisioning"
    sn-cis-apps.png
  3. Click the Add button, confirm your selection and close the Add Web Apps window.
  4. In Identity Service, you'll be placed on the Application Settings tab for the ServiceNow app template, scroll down and click on Download Signing certificate
    sn-down-cert.png
  5. Open a text editor in your platform (Notepad, TextEdit or Vi) and open the downloaded file.  Copy the contents to memory.
    (Note:  the contents should be a PEM-encoded certificate)

 

Import the Certificate to the Multi-Provider SSO via x.509 Admin Module

  1. In ServiceNow > Multi-Provider SSO > Administration > x509 certs
  2. New Cert > Give it a unique name
  3. Format > PEM
  4. PEM Certificate >  paste the contents of memory loaded in the previous section
    sn-x509.png
  5. Press Save.

 

Configure the Identity Provider

  1. In ServiceNow > Multi-Provider SSO > Identity Providers
  2. Select New > SAML2 Update 1 > and when the "Import Identity Provider Metadata" pop-up comes up, select Cancel.
  3. At this point, you can use the table on this page to configure the settings.  This is because it depends on your directory source and optional settings.  Here's the configuration for a now decommissioned demo environment:
    sn-config.png
    Notes: 
    - The look and feel of the multi-provider SSO plugin varies between SN versions Fuji, Geneva and Helsinki.
    - The identity provider has to be set to Active and default if you want Service-Provider initiated to be possible.
    - The "Failed Requirement Redirect" is set to the same value as the "Identity Provider AuthnRequest."
    - The location of the x.509 certificate options varies.  You may have to press save to see the option in some versions of ServiceNow.
    - The default field option for the Identity Provider is email.  Modify this setting based on your planning and identity source field mappings.
  4. Once finished, press Save

 

Enable Multi-Provider SSO

  1. In the Multi-Provider SSO app , select the Properties module
  2. Check the "Yes"  box under "Enable multiple provider SSO"
    sn-enable.png
  3. Press Save.  This completes the ServiceNow set-up for SSO.

 

Configure the ServiceNow App in Identity Service

  1. In Identity Service, go back to ServiceNow > Application Settings
  2. If you haven't, type in the instance ID under "Your ServiceNow instance name", then click on User Access
  3. Check the box next to the Centrify Role that was created in the planning phase.  Click on Account Mapping
  4. Because in this example, we're using Active Directory as the user source, we are going to use "samaccountname"
    Note:  that's is the "username" field in Active Directory, therefore, the user ID in ServiceNow must match for each user.
    This is one way to do it, there is flexibility here.  Other common deployments use the email field.
    sn-mappings.png
  5. Testing your work in the Advanced page
    Use the test button with some users in the target role to make sure that the assertion will be correct.
    sn-testing.png

 

Testing

For testing, all you need to do is create an Active Directory Identity Service user and match the User ID in ServiceNow with the user's AD login name (samaccountname) and set it to active. 
sn-lisa.png
Since this will be an SSO user, there's no need to give it a password.  At this point you are set to perform Identity-provider or Service-provider initiated tests.

  • Identity-provider initiated login
    Log in as your AD user, to the Identity Service User Portal.  You should see the user's assigned apps including ServiceNow
    lisa-portal.png
  • Service-provider initiated login
    Go to your instance URL and select external login.  When you type-in the username, you'll either be re-directed to your Identity Service portal for authentication, or if you have a current session (or Kerberos ticket and IWA enabled), you'll be placed in the app.
    sn-ext-login.png

    Note that this behavior can be modified if the SN multi-provider SSO is set as default.

 

Enhancing the Implementation

There are several areas for enhancement, but these come to mind:

  • Enable Provisioning (next blog post)
  • Enable multi-factor authentication
  • Protect shared accounts
  • Enable workflow and approvals

Centrify-ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:

Restricting access to the USB port can help protect Macs against some USB attacks and help prevent data from being copied to external USB drives. Centrify enables the ability to manage this setting on the Mac through Active Directory Group Policies. 

 

Step 1. Enable: Computer Configuration > Policies > Administrative templates > System > Group Policy > Configure User Group Policy loopback processing mode.

 

Loopback.png

 

Set the policy to Enabled and the mode to Merge.

 

LoopbackMerge.png

 

Step 2. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: External Disks and select the desired access setting.

 

USB port policy.png

 

For more details regarding this setting and other media access settings, see documentation on Media Access Settings.

Find out how to recover administrator access to an existing DirectAudit Installation by granting an AD User administrator privileges at the Database level. 

Read more...

Many customers have Duo MFA already installed in their environment. Here's how you can integrate with Centrify Identity service using RADIUS.

Read more...

Oracle has supported authenticating internal users against Active Directory for several years now, but it does require a fundamental comprehension of Kerberos in order to configure it properly. Of course, this is much easier to accomplish on Windows than Unix and Linux, but luckily, we have the Centrify DirectControl agent to extend the Kerberos environment and help us achieve secure, Active Directory-based authentication without remembering passwords.

Read more...

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 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.

 

The Challenge:  Extend Existing Enterprise Identity and Access Management in Public Clouds

In a previous entry of this series, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based controls.  However, organizations may already have capabilities for Centralized Identity which is at the heart of strong access controls.  This may mean that organizations need to find ways to extend this infrastructure out to public clouds like Amazon.  This may imply:

  • Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
  • Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
  • Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

 

Centrify Privilege Service

cps-snap.PNG

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

  • Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
  • Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
  • Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
  • Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

 

New Linux Agent

The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

 

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

ibconcept.png

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

  • No need to deploy "jumpboxes" to the private clouds (limits exposure)
  • Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
  • Access Request provides the assurance of "documented approvals" to sensitive systems
  • Deploy MFA or access only from the OnPrem network as additional controls.

This topic was covered in this post.

 

Agent Architecture

The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

 

Supported Platforms

agent-platforms.PNG 

UNIX Identity

Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.

Login - user's short name (must use the fully-qualified name the first time)

UID - auto-generated based on the GUID

Primary group - auto-private (same as UID)

GECOS - the display name in Centrify Identity Service

Home/Shell - configurable in the Settings tab.

ibgecosshell.png

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

 

Automation

There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

ib-enroll.PNG

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

 

Identity Broker

Privilege Service can accomodate several identities, including:

ib-sources.PNG

Note that it can accommodate identities from Active Directories without any trust relationships.

These identities can be aggregated using Identity Service Roles:

ib-role.PNG

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

IB-aws resource.png

As you can see the model works like this:

Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

 

Basic Commands

Agent Operation

  • cinfo – obtain information about the agent
  • cenroll – enroll the identity platform and enable features
  • cunenroll – leave the platform and optionally delete resource and any managed accounts
  • cflush – flush the local cache

IB login.PNG

 

AAPM

  • csetaccount – add a managed account for the resource
  • cgetaccount – obtain a managed account’s password
  • cdelaccount - delete a managed account's password

 

To test-drive the new Linux agent and to see how it can secure your public-cloud Linux instances, request a CPS trial today:  https://www.centrify.com/free-trial/privilege-service-form/

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

Reject Scripting With O365 for Fine Grained Control

By Centrify Contributor II on ‎11-22-2016 05:48 PM - last edited ‎11-28-2016 09:39 AM

Centrify allows you to select which objects you'd like to sync, per-domain. What if you want to limit these objects even further?

Read more...

Many federal IT departments are being told to provide 2-factor authentication not only for all logins, but also for all privilege elevations, including the launching of critical applications. Here’s how Centrify can help.

Read more...

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.  

 

This article discusses how you can use Centrify Privilege Service to meet or exceed the requirements to secure shared database accounts in Amazon RDS.

 

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.

 

How are Amazon RDS instances secured?

 

The WS Security Best Practices document specifies the following information:

aws-rds.png

 

Amazon best practices provide information about data security and encryption and additional controls in each database, however, it's up to you to secure other areas like shared database accounts.  This is where Centrify Privilege Service can help you meet or exceed your goals for shared responsibility.

 

Note that it still possible for you to add your instance to an infrastructure like Active Directory; however, you can control the account, and use least privilege with other users.

 

The Database Shared Account issue

The problem is straightforward.  When you provision an Amazon RDS instance, you are provided with an administrative account that is typically shared amongst administrators.  

sql-shared.png

 

In an enterprise environment, depending on the data classification, risk profile, regulation or policy, you have to be able to control the shared account lifecycle:

  • Governance/Business Process:  Request/Approve
  • Password operations:  Check out-Check-in, Rotate/Update, Maintain History.
  • Policy:  length, complexity, expiration, rotation requirements, etc.
  • Operations:  Provide input for security operations (monitoring, remediation) and compliance

Controlling the Governance Lifecycle

Centrify Privilege Service provides the ability to take control over this process and enhance your capabilities, it can implement an Access Request model (native or with ServiceNow) to control requests and approval flow.

 

sn-aws.png

 

Controlling Password Operations Everywhere

The SAPM process is enhanced by Centrify by providing the ability to control both on-premises or public cloud database deployments.  The Connector infrastructure facilitates the deployment.

agent.png

 

 

Identity Flexibility

Leverage your Enterprise Directory (AD or LDAP) and have the flexibility to use federated identity, Google for Work or the built-in Centrify Directory for added flexibility.

 

dir-svc.png

 

RBAC, Policy Engine and Multi-factor Authentication (MFA)

Role-based access controls starts with a great grasp on identity.  With CPS, roles can be constructed leveraging any identity source visible to the platform.

 

Establish controls like accessibility only from inside the network, geo-location, plus using modern Multi-factor (Smart Card, Yubikey, OATH, Authenticator), step-up methods (e-mail, phone factor, SMS) or your own legacy (SecurID, Vasco, Symantec) infrastructure.

 polic.pngap.png

 

Enhance Security Operations

Provide flexible mechanisms to export event information (REST, SQL) to integrate with your existing monitoring infrastructure, or leverage the provided dashboards and activity feeds.

secov.png

 

activity.png

 

Demo:  Setting-up Centrify Privilege Service to Manage a SQL Server-based Amazon RDS Instance

 

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

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

I was recently reading an article about AWS security blunders.  The article takes a very common-sense approach to what can be applied on any Public or Private Cloud.   

 

My personal observation is that many of the challenges on any public cloud relate to the complexities of extending enterprise capability out to a public cloud and Identity and Access Management is as the heart of it. Starting with the Amazon Account and IAM, these could potentially be managed in parallel from the current IT infrastructure; this slowly becomes a management nightmare while increasing security exposure.  

 

The good news is that at Centrify we provide products and capabilities to meet and exceed the Access Control requirements for AWS around IaaS and our platform is uniquely positioned to help you today.

 

plaform.png

 

Leverage your Identity and Access Management to secure your AWS IaaS

In the article, blunders like “not knowing who is in charge of security” typically happen due to infrastructure duplication and fragmentation.  Since everything starts with Identity, at Centrify we allow you to integrate Amazon’s Identity and Access Management (IAM) with your existing directory (Active Directory or LDAP) leveraging SAML or the Native APIs.

aws.png 

To address the issue of “giving away too many privileges” & “not taking root seriously”  securing the Amazon Account and Implementing Amazon IAM are key areas and quick wins that can be accomplished with minimal effort using Centrify’s Identity Platform. 

Here are a few Tech Blogs that cover this topic:

 gears.png

 

The article also mentions challenges with Passwords and Keys (“relying too much on passwords” & “exposed secrets and keys”).  Passwords exist in web apps, Linux and Windows servers and even within scripts (a very insecure habit).  A big benefit of the Centrify Identity Platform is that you can implement Shared Password capabilities for web apps (password walleting), and vaulting of Windows, Linux and other systems.

 

See a technical showcase on CPS here:  http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

AWS and the Identity Challenge

A common strategy is to implement or extend Active Directory to AWS.  This will eliminate the need to rely on keys.  With products with our Centrify Server Suite, an access control and privilege management model can be implemented quickly and it provides a single-pane of glass that can provide security and visibility across Windows and Linux systems in AWS.  Learn more here:

http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

However, this does require either the implementation of AD in the cloud (new forest) or the extension by implementing a site-to-site VPN and using either a 1-way trust or an RODC setup.  Although these are great best practices for the enterprise, they come with cost and complexity when working with public clouds.

 

Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

With our November release of the Identity Platform, we are providing two exciting capabilities:

 

a) Centrify Agent for Windows:  Extends our award-wining Windows PIM capabilities to Identity Service or Privilege Service customers looking to secure Windows systems on console login, RDP or screen unlock.

methods.PNG

The back-end services supported are MFA methods like Mobile Authenticator, Yubikey, OATH Token or even your legacy tokens via RADIUS (e.g. SecurID, Vasco, Symantec), plus step-up methods like Phone Factor, SMS, or E-mail.

To see an article that covers this new capability, click here:  http://community.centrify.com/t5/Community-Tech-Blog/AWS-Shared-Responsibility-Login-MFA-for-Windows...

 

This new capability provides security mechanisms for organizations using Windows systems as AWS jumpboxes or that simply it is required based on the system's risk profile.

 

b) New Platform Agent for Linux -  an alternative way to provide Authentication and AAPM services for Linux systems in private or public clouds like AWS.  It’s a brand-new, “lightweight” Centrify agent.

This client works with the identity platform.  Linux systems are “enrolled” to our service and we act as an Identity Broker for your enterprise AD or LDAP-based identities.

 

The convenience of the new agent lies in its simplicity and low overhead.  Since newer workloads don’t require legacy support for NIS-like services this makes the footprint very small and the infrastructure requirements minimal in comparison of deploying a full AD forest or LDAP tree, and simpler than alternatives like one-way trusts or RODCs.   Simply drop a Centrify connector in your AWS (or other) cloud and that’s it.  Connector to cloud and agent to connector (or cloud) only requires HTTPS connectivity.  Enrollment can be fully automated using codes.

 

Here's a quick demo

 

 

The architecture of Centrify Privilege Service for AWS (or any public loud) is quite simple.  The Centrify connector talks to our service over HTTPS and extends cross-platform services like federation, policy, MFA, shared account password management, privilege session brokering, application-to-application password management and more.

 

The huge benefit is the service's identity flexibility.  Regardless of your identity source (traditional LDAP or AD), modern (Google Directory, Federated Identity, Centrify Cloud Directory) you can extend application access and PIM services.  All you need is the Centrify connector where you want those services available. 

 

 agent.png

 

In conclusion, regardless of your Public cloud, you will find that with Centrify you can meet or exceed your security requirements PLUS you can balance value and functionality, keeping capability fragmentation at bay.

Requiring an administrator password to access system-wide preferences prevent users from changing locked system preferences without an administrator’s password. This setting helps to improve data and device security and complies with the security requirement for CIS (Center for Internet Security) benchmark and other security standards. Centrify enables the ability to manage this setting on the Mac through Active Directory Group Policies.

 

Step 1. Enable: Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Require password to unlock each secure system preference

 

RequirePasswordSysPref.png

 

 The policy will apply after the next group policy interval.

 

If you want to block access to certain System Preferences panes from administrators read the article

Restricting System Preferences access

[Mac] Enable Gatekeeper

By Centrify Advisor I on ‎11-04-2016 09:44 AM

Gatekeeper is Apple's application white-listing control that restricts downloaded applications from launching. It functions as a control to limit applications from unverified sources from running without authorization. Enabling Gatekeeper improves data and device security and complies with the security requirement for CIS (Center for Internet Security) benchmark and other security standards. Centrify enables the ability to manage this setting on the Mac through Active Directory Group Policies. 

 

Step 1. Enable: Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Enable Gatekeeper

 

 

EnableGatekeeper.png

 

Step 2. Select the desired Gatekeeper setting

 

GatekeeperOptions.png

 

The policy will apply after the next group policy interval.

 


 

[Mac] Disable automatic login

By Centrify Advisor I ‎11-03-2016 10:03 AM

The automatic login feature saves a user's system access credentials and bypasses the login screen, instead the system automatically logs in at startup or after entering the credentials to unlock FileVault at the EFI login screen. Disabling automatic login improves data and device security and complies with the security requirement for CIS (Center for Internet Security) benchmark and other security standards. Centrify enables the ability to manage this setting on the Mac through Active Directory Group Policies. 

 

Step 1. Enable: Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Disable automatic login

 

DisableAutomaticLogin.png

 

The policy will apply after the next group policy interval and logout.

passwordhint.png

 

Disabling "Show password hints" improves data and device security and complies with the security requirement for CIS (Center for Internet Security) benchmark and other security standards. Password hints make it easier for unauthorized persons to gain access to systems by providing information to anyone that the user provided to assist remembering the password. This info could include the password itself or other information that might be readily discerned with basic knowledge of the end user or gathered through social engineering. Centrify enables the ability to manage this settings on the Mac through Active Directory Group Policies. 

 

Step 1. Enable: Computer Confiugration > Policies > Centrify Settings > Mac OS X Settings > Accounts > Set login window settings

 

Showpasswordhints.png

 

Step 2. Make sure "Show password hints" is unchecked.

 

The policy will apply after the next group policy interval and logout.

nameandpasswordlogin.png Listofusers.png

 

Displaying the Mac login page with the name and password fields instead of the list of local Mac accounts improves data and device security and complies with the security requirement for CIS (Center for Internet Security) benchmark and other security standards. For hackers, knowing the login name is half the battle. Prompting the user to enter both their username and password makes it twice as hard for unauthorized users to gain access to the system since they must discover two attributes. Centrify enables the ability to manage this setting on the Mac through Active Directory Group Policies. 

 

Step 1. Enable: Computer Confiugration > Policies > Centrify Settings > Mac OS X Settings > Accounts > Set login window settings

 

Name and Password.png

 

Step 2. Select "Name and password" from pulldown list for Display login window as.

 

The policy will apply after the next group policy interval and logout.

Restricting users from making changes in System Preferences can help improve security, lower support tickets, and prevent users from reversing settings required for maintaining compliance. Centrify can block users from access System Preferences even if they have administrative rights on the Mac. The restriction is applied at the user level so users such as IT can be excluded.

 

Step 1. Since this setting is user-based, you will need to enable loopback processing mode: Computer Configuration > Policies > Administrative templates > System > Group Policy > Configure User Group Policy loopback processing mode.

 

Loopback.png

 

Set the policy to Enabled and the mode to Merge.

 

LoopbackMerge.png

 

Step 2. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > System Preferences Settings > Use version specific settings

 

SystemPreferencesVersionSpecific.png

 

Step 3. Enable:  User Configuration > Policies > Centrify Settings > Mac OS X Settings > System Preferences Settings > Mac OS X 10.10 or above Settings > Limit items usage on System Preferences

 

LimitItemUsageSysPref.png

 

Step 4. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > System Preferences Settings > Mac OS X 10.10 or above Settings > Enable System Preferences Panes > Enable built-in System Preferences panes

 

DisableSystemPreferencesPane.png

 

Step 5. Deselect the System Preferences pane you want to block users from accessing.

 

PreferencePaneList.png 

 

The policy will take effect when the user logs off and logs back in. When the policy is in effect, the disabled System Preferences pane(s) will be greyed out and not accessible even by domain users with Mac admin rights.

 

GreyedOutSystemPref.png

 

 

Other articles of interest:

Centrify - Yubico Deployment Guide

By Centrify Contributor II ‎10-31-2016 11:51 AM

Yubico and Centrify together provide context-based, adaptive authentication across all enterprise users and resources. Whether it’s for PIV-based authentication, OATH One-time passwords, or as a physical NFC token for mobile devices — Centrify and Yubico provides IT the flexibility to enforce security without user frustration.

 

 

Attached is  the Centrify - Yubico Deployment Guide for step by step instructions on how to configure Yubico Yubikey's for OTP or PKI authentication

 

Read more...

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

 

Remote Apple Events enables your Mac to accept Apple events from apps running on other computers. An Apple event is a task being performed on a Mac, such as “open this document” or “print.” With remote Apple events turned on, an AppleScript program running on another Mac can interact with your Mac. Disabling remote Apple Events is recommended for hardening your Macs from network attacks and a requirement for the CIS (Center for Internet Security) benchmark.

 

Step 1: Configure the follow group policy setting and set to Disabled: Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable remote Apple events

 

Remote Apple Events.png

 

Once the setting is configured, the policy will take effect at the next group policy interval.

Setting the inactivity time to trigger display sleep to a value larger than the inactivity time to trigger the screen saver is a recommendation by the CIS (Center for Internet Security) benchmark. If the display goes to sleep before your screen saver is triggered, users can mistakenly assume their computer is protected and walk away. 

 

Using Centrify, you can push out group policy settings to configure both the display sleep time and screen saver time to meet the security settings.

 

Configuring Display Sleep Time 

When configuring the display sleep time, be sure to configure both On AC power and On battery power settings.

 

1. Enable and configure: Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > On AC power > Set display sleep time Make sure the time is set longer than your screen saver time.

 

OnACpower.png

 

2. Enable and configure: Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > On battery power > Set display sleep time Make sure the time is set longer than your screen saver time.

 

OnBatterypower.png

 

Once the settings are configured, the policy will take effect at the next group policy interval.

 

Configuring Screen Saver Time and Require Password

1. To meet the security policy to require a password to wake a machine from sleep, enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Require password to wake this computer from sleep or screen saver

 

Requirepasswordfromsleep.png


2. Set the time to require a password after the Mac goes to sleep or screen saver begins. Make sure this time is less than the display sleep time.
Enable and configure: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Desktop Settings > Set computer idle time for Starting screen saver

 

Screensavertime.png

 

3. Since this is a User Configuration, you may need to also apply the following group policy setting:
Computer Configuration > Policies > Administrative Tempaltes > System > Group Policy > Configure User Group Policy loopback processing mode

 

Loopback.png


Set the Mode to Merge.

 

LoopbackMerge.png


Once enabled, this group policy takes effect at next user logon.

Centrify and Yubico Use Cases

By Centrify Contributor II on ‎10-24-2016 03:45 PM

A quick overview and video of the MFA use cases that Yubikey's can be utilized with Centrify's Identity Platform

Read more...

In the course of helping customers migrate to Centrify Adbindproxy, Support has identified some instances where the scale of Samba environments impact the effectiveness of the new adbindproxy component.  This blog will summarize a recent issue and workaround which may help other customers facing a similar situation.

 

Centrify supports another way of implementing stock Samba4 with Centrify that does not use adbindd, but uses NSS instead.  Access control is then based on NSS users and groups with winbind instead of using adbindd (Active Directory).


Background:

In one customer's environment, they were using Samba to share directories to a large number of end users whom were moving and accessing lots of large media files to and from those shares.

Read more...

Yubico for MFA with Centrify

By Centrify Contributor II ‎10-24-2016 09:07 AM

Centrify and Yubico give IT and users the largest variety of options for enforcing strong authentication covering a large number of the most important use cases to stop hackers from compromising credentials by adding in context-based MFA thus stopping the hacker with compromised credential from doing any damage.

Read more...

Installing DB2 Express-C on Linux and configuring the Centrify DB2 plugin

By Centrify Contributor I on ‎10-21-2016 09:09 AM - last edited 2 weeks ago

The Centrify Community has some great resources when it comes to IBM DB2 integration with Active Directory using Centrify. But, have you ever wanted to quickly set up DB2 in a test environment to play with these integrations? By following this article, you can!

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel