Security Corner - How to demonstrate alignment with Sarbanes-Oxley with Centrify for UNIX/Linux and Active Directory

Background on the Sarbanes-Oxley Act

You need to understand what a security analyst or auditor is asking of you, let's start with the basics:

• What is SOx?The Sarbanes-Oxley act of 2002 or “Public Company Accounting Reform and Investor Protection Act”
• Who needs to comply with it?All publicly-traded companies.
• How can you prove due-diligence with SOx?They need to provide the assurance that systems that impact financial statements have implemented the proper security controls.
• What is the point of SOX?The main intention of SOX is to establish verifiable security controls to protect against disclosure of confidential data, and tracking of personnel to detect data tampering that may be fraud related. The central purpose of the act is to reduce fraud, build public confidence and trust, and protect data that may affect companies and shareholders.
• What is the cost of non-conformance?Very steep penalties and/or prison time for executives.
• What systems are bound by SOx rules?Any system that supports applications that impact the business bottomline.  Your organization should have written guidelines to categorize the data that travels or is stored in those systems.
• What are the guidelines to determine if a system may be bound by SOx?This should be defined by a risk assessment exercise, however, a simple model is to use the CIA rating (Confidentiality-Integrity-Availability).  This triad can be used to do a simple test.  As yourself these 3 questions.
  If the data on these systems....
  a) is made public (confidentiality breach)
  b) is tampered with or not reliable
  c) is not available (system down)
  ... is there an impact to the organization's bottomline (financial, reputation, major productivity loss)?
  The answer to this question should give you a pretty good idea.  As a matter of fact, any system that falls into that category (infrastructure like Routers, Switches, DNS, PKI, etc.) has impact to operations.

What are the common misconceptions of the SOx Act?
That you should only produce reports (e.g. lists of users in the context of IAM).  The whole point of the concept of "verifiable security controls" is to prove the effectiveness of the controls;  the reason why organizations have to produce reports is due to legacy issues.
For example, if you are using /etc/passwd for 20 users, you have to potentially attest for 20 different user/attestation reports.

Now let's discuss how Centrify can help.

Centrify-Sarbanes Oxley Reference Guide
This table, should be a good starting point; however we ask that you reconcile this information with your organization's security policies, guidelines and procedures.

Section	What it means	Centrify Products/Features	Centrify Implements
Section 302.2 – Establish safeguards to prevent data tampering.	Controls are implemented to prevent, correct or detect data breaches	DirectControl, DirectAuthorize, DirectAudit / Privileged user management, logging, auditing	Centrify implements a RBAC mechanism that allows to control: a)     Who can access a system b)     How they can access the system (console, SSH, RDP, etc) c)      What can they do in that system (DirectAutorize) This approach protects systems end-to-end and it’s not password-centric.  It’s called Least Access/Least Privilege Principle Resource: What is DirectAuthorize?
Section 302.4.B – Establish verifiable controls to track data access.	Controls are implemented to attest who has access	DirectControl, DirectAuthorize, DirectAudit / Reporting, Auditing	All access and privilege elevation events are logged to UNIX/Linux syslog and the Windows Event log (if Kerberos events are being audited)
Section 302.4.C – Ensure that safeguards are operational	Self-described	DirectControl, DirectAuthorize, DirectAudit / site awareness, watchdog, caching, offline audit	Centrify implements the following high-availability mechanisms: a)     AD Site/Services awareness – this means that it will failover upon domain controller failure b)     Offline Cache:  in case of no DC availability it can provide login with cached credentials c)      Telemetry calculations:  the client proactively will probe to see if it’s talking to the most optimal DC. d)     Watchdog processes:  Implements a watchdog daemon that will spawn new processes if needed. Resource: Youtube Playlist - HA Mechanisms.
Section 302.4.D – Periodically report the effectiveness of safeguards.	Attest that controls are working as expected	DirectControl, DirectAuthorize, DirectAudit /enhanced logging, alerts.	Centrify Implements a)     Console-based reporting b)     Script-based reporting (UNIX, Windows PowerShell) c)      SQL-Server Based Reporting (CSS 2016, now in Beta)
Section 302.5.A&B – Detect Security Breaches	Self-described	DirectControl, DirectAudit / logging, capture and replay	Centrify Provides: a)     Event log and syslog logging b)     Session Transcripton (EE) c)      Session Capture and Replay (DVR-like) (EE) d)     Event consolidation (EE) e)     Event reporting (EE)
Section 404.A.1.1 – Disclose security safeguards to independent auditors. Section 404.A.2 – Disclose security breaches to independent auditors. Section 404.B – Disclose failures of security safeguards to independent auditors.	Demonstrate the existence of a security framework, for example: •       Procedures to eliminate terminated (or changed) employees •       Password Policy •       Separation of Duties •       Attestation	DirectControl, DirectAuthorize, DirectAudit / zone provisioning agent, policy enforcement, zone delegation,  role-based access, reporting, logging, auditing	Centrify allows for a)     Collapsing the termination of users directly in active directory b)     The password policy from Active Directory is reused in UNIX, Linux, Mac and Apps c)      Provides mechanisms to implement delegation and separation of duties.

The bottomline is this:
Organizations that have multiple identity silos (like /etc/passwd or /etc/group) have a very hard time (or have a lot of complexity or an army of people) just to manage simple tasks like the user/group life-cycle (add/moves/changes).  With Centrify and Active Directory these tasks become centralized, making the security controls more effective.  Organizations effectively piggy-back on existing processes, so when you get the question "how can you prove that you're performing on-time user add/moves or changes?" you can simply say:  "This is all tied to our Active Directory processes and procedures"

Here's a good sequence (for user adds/moves and policy)

1. Log on to a UNIX, Linux or Mac with an AD user.
2. Show the system log (messages log, syslog or event log)
3. Logoff and Disable the user in AD
4. Attempt login (you should fail).  Show the log again.
5. Re-enable the user and log in.
6. Try to change the password to something misaligned with policy (like 1235).
7. Show the failure in password updates.

Note: You have to be auditing logon success and failure events in Active Directory Domain Controllers to see this.  You can set this up by enabling success and failure of the Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Account Logon Events GPO.

Samples:
In this sequence, the user Diana (dwirth) logs in to a CentOS system via SSH.

Event on UNIX/Linux:

Jul 27 17:17:55 engcen5 adclient[3313]: INFO  AUDIT_TRAIL|Centrify Suite|PAM|1.0|200|
PAM set credentials granted|5|user=dwirth(type:ad,dwirth@CENTRIFYIMAGE.VMS) 
pid=25913 utc=1438035475776 centrifyEventID=24200 status=GRANTED service=sshd tty=ssh 
client=member.centrifyimage.vms

Event on Windows:


Centrify Architecture and Credential Consolidation
You often have to explain how our solution is architected.  The bottomline is that for all intends and purposes, the system acts like a Windows system.  However, you may need to materialize diagrams like this:

Make sure you explain that Centrify uses UNIX frameworks, standard protocols and Microsoft Active Directory specifications.  Here are some of the key ones:

• Name Service Switch (NSS) –provides a facility to the OS for sources of identity information like users and groups
• Pluggable Authentication Modules (PAM) – provides a facility to the OS applications to abstract authentication providers.
• Kerberos:  Centrify communicates with AD for authentication using Kerberos.  Kerberos is an authentication protocol that relies on a Key Distribution Center and Authentication servers.  The whole principle behind Kerberos is the use of mutual authentication, tickets, encryption and mechanisms to detect replay attacks.  Centrify provides MIT-Kerberos based tools and libraries that have been optimized to work with Microsoft’s Active Directory Kerberos implementation.
• High-availability is provided by AD Site Awareness, offline credential cache, telemetry calculations and the watchdog process.

How does the authentication process work?
At a very simple level:

1. A UNIX-enabled AD user attempts to log in using a PAM-enabled(*) application (like login or SSH)
2. An application like login uses the Centrify PAM module to attempt to log in.
3. The PAM modules will perform a series of checks, e.g. (user is authorized, AD account in good standing), password is correct, etc,
4. Kerberos: The system will use a mutually authenticated encrypted connection (with the highest allowed encryption) to talk to a domain controller and get the appropriate service tickets.
5. The user will be logged in to the system via the corresponding application (e.g. login, SSH)
   (see the attachment)

Encryption Levels
You may be asked about encryption too.  Make sure you explain that in an Active Directory environment, encryption algorithms and strength are defined by the version and functional level of the environment.  For example, an AD DC that is running in 2008R2 functional level will use AES256 for encryption, previous versions would use lower encryption levels.  The Centrify agent will follow the levels defined by Active Directory. 

Passwords are stored in Active Directory domain controllers and the encryption level is defined by the msDS-SupportedEncryptionTypes attribute.  To view the encryption levels supported by your current infrastructure, consult your AD team, or look at the /etc/krb5.conf configuration of any Centrified system. 

Encryption is used for two areas:

• Kerberos transactions (encryption in traffic – self-explanatory)
• Offline cache:   Centrify just like Windows supports the use of offline logins, as a compensating high-availability mechanism in case of lack of communication with a Domain controller.  The encryption levels for the offline has are the ones available by the AD functional level.  The parameter to encrypt the hash of the offline credential is cache.encrypt (or its corresponding Group Policy Object) and you can force an encryption type by using the adclient.cache.encryption.type (or the corresponding GPO).

Due Diligence
Due to Centrify’s penetration in high-security environments, we’ve had to perform additional due diligence and have achieved the following certifications:

• Common Criteria EAL2+:  https://www.commoncriteriaportal.org/files/epfiles/centrify-v20132-cert-eng.pdf
• FIPS 140-2:  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2011.htm#1604
• For additional certifications:  http://www.centrify.com/solutions/federal/certifications/

Resources:

• Centrify Configuration and Tuning Guide:  https://www.centrify.com/downloads/products/documentation/suite2015/centrify-unix-config-guide.pdf (page 31 – adclient.cache encrypt/encryption.type)
• About functional levels:  https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx
• About Active Directory encryption levels:  https://msdn.microsoft.com/en-us/library/cc223853.aspx

Identity: Why aren’t AD Schema extensions or software in Domain Controllers required?
I've seen instances in which the auditor/security analysts asks this question.  
As it relates to identity data, Centrify has several ways to use Active Directory without requiring Schema Extensions:

• Pre-Windows 2003R2 AD functional levels:  Centrify zones implement mechanisms to store UNIX identity information in classic zones.
• Windows 2003R2 and above functional levels:  Centrify can use identity stored in the RFC2307 attributes implemented natively in this schema.
• Services for UNIX (SFU) Schema:  If a customer or prospect extended the AD schema to SFU, we can store information there (although it provides less flexibility than Centrify zones).

In addition, Centrify subscribes to Microsoft’s documented APIs (ADSI), therefore there’s no need to add software in domain controllers.

Resources for Identity: 

• Video – How DirectControl stores information in Active Directory:  https://www.youtube.com/watch?v=JO3_AJObkAs
  in this video, the CTO and creator of DirectControl, explains how Centrify stores data in AD.
• RFC 2307: https://www.ietf.org/rfc/rfc2307.txt
• Attached - The “Understanding the Centrify DirectControl Agent.pdf” excerpt; explains the process step by step and more detail.
  
  (*) Centrify provides functionality for IBM Loadable Authentication Modules (LAM) as well.

Application Edition
If an Application (Apache, Java, DB2, SAP) initiates an authentication request via an interface (SPNEGO, GSSAPI, SASL, SNC, etc) ultimately the agent will use Kerberos for authentication.


In addition  Centrify has a whitepaper titled "Using Microsoft Active Directory to Address Sarbanes-Oxley (SOX) Compliance in Heterogeneous Environments".

Note: the original version of this article was published in the Centrify Community.

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (4/5)

This is part 4 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".  (Also relates to PCI DSS 10.2)

CSC 12-11

Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.

Why should you do this?
This is a detective control.  You can't control what you're not tracking.  Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.

What is the typical approach?
On Windows:  Harvest and mine of the Windows event logs.  Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX:  Harvest and mine the UNIX syslogs.

What is the real challenge for organizations?
Data vs. Noise.   How can organizations reconcile all the sources of data into meaningful information?  This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.

Centrify's enhancers:

• Use what's native:  Uses syslog and event logs.  Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
• Enhance to differentiate the data from the noise:  Centrify can be configured to require reference information upon elevation, for example, change control number.
• Contextualize with DirectAudit to "clear the noise":  Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
• Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"

Have a look:

How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:

How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation

How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (3/5)

This is part 3 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-7

Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.

Why should you do this?
To limit the exposure of administrative accounts to malware.

What is the typical approach?
On Windows:  Two sets of accounts are given to administrators,  a "dash-a" account and a normal account.  On the server side, to access the internet there's an air gap or the proxy server does not allow the servers or the "dash-a" account to go out to the internet.  The IE Enhanced Security mode is enforced.

On UNIX:  Systems are crippled from internet access or GUIs.  The email/surfing computer is different from the server systems.

What is the real challenge for organizations?
Human nature - people find ways to go around this, especially in the process of doing their actual jobs.  In the times of "knowledge on demand" having an internet browser to consult FAQs and community boards is very common.

Centrify's enhancers:
It's not all about just giving separate accounts, but being able to establish additional controls, like scope of systems, types of roles, privilege effectiveness, logon experience and flexible assignments.

CSC 12-10

Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.

Why should you do this?
At basic level this is a detective control, all administrative access should be traced back to an approval, otherwise this is misuse or a data-breach.

What is the typical approach?
Log aggregation.  Logs from multiple systems are sent to an enterprise security operations dashboard.

What is the real challenge for organizations?
Log aggregation lends itself for NOISE, then the log aggregation needs to be complemented by a data mining engine;  this is all to make sure that what's happening out there is authorized.

Centrify's enhancers:

• A Centrify deployment limits the local root or administrator account to break-glass situations.  They are not needed.
• Centrify (without any modification) augments log aggregation.  Therefore, the existing collection mechanisms can have richer data.
• Plus, Centrify reporting shows you what are the AD principals that grant the administrative roles, if things are tied to a Workflow or an IDM, anything that is not there by way of approvals will be identified quickly or rolled back.
• Plus Centrify DirectAudit provides the ability to view or audit who makes changes to the governance model.

Short video:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (2/5)

This is the continuation of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-3

Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.

CSC 12-5

Ensure that all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords.

CSC 12-8

Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows "administrator" or UNIX "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts.

CSC 12-9

Configure operating systems so that passwords cannot be re-used within a timeframe of six months.

Why should you do this?
Because the password policy for admin accounts should be a step-up from regular users given that they hold the keys to the kingdom. 

What is the typical approach?
On Unix:  cracklib PAM module.
On Windows:  group policy.

What is the real challenge for organizations?
Human nature - sysadmins love their root or administrator accounts given their inherent mistrust in software, and unfortunately vendors promote fragmentation. 

Centrify's enhancers:
It's the solution that can accomplish this with true RBAC (allowing the administrative accounts to be put away) plus the tight AD integration with Group Policies (and support for fine-grained password policies).  In addition, Centrify's resiliency truly makes sure that the root or administrator account are only needed in emergency situations.

In UNIX - privilege elevation using Centrify-enhanced sudo (no sudoers) - DirectAuthorize (DZ)
In Windows - privilege elevation with the Centrify agent for Windows (DZ Win)

CSC 12-4

Before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts.

Why should you do this?
Anyone that has had a Linksys router knows the answer to this.  In UNIX/Linux, there's too much reliance on the root account or the switch user command.  Local administrator in Windows is treasured by Windows admins.

What is the typical approach?
Unfortunately, in a lot of environments there's too much sharing of these accounts.  TACACs, RADIUS and password vaults help with network appliances.

What is the real challenge for organizations?
Human nature.  A Unified approach for these accounts like a password vault is typically the right solution.

Centrify's enhancers:
Due to the true RBAC and privilege elevation methods employed by Centrify, organizations can decrease their costs in password vault user licensing costs, by just leveraging it for non-human admin accounts, while the rest of the population uses RBAC.  The end-to-end nature and resilience mechanisms, makes it more efficient to align with regulatory requirements without a single point of failure.  In UNIX, single-user-mode or Windows safe mode without network will be the only instances in which these accounts are needed.

No need to check-out the keys to the kingdom each time the root, or administrator accounts are needed.

• Tied to your identity infrastructure (Active Directory)
• True Role-based access
• Minimal process impact
• Increased accountability using the native tools (syslog/event viewer)
• Extensible to session capture and replay

Tried and true AAA.

CSC 12-6

Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800-132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.

Why should you do this?
There was a time in the security discipline in which encryption was thought to be the solution;  time and different attack vectors have proven this to be wrong; however, encryption in transit and encryption at rest are a must.  There's an arms race going on because although algorithms are strong, Moore's law, virtualization and well-funded and motivated agents are lurking.

What is the typical approach?
Rely on the OS, Directory or the appliance.  Fortunately Microsoft has this very-well documented.

What is the real challenge for organizations?
Human nature, again  It doesn't matter how hard your encryption is if credentials are shared or clear-text passwords are used in scripts or other facilities.

Centrify's enhancers:

• More US-federal government certifications that I can even pretend to understand
• Common Criteria
• FIPS 140-2 Validated

However, the bullets above are just marketing speak if we don't back-it up with examples:

• Kerberized tools:  install.sh adjoin, adleave, adkeytab, adcert, dzdo + more are all Kerberized, which means no need to actually store passwords.  The Hadoop and MongoDB examples illustrate practical use.
• Microsoft CA PKI client:  Use Certificates in your Unix, Linux, Mac systems.
• Extend it to your HTTP, Java, SAP or DB2 needs.

Why even have the problem when you can completely avoid it?

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (1/5)

Background

One of our prospects looking at the Centrify privileged elevation tool for Windows, just highlighted to me that Server Suite is very well-aligned with the SANS Critical Security Controls Section 12: "Controlled use of Administrative Privileges" so I decided to take a deeper look.  We will cover 2 each post until we have the 14 topics explored.

Controlled use of Administrative Privileges

CSC 12-1

Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.

Why should you do this?
Because the more somebody uses a privileged account the highest risk of malware being executed with elevation, more exposure to attacks like pass-the-hash attack, etc. 

What is the typical approach?
On Unix:  sudo, password vaults or RBAC
On Windows:  dash-a accounts, password vaults or RBAC

What is the real challenge for organizations?
Well, sudo is simple, proven but a pain, PVs just give out the keys to the kingdom in a controlled way - great for appliances BTW, and RBAC is hard to implement given that it typically requires multiple solutions.

Centrify to the Rescue:  Centrify Server Suite offers a serverless, cross-platform Unix, Linux and Windows based solution that provides access governance with RBAC leveraging AD.

End Result: The ability to limit access, control privileges (no giving out the keys to the kingdom) and reusing processes, cross platform, using existing technology and infrastructure.  This was explored in the 10-minutes PCI 7 challenge:.

CSC 12-2

Use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.

Why should you do this?
This is all about keeping track and being able to attest who approved the type of access that users have.  It's also an administrative preventative control.  This is not limited to domain accounts but local accounts as well

What is the typical approach?
The solution to this is basically workflow.  Unfortunately, simple workflow engines are hard to come by, or they are tied to a monster solution.  Scripts are popular as well.

What is the real challenge for organizations?
This should be relatively simple, but vendors don't make this easy.  Surprisingly PV vendors do a good job due to the appliance/proxy based nature of their solutions. Go to the vault, request access, approver gets notified, approves/denies, then the access is granted/denied.  Great for break/fix.

How Centrify helps?  Although Centrify does not provide workflow capabilities today (wink);  it makes it very easy for any IdM or workflow engine to perform the functions upstream.  Since the process boils down to AD groups and any decent workflow engine can do this, then the solution looks like this:

Utilities:  Automatic provisioning and role assignment is often achieved with ZPA.  This post and video cover a basic design:



In the next post we'll continue with the list.

Labs: PCI DSS 3.0 Req # 7 - Implement Strong Access Controls 10-minute Challenge

Challenge Accepted!

In a previous post, we outlined the PCI DSS3 Requirement 7 10-minute challenge.
This entry is to outline current environment, high level steps and verification protocol.

Here's the current environment as of today (excluding the 2-node Hadoop cluster):

Here's what we're adding for the challenge:

The cast of characters

• J. Peterman and Elaine Benes are the PCI Developers
• On Windows - PCI Developers shall perform developer tasks like:
• Opening SQL Server Studio
• Resetting IIS websites
• Control System Services
• On Linux -  PCI Developers shall perform LAMP functions like:
• Control the httpd service
• Elevate to the mysql account (without knowing the credentials)
• Edit the httpd daemon config file /etc/httpd/conf/httpd.conf
• Jerry Seinfeld is a Domain Admin
• George Constanza is the UNIX Sysadmin

Steps to the Challenge - 10 minutes

Planning
- Will use a new zone to prove this concept (may be needed for separation of duties) - name: PCI
- Will reuse the existing ZPA service (provisioning has nothing to do with PCI, will control access with Roles)
- A Combined UNIX/Windows role will be created with the following access:

• Role Properties
• Available 24x7
• Password Login and SSO enabled
• Non-Restricted Shell
• Access Rights
• PAM SSH
• Remote (Windows)
• UNIX Commands
• systemctl (start|stop|restart)*httpd  as root (authenticated)
• su - mysql  as root (authenticated)
• vi /etc/httpd/conf/httpd.conf
• Windows Applications
• iisreset.exe  as local administrator
• services.msc as local administrator
• SQL Management studio as local administrator

- PCI Developers group will be called - PCI Developers

Implementation

On the management station:

1. In ADUC create the PCI Developers role
2. In access manager set up the new zone.
3. Set up the Unix identity properties
4. Set up the UNIX commands
5. Set up the Windows Applications
6. Create the PCI Developers role, set up properties, add the rights
7. Perform the role assignment at the zone level.

On CEN2

1. Unpack the Centrify agent bits
2. Run adcheck
3. Join the zone
4. Run adquery user and dzinfo

On APP2

1. Install the Centrify Agent
2. Join the Zone and Reboot

Test Plan (Check) - 5 minutes

• We'll verify that PCI developers can:
• Only log in via SSH (Linux) and RDP (Windows)
• Perform administrative tasks on APP2 (Win Server 2012 R2)
  Not a member of Local Administrators or Domain Admins
• Perform LAMP admin duties on CEN2 (CentOS 7)
  They shall not know the root account.
• Windows Domain admins should not be allowed to log in to the PCI systems (Jerry)
• Enterprise UNIX admins - should not be allowed to log in to the PCI systems (George)
• Any other users can't access the systems (Soup Nazi)
• The model should work for both Unix/Linux and Windows.

First Video - Challenge Explained (5:03)

Second Video - Implementation (9:40)

Third Video - Verification (6:49)

Security Corner: PCI DSS 3.0 Requirement 7 - Implement Strong Access Controls 10-minute Challenge

Background

The Payment Card Industry (PCI) Data Security Standards (DSS) is a great measuring stick for the security posture of any organization.  In fact, I love it because it's so clear.

Requirement 7: "Restrict access to cardholder data by business need to know" poses an interesting set of challenges, because it requires the enforcement of the principles of:

• Least Access - users shall only access the systems they need access to
• Least Privilege - once in these systems, they shall only do what they're supposed to do
• Implement a Role-Based Access Controls (RBAC) model
• Shall be enforced across heterogeneous platforms (7.2.1)
• Ideally the process is consistent and easy to document and adhere to workflow (7.1.4, 7.3)
• Closed systems - All systems default to deny access unless (7.2.3)

Challenge

1. Implement the technical(1) controls of Requirement 7
2. Multi-platform:  Unix/Linux & Windows
3. Implement it in less 10 minutes or less
4. Prove compliance in 5 minutes or less

The Environment:

1. Active Directory 2012 Domain (based on the Microsoft Test Lab Guides)
2. One Windows Server
3. One RHEL 7
4. Centrify software already loaded on a management server (MMCs) and copied in target systems.

Access Rules

The access rules have to be defined as per 7.1.1.

 The card data environment consists of one Windows Server 2012, a RHEL 7 and an Ubuntu 14.04 servers.  The nature of the work performed is database (SQL Server) and Web (IIS) work on Windows.  The RHEL platform is used for an Apache/MySQL app.  There are two types of roles in this environment:

• Sysadmin (cross-platform)
• Sysadmins shall perform tasks as root in RHEL systems without knowing the root password. (7.1.2/7.1.3/7.2.2)
• Sysadmins shall be able to perform tasks as Administrator on Windows platforms without being a permanent member of the Local Administrators or Domain Admins group. (7.1.2/7.1.3/7.2.2)
• Developer (cross platform)
• Developers shall perform service control of Apache and IIS services  (service httpd start | stop | restart) and iisreset.exe - No root/apache/ credentials or ocal admin rights. (7.1.2/7.1.3/7.2.2)
• Developers shall be able to elevate to the mysql service account and to run the services.msc snap-in in Windows (to stop/start/pause) SQL without the root/mysql credentials or local windows admin rights. (7.1.2/7.1.3/7.2.2)

Additional Guidelines

• Because these are PCI systems, no one than the PCI Sysadmin and PCI developer Role can log in to the system.  This includes any other trusted administrators like Domain Admin. (7.2 - deny-all)
• Access to both roles is restricted to the terminal (SSH on Linux and RDP on Windows) no console access.
• The add/moves/changes process shall be controllable via AD Group membership.  This makes easy for other upstream tools to control workflow and approvals. This makes compliance with 7.1.4 (approvals) and 7.3 (documentation) much easier.

Our next post consists of a set of steps and video challenge. 

Security Corner: Eliminating Cleartext Password Usage in Scripts and Facilities

Background

In the previous post "What is a Kerberos Keytab and why should I use it?"  we discussed that once you have a Centrified system, Kerberos-enabled applications can leverage this authentication mechanism.  The key benefit being that the Centrify agent (adclient) automatically maintains the Kerberos environment (e.g machine keytabs and krb5.conf files are updated based on the AD sites and services info) and both the OS and Centrify offer an array of "Kerberized" apps to help the most seasoned Sysadmins.

In this post I will discuss some popular use cases:

• Using the Centrify DNS utility (addns) to leverage Active Directory DNS Dynamic Updates
• Eliminating cleartext passwords from the mount command or from /etc/fstab

Using AD DNS Dynamic Updates and addns to keep your DNS entries up to date

One of the coolest Centrify tools is addns.  As discussed in an earlier post, this utility can help in performing dynamic or manual updates to DNS registrations for Centrified systems.  Think about the "ipconfig /registerdns"  command on Windows.  This is very useful especially when servers are being built with static IP addresses an in a Mixed UNIX/Linux and Windows environment. 

How does it work?

As per TechNet:  "Domain Name System (DNS) client computers can use dynamic update to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.

Dynamic updates can be secure or nonsecure. DNS update security is available only for zones that are integrated into Active Directory Domain Services (AD DS). After you directory-integrate a zone, access control list (ACL) editing features are available in DNS Manager so that you can add or remove users or groups from the ACL for a specified zone or resource record."

This means that in cases in which there are workstations (like Macs or Linux) that change networks frequently or when servers are being provisioned and there's no available Windows DNS administrator, addns can be a very useful tool.

The addns utility supports the -m (or --machine) switch, this means that instead of providing a valid AD account to update the DNS records for a computer, you can use the computer account's credentials instead.  The key benefit here is that there's no need to type credentials.

[root@engcen7 ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)
[root@engcen7 ~]# adinfo -v
adinfo (CentrifyDC 5.2.0-218)
[root@engcen7 ~]# addns -U -m
Updating host records for engcen7.centrifyimage.vms on 192.168.81.10.
Updated host records engcen7.centrifyimage.vms.

Updating reverse lookup records for engcen7.centrifyimage.vms on dc.centrifyimage.vms.

Updated reverse lookup record 167.81.168.192.in-addr.arpa.

Alternatively, if you know the credentials of an AD DNS administrator (or have a keytab), you can kinit and launch addns without the need to specify the --user (or -u) switch:

[root@engcen7 ~]# /usr/share/centrifydc/kerberos/bin/kinit dwirth
Password for dwirth@CENTRIFYIMAGE.VMS:
[root@engcen7 ~]# addns -U
Updating host records for engcen7.centrifyimage.vms on 192.168.81.10.
Updated host records engcen7.centrifyimage.vms.
Updating reverse lookup records for engcen7.centrifyimage.vms on dc.centrifyimage.vms.
Updated reverse lookup record  167.81.168.192.in-addr.arpa.

Potential Uses:

• Troubleshooting DNS connectivity for a roaming computer (Linux or Mac)
• Automated provisioning of IP addresses during Server provisioning.

Keep in mind, all the Centrify "ad" tools that take the -u (--user) option are Kerberized, including adjoin, adleave, addns, adcert, adsmb, adkeytab, etc;  so your scripts don't require interactive attention or the use of cleartext passwords!

Eliminate Cleartext Passwords from the Mount Command or the filesystems table

The mount command traditionally lends itself for the use of cleartext passwords.  Although Centrify has nothing to do with this command (there's a great degree of variability based on the distribution);  the key continues to be Kerberos.

Let's pick on this example.  The idea is to use the mount command from a Unix or Linux system to mount a CIFS share that is on a NAS device or Windows Share.


Both the Mount Syntax
# mount -t cifs //ntserver/download -o username=vivek,password=myPassword /mnt/ntserver
and the fstab entry

//ntserver/docs /mnt/samba      smbfs   username=docsadm,password=D1Y4x9sw 0 0

specify the use of a cleartext password.  Let's improve on this example by leveraging a Centrified system in the modified Microsoft Test Lab Guide.  The idea is to leverage the AD Kerberos environment, the Centrify client, the machine account and the user account to eliminate the use of the cleartext password.

Using the Machine Account to access a Read-only Share

On APP1 - Assign permissions to the Unix/Linux system

1. Open Windows Explorer and go to the root of the C: drive.
2. Create a new folder and call it 'mysmb'
3. Right-click the folder > Properties > Sharing > Advanced Sharing > Permissions and set:
   Authenticated Users :  Read
   Domain Admins :  Full Control
   
4. Right-click the folder > Properties > Security > Edit > and Add
   Select Type: Computers
   CEN1$ (or your centrified system) : Read
   
   
5. Create a a text file in the folder (myfile.txt) and put some text in it.

On CEN1 (or your Centrified system) - Test your mount
Note: Make sure the cifs-utils package is installed on RHEL derivatives.

1. Log on with a user that has the ability to elevate.
2. Use the following command:
   mount -t cifs //app1.corp.contoso.com/mysmb //mnt/share -o sec=krb5
3. Test your share.

   

   This mapping is done right without the need of cleartext passwords.

The active session comes from the Linux computer.

Because the mapping has been done with the Kerberos ticket of the machine account and typically per policy, these only last 10 hours;  a mechanism to renew the ticket for the lifetime of the mount has to be implemented.  For example, a cron job that renews the ticket before it expires like this:

Runs every day at midnight, 8AM and 4PM.  This assures there’s a fresh ticket every 8 hours.

# crontab -l

01 00 * * * /usr/share/centrifydc/kerberos/bin/kinit -k cen1$

01 08 * * * /usr/share/centrifydc/kerberos/bin/kinit -k cen1$

01 16 * * * /usr/share/centrifydc/kerberos/bin/kinit -k cen1$

Or you can leverage the Set Crontab Entries GPO.

Crontab entries can be controled using Group Policy

In addition, and in support of Hadoop, Centrify has come up with another set of GPOs to help with Kerberos ticket renewal.  This parameter can be specified in the configuration file or via GPOs:

Infinite ticket renewal GPOs

This sets up the building blocks for our next entry.  Leveraging UNIX-enabled AD groups to control access to a Windows share leveraging Centrify.

Security Corner: What is a Kerberos Keytab and why should you use it?

Background

Active Directory provides a Kerberos environment.  We have written extensively about Kerberos capabilities in this blog.  We also have explained that Centrify provides tight integration with Microsoft's Kerberos AD implementation by way of their MIT-Kerberos libraries and tools.  The advantage of using Centrify's tool set is that the tools are extensively tested against Microsoft's implementation.

A Kerberos key table (or "keytab") file is "is a file containing pairs of Kerberos principals and encrypted keys (these are derived from the Kerberos password)."(1).

Kerberos keytab files can help overcome two major issues:

• The security requirement of not having plain-text passwords in scripts or helper files.
• The increasing IT Infrastructure requirement for automation.  The proliferation elastic computing by way of private and public clouds requires that IT adds or reduces capacity on demand in a secure way.

Kerberos Keytabs 101

• In a Kerberos environment, each system has at least one keytab table stored on disk.  The keytab table lists the service principals and provides at least one key for each of those service principals (/etc/krb5.keytab by default).  Remember that principals typically follow the "service@host/REALM" format.
• End-users also have Kerberos files, but they are temporary (by default 10 hours), they are stored as a Kerberos cache file (by default /tmp/krb5cc_<uid of the user>), they list any user principals.
• When working with a Centrified system, the location of the Centrify-enabled Kerberos tools is /etc/centrifydc/kerberos/bin.  
• Quick primer on basic Kerberos tools:
• kinit: is used to obtain a kerberos ticket-granting-ticket
• klist: is used to list the cached tickets.
• kdestroy: destroys kerberos tickets
• The Centrify Kerberos tools documentation is publicly available here.
• Keytabs are Sensitive/Confidential information: A Security Procedure needs to be established for the handling of keytabs, because whoever has the keytab can authenticate as the principal used to create it.  As a tip, this process should be viewed with the same sensitivity as the handling of private keys.

Using Kerberos Tools

Kerberos tools are great for troubleshooting purposes.

1. Testing end-to-end AD connectivity and account availability with kinit (e.g. accunt jerry.seinfeld)
   # /usr/share/centrifydc/kerberos/bin/kinit jerry.seinfeld
   Password for jerry.seinfeld@CORP.CONTOSO.COM:
   You are prompted for the user's password.  The benefit of this test that it bypasses the NSS, PAM and authorization modules.  This means that any user in AD can be tested with kinit.
2. Listing the contents of a keytab or cache file with klist
1. For systems
   # /usr/share/centrifydc/kerberos/bin/klist -kt krb5.keytab
   Keytab name: FILE:krb5.keytab
   KVNO Timestamp         Principal
   ---- ----------------- ----------------------------------
   3 05/17/14 22:22:55 host/cen1@CORP.CONTOSO.COM
   
   Note: By default, during a system join (with adjoin) Centrify will automatically register service principals for  http ftp cifs nfs, this parameter is controlled by the adclient.krb5.service.principals directive of the centrifydc.conf file.
2. For users (user root)
   /usr/share/centrifydc/kerberos/bin/klist
   Ticket cache: FILE:/tmp/krb5cc_0
   Default principal: jerry.seinfeld@CORP.CONTOSO.COM
   
   Valid starting     Expires            Service principal
   08/24/14 14:07:02  08/25/14 00:07:04  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM
   renew until 08/25/14 14:07:02
   Notice that this is a Kerberos Ticket Granting Ticket (krbtgt).

Ticket-Granting-Tickets vs. Service Tickets

Depending on how the application is using the keytab, it's possible that it will request a ticket-granting ticket (TGT), or a service ticket.  Generally, a TGT is given upon a session log-in;  a service ticket is requested when a user attempts to access a service on the network.  The key here is that a principal without a servicePrincipalName (SPN) can't be used to request a service ticket.  This changes how the AD principal is created.

The example above shows how to request a TGT.  This example, shows how to test a keytab for a service ticket:

First, we check if the account has a servicePrincipalName (e.g. db2inst1)

$ adquery user -A db2inst1

dn:CN=db2inst1,CN=Service-Accounts,DC=centrifyimage,DC=vms

samAccountName:db2inst1

userPrincipalName:db2inst1@CENTRIFYIMAGE.VMS

servicePrincipalName:db2inst1/engcen5.centrifyimage.vms

Second, we attempt to get a service ticket (the keytab is db2inst1.keytab)

$ /usr/share/centrifydc/kerberos/bin/kinit -S db2inst1/engcen5.centrifyimage.vms -kt db2inst1.keytab db2inst1

[db2inst1@engcen5 ~]$ /usr/share/centrifydc/kerberos/bin/klist

Ticket cache: FILE:/tmp/krb5cc_1004

Default principal: db2inst1@CENTRIFYIMAGE.VMS

Valid starting     Expires            Service principal

11/24/14 11:24:46  11/24/14 21:24:47  db2inst1/engcen5.centrifyimage.vms@CENTRIFYIMAGE.VMS

        renew until 11/25/14 11:24:46

Notice that this is not a KRBTGT, but a service ticket.

Using Centrify Tools for Kerberos-related operations

adinfo (with the C option) can be used to review the system service principals, and encryption level. Remember that the latter is set by the domain controller functional level.
$ adinfo -C
Computer Account Diagnostics
  Joined as: cen1
  Trusted for Delegation: false
  Use DES Key Only: false
  Key Version: 6
  Service Principal Names: nfs/cen1.corp.contoso.com
                           nfs/cen1
                           ipp/cen1.corp.contoso.com
                           ipp/cen1
                           http/cen1.corp.contoso.com
                           http/cen1
                           host/cen1.corp.contoso.com
                           host/cen1
                           ftp/cen1.corp.contoso.com
                           ftp/cen1
                           cifs/cen1.corp.contoso.com
                           cifs/cen1
                           afpserver/cen1.corp.contoso.com
                           afpserver/cen1

Supported Encryption Type(s): RC4-HMAC
                              AES128-CTS-HMAC-SHA1-96
                              AES256-CTS-HMAC-SHA1-96

Operating System Version: 6.1:6.5 (Final)

Adkeytab

adkeytab, is arguably one the most powerful command line tools provided by Centrify.  When used in tandem with scripts and the Kerberos tools it can help to increase security and provide flexibility in automation scenarios.  It has the ability to provision, deprovision and modify server and user principals.  Aside from adedit, adkeytab contains the largest command reference.

adkeytab  -  create  and manage Kerberos key tables (*.keytab files)and coordinate changes with the  Kerberos  key  distribution center(KDC) provided by Active Directory.

I will try to highlight some benefits of using adkeytab:

• It can be used to create or adopt AD principals:  adkeytab can create the user in AD for you, or in a separation of duties scenario, the UNIX/Linux admin can adopt the account provided he has the appropriate rights to modify the AD account.
• It randomizes the AD account's password:  The major issue with service accounts it that they are considered a shared account since at least one person (the creator or the user) knows the password.  With adkeytab it's possible to randomize the password of the AD account, effectively minimizing the need for aggressive password rotation.
• Can be fully automated:  adkeytab can be used with your scripts to perform operations.  This helps with elastic or private clouds.
• It's Kerberized!  what that means is that you can use a keytab to use adkeytab - this is great for automation.
• Syntax can be tricky - there are so many options that it can be overwhelming for beginners; my tips are to use the long for options (e.g. --adopt) and verbose output.
• Fixes stale AD computer accounts:  It can be used to reset the machine computer account.  Just elevate to use the adkeytab command with the -C (--change-password).  The output below uses the local system's computer account (--machine) in AD to reset the computer's password in AD.

$ dzdo adkeytab --change-password --machine -V

Attempting bind to centrifyimage.vms site:Demo-Site server:dc.centrifyimage.vms: ccache:FILE:/etc/krb5.ccache

Bind successful to server dc.centrifyimage.vms

Searching for AD Object: filter = (samAccountName=engcen5$), root = DC=centrifyimage,DC=vms

AD Object found: CN=engcen5,OU=UNIX-Servers,OU=Unix,DC=centrifyimage,DC=vms

Key Version = 21

Changing account 'engcen5' password with machine credentials.

Searching for AD Object: filter = (samAccountName=engcen5$), root = DC=centrifyimage,DC=vms

AD Object found: CN=engcen5,OU=UNIX-Servers,OU=Unix,DC=centrifyimage,DC=vms

Key Version = 22

Success: Change Password: Default Key Tab

The posts below, cover scenarios that use Kerberos key table files:

• Big Data (Hadoop)
• DB2 AD Integration and SSO
• MongoDB AD-Integration with Centrify
• Automating system AD joins/removals

(1) Source: Indiana University IT, https://kb.iu.edu/d/aumh

Labs: Testing the Availability Controls of Centrify for UNIX/Linux/Mac

In this Lab:

1. We'll use the dns.block parameter to use the domain controller fail-over capability.
2. We'll simulate a network failure on UBU1 and use the offline cache.
3. We'll attempt to kill the adclient process as a regular user
4. We will corrupt the /etc/nsswitch.conf and krb5.conf files 
5. We'll simulate an abnormal ending of the client process to invoke the watchdog process
6. We'll describe the domain controller telemetry process

Security Corner: Centrify UNIX Agent's Availability controls

Availability is the security principle that states that information should be available when needed and authentication mechanisms are required to be highly available since they are the door to the information that may be needed to make a business decision.

The Centrify agent for UNIX has a great advantage since it enables those platforms to integrate to Active Directory.  Active Directory was created with high-availability in mind and when properly implemented(*) provides:

• Replication:  Changes in the AD database are replicated to other domain controllers.  This process is called convergence.  Replication applies to LDAP objects and files.
• Multi-master:  Unlike NTDS 4.0 that relied on a Primary Domain Controller (PDC) role for write operations, in AD all DCs are writable.  There are some exceptions in what are called Flexible Domain Master Operations roles.  
• Sites and Services and DNS SRV records:  AD leverages DNS to provide the closest-to-client services;  any services that rely on these capabilities will be able to access the best connected service based on network location.

(*) Sadly, on the field (especially on lab environments) we see a lot of single DC environments and improper configuration of AD Sites and Services.  When we see the infamous "Default-First-Site-Name" displayed it decreases the credibility of the environment's maintainer.

One of the biggest concerns for any UNIX/Linux Systems Administrator is not having the ability to do their job because authentication scheme is not available;  as a matter of fact, that is why many of them are biased on using shared accounts (like root), because those accounts are reliably available.  Unfortunately this perpetuates the poor security practice of sharing those sensitive accounts.  The benefit with Centrify is that the mitigation for HA happens automatically without the need to re-target LDAP services or reconfigure krb5.conf files.

How does Centrify mitigate the Availability question?

Any true risk is mitigated by preventative, detective and corrective controls.  The controls deployed by Centrify are:

1. AD Sites and Services compatibility:  this means that the agent will pick an alternative domain controller based on the AD site topology.  (Corrective/Preventative)
2.  Performance Optimizations:  the agent performs its own telemetry calculations to determine if it's talking to the most optimal domain controller. (Preventative)
3. No AD available:  In case of a network-level failure (inability to connect to any DC) the agent provides the offline credential cache. (Corrective)
4. Abnormal termination:  the cdcwatch process is a watchdog that will spawn a new agent process in case of an abnormal termination.  (Corrective)
5. System file corruption:  Any changes in name server switch (NSS) (nsswitch.conf), Kerberos (krb5.conf) or pluggable authentication module (PAM) config files is monitored and rolled-back to proper operational mode if needed. (Corrective/Preventative)
6. Process Protections:  All agent-related processes (and the watchdog) are owned by root. (Preventative)
7. Logs and Core Dumps:  Centrify integrates with the syslog facility and provides its own core dumps in case of an abnormal termination. (Detective)

As you can see, Centrify's agent implements a high-level of controls to ensure high-availability.

When will a privileged system or local account be needed?

In two instances:

a) Normal termination of the Centrify agent process:  The agent has been stopped, therefore there's no communication with AD or the cache.  The authentication stack will continue on.  For example, on your /etc/nsswitch.conf you may see a line for users (or groups like this):

passwd         centrifydc   files

In case the adclient process is not available, any local account will be granted access.  This is the same under normal operations.

b) Single-user mode:  If the system abends and falls into that mode, the only account that can access the system is root.

Command Line Tool tips

The best command to troubleshoot the agent is adinfo.  Use it with the --test option perform connectivity tests.  Sample output:

george@suse1:~> adinfo --test

Domain Diagnostics

  Domain: corp.contoso.com

  Subnet site: CorpHQ

    DNS query for: _ldap._tcp.corp.contoso.com

    Found SRV records:

      dc1.corp.contoso.com:389

  Testing Active Directory connectivity:

    Domain Controller: dc1.corp.contoso.com

      ldap:      389/tcp - good

      ldap:      389/udp - good

      smb:       445/tcp - good

      kdc:        88/tcp - good

      kpasswd:   464/tcp - good

      ntp:       123/udp - good

Tips about conducting Disaster Recovery tests

Disaster recovery with Centrify for Servers can piggyback on the AD infrastructure and work performed for Windows domain members.  Unix/Linux systems just become another "customer of AD" this means:

• If you're performing a total (from scratch) AD recovery, AD DCs and DNS go first, then the Zone data has to be rebuilt.  UNIX/Linux systems rebuild happens in parallel, once ready, load the agent and join the zone; at that point instead of using the root account, you can switch to dzdo.
• If you're performing a partial or restore of existing systems, restore the AD infrastructure first;  you can work in parallel with UNIX/Linux systems  (credentials will be cached up to the moment of the backup or snapshot) and access will be offline - once AD is online the agent will go in connected mode.
• If you're testing with a disaster recovery site that goes online during tests your strategy may vary. In some outfits its not desirable that the agent fails over to the DR site; so using the dns.block parameter (or the Blacklist DNS DC hostnames GPO) to have those DCs blocked during production is desirable.  However, during the disaster, it should be scripted (or automated) that the DR Site DCs will be unblocked so they are eligible for fail-over.  Another variation of this test is to block the production DCs and only allow the DR DC (that is a crude/forced DR test).
• In larger environments, it's quite common that not all trusted sysadmins have had logged on to all target systems, that is why Centrify has the ability to pre-validate (or pre-cache) user credentials.  Prevalidation will be the subject of another posting.

Description of the dns.block parameter

This configuration parameter specifies which DCs should be filtered out of the pool of existing DCs for the domain.  This is useful when a DC is behind a firewall, has been decommissioned but there's a stalled object or for DR tests.

The parameter in the /etc/centrifydc/centrifydc.conf file works by specifying the directive followed by the FQDNs of the DCs in question separated by commas.

dns.block: dc1.corp.contoso.com,exp1.corp.contoso.com

If you prefer to use GPOs, the path is:  Computer Configuration > Policies > Centrify Settings > DirectControl Settings > Network and Cache Settings > Blacklist DNS DC hostnames group policy.

Labs

Security Corner: Opinion about Synchronization of UNIX identities and Password Management

Background

We have been recently been asked questions from prospects to contrast Centrify solutions versus solutions that synchronize identities in the local system and if Password Management is the right approach for Privilege Management.

How Synchronization Works

Synchronization varies between providers but typically it works this way:

There is an authoritative source for an object (user, file, attribute, etc.) this is considered the Master copy.  Then there are the targets that need copies.
Solutions like BMC ControlSA implement synchronization this way;  there is a server or a source that provides master copies, and in the case of UNIX, the replicas are propagated to UNIX/Linux Systems. In the case of users, they are replicated into the /etc/passwd file;  in the case of groups, into the /etc.groups file;  In the case of passwords, the /etc/shadow file.

Problem solved:  Identity is Centralized....?

Wait... let's examine this closely.

• Synchronization can break (due to many things), this means that a compensating control needs to be implemented to make sure that replicas are in sync with the master.  At this point, you have to deploy a monitoring agent to make sure that all your end systems are properly synchronized (detective);  also people or automation has to be implemented to fix it (corrective).
  Centrify approach:  We talk directly with AD and use NSS, so nothing has to be sync'd.  Can we go offline?  Yes.  But most likely it has to do with someone making a change (maybe moving to  a new subnet not registered in AD) and even there we have the cache.
• Password Synchronization weakens confidentiality.  This is because passwords have to be read from an authoritative source and synchronized with the master server or with the agents.  If your users live in AD, that means that compromises need to be made (reversible encryption) just to make sure that your synchronization works.
  Centrify offers Password Synchronization, but we will be the first to tell you that it is just a competitive feature. We do inline transactions using Kerberos, so no passwords are synchronized or in the clear.  It's all ticket-based.
• The master copy is another directory.  This means more assets, people and processes.
  Centrify uses AD.  No duplication of capabilities.
• Identity Synchronization is NOT authentication.  In the scenario described below, authentication still happens locally since even passwords are synched locally.  This is why you will see solutions like BMC combined with other solutions; they can't solve the other side of the puzzle.
  With Centrify, authentication is implemented as a PAM module on UNIX and it uses our MIT Kerberos-based libraries that have been extensively tested against Microsoft's Kerberos Implementation.
• Identity Synchronization is NOT privilege management:  Privilege Management is about limiting access, privileges, across multiple platforms, getting timely information about who has access to what.
  The Centrify Base Agent provides a robust RBAC model that not only works on UNIX/Linux, but in Windows as Well.
• Identity Synchronization is NOT Governance:  Governance is about being able to separate the people who set the rules from the people that perform the operations.  At the Master copy level this may be possible, but not at the system or end-point level.
  With Centrify, delegation is possible by leveraging AD objects.  Discretionary Access Control Lists allow us to separate the functions of a person that needs to join systems, vs. a person that defines roles and rights.

Synchronization may be inevitable in complex organizations, but when it comes to UNIX/Linux identities with Active Directory it does not have to be that way.

How Password Managers Work

This has been an interesting topic as of late.  The whole capability has the key in the name:  password Management (or shall we say Shared Account Password Management?).  The whole premise is that there's a privileged account (or a service account) that needs to be controlled.

The great thing about password managers is that they can be the faster path to compliance (like a failed audit), but they don't really solve the Privilege Management issue.  They are absolutely part of the solution, but help 20 to 25% of the use cases; the rest of the cases you should be using the principle of least privilege.

Password Managers offer capabilities like:

• Robust Encryption
• Customizable Workflows
• Web Interfaces
• Quick ways to keep auditors happy
• Many password managers provide session management and can capture and replay the session

Problem solved:  Privilege Management is conquered?

Shared Account Password management is not the same of Privilege Management, it's just a subset of capabilities needed for proper privilege management.

Let's look closely:

• The privileged shared account is still used.  It is still root or oracle that are being used;  the only thing that happened is that there's a traffic cop (the password manager) that via the pre-configured workflows allows to check out the password for the account in the target system.
  With Centrify, this is not the approach;  you can grant the individual (AD user) the proper rights; be it a super user or a person that can run only one privileged command. This is implemented with a modified version of sudo (dzdo). You can control how they access the system as well.  And works on Windows.
• Since the password manager is so important, now it has to be highly available = More costs
  With Centrify, we leverage the existing investment in AD.  Reuse vs. New CapEx.  What's easier to justify?
• Password Managers are intermediate systems or proxies.  What if the system accessed directly?
  With Centrify, the adclient is loaded on all managed systems, therefore the rules are enforced end-to-end.  If John Doe can't log in to  Web system, he just can't.  Also, forget about the session capture data.
• The fact that the shared privileged account is managed, does not mean that access is controlled at an individual basis.
  In an environment that follows proper security access management practices, it's still required to know who has access to what and what can they do.
  That's why Centrify's approach is identity-based (leveraging the AD account), not only access can be limited, but privileges can be set as well.
• Perception of Security:  A password manager does not secure the data in the target system.  Don't forget the reason why you're doing security in the first place:  to protect sensitive data.  The problem is not the password, in the context of identity it's implementing strong access controls.
  With Centrify, the local agent will make sure that only folks that are authorized to access the system will be able to, and it can't be circumvented.
• You are affecting the user's productivity:  Ask any vault or SAPM user and they will tell you that they hate it.
  With Centrify, users sign in to the target system (regardless of using SSH, console, RDP) with their AD credentials and are able to perform privilege elevation.  As a matter of fact, Vault makers don't disagree with this approach (otherwise why would they license this?)
• Per-User Costs:  A sad situation for any prospect is that vaults have a complex licensing scheme. The vault needs to be bought (+ additional vaults for HA), this is CapEx; Now add a per-user cost for all managed systems (UNIX or Windows)!!!  (and I have yet to get to support/maintenance costs or complexities due to geographical deployments)
  With Centrify, we provide PERPETUAL per system licensing.

SAPM solutions are definitely necessary in complex enterprises.  In Unix there's single-user mode, in Windows there's the local Administrator account and finally on there's the issue of network appliances.  They can also be a quick solution to a tactical security issue.  This is why Centrify is looking at this capability very closely.

Note (May 2015):  Centrify has released their own SAPM solution; this means that now they can offer both the Least Privilege and Shared Account approaches.




In my personal opinion, I also think that since Password Managers are typically appliances, it's easier to say, well, "at least we have something to stare at" effect is present.  Software-based solutions are harder to "get" - We go through this every day:
- Prospect:  "Where is the server?"
- Centrify:  "No sir/madam, there's no server, you already have the infrastructure in place."
- Prospect:  "But where are you synchronizing?"
- Centrify: "No Ma'am, identities live in AD."
- Prospect: " But where do you put the sudoers file?"
- Centrify:  "There's no sudoers.  We leverage AD and our technology"

People are more interested in how we do things than the fact that we are making things simple.  Most people can't believe it.  Just like magic.


The HUMAN Problem

Another challenge is that a lot of UNIX administrators have not learned to let go of the root account and other service accounts.  In looking at how some our existing customers use their systems today, it's very common to see them log in with their AD account, and the first command is dzdo su - or dzdo su - oracle, etc;  what this means is that they see a vault as the easiest way to maintain the status quo.

This problem exists on Windows as well.  It is quite common for admins to camp on different workstations or RDP sessions with their "-a" accounts.  This is a poor behavior that must be eliminated by imposing privilege elevation on Windows too.