Authentication is a process that requires users and services to prove their identity when trying to access a system resource. Organizations typically manage user identity and authentication through various time-tested technologies, including Lightweight Directory Access Protocol (LDAP) for identity, directory, and other services, such as group management, and Kerberos for authentication.

Cloudera clusters support integration with both of these technologies. For example, organizations with existing LDAP directory services such as Active Directory (included in Microsoft Windows Server as part of its suite of Active Directory Services) can leverage the organization's existing user accounts and group listings instead of creating new accounts throughout the cluster. Using an external system such as Active Directory or OpenLDAP is required to support the user role authorization mechanism implemented in Cloudera Navigator.

For authentication, Cloudera supports integration with MIT Kerberos and with Active Directory. Microsoft Active Directory supports Kerberos for authentication in addition to its identity management and directory functionality, that is, LDAP.

Kerberos provides strong authentication, strong meaning that cryptographic mechanisms—rather than passwords alone—are used in the exchange between requesting process and service during the authentication process.

These systems are not mutually exclusive. For example, Microsoft Active Directory is an LDAP directory service that also provides Kerberos authentication services, and Kerberos credentials can be stored and managed in an LDAP directory service. Cloudera Manager Server, CDH nodes, and Cloudera Enterprise components, such as Cloudera Navigator, Apache Hive, Hue, and Impala, can all make use of Kerberos authentication.

  Note: Cloudera does not provide a Kerberos implementation but rather can use MIT Kerberos or Microsoft Server Active Directory service and its KDC for authentication.

Configuring the cluster to use Kerberos requires having administrator privileges—and access to—the Kerberos server Key Distribution Center (KDC). The process may require debugging issues between the Cloudera Manager cluster and the KDC.

  Note: Integrating clusters to use Microsoft Active Directory as a KDC requires the Windows registry setting for AllowTgtSessionKey to be disabled (set to 0). If this registry key has already been enabled, users and credentials are not created—despite the "Successful" message at the end of the configuration/integration process. Before configuring Active Directory for use as KDC, check the value of AllowTgtSessionKey on the Active Directory instance and reset to 0 if necessary. See Registry Key to Allow Session Keys to Be Sent in Kerberos Ticket-Granting-Ticket at Microsoft for details.

On each host operating system underlying each node in a cluster, local Linux user:group accounts are created during installation of Cloudera Server and CDH services. To apply per-node authentication and authorization mechanism consistently across all the nodes of a cluster, local user:group accounts are mapped to user accounts and groups in an LDAP-compliant directory service, such as Active Directory or OpenLDAP. See Configuring LDAP Group Mappings for details.

To facilitate the authentication process from each host system (node in the cluster) to the LDAP directory, Cloudera recommends using additional software mechanisms such as SSSD (Systems Security Services Daemon) or Centrify Server Suite. See the Centrify guide Identity and Access management for Cloudera for details.

Continue reading:

• Kerberos Security Artifacts Overview
• Configuring Authentication in Cloudera Manager
• Configuring Authentication for Cloudera Navigator
• Configuring Authentication for Other Components
• Configuring a Dedicated MIT KDC for Cross-Realm Trust
• Integrating MIT Kerberos and Active Directory
• Hadoop Users (user:group) and Kerberos Principals
• Mapping Kerberos Principals to Short Names