Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

Integration of legacy platforms with Centrify Server Suite

11 April,19 at 11:50 AM

Consider the following scenario:


A customer has made the decision to deploy Centrify Server Suite release X (let's take release 2016.1 for this example). They check the supported platforms website to verify that all their target operating systems are supported.

After downloading the installation media for the Centrify Server Suite release 2016.1, the customer then notices that some of their operating system flavours are not listed in the section 'Supported Platforms' in the included release notes of that release (e.g. in 'Centrify-Server-Suite-2016.1-Release-Notes.html' for the latest release at the time of writing).

 

The client then poses the following question, based on the information they retrieved:
"The operating systems on some of my machines, Solaris 8 and 9, HP-UX 11.11 and 11.23, are all listed as 'supported', but are not supported by the Centrify Server Suite release that I want to deploy. Should I deploy an older version of Server Suite instead, that supports all these operating systems? And how do I deal with my deployment of servers running the legacy HP-UX 11.00 OS, that does not show up at all on this list of supported platforms ?"

 

This article addresses these two questions.

 

Question 1 - What is the difference in 'Supported platforms by Centrify Server Suite' vs 'Supported platforms in latest release'?

A Centrify agent release supports a certain set of features. Some of these features depend on information stored in the Centrify Zone structure in Active Directory. This Zone structure is usually managed by the Centrify DirectManage Access Manager Console, among other tools. Each of the components Agent, Centrify Zone and Access Manager Console, can be identified with a version number.

 

Fortunately for our clients, components carrying different version numbers have a certain degree of interoperability. The 'Centrify Upgrade and Compatibility Guide' ('centrify-upgrade-guide.pdf' included on the installation media), helps us shed a light on the degree of interoperability.

The section 'General compatibility between versions of Centrify software' in this document, tells us that:

  • The latest Centrify *NIX agents will be able to join Zone Structure created with an older version of the console, all the way back to version 2.x of the console (Server Suite 2016.1 carries the Access Manager console version 5.3.1). Of course, this means also that the agent will not be able to leverage any features it normally supports, that rely on newer versions of Centrify Zones.
    For example, if you join an agent with version 5.3.1 to a classic zone generated with Access Manager 4.4.1, you will not be able to use hierarchical zone features such as computer overrides, runtime variables in user profiles, etc.
    A more recent example would be that, when joining a agent with version 5.3.1 to a hierarchical zone managed by Access Manager 5.1.3, you will not be able to manage local users and groups on the *NIX computer, as you lack the ability to manage those in the Centrify Zone with that version of the Access Manager console.
  • *NIX agents are forward compatible with Centrify Zones created by a console that has a major version number 1 ahead of the agent version; there are exceptions: agents supporting only Classic Zones (e.g. version 4.x) cannot be joined to Hierarchical zones (created by a Access Manager console version 5.x). However, agents supporting hierarchical zones (5.0 or newer) can be joined to zones created by any 5.x console release (e.g. with Access Manager console version 5.3.1 in the 2016.1 release). Again, the downside is that the agent will not be able to leverage features present in the zone structure that have been introduced after the release of the agent. Similarly, any group policies that define new features are ignored by the older version of the agent.
    As an example of this, you can join a agent with version 5.1.3 to a zone managed by the Access Manager 5.3.1, but any local users and groups that have been defined in the Centrify Zone will not be pulled by the *NIX system running that version of the agent.

After logging in to our support website, our client needing support for Solaris 8, 9 and HP-UX 11.11 and 11.23, will be able to consult the section 'LIFECYCLE POLICY FOR CENTRIFY SUPPORT OF OPERATING SYSTEMS' on the product lifecycle website, to find that the latest agent version supporting these operating systems are DirectControl version 5.2.3 (Solaris 8) and 5.3.0 (Solaris 9, HP-UX 11.11 and HP-UX 11.23). As all of these agents sport version 5.x, they can join hierarchical zones, and all is good in terms of interoperability.

 

But what about support? Didn't all these operating systems show up as supported?
On that same Product Lifecycle website, in the section 'LIFECYCLE POLICY FOR CENTRIFY PRODUCTS', a table details the support status of each of these agent versions.

In this section, we find that:

  • DirectControl 5.2.3 is supported until July 2020 with a premium or elite support contract, and until July 2018 with standard support contract.
  • DirectControl 5.3.0 is supported until December 2020 with premium or elite support contract, and until December 2018 with standard support contract.

After the phase when support with a standard support contract ends, also known as the 'Core Support' period, no new features will be added to those agent versions, and no new maintenance builds will be issued.


The Centrify agent lifecycle policies should give enough time to phase out these legacy platforms, as end of latest agent support often matches or exceeds the support period by the OS vendor itself. Keeping these old systems around for any longer may pose serious security risks to the corporate network they reside in.

 

Let say that the client wants to support an operating system that no longer is supported, such as HP-UX 11.00 (latest agent is DirectControl 4.3, end of premium support date was May 2014). Fully aware of the security risk, the client inquires what options there are for integration with centralised identity management and, if possible, access control.

This is when we arrive at the next question of this article, that has a more complex response...


Question 2 - How to deal with legacy operating systems?

Let's take the example of a machine running the HP-UX 11.00 operating system. The product lifecycle website, tells us that the last agent release supporting this version is DirectControl 4.3, with an end of premium support date of May 2014. This agent version only supports joining to Classic Zones.

 

The best recommendation would be to decommission this system, as it is out of support from its vendor, from Centrify, and likely poses big security risks when joined to the corporate network without sufficient network access controls.


If decommissioning of this system is not an option, then it would be a good idea to switch to using local accounts exclusively, and to isolate the machine as much as possible on the network, if network access is deemed a requirement.


If neither of these two options is feasible, and integration with Active Directory for identity management platform is strongly desired, despite the security concerns, the following four options remain:

 

  1. Use the last Centrify agent released for the target operating system, and join the machine to AD
    In our case, this means using the unsupported DirectControl 4.3 agent, and joining the system to a Classic Zone, specifically created for this purpose. Any identities will need to be provisioned specifically for this zone, or synchronised from the hierarchical zone structure that is part of the main Centrify deployment in the domain (e.g. using custom PowerShell scripts provided by a Professional Services consultant during a services engagement).

    Advantage of using the DirectControl 4.x agent with a Classic Zone:
    - Leverage AD's identity platform, and manage UNIX identities using a single solution (Centrify Server Suite)

    Disadvantages:
    - Classic zones are very limited in terms of functionality, and continued integration of UNIX identities in both hierarchical and classic zones requires a complex setup dependant on custom scripts.
    - Since the agent version is no longer supported, no new featues will be incorporated, nor will bugs actively be fixed.

  2. Setup a NIS proxy server and configure the target system to use NIS as source of identities and their password hashes
    Designate a *NIX system that runs a supported Centrify agent as NIS proxy server, install the Centrify NIS proxy (adnisd) onto this system, provision user objects in Active Directory with password hashes, authorize the proxy server machine to read the password hashes, and finally configure the legacy system with ypbind to use the NIS proxy server as source for the Name Server Switch (NSS) passwd and group maps. This procedure is fully documented in the Centrify Network Information Service Administrator’s Guide (centrify-nis-guide.pdf).

    Advantage of using NIS proxy for identities and authentication:
    - Does not require a Centrify agent on the target operating system, meaning that just about any platform will be supported
    - Leverages Centrify Zones for managing identities and very basic authorization ('login' & 'listed').
    - Can optionally use a consolidated authentication data, by using a password synchronisation tool to keep the AD password and the user password hash for NIS in sync.

    Disadvantage of using the NIS proxy for identities and authentication are plenty:
    - NIS protocol data transits in clear text over the wire. This means identity data and password hashes can easily be captured, which is a grave security concern.
    - Legacy operating systems usually don't support strong password hash algorithms. Despite choosing the strongest hash algorithm supported by all target legacy systems in the environment, collisions can often be calculated relatively quickly (see https://en.wikipedia.org/wiki/Crypt_(C) for more information on the hash algorithms). Once a collision has been found, it will be accepted as a valid password on the legacy systems using NIS for authentication. Even worse is if the found collision is the actual Active Directory password, making it possible to break into every AD-integrated system for which the recovered identity has access rights. These password hashes can be retrieved through various means: capturing network traffic between legacy systems and the NIS proxy, from a compromised legacy system or NIS proxy server, or using an privileged Active Directory identity that has read access to the user attribute containing the password hash.
    - When a single password is desired for both AD and NIS, the procedure to keep the Active Directory password and the password hash for NIS in sync, requires a password synchronisation solution that can be very hard to set up without negatively impacting security. This is a lesser concern for companies that already use a password management solution, such as a web portal, from where passwords are propagated to various identity sources, including Active Directory.
    - Access controls are very limited using NIS; either a user has a valid combination of UNIX profile, login shell and password hash, or they don't. This corresponds with controlling access only through the 'UNIX login' and 'listed' roles in the Centrify zone. Even more limiting than that, as user authentication is not performed through either Kerberos or NTLM, disabling the user in AD will not result in revoked access to NIS clients.

  3. Setup an LDAP proxy server, and configure the target system to use LDAP as source of identities and their password hashes
    Designate a *NIX system that runs a supported Centrify agent as LDAP proxy server, install the Centrify LDAP proxy server (a modified version of openldap) onto this system, provision user objects in Active Directory with password hashes, authorize the proxy server machine to read the password hashes, and finally configure the legacy system with NSS ldap integration, to use the LDAP proxy server as source for the Name Server Switch (NSS) passwd, group and shadow maps.

     

    Advantage of using the LDAP proxy for identities and authentication data:
    - The same advantages as mentioned for using the NIS proxy
    - Theoretically more secure against leaking identities and authentication in network packet captures, as the LDAP proxy supports TLS v1.2 for securing network traffic.

     

     

    Disadvantages of using the LDAP proxy for identities and authentication data:
    - The same disadvantages of using the LDAP proxy
    - In practice using the LDAP proxy with password hashes is even more insecure and complex than using the NIS proxy:
    Most legacy platforms will not support communications to the LDAP proxy with a sufficiently strong TLS protocol, leading to similar protection of data-in-transit; as the LDAP proxy only supports simple binds, the username and password for the service account used to authenticate against ldap proxy, will pass in clear text, or over an encrypted channel using outdated security, such as SSL 3.0.
    - The legacy systems require an Active Directory service account to query the identities. This means setting up a reasonable number of service accounts, as sharing a single account for all LDAP clients would lead to a single-point of failure.

     

  4. Setup an LDAP proxy server, and configure the target system to use LDAP as source of identities, proxy PAM authentication requests to the LDAP proxy
    Designate a *NIX system that runs a supported Centrify agent as LDAP proxy server, install the Centrify LDAP proxy server (a modified version of openldap) onto this system, configure the legacy system with NSS ldap integration, to use the LDAP proxy server as source for the Name Server Switch (NSS) passwd and group maps. Configure PAM ldap integration to pass all authentication requests to the LDAP proxy server.

    Advantage of using the LDAP proxy for identities and as authentication proxy:
    - Does not require a Centrify agent on the target operating system, meaning that just about any platform will be supported
    - Leverages Centrify Zones for managing identities and very basic authorization ('login' & 'listed').
    - Leverages centralised authentication by Active Directory to process user authentication attempts
    - Unlike NSS integration, this method does not depend on password hashes being stored in Active Directory, and thus eliminates a bunch of security concerns
    - In theory, more secure than NIS against leaking identities and authentication in network packet captures, as the LDAP proxy supports TLS v1.2 for securing network traffic.

    Disadvantages of using the LDAP proxy for identities and as authentication proxy:
    - In practice, often most legacy operating systems usually don't even support LDAPS with TLS v1.0; As the ldap proxy only supports simple binds, service account binds and user authentication attempts will transit in clear text, or over an encrypted channel using outdated security, such as SSL 3.0. In these situations, additional measures will need to be taken to secure traffic between legacy systems and LDAP proxy, such as VLAN isolation or IPSEC.
    - The legacy systems require an Active Directory service account to query the identities. This means setting up a reasonable number of service accounts, as sharing a single account for all LDAP clients would lead to a single-point of failure.
    - Access controls when using the LDAP proxy for identities and proxied authentication more or less is equivalent to using Centrify Classic Zones without DirectAuthorize.

 

Summarizing the answers and various options available in the original scenario:
- The Centrify Server Suite solution happily works with a big variety of agent and console versions, provided one takes into account the possible limitations that result from mixing and matching different versions.
- Just because the latest Centrify release does not support UNIX/Linux platform X, does not mean that platform X cannot be successfully integrated into the common Centrify deployment while retaining full or near-to-full functionality and/or support. Always consult the product lifecycle website to find full details !
- Many different options exist to integrate legacy platforms if the hard requirement exists: using native Centrify agents joined to a special legacy zone, using NIS protocol, or using the LDAP protocol. A Centrify Professional Services consultation provides a good means to find the optimal method for integration in these type of scenarios.

In my next article, a walk-through will be provided that explains how to set up the LDAP proxy, as a source for identity data and to process proxied authentication requests from the PAM stack.

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.