How to configure the integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk

Part2 - Integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk

SummaryThe configuration of a profile will be made to start the recordings of the sessions from the elevation of privileges and the integration will be made with splunk so that the auditing sessions can be viewed directly from the Splunk Portal.

As customers move more and more to the cloud, many customers are leveraging AWS Workspaces as a Desktop as a Service Solution (DaaS) to provide end users access to corporate resources at any time from any where. Given Workspaces are available to anyone, from anywhere, a key consideration to moving to AWS Workspaces, is of course Security.

AWS Workspaces can be configured to require Multi-Factor Authentication (MFA) to add a layer of protection to a user name and password (the first “factor”) by requiring users to enter an authentication code (the second factor), which can be provided by a virtual or hardware MFA solution.

There are two ways to do this.

Option 1) Use Centrify Endpoint Services. @Robertson in this article covered how to use the Centrify agent to enforce strong workspace level security with Centrify's Endpoint Services solution to deliver:

The Centrify Agent for Windows™ provides organizations with the ability to secure Windows systems. This article's goal is to introduce the basic information (pre-requisites, communications), deployment scenarios and tools available for each deployment option. The next articles in the series focus on specialized topics or use cases.

As part of the security toolbox, we must deal with shared credentials, more specifically passwords. Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases. In this article we'll explore the options available to retrieve passwords from the CLI using Centrify, how it works, how it's secured and how programs or scripts to retrieve them.

Using shared passwords in CLI scenarios while maintaining assurance

Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials. However, at the same time we need to maintain assurance and enforce principles like:

Try to eliminate passwords

Limit lateral movement

Just in time/just enough access/privileges

Identity Assurance

Monitoring and Auditing

Policy enforcement, etc

The maturity model illustrates this best:

Eliminate Passwords

Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party. The enrollment process looks like this:

Each system is represented by a service account in Centrify Infrastructure Service. Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system into Centrify Infrastructure Services.

In Linux, this is implemented with the cenroll command. If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here (enrolls a system called centos7 to a vault.centrify.vms using the admin@opie.demo credential and enables all features):

If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code (enrolls a system called member-vault using an enrollment code):

Access Control, Entitlements and VisibilityCentrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation. In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform. Centrify includes a built-in group called: Centrify Agent Computers; by default, this group has visibility to systems, domains and databases.

As a best practice, don't overload the Centrify Agent Computers built-in group. Just use it for visibility purposes. Create sets and other roles, and leverage those instead.

Permissions

For accounts, there are several entitlements

This means that you need View+Check out at the account level to check out a password. This is a mechanism for least access and limiting lateral movement.

Policy Enforcement and Monitoring

The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.

A great policy that can be implemented is the use of internal/external, datetime or even Risk. This can be applied at the account level.

Monitoring

Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like: Dashboards, Reports or the ability to send events to a security operations or SIEM tool.

Deployment Utilities

Enrollment codes: allow Centrify clients to enroll the platform automatically. The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.

Sets: Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.

Packages: The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.

Policy overrides: Password lifetime overrides allow for different policies at the parent or account levels. This is useful when you need policies for human beings vs. machines.

Implementations

The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).

Here's how it looks in PowerShell (checking out the sa SQL server account from the database enterprise for 2 minutes)

Note that these examples are interactive checkouts. Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable; as you can also see, the option to specify the checkout lifetime is available.

Developer Portal

The solutions above address the challenge from the point of view of an infrastructure lead specifically focusing on systems. Although in this article we don't cover this in depth, it should be known that everything in the Centrify Identity Platform uses REST APIs.

The goal of this article is to set up the building-blocks to test Centrify Server Suite and Privilege Service in an AWS environment. This article is the foundation for several how to guides in development.

In the Create Bucket dialog box, in the Bucket Name box, type a name for your bucket (nmust be unique)

In the Region box, click the region where you want the bucket to reside.

Optional - Enable logging.

Click Create.

Sanity Check # 1At this point, you should have:

At this point you should have several credentials:

An amazon account (your root account) that has all the rights to your AWS account - this account is your email account.

If you created an IAM user, you should have that credential too.

An AWS key-pair that allows you to SSH into Linux instances using the ec2-user or decrypt Windows Administrator passwords.

You have created a virtual private cloud (VPC)

You have configured a security group that allows you to access the AWS EC2 instances/services and communications between them. You'll be using this security group for all newly-created EC2 instances.

You have an S3 bucket that you can use later to host files.

Active Directory in AWS

Active Directory in AWS (or other clouds) can be deployed in different ways. This all boils down to the connectivity between corporate and AWS. If there's a dedicated VPN, provided that DNS and Security rules are well-designed, you an either extend or duplicate your AD infrastructure in AWS.

This article is not concerned with that. If you are doing a lab, most likely you'll be using the scenario where AD is run in AWS (hosted by you in EC2 instances) or hosted by AWS (SimpleAD or AWS Directory Service).

Note that whether you set up your own, or are using a hosted option, you should have the domain name, IP address(es) for the domain controller(s) and an admin credential. The addresses are needed for the next step, and the credential is needed to manage AD with tools like AD Users and Groups.

3. Modify DHCP Option Sets to align with your new DNS

Without properly functioning DNS, there is no Active Directory functionality. DHCP option sets in AWS make your life very easy and you don't need to add Route53 (AWS's DNS Service) complexity.

Add the options for your domain name and DNS Servers (your DC and the Amazon-provided DNS). In the name tag, provide a descriptive name, domain name servers, type the IP address of the DC(s) and an Amazon-provided DNS, and the AD domain name in the domain name.

Press Yes, Create

In the navigation pane, choose Your VPCs.

Select the VPC(s) for your lab, and select Edit DHCP Options Set from the Actions list.

In the DHCP Options Set list, select the set you created from the list, and then choose Save

Sanity Check # 2At this point, you should have:

A running your domain controller managed by you or hosted Active Directory and you should be able to connect to it as an administrative user.

Your domain controller should be running Microsoft DNS hosting the AD records. Write down the IP address and domain name.

DNS resolution in your subnets, when you launch an EC2 instance and you ping your DC by name, it should be resolvable as well as public FQDNs.

Centrify Standard Edition Lab Setup - Member Server

The member server will be running the Active Directory and Centrify tools. In addition, we can use the server as a Centrify Connector and DirectAudit Infrastructure. This post will focus on AD and Centrify tools:

This script creates our cast of AD users and a group inside the AWSDemo OU. Make sure you change the text in red to fit your environment.

Create and Configure a Centrify Zone

Our zone name will be AWS, and it will have a very simple set up. All users will be UNIX-enabled and there will be three roles: A UNIX Sysadmin role, a Windows Sysadmin role and a regular UNIX user role.

Make sure you correct any major errors outlined by adcheck. The key here will be name resolution and connectivity with your domain controllers; if you laid-out your security rules correctly and have DNS set to resolve AD records, you should be fine.

Modify default AWS EC2 SSH Server Settings

By default, OpenSSH in AWS EC2 is not configured to allow password authentication. Although with Centrify the underlying authentication uses Kerberos to talk to DCs, ultimately the user must be allowed to type their password in an SSH session.

$ sudo adjoin -z AWS -c "ou=servers,ou=centrify" -n demo3 -u admin awsrealm.centrifying.net
admin@AWSREALM.CENTRIFYING.NET's password:
Using domain controller: dc1.awsrealm.centrifying.net writable=true
Join to domain:awsrealm.centrifying.net, zone:AWS successful
Centrify DirectControl started.
Initializing cache
.
You have successfully joined the Active Directory domain: awsrealm.centrifying.net
in the Centrify DirectControl zone: CN=AWS,CN=Zones,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operation. Failure to do so may result in
login problems for AD users.

Verify your UNIX Access and Privilege model

Connect to your Linux system using SSH (e.g. PuTTY or ssh), log in as one of your AD users (e.g. lisa)

Join to a Zone > Select the zone you created earlier (AWS) and Press NextNote, you may be asked to add the Domain Administrators to the Login role. You must do this, otherwise the only user that will be able to sign-in will be maggie (in this example).

Configuration completed, Press Finish.

If asked to restart, press Yes when you are ready.

Verify your Windows Access and Privilege model

Sign-in to your Windows system as a member of the Domain Admins group

Right click start and run mstsc -v member -w:800 -h:600 (this launches an RDP session)

Attempt to log in with maggie (she should be able to log in)

Open the Windows systray and right-click the Centrify icon > Authorization Center and click on the Effective roles tab

Note Maggie's current roles in the AWS zone. Logoff.

Repeat step 2, and now try to log in with Bart. The result should be:This is because Bart has not been assigned a role that allows for Windows access.

Press OK and close. At this point, you have tested the access model on Windows.

Sanity Check # 4

At this point you should have

Centrify tools installed in your member server (e.g. DirectManage)

You have a domain-joined Amazon linux instance

In the Centrify zone, you have a linux instance and your Windows member server

You have tested your access and privilege model in both Linux and Windows platforms.

MILESTONE: Now you have a system that you can use for sanity checks and to generate some of the tools required for the Standard Edition AWS labs. This is the state of your lab:

Once your tenant is set up, open its URL from the browser in your EC2 Windows instance (member server)Note that you may have to relax the IE ESC settings on Windows or download an alternative browser like Chrome or Firefox. E.g. https://your-tenant.my.centrify.com/manage

Navigate to Settings > Network and click "Add Centrify Connector"; this will download the Connector bits.

Double-click the Connector zip file, and run the included setup file, this will start the wizard- Welcome Page - press next- EULA Page - check the box and press next- Custom Setup - only install the Centrify Connector- Ready to install - press next. When complete, press Finish. This will launch the configuration Wizard.

In the Configuration Wizard:- Welcome Page - press next- Centrify Connector Configuration - provide your admin account name and password- Connector Configuration - Optional: check the box in the domain (you may not be able to if you're using a managed AD.- Connection test - should be successful if your instance is allowed to go out to the Internet, press Next- Configuring connector - Next and then Finish.

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.

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.

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.

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.

Log on to Identity Service with an administrative account

Go to Policies > New Policy

In Policy Settings, scroll down and select the "Specified roles" radio button

Press Add and browse for the role created in the previous step.

On the left pane expand User Security Policies > Login Authentication and select Yes to enable.

Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.

Press Save

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.

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

Go to the ServiceNow app store and search for Centrify.

Click on Centrify App Access

Click "Get" to make the Centrify Identity Service app available for your ServiceNow instances.

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

In the application pane (left) navigate to Centrify App Access > Properties. Populate these three fieldsCentrify 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 stepsCentrify Cloud Service Account Password: the strong password you created for the user

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

Go to Centrify App Access > Customize API Sync

Set the Active checkbox

Select an appropriate interval based on your SLAs (e.g. 1 hour)

Press Save and then Execute Now.This process will synchronize the CIS Apps and Roles available with ServiceNow. Alternatively, you can go to the Applications and Roles sections and press the Sync Now button.

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

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. First, you must verify that the roles and applications have been properly populated.

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.

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

Since this app focuses on ServiceNow approvals, the enhancements are around workflow design. For example, you can have multi-approval groups, you can set timers for SLAs, etc.

Centrify & ServiceNow Resources

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

We will be focusing on UNIX/Linux system access leveraging strong authentication to Windows (or Mac) systems via smart card or YubiKey. Centrify Server suite allows definitions of roles that only allow non-password authentication to be enforced. YubiKeys are full-fledged personal identity verification (PIV) cards that work very well with AD and Certificate Services.

The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility.

The "jumpbox" or proxy approach combined with additional controls like workflow can help as long as connections are centralized, however many organizations are getting audit comments due to circunvention of these mechanisms.

Although there are different multifactor providers in the market and most of them provide Pluggable Authentication Modules for their solutions, the implementation requires a high-degree of expertise and translating the capability to hundreds or thousands of servers with heterogeneous OSs can be quite complex.

Opportunities

Although Centrify can accommodate the "jump box and shared account" model using Centrify Privilege Service, organizations should complement their security strategy with the least access model:

Users shall only access the systems they need to based on business need-to-know with strong authentication

Users shall be limited to the minimum privileges required for their functions: this is accomplished by providing users roles with the rights that they need.

Rights shall be assigned and limited to the business function with a privilege elevation mechanism (e.g. sudo) that has the flexibility to provide strong authentication.

In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.

Active Directory and Centrify provide a stack that can secure systems and eliminates complexity across the different UNIX/Linux platforms

Lab Goals

Limit privileged users to a subset of UNIX/Linux systems based on their needs (AD and Centrify Zones enable this)

Require strong authentication for local or remote (SSH) access (this is enabled by Centrify DirectAuthorize)

A domain joined member server with Centrify Server Suite 2016 (DirectControl)

One or two UNIX/Linux systems with Centrify DirectControl and Centrify-Enhanced OpenSSHBecause we will be relying on SSO, Centrify OpenSSH comes compiled with Centrify methods that simplify the process in simple and complex AD environments.

For SSO to work, the system has to be resolvable by name (shortname or FQDN) by the Kerberized clients.

We will use the Yubikey/Smart Card with the Certificate provisioned to the user in the base lab. With Centrify Access Manager, we will create a role that allows her to access a system (locally and via SSH) and we will prove:

That the user can only log into her Windows station with her Smart Card/YubiKey

That the user cannotsign-in to UNIX/Linux system locally or remotely (via SSH) with a password

That the user is onlyallowed to log in remotely via SSH to UNIX/Linux systems via SSO (Kerberos or GSSAPI)

That these rights can be assigned to groups of systems, or groups of users in a temporary or permanent basis

Minimal to zero configuration at the system level. Once the system is joined to AD, the security measures should just work.

In this instance we are setting up a Web Admin role that contains the pre-defined "login-all" PAM right. We are not breaking down the rights to prove that we can stop the user from logging in via console or via SSH with a password.

The privileged user assigned the role must have authenticated with her YubiKey or SmartCard to obtain a Kerberos TGT from Active Directory, subsequently, Centrify DirectAuthorize will be in charge of denying access to the user if they don't use SSO for access (via Kerberos or GSSAPI). All we're going to need is a zone and a role.

Create two UNIX commands. Since this will be our "Web Admin" we'll allow the role to manipulate the httpd daemon and edit the config file for the Apache server. The commands are:Glob expression vi /etc/httpd/conf/httpd.conf from the standard user path /usr/bin no reauthentication required.Glob expression service httpd* from the standard system path /usr/sbin no reauthentication required.

Add the rights to the role. Right click the "UNIX WebAdmin - StrongAuth" role and select "Add Right"

The role is ready to be assigned. Now press OK and right-click the Authorization > Role Assignments > Select Assign Role

Press the Add AD account > type the name of your test user, select it and press OK.Note: This is a permanent direct assignment to a user principal at the zone level. This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

Install DirectControl and join the system to the Centrify Zone

Use your preferred software distribution method to copy the Centrify softwareIn my case I already have a local repo for RHEL and derivatives. (Read how to set up here)

Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH

If your system was not resolvable by Windows DNS, you can use the addns command to register automatically with dynamic updates (if your DNS zone allows):

$ sudo /usr/sbin/addns --update --machine
Updating both HOST and PTR record for: centos67.centrify.vms
Deleting old reverse lookup records for centos67.centrify.vms on 192.168.81.10.
No old reverse records deleted because no host records found for centos67.centrify.vms on 192.168.81.10.

Verify that your users are correctly UNIX-enabled and with the expected rights (use adquery user and dzinfo)

Try to access the system with any other AD user than test user - expected result: Access DeniedThis is because users need to be explicitly be granted access a UNIX identity and a Centrify role in the zone for the computer.

Try to access the system with your test user (Maggie) with her password (Console or SSH) - expected result: Access DeniedThis is because the test user was defined with "Smart card required for interactive logon"

login as: maggie.simpson
-----------------------------------------------------------------
CENTRIFY DEMO -
-----------------------------------------------------------------
WARNING: This is a PRIVATE system exclusively for Centrify demos
Your actions will be monitored and recorded.
-----------------------------------------------------------------
Using keyboard-interactive authentication.
Demo Password:
Using keyboard-interactive authentication.
Account cannot be accessed at this time.
Please contact your system administrator.

This is the first lab in the series around Strong Authentication (series link). We will be focusing on Windows systems and providing strong authentication for privileged users using Yubikeys. Yubikeys are full-fledged personal identity verification (PIV) cards that work very well with Active Directory Certificate Services and Centrify software for UNIX, Linux and Windows.

The challenges

The Windows security model lends itself for organizations to grant additional privileges to users by way of the local Administrators group. In Active Directory environments organizations struggle with excessive memberships on privileged groups like Domain Admins.

In Active Directory, a common mitigation strategy is to provision each privileged user an "administrative" account (e.g. joe/joe-a). This strategy can be supplemented by having the "-a" account password stored securely.

Unfortunately, advanced attacks like password mining, pass-the-hash and others have become more ubiquitous, this makes a member of a privileged group ("-a" or not) more susceptible to exposure.

The "dual account" model is often paired with PSM (jumpbox) to provide session brokering and recording. Unfortunately, this model can be circumvented by bypassing the jumpbox, and since the "-a" account is very powerful, that means that the privileged user can go anywhere.

The opportunity

Although Centrify can accommodate the "dual account" model using Centrify Privilege Service, ideally organizations would implement the least privilege model:

Users shall only access the systems they need to based on business need-to-know with strong authentication

Users shall be limited to the minimum privileges required for their functions: this is accomplished by providing users roles with the rights that they need.

Rights shall be assigned in the context of applications, desktops and network rights. Strong authentication shall be required when using privilege elevation.

In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.

Lab Goals

Limit privileged users to a subset of Windows systems based on their needs (AD and Centrify Zones enable this)

We'll use the smart card user certificate provisioned to your test user's Yubikey. In Active Directory we'll require smart card authentication for the user (this also be implemented in a subset of systems using Group Policy).

We will grant the test user a Centrify DirectAuthorize role that allows her to:

Run Disk Management as the local administrator and will require strong authentication to be launched

Use an administrative desktop (as local administrator) and requires strong authentication to be launched

In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

Name: Demo RoleSystem Rights: "Remote Login is allowed" < this will allow the user only to access via RDP

Press OK and right-click the newly created role and select "Add Right"

The role is ready to be assigned. Now press OK and right-click the Authorization > Role Assignments > Select Assign Role

Press the Add AD account > type the name of your test user, select it and press OK.Note: This is a permanent direct assignment to a user principal at the zone level. This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

Install DirectAuthorize for Windows and join the system to the Centrify Zone

In your domain-joined test systems, browse to the path for the Centrify Standard Edition software.

Go to Agent > and Run "Centrify Windows Agent.exe"

Follow the Wizard, you will select the "Access" components. If you have DirectAudit, also select Audit.

When the installation ends, you need to configure the client to join your desired zone.

The system will ask to reboot when complete.

Important Notes:

When a Windows system is added to the Centrify Zone, the security model changes.

In order to access a Centrified Windows system, users must be explicitly granted logon rights. This means that even Domain Admins won't be able to access those sytsems.

The type of access is based on the Windows setup (Remote/Log on Locally) and the Centrify Role definition (Console/Remote)

When adding your first system to a zone, you will have an opportunity to explicitly add Domain Admins, otherwise you may completely lock the system

Try to run application "disk management" normally - expected result: Error: "You don't have access rights to logical Disk Manager on [Server]" This is because when the user launches the app, they are doing so without any privileges.

In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management plus recording and strong access controls. Here are the detailed goals:

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service: Federation, Workflow, AD-Bridge, Multifactor Authentication and more. CPS has a connector-based architecture like this:

This means that there are several ways to use Privilege Service in IaaS scenarios. However, I will focus on this type of design:

The benefit oft his design is that it allows flexibility. Here are some highlights:

The single source of identity continues to be the on-premises Active Directory. AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.

Allows for connected or disconnected AWS connectivity. Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.

What are the systems that need to be accessed?The answer to this question has implications for AWS security groups. For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).

What are the user populations that need access to AWS systems?This determines the identity stores. User populations can be full-time employees, contractors, vendors, etc. Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy. Some examples:- Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.- Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.

What are the groups that should manage the system? what are their entitlements?The answer to this question has directory service and functional implications.

What are the security controls to be put in place? (strong auth, geo-fencing, time-based controls, workflow/approvals)The data classification of the systems determines the controls that should be in place. The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.

Password Management lifecycle questions:Should approvals be required for password checkouts? Should multiple password check-outs allowed? should passwords be rotated in a specific interval? Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed? Should active directory account passwords be managed?

Password StorageShould the Centrify Secure Storage be used or is a physical or virtual HSM (Safenet SecureKey) available?

Will AAPM or self-registration be needed?The answer to this question has implications for AWS images or DevOps. Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.

Monitoring and ReportingWhat events should be sent to log aggregation (SIEM) platforms? What reports should be generated and who are the consumers of these reports?

AttestationWhat is the process of validating that certain privileged users should have (or continue to have) access to certain resources?

Session RecordingWhat is the data retention policy for audited sessions? How many concurrent sessions (SSH/RDP) can be expected?These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide.

Implementation

In this example, I will use an AWS environment with Active Directory to:

A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.

The Installation bits for Centrify DirectAudit

A domain-joined system for:a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab). Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389 (or your custom ports if changed).b) DirectAudit components: this will be the not recommended all-in one scenario (Database/Collector/Agent).

Test Linux and Windows EC2 instances.

Optional: An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP

Limited visibility of resources using the Privilege Portal login right.

End of Series - Conclusion

This ends the series on AWS and hopefully you've seen how the Centrify product lines: Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.

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

To continue to leverage Active Directory as the source of identity and privileges

To eliminate the reliance on SSH keys or fragmented identities

To provide a tried and true privileged elevation mechanism (sudo) without the inconveniences of sudoers files

To be able to deploy additional controls such as time-fencing and multi-factor authentication for linux

To be able to quickly attest who can access systems, their roles, privileges and how the privileges were granted

To enforce the principle of separation of duties

Active Directory and AWS

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

The Connected Model

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

Account-resource model: With accounts living on-premises and a resource domain existing in AWS (for example, with a one-way trust).

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

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

The Disconnected Model

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

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

Faster-to-production because there's no need to wait for dedicated connectivity to be set up.

No need to architect a security model around AD.

The obvious drawback of this model is dual administration.

Commonalities and Customer Inquiries

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

They want to extend the Centrify Server Suite benefits to these environments

They have questions about their AD architecture (the two models below hint at how things would be designed and managed)

They have miscellaneous questions about pre-validation and the use of DirectAudit (session capture and replay)

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

Extending Centrify Server Suite to Amazon Web Services

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

If status-quo will be maintained and the same user population retains the same rights to AWS

You may only need to create a child zone or a computer role in your existing zone structure.

Active Directory design principles are maintained: - AD Sites and Services (subnets/sites) need to be created and maintained. - Global Catalog location needs to be accounted for, especially if Universal or nested groups are used.

If there will be a completely new governance model within the same forest, then a parallel zone may need to be created and delegated to the proper group.

If a brand-new forest with a 1-way trust is created, then a zone in the resource domain will have to be created and principals from the trusted domain have to be added to provisioning and role-granting groups.

EC2 Instance Lifecycle

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

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

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

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

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

DevOps Frameworks

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

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

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

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

Advanced Controls and Reporting

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

In the field, we often get inquiries on deployment, governance or orchestration frameworks. Common questions range from: how do I deploy the Centrify client? or How do I establish an approval flow for the Access Control model that you facilitate?

Sometimes we also hear these questions: We use Ansible | Bladelogic | Chef | Puppet in on premise or with our IaaS (cloud) deployment, how would I go about deploying your product using those tools?

These are important questions, especially in the age of private/public clouds and elastic environments. Some of you are adopting frameworks like OpenStack, Amazon AWS or Microsoft Azure that underneath use these toolsets.

At Centrify we have invested heavily through the years to make sure that the products "just work". From a deployment perspective, we our messaging is consistent:

We always provide the native platform package

Our tools are all Kerberized (ready for automation)

We also provide other tools like install.sh and Deployment manager that abstract the underlying OS package manager

The Centrify agent automatically maintains its configuration and the Kerberos configuration based on Active Directory, and it uses AD specs for Sites and Services, DC location, offline cache.

The configuration parameters can be managed by any tool, plus native Active Directory Group Policy.

In other words, Centrify software is easier to use in these scenarios than what the typical IT Infrastructure lead may think.

A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support). This system has to be set up as a YUM repository, as described in the the original orchestration article.

A second RHEL-derivative system to install Puppet (see below), this system must have DNS settings configured correctly.

Note: Although it's possible for you to follow this and put together a working prototype, I strongly-encourage that you really explore the concepts of DevOps/infrastructure as code. The whole philosophy promotes constant improvement, this means that if you expect this to be a "set it and forget it" solution, I advise that you realign your expectations.

Finally, By no means what's outlined here is ready for production. Check out the reading list below.

Example Diagram

Implementation Steps

Planning

The goal of this lab is to be able to deploy the Centrify bits in a RedHat, CentOS, Scientific or Oracle system in a consistent way. Also, if you know what you're doing, you can extend this to other OSs, and platforms as well.

The 'core' process without checking for major dependencies or issues is to:

Install Centrify DirectControl

Authenticate against Active Directory with an account with minimal rights

Usable krb5.conf: You can copy this file from any Centrified system; however, depending on where you're onboarding the system, you want to edit the file only with the DCs that are reachable to the new system.

Make the krb5.conf and service account keytab available to your infrastructure

In the original article, we piggy-backed on the Apache webserver as the transport for our repository. Now we're going to create another folder for utilities (utils for short) and copy the keytab and krb5.conf file.

If you prepared this for the Chef article, you can skip to Puppet installation.

Make sure your system's DNS settings are up to date (yes, no "localsystem.localdomain")Can you ping your own system by name and FQDN?What is the output of the hostname command?Run this:

facter | grep hostname
facter | grep fqdn

if the output isincorrect, you must edit the /etc/hosts and /etc/resolv.conf and speak to your DNS admin to set things straight

Logout and log back in to verify the ruby path$ sudo puppet module install maestrodev-wgetYou should be ready to get going.

Create and test your stand-alone Puppet Script

To recap, the sequence to automate Installation and joins is as follows:

Retrieve a usable krb5.conf file

Retrieve the keytab of a valid service account with minimum rights to join systems to the target AD OU, to the target zone (if using in zone mode) and if adding to a Computer role, with rights to add to the target AD groups.

Install the Centrify Package and use the kinit tool to obtain a TGT

Run adjoin with the proper options.

Perform cleanup

Here is the Non-idenpotent Puppet Script:

# This stand-alone recipe will install the Centrify Agent on RHEL derivatives,
# joins Active Directory and places the system in a Computer Role
# Notes: This recipe is not idempotent (achieving this is up to you!)
include wget
# Variables for my environment (see blog post)
# domain is the most basic parameter to join Active Directory
$adname = "centrify.vms"
# Notice that I could not use "domain" like in the Chef example. # That word seems to be reserved in Puppet
# In Zone Mode (licensed with UNIX identity and Access Control) the zone
# parameter corresponds is where the system will be placed. Not needed
# if working in workstation or express mode.
$zone = "Global"
# OU is where your computer object will be placed in Active Directory
# your ad-joiner account should be able to join systems to this container
$ou = " ou=servers,ou=unix"
# A Computer role is one of the ways to group systems and define access
# control. A system may be a member of multiple computer roles.
# E.g. a LAMP system may be accessible by Web Admins, Developers and
# DBAs with different access rights and privileges.
$crole = "App Servers"
# nodes are the managed system in Puppet; in a true deployment you can
# apply to individual systems or collections of systems. Since this is not
# idempotent, you must specify the fqdn.
node "your-system-fqdn" {
# Centrify's utilities are Kerberized, this means that they will use the current
# user's Kerberos TGT to attempt the transaction against AD. However, in a
# virgin system, there are no working krb5.conf files, therefore kinit won't know
# how to find a KDC to authenticate against. This is why we need a krb5.conf
# file from a working system (or that points to a reachable Domain Controller),
# in the previous blog entry, we piggy-backed on an Apache Web server to
# serve those files (engcen6).
wget::fetch {"download a working krb5.conf":
source => 'http://engcen6.centrify.vms/centrify/utils/krb5.conf',
destination => '/temp/krb5.conf',
timeout => 0,
verbose => true,
nocheckcertificate => true,
before => Exec["kinit"]
}
# The keytab corresponds to a service account that has the minimal rights, in
# this case, the rights to write a computer object in the designated container
# (ou), centrify zone and the AD group that contains the "App Servers"computer
# role needless to say, you need to treat this file with care and if possible,
# remove when complete.
wget::fetch {"download the ad-joiner keytab file":
source => 'http://engcen6.centrify.vms/centrify/utils/ad-joiner.keytab',
destination => '/temp/ad-joiner.keytab',
timeout => 0,
verbose => true,
nocheckcertificate => true,
before => Exec["kinit"]
}
# We leverage Puppet to ensure the files are present. This will be used later
# to guarantee proper sequencing.
file {"ad-joiner.keytab":
ensure => present,
path => '/temp/ad-joiner.keytab'
}file {"krb5.conf":
ensure => present,
path => '/temp/krb5.conf'
}
# In this command, we authenticate against AD with the keytab of our service
# account. Note that we are using the usable krb5.conf file so kinit can reach
# a KDC (domain controller). The end-result is that root (or sudo) user will
# have a TGT and you don't need to put keys, hashes or passwords in your
# script. The before/subscribe and require Puppet directives guarantee proper
# sequencing.
exec {"kinit":
command => "/bin/env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner",
before => Exec["adjoin"],
subscribe => [
File["/temp/ad-joiner.keytab"],
File["/temp/krb5.conf"],
],
require => Package["CentrifyDC"],
}
# In a pre-requiste blog entry, I outlined how to create a YUM repository for
# RHEL and derivatives. This means that you need a yum or apt repo with
# the Centrify packages. Puppet will simply make sure the package is present
# notice the differences, I declared this after the previous directives, when
# the package is a pre-requisite.
package {"CentrifyDC":
ensure => 'installed',
}
# Finally we run adjoin. At this point we are using the variables from my
# environment. Although in doing so, we broke the 'idempotent principles, I'm
# certain that Puppet experts can find ways to improve on this.
exec { "adjoin":
command => "/usr/sbin/adjoin -z $zone -c $ou -R \"$crole\" -V $adname",
require => Package["CentrifyDC"]
}
# In the cleanup phase, we clear the TGT and delete the utility files
# Although the keytab provides very specific limited AD rights, always make
# a habit of cleaning-up.
exec {'kdestroy':
command => '/bin/env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kdestroy',
require => Exec['adjoin'],
}
exec {"/bin/rm -f /temp/*":
require => Exec['kdestroy'],
}
} # End of Script

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

In this first part, we'll address how to secure the AWS Root Account. Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.

Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.

As customary, we'll use the Plan-Do-Check-Adjust methodology.

Planning

Role-Based Access Control

- Should the application always be accessible by a limited group of users?

- Should application access be governed by AD group membership or Centrify Role?

Should the application be accessible to nobody and only requested on demand?

Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.

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

Access Control Building-Blocks

Create the AD Groups

In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.

Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.

- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)

Create the AWS Root Role

Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

In Cloud Manager, navigate to Role and Click Add Role

Description: AWS Root

Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Create the AWS Root Approvers Role

Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

In Cloud Manager, navigate to Role and Click Add Role

Description: AWS Root Approvers

Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Configuration in Identity Service

Add and Configure the AWS User/Password App

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 User/Password" 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.

Description - in this step you will change the name to something descriptive to your environment.

User Access - check the box next to the role you created for this purpose (in our example AWS Root)

Policy - we'll revisit this in the "Adjustments" section.

Account Mapping - This is where you'll securely store the AWS credentials. Selecta) Select "Everybody shares a single username"b) Populate the username with the AWS root account email address and the password with the current password.

Press Save, you're ready for initial testing.

Verification

At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role

You should see the AWS As Root App. Click on it.

This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.

You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app.

Adjustments

Limiting Access only from the Corporate Network

This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets or IP addresses that are translated via NAT for outbound internet connectivity to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.

Adding Multifactor Authentication or Other Controls

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.

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.

This article describes the steps to install, configure and test the local UNIX user and group management feature included with Centrify Suite 2016. You will find this article useful if you're looking to accomplish the following goals:

Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)

Control local UNIX primary or secondary groups (provision, control membership, or removal from /etc/group)

Use a single management framework (DirectManage GUI, PowerShell, UNIX adedit)

This article describes the steps to install, configure and test the Centrify Reports feature included with Centrify Suite 2016. You will find this article useful if you're looking to accomplish the following goals:

Increase the speed of Access and Privilege related reports

Provide information to your Security or Audit counterparts for Access or Attestation purposes

Automate Attestation report generation and delivery

Provide a data source for custom report generation.

Disclaimer: This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.

The typical scenario is that depending on your risk or regulatory profile you need to provide user entitlements (who has access to a server or collection of servers in a Centrify zone and what can they do with Privilege using DirectAuthorize). For example:

Who has access to UNIX/Linux or Windows Server? What privileges do they have (dzdo/dzwin)? What AD object grants access?

Who can access this collection of systems? What privileges do they have (dzdo/dzwin)?

These entitlement reports, are used typically in attestation exercises. Attestation may be done manually (you get together an ratify that these are the proper people that should have access) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool).

With the end of extended support for Windows Server 2003, many organizations are exercising due diligence and upgrading Windows Active Directory systems to newer OS versions. Although this requires thorough planning by your organization, many of our prospects and customers often ask about their current AD changes and wonder about how that impacts systems running Centrify Server Suite for UNIX/Linux or Identity Service Mac Edition clients. This article is a quick primer on what changes when the Domain Functional Level changes. We are focusing on the jump from 2003 to 2012 as an example.

In the original article about orchestration basics, we set up a basic implementation of YellowDog Updater Modified (YUM) for RHEL and derivatives (CentOS, Scientific, Oracle Linux, etc) in different architectures

(Intel, Power, zLinux).

In this second article of the series we discuss how we can use a simple (non-idempotent) Chef recipe to deploy, and join a node to Active Directory with Centrify DirectControl.

Repositories for Yellow Dog Updater Modified (YUM) or the Advanced Package Tool (APT) are now part of every IT Infrastructure department's arsenal. They provide foundational services for deployment and automation of software. Centrify has traditionally shipped all the native packages for each supported platform, this means any customer (Express or Commercial) should be able to download software from the Download Center and integrate it to their existing orchestration and package management solution.

In many cases prospects and customers ask us how can we help integrate with their existing [Bladelogic | Satellite | Chef | Puppet | System Center | Casper | other]; the answer is very simple: "We give you the native package"; however, this may not be enough. In the "Orchestration basics" series we will write a set of articles that lay the foundation for these services.

We will start by teaching you how to set up your very own YUM repository to support RHEL and derivatives. This should be good for the following platforms: CentOS, Citrix XenServer,Oracle Linux, RHEL, Fedora and Scientific Linux on i386, x86_64, PPC, S/390x and Itanium. We'll add other strategies like APT, HTTP and NFS as well.

IT Professionals are often required to provide evidence of alignment with security regulations. At Centrify, since we provide Identity and Access Management solutions, this means that providing capabilities that satisfy regulations is at the heart of many of our products; it drives design, engineering and marketing efforts.

All this would be nothing if we weren't in the position to coach our customers and prospects on how we can meet or exceed their needs. This entry is based on a template email that we developed in the New York Metro region to assist when our customers ask us how to prove Server Suite's alignment with the Sarbanes-Oxley Act.

Amazon AWS is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.

It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.

This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.

Organizations can always count with the reliability of IBM hardware, operating systems and utilities for mission critical applications. That’s why Centrify has invested in certifying the product lines with IBM infrastructure.

This post discusses the DB2 SSO Module; this plugin (like the Apache HTTP and Java plugins) leverages the Active Directory integration capabilities and robustness of the Centrify agent to provide additional value and functionality to DB2 implementations.

The DB2 plugin provides the following benefits:

No need to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have user accounts in the local /etc/passwd file. The DB2 enables AD users to access DB2 so the benefits of Unified Identity, Centralized Administration, Streamlined Authentication and Policy Enforcement are organically attained.

In practical terms: no more getting dinged by auditors when the account of a long-gone user is found active in the /etc/passwd of a DB2 system.

Long login names: Support for logins that are longer than 8 characters

Active Directory Group Support: AD group memberships can be leveraged to grant entitlements inside DB2.

This is one of the best Database to AD integration models out there.

This article covers setup, configuration and testing of the DB2 moduleon Linux 64 bit in a lab environment. We will focus on the User/Password and Group Plugin first since they enable a UNIX/Linux admin to set it up without any AD requirements. In a follow-up post we'll cover the SSO GSSAPI plugin.

Like any other DBMS, a true production implementation requires planning and understanding of the current environment.