Business Cases: Centrifying Java Application Servers to provide on premises AD-based SSO and Authorization

Background

Java application servers like JBOSS, Tomcat, WebSphere and WebLogic are pervasive in large enterprises.  So is Active Directory.  Just like with Apache HTTP, Centrify customers can leverage the tight AD integration in UNIX and Linux platforms and great support for the Windows platform as well. 

We covered the benefits during the Apache HTTP SSO discussion, and the principles are the same.
This post covers how to install the Java SSO module using Apache Tomcat as an example.

Requirements

• A Centrified Unix/Linux system running Apache Tomcat (Tomcat6 in this example)alternatively, you can follow on JBOSS, WebSphere or WebLogic as well.  The system should be joined to a domain either in zone or workstation mode.
•  Apache Tomcat running and accesible
• A domain-joined PC system (or a centrified Mac) to test access from an authenticated Windows system  with a web browser (SPNEGO is not available on Safari)

Implementation Steps

Information gathering

1.            Collect the OS version, architecture, version of Centrify adclient and if an SPN for HTTP is registered
uname -a, adinfo -v and adinfo -C | grep http provide that information

2.            Collect the service status, version, architecture and java version.
“service tomcat(x) status, rpm –qa | grep tomcat and java-versiont” should provide this.

3.            Make sure the Tomcat home page (if enabled) is accessible from the Windows client.

4.            Obtain the proper version of the J2EE SSO plugin from the Centrify Customer Support Center.
Based on the information from steps 1 and 2, you can select which package to download. For example, in my CentOS 6.x, 64bit, Tomcat6

$ uname -a

Linux engcen8.centrifyimage.vms 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ java -version

java version "1.7.0_71"

OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)

OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

$ adinfo -v

adinfo (CentrifyDC 5.2.0-218)

$ adinfo -C | grep http

$ dzdo adinfo -C | grep http

                           http/engcen8.centrifyimage.vms

                           http/engcen8

[dwirth@engcen8 lib]$ rpm -qa | grep tomcat

tomcat6-6.0.24-80.el6.x86_64

It looks like my service is running and that is a 64 bit CentOS with Tomcat 6 based on this information,  I will download the package " DirectControl for J2EE App Servers on RHEL 4, 5, 6, Fedora 14, 15, 16, 17 x86_64 " the version is 4.4.4 as of the original post in November 2014.

Installation

Unpack and install the SSO plugin

$ tar xzvf centrify-web-4.4.4-rhel3-x86_64.tgz

The installation file on RHEL for this version is called centrifydc-apache-4.4.4-rhel3-x86_64.rpm, so perform a yum or rpm install.

$ dzdo rpm -Uvh centrifydc-web-4.4.4-rhel3-x86_64.rpm

Preparing...                ########################################### [100%]

   1:CentrifyDC-web      ########################################### [100%]

Configuration of the Java Server and Sample Application

Centrify provides a script that allows for the configuration of JBoss, Tomcat, Websphere and Weblogic.  These servers can run on Microsoft Windows, so there are versions of the plugin for those platforms too.  The script is in /usr/share/centrifydc/java/web and it’s called configure.pl.  All you need to do is follow the prompts to configure Tomcat (options 1-3) and ignore everything about ADFS or certificates at this time.

# /configure.pl

=====================================================================

Welcome to Centrify DirectControl for J2EE Servers Configuration.

 At any prompt, enter ? for help, or return to accept the default value (shown in brackets []).

Please select what type of J2EE server to configure:

[0] Tomcat.

[1] JBoss.

[2] WebLogic Server.

[3] WebSphere Application Server.

[4] Exit this configuration program.

Enter selection:

[0] > 0

===== Configure Tomcat Server for Centrify =====

[0] Run full configuration (all options below).

[1] Copy Centrify jar files to Tomcat server.

[2] Configure Tomcat Server for Centrify.

[3] Setup and deploy Centrify samples.

[4] Configure Tomcat for SSL.

[5] Exit this script

[0] > 1

 === Copy Centrify jar files to Tomcat server ===

Enter the directory where Tomcat Server is installed:

[/usr/share/tomcat6] >

Enter the directory where Java SDK is installed:

[/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64] >

Enter the Tomcat Server version (7.0.x, 6.0.x, 5.5.x or 5.0.x):

[6.0.x] >

You have entered the following:

Tomcat Server directory = /usr/share/tomcat6

Java SDK directory = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64

Tomcat Server version = 6.0.x

Is this correct (y/n) ?

[y] > y

Copying /usr/share/centrifydc/java/web/scripts/tomcat/centrifydc_jaas.config to /usr/share/tomcat6/c

<...>

===== Configure Tomcat Server for Centrify =====

[0] Run full configuration (all options below).

[1] Copy Centrify jar files to Tomcat server.

[2] Configure Tomcat Server for Centrify.

[3] Setup and deploy Centrify samples.

[4] Configure Tomcat for SSL.

[5] Exit this script

Enter selection:

[0] > 3

=== Copy Centrify jar files to Tomcat server ===

Enter the directory where Tomcat Server is installed:

[/usr/share/tomcat6] >

Enter the directory where Java SDK is installed:

[/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64] >

Enter the Tomcat Server version (7.0.x, 6.0.x, 5.5.x or 5.0.x):

[6.0.x] >

You have entered the following:

Tomcat Server directory = /usr/share/tomcat6

Java SDK directory = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64

Tomcat Server version = 6.0.x

Is this correct (y/n) ? y

<...>

===== Configure Tomcat Server for Centrify =====

[0] Run full configuration (all options below).

[1] Copy Centrify jar files to Tomcat server.

[2] Configure Tomcat Server for Centrify.

[3] Setup and deploy Centrify samples.

[4] Configure Tomcat for SSL.

[5] Exit this script

Enter selection:

[0] > 3

=== Setup and deploy Centrify samples ===

Enter the directory where Tomcat Server is installed:

[/usr/share/tomcat6] >

Enter the directory where Java SDK is installed:

[/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64] >

Enter the Tomcat Server version (7.0.x, 6.0.x, 5.5.x or 5.0.x):

[6.0.x] >

You have entered the following:

Tomcat Server directory = /usr/share/tomcat6

Java SDK directory = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64

Tomcat Server version = 6.0.x

Is this correct (y/n) ?

[y] > y

Do you want to setup the Centrify ADFS samples now (y/n) ?

(You must have the ADFS server's hostname and SSL port to setup the ADFS samples.)

[n] >

Verify that everything is working as expected

1.            Sign-in to a Windows client that is a member of your AD Domain

2.            Clear your Kerberos ticket cache by opening a command line and typing "klist purge"
C:\Users\dwirth>klist purge
Current LogonId is 0:0x9bb0d
Deleting all tickets:Ticket(s) purged!

3.            Open Internet Explorer and go to Internet Options > Security > Local Intranet > Sites > Advanced and make sure that your browser has the FQDN or the suffix of the SPN for HTTP registered by the server.
If using Firefox, go to about:config and search for network.automatic-ntlm-auth.trusted-uris, add the SPNs suffix or FQDN there.

4.            Go browse to http://<your-server>/centrifydc-samples.  This will expose the Centrify Sample pages.  Click on Kerberos.  If everything is correct, you should be able to see output that looks like this:

5. Now if you inspect your kerberos ticket cache, you'll something like this (truncated):
   C:\Users\dwirth>klist
   Current LogonId is 0:0x9bb0d
   #0>     Client: DWirth @ CENTRIFYIMAGE.VMS
   Server: krbtgt/CENTRIFYIMAGE.VMS @ CENTRIFYIMAGE.VMS
   
   #1>     Client: DWirth @ CENTRIFYIMAGE.VMSServer: HTTP/engcen8.centrifyimage.vms @ CENTRIFYIMAGE.VMS

Ticket # 0 is a Kerberos TGT and #1 is a service ticket that was requested by Diana to access the Apache HTTP service on engcen8.

Using the Java Plugin

The Java plugin has exposed the methods to leverage AD authentication via Centrify.  For example, the web.xml file of a server may add directives like these:

<login-config>

     <auth-method>SPNEGO</auth-method>

     <realm-name>CENTRIFYDC</realm-name>
</login-config> 

The Centrify Java Guide, explains to J2EE Web Admins and developers how to use these directives and methods.

Video Playlist

(7 minutes total)

Business Cases: Centrifying Apache HTTP Server to provide on premises AD-based SSO and Authorization

Background

Apache is the de facto Web Server for many apps and organizations have  the challenge of providing access to enterprise users that are very likely coming with Active Directory credentials;  not an issue for Centrify customers because fortunately, every centrified Unix/Linux  system has a single, secure connection to AD.

This approach results in centralized administration, streamlined authentication, policy enforcement and role-based access controls (privileged management) and since the underlying technology simplified  AD connectivity by leveraging native features and topologies (sites and services, global catalogs, subnets, one-way or cross-forest trusts, DC telemetry and caching)

In order to extend these benefits to web apps, Centrify offers the Apache HTTP SSO plugin that natively extends the authentication mechanisms of Apache to provide SPNEGO via the GSSAPI; the result is having the capability of Windows Integrated Authentication in UNIX/Linux-based Apache servers.

Translation: SSO via Kerberos or NTLM, authorization based on AD principals and the exposure of AD-attributes via native Apache APIs.  This post covers how to install the Apache plugin on a centrified server, how to get the sample application up and running, and how to incorporate it to existing Apache sites (we'll use phpPgAdmin as an example).

What is SPNEGO?

SPNEGO stands for "simple and protected GSSAPI negotiation mechanism" microsoft likes to call it IWA (Integrated Windows Authentication) and basically enables the capability for a browser to negotiate the authentication mechanism based on capabilities.  If configured correctly, the browser will attempt to use Kerberos, downgrade to NTLM if not possible fall back to basic authentication.   This means that for any Authenticated AD session, provided the browser is configured correctly the user will get SSO, otherwise they will get challeged via NTLM.

What you'll need

• A Centrified Unix/Linux system running Apache
  Joined to the domain either in zone or workstation mode.
• Apache HTTP server running
  You need to know the version and architecture to obtain the right version.
• A domain joined PC system to test access from an authenticated Windows system (or a centrified Mac) with a web browser (SPNEGO is not available on Safari)

Implementation Steps

Information gathering

1. Collect the OS version, architecture, version of Centrify adclient and if an SPN for HTTP is registered
   uname -a, adinfo -v and adinfo -C | grep http provide that information
2. Collect the service status, version, architecture and if dynamically loaded modules are enabled.
   httpd -V and httpd -l (look for mod_so.c) provide this info.
3. Make sure the Apache home page (if enabled) is accessible from the Windows client.
4. Obtain the proper version of the Apache HTTP SSO plugin from the Centrify Customer Support Center.
   Based on the information from steps 1 and 2, you can select which package to download. For example, in my CentOS 6.x, 64bit, Apache 2.2
   
   
   $ uname -a
   Linux cen3.corp.contoso.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

   $ adinfo -v

   adinfo (CentrifyDC 5.2.0-218)

   $ adinfo -C | grep http
   

                              http/cen3.corp.contoso.com

                              http/cen3

   $ dzdo service httpd statushttpd (pid  2811) is running...

   $ httpd -V

   Server version: Apache/2.2.15 (Unix)

   Architecture:   64-bit

   $ httpd -l | grep mod_so.c

     mod_so.c
   
   It looks like my server is running CentOS 6.x and Centrify 5.2;  the SPN for HTTP is cen3.corp.contoso.com. As far as Apache goes it is a 64 bit Apache 2.2.  Based on this information,  I will download the package "DirectControl for Apache HTTP Server on RHEL 4, 5, 6, Fedora 14, 15, 16, 17 x86_64" the version is 4.4.3 as of the original post in November 2014.  

Installation

Unpack and install the SSO plugin

$ tar xzvf centrify-apache-4.4.4-rhel3-x86_64.tgz

The installation file on RHEL for this version is called centrifydc-apache-4.4.4-rhel3-x86_64.rpm, so perform a yum or rpm install.

$ dzdo rpm -Uvh centrifydc-apache-4.4.4-rhel3-x86_64.rpm

Preparing...                ########################################### [100%]

   1:CentrifyDC-apache      ########################################### [100%]

Configuration of the Sample Application

Centrify provides a working sample app that can be used to see how to use the directives of the plugin.  To enable it, just include the path to the corresponding config file in the /etc/httpd/conf/httpd.conf file.  The sample app is in /usr/share/centrifydc/apache/samples and since I'm running Apache 2.2.x 64 bit, all I need to do is add this line 

Include /usr/share/centrifydc/apache/samples/conf/centrify22_64.conf

and restart the Web Server.

$ dzdo vi /etc/httpd/conf/httpd.conf    

==>then 'G' to go to the end and 'o'' to insert a line

# Include of Centrify Samples

Include /usr/share/centrifydc/apache/samples/conf/centrify22_64.conf  

==>Then <ESC> wq! to save

$ dzdo service httpd restart

Stopping httpd:                                            [  OK  ]

Starting httpd:                                            [  OK  ]

Verify that all is working as expected

1. Sign-in to a Windows client that is a member of your AD Domain
2. Clear your Kerberos ticket cache by opening a command line and typing "klist purge"
   C:\Users\jerry.seinfeld>klist purge
   Current LogonId is 0:0x9bb0dDeleting all tickets:Ticket(s) purged!
3. Open Internet Explorer and go to Internet Options > Security > Local Intranet > Sites > Advanced and make sure that your browser has the FQDN or the suffix of the SPN for HTTP registered by the server.
   If using Firefox, go to about:config and search for network.automatic-ntlm-auth.trusted-uris, add the SPNs suffix or FQDN there.
4. Go browse to http://<your-server>/samples.  This will expose the Centrify Sample pages.  Click on Kerberos.  If everything is correct, you should be able to see output that looks like this:
   
5. Now if you inspect your kerberos ticket cache, you'll something like this (truncated):
   C:\Users\jerry.seinfeld>klist
   Current LogonId is 0:0x9bb0d
   #0>     Client: jerry.seinfeld @ CORP.CONTOSO.COM
           Server: krbtgt/CORP.CONTOSO.COM @ CORP.CONTOSO.COM
   
   #1>     Client: jerry.seinfeld @ CORP.CONTOSO.COM
          Server: HTTP/cen3.corp.contoso.com @ CORP.CONTOSO.COM

Ticket # 0 is a Kerberos TGT and #1 is a service ticket that was requested by Jerry to access the Apache HTTP service on CEN3.

From a domain-joined computer, as it's configured by default, any valid AD user should have access. The directives to add to your Apache web sites is as follows:

 AuthType           CENTRIFYDC    # This directive enables the Centrify Plugin for the Site.

    EnableBasicAuth    true               # This directive enables Basic Auth (use only with SSL)

    EnableNtlmAuth     true               # This directive enables NTLM authentication

    EnableKerberosAuth true           # This directive enables Kerberos authentication

    Require            valid-user             # This directive controls authorization. Valid user is any AD authenticated user.

The require directive can be used for AD-based authorization, For example, if I want to only allow the members of the "Demo Users"  AD group, the Require will look like this:

Require group "Demo Users"

Plugin in Action - phpPgAdmin

In this example, we'll use the Apache SSO Plugin to AD-enable the phpPgAdmin app.  phpPgAdmin provides a web interface to manage PostgreSQL.  To install it  (e.g. in CentOS 6.x)

Add the repository

$ wget http://yum.postgresql.org/9.1/redhat/rhel-6.3-x86_64/pgdg-centos91-9.1-4.noarch.rpm

$ rpm -Uvh pgdg-centos91-9.1-4.noarch.rpm

Install the app

$ dzdo yum install phpPgAdmin

Configure the App to accept local connections

Edit the /etc/httpd/conf.d/phpPgAdmin.conf for example:

allow all from 10.0.0.0

Restart the Web Server

$ dzdo service centrifydc restart

Verify Access by browsing to your server in the /phpPgAdmin virtual directory:

To enable access with the Centrify plugin, just add the directives below inside the Location stanza of the /etc/httpd/conf.d/phpPgAdmin.conf file.  In this case we are limiting access based on membership on the Demo Users AD group.

 AuthType           CENTRIFYDC  

    EnableBasicAuth    true              

    EnableNtlmAuth     true               

    EnableKerberosAuth true           

    Require group "Demo Users"

Don't forget to restart the Apache Server!!!

Video Playlist

(11 minutes, 30 seconds total)

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:

Basics: Centrify User Suite

Background

Centrify has two product lines.  Server Suite and User suite. With the release of Suite 2014.1, we are starting to see some synergy between product lines and since the blog has focused exclusively on server suite, we figured we need to expand, but first, let's explore this product.

What is Centrify User Suite?

Well, let's see:

• It's a cloud-based Identity Provider
• It provides access and SSO to on premise and cloud apps
• Provides Mobile Device, Application and Container Management
• It provides self-service capabilities (device enrollment, management, self-service password reset)
• Provides a catalog of over 2500 templates for fast publishing of Web, SaaS (SAML, WS-Fed, etc) and Mobile Apps.
• Provides Multi-factor Authentication
• Provides AD-based, Cloud-based or Mixed Identity
• Works with Active Directory in a non-intrusive (no directory duplication) and secure way
• Provides a policy engine for the directory
• Provides Role-Based Access for Application access and Privilege Management
• Provides multi-geography, shared or dedicated hosting
• Provides an interface that
• Provides access in rich (web) and mobile clients
• Provides tenants with their own publicly-rooted certification authority
• Provides access to apps can be via a self-service portal (provider-initiated) or application initiated.
• Extensible by way of an SDK, customizations and branding.
• Recognized by Gartner as a visionary in the 2014 IDaaS MQ.
• Continues to add capabilities at a near monthly rate

Where's the value?

In my opinion, the biggest value of user suite is that in the same spirit of server suite, for any organization with AD, provides the fastest, most efficient and secure way to adopt SaaS applications, it does it without breaking the bank and without aspiring to become the organization's directory of record.  The mobile, directory and hybrid identity and policy services are the cherry on top.

Here's what you don't need to do with user suite:

• Deal with servers in the DMZ
• Deal with understanding on premise federation technologies
• Deal with understanding app authentication or federation patterns
• Deal with publicly rooted certificates
• Pay for expensive MDM solutions
• Pay for 2-factor authentication solutions
• Worry about geographically located solutions
• Worry about language and branding
• Worry about having a split strategy for mobile devices

This translates to tighter control, time to market, added capabilities, etc.

What you must know and have:

• What are the different Cloud IdPs and their pros and cons.
• A policy for cloud-based access controls
• A plan for service availability

We'll explore topics related to cloud in Security Corner.

User Suite Tour

Labs and User Suite

Updated labs logo

We will keep things practical expect a lot of labs, howto's, etc.  We will be using Office365, Google Apps and Salesforce as our key apps given that they either provide a free or cheap version.  As we can find trial apps we will explore them.  As it relates to mobile, we will use iOS, Android and OS X.

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?