Q&A: IAM and the Unix/Linux Organization
Unix/Linux systems needn't be islands of identity; we show you the challenges and options for addressing authentication, provisioning, and security and take a closer look at Active Directory bridges.
Identity and management (IAM) can be particularly challenging for IT shops with Linux and Unix. From authentication and provisioning (and de-provisioning) to a host of security concerns (such as maintaining password policies) confront IT. To learn what options you have to manage in this environment, and how Adtive Directory bridge products play a role, we turned to Jackson Shaw, senior director of product management at Quest, where he oversees product direction, strategy and go-to-market activities for the company’s portfolio of Identity and Access management products.
Enterprise Strategies: What are some of the unique challenges Unix/Linux organizations face with identity and management (IAM)?
Jackson Shaw: Natively Unix/Linux systems are “islands of identity” with each server having its own directory and each directory housing a different version of an individual’s identity. This means that any one user could have dozens (or more) of disparate identities across an entire environment. Each identity is associated with a unique user ID (UID) that typically is not consistently established across the entire population of Unix systems. An antiquated technology called Network Information Service (NIS), which is in use by most Unix/Linux organizations, is non-compliant due to the way it transmits passwords in clear text over the wire and must be eliminated or secured by most organizations.
This disjointed, disparate identity namespace in Unix/Linux causes a number of fundamental IAM challenges. Authentication in Unix/Linux systems is generally not compliant with the latest security and regulatory demands; provisioning and de-provisioning of accounts is usually done on a box-by-box basis, which causes delays, security holes, and compliance violations; and password policy across the entire range of Unix/Linux systems is inconstant and typically not up to enterprise security standards.
In addition, it is virtually impossible to audit identity and access information across an entire population of Unix/Linux systems; password resets across multiple systems are time-consuming and inefficient; and users with the Unix root account are not controlled or tracked at a level that will satisfy auditors and security standards.
Finally, it is extremely difficult to add strong authentication (such as one-time passwords or smart cards) across the entire range of Unix/Linux systems
What are the options to address those challenges?
There are several options for addressing the challenges I’ve outlined. You can do nothing and continue using native tools, manual processes, and repetitive tasks to address the password, provisioning, audit, and authorization (root access), authentication challenges of Unix/Linux systems. There is no need to acquire new software with this option, but it doesn’t address the fundamental problem of disjointed identities and inefficient and non-secure IAM practices.
You can implement targeted tools to address specific challenges (such as SUDO for root account delegation), and this will solve specific pains. The problem with this option is that it results in a disjointed set of tools without a common interface. These tools often do not scale across multiple systems -- you still perform the task individually on each box. Open source tools also lack commercial support.
Another option is to implement an IAM framework and synchronization to implement a common management interface across all systems, including Unix/Linux. This results in an enterprise-wide IAM platform that is custom built to address the needs of the organization, but it is extremely expensive, highly complex, and requires multiple years of custom development and deployment. It also needs a high level of ongoing maintenance, and a dedicated highly skilled staff. It is not equipped to address such fundamental issues as non-secure authentication, root delegation, or single sign-on.
The final option is to consolidate Unix/Linux directories and unify identities (Active Directory bridge) into an existing directory structure (Active Directory). This provides Kerberos authentication for Unix/Linux systems and eliminates Unix/Linux identity in favor of more-secure Active Directory (AD) identity. It enables the implementation of group policy management principles across Unix/Linux systems, provides “true” single sign-on, and extends security and compliance advantages of AD (password policy, authentication, etc.) to non-Windows systems. It delivers a single, secure point of provisioning and de-provisioning across Windows, Unix, and Linux systems.
One drawback to this approach is that it does not reach the entire enterprise (i.e., some systems such as RACF cannot “join” AD). It also elevates AD to a higher level in the enterprise, which may be an issue for some Unix/Linux purists or organizations with a prejudice against Microsoft technology.
Can you explain the idea behind Active Directory bridge products? What are the benefits and drawbacks of such products?
Active Directory bridge products fundamentally enable Unix/Linux systems (including Macs and a number of standards-based applications) to become “full citizens” in Active Directory. This means that identities in Unix/Linux can be entirely eliminated and only the single account in AD is required for access to all AD-joined Unix/Linux systems. At their very core, AD bridge products “Kerberize” Unix/Linux systems to enable those systems to participate in the AD “trusted realm” just like Windows clients.
The many benefits of Active Directory bridge products include single sign-on; secure Kerberos authentication; directory and identity consolidation; group policy for Unix/Linux; the extension of AD security principles to Unix/Linux; and NIS migration and enhanced security.
On the downside, you have identity reconciliation, which is not really a drawback – it’s the right thing to do but may be difficult to achieve. It also requires reliance on Microsoft technology (the technology is really good, but, if you don’t like Microsoft, that may be a problem), and there is confusion among the AD bridge vendors on the right way to do it.
What makes these AD bridge solutions different from the native tools available through OS providers and open source options?
The big differentiator between an AD bridge solution and native offerings or an open source solution is the enterprise-ready capabilities of the AD bridge solutions. Key differentiators available from the vendors include group policy for Unix/Linux; single-solution support for multiple Unix/Linux versions, vendors, and releases; auditing and reporting; deployment, configuration, and management tools; commercial support; and integration with expanded IAM offerings such as root delegation, strong authentication and provisioning.
With such a fundamental shift in IAM strategy with an AD bridge solution, what are some of the things organizations should look out for?
They should look for a solution that works in their environment (i.e., has been successfully deployed at an organization of equal size and complexity), and addresses short-term goals such as improving password policy, while delivering on long-term best practices such as identity reconciliation. A good solution also should include all of the management tools and flexibility necessary to address all of the organization’s needs; provide a path from current state to ideal end-state; and come from a stable vendor that will be around for the long-haul.
How is this different from more “traditional” solutions (such as a metadirectory and synchronization)?
“Traditional” solutions generally attempt to address the IAM challenges of Unix/Linux systems by adding more infrastructure and synchronizing all the disparate Unix/Linux identities and systems with a metadirectory. Generally, the custom work required to build the necessary connectors is extremely expensive, very time-consuming, and often limited by budget and technology constraints. In addition, the underlying problem of multiple, disparate identities is not addressed but simply covered by more complexity and more infrastructure.
Can you give some examples of where and how AD bridge technologies are used in the real world?
A U.S.-based bank was spending more than $1 million a month on password resets alone, as retail tellers had 18 separate passwords required to do their job. Sixteen of those passwords were for Unix systems. By implementing an AD bridge solution, the bank was able to reduce teller passwords from 18 down to two, and cut the help desk burden accordingly.
In another example, a government agency estimates that it will save $45 million in 2010 simply because Unix/Linux provisioning and password management can now be addressed through a single AD account rather than multiple local Unix/Linux accounts.
A couple of additional examples include an insurance company that was able to address compliance concerns with its NIS infrastructure by migrating all Unix identity information to AD and enforcing AD-based security policy on the full range of Unix/Linux systems, and an international food company that wanted to streamline its management burden with a large IAM framework. By implementing an AD bridge solution, the food company was able to dramatically streamline IAM, eliminate thousands of dedicated Unix/Linux synchronization connectors, and implement AD-based single sign-on for its large SAP environment.
What does Quest offer for Unix/Linux IAM?
Quest Authentication Services offers AD bridge technology, and also includes comprehensive audit, alerting, and change tracking of Unix identity information stored in AD. It also provides strong authentication for the entire range of Unix/Linux platforms, optimized enterprise group policy, and full flexibility in deployment and migration.
Quest Privilege Manager for Unix offers delegation and auditing of the Unix/Linux root account for granular control over who can do what, and full visibility into what they do with their rights. Quest Identity Manager for Unix is a free tool that provides centralized management and reporting on local Unix/Linux users and groups, as well as readiness assessment for AD bridge technology. Finally, Quest Defender offers one-time password (OTP) authentication for the full range of Unix/Linux systems supported by Quest Authentication Services.