Configuring External Authentication for Cloudera Manager

1. Log in to Cloudera Manager Admin Console.
2. Select Administration > Settings.
3. Select External Authentication for the Category filter to display the settings.
4. For Authentication Backend Order, select the order in which Cloudera Manager should look up authentication credentials for login attempts.
5. For External Authentication Type, select Active Directory.
6. In the LDAP URL property, provide the URL of the Active Directory server.
7. In the Active Directory Domain property, provide the domain to authenticate against.

   LDAP URL and Active Directory are the only settings required to allow anyone in Active Directory to log in to Cloudera Manager.

   For example, if you set LDAP URL to ldap://adserver.example.com and the Active Directory Domain to ADREALM.EXAMPLE.COM, users can log into Cloudera Manager using just their username, such as sampleuser. They no longer require the complete string: sampleuser@ADREALM.EXAMPLE.COM.

8. In the LDAP User Groups property, optionally provide a comma-separated list of case-sensitive LDAP group names. If this list is provided, only users who are members of one or more of the groups in the list will be allowed to log into Cloudera Manager. If this property is left empty, all authenticated LDAP users will be able to log into Cloudera Manager. For example, if there is a group called CN=ClouderaManagerUsers,OU=Groups,DC=corp,DC=com, add the group name ClouderaManagerUsers to the LDAP User Groups list to allow members of that group to log in to Cloudera Manager.
9. To automatically assign a role to users when they log in, provide a comma-separated list of LDAP group names in the following properties:
   • LDAP Full Administrator Groups
   • LDAP User Administrator Groups
   • LDAP Cluster Administrator Groups
   • LDAP BDR Administrator Groups
   • LDAP Configurator Groups
   • LDAP Key Administrator Groups
   • LDAP Navigator Administrator Groups
   • LDAP Operator Groups
   • LDAP Limited Operator Groups
   • LDAP Auditor Groups
   • LDAP Dashboard Groups
   If you specify groups in these properties, users must also be a member of at least one of the groups specified in the LDAP User Groups property or they will not be allowed to log in. If these properties are left empty, users will be assigned to the Read-Only role and any other role assignment must be performed manually by an Administrator.
10. Restart the Cloudera Manager Server.

1. Log in to Cloudera Manager Admin Console.
2. Select Administration > Settings.
3. Select External Authentication for the Category filter to display the settings.
4. For Authentication Backend Order, select the order in which Cloudera Manager should look up authentication credentials for login attempts.
5. For External Authentication Type, select LDAP.
6. In the LDAP URL property, provide the URL of the LDAP server and (optionally) the base Distinguished Name (DN) (the search base) as part of the URL — for example ldap://ldap-server.corp.com/dc=corp,dc=com.
7. If your server does not allow anonymous binding, provide the user DN and password to be used to bind to the directory. These are the LDAP Bind User Distinguished Name and LDAP Bind Password properties. By default, Cloudera Manager assumes anonymous binding.
8. Use one of the following methods to search for users and groups:
   • You can search using User or Group search filters, using the LDAP User Search Base, LDAP User Search Filter, LDAP Group Search Base and LDAP Group Search Filter settings. These allow you to combine a base DN with a search filter to allow a greater range of search targets.

     For example, if you want to authenticate users who may be in one of multiple OUs, the search filter mechanism will allow this. You can specify the User Search Base DN as dc=corp,dc=com and the user search filter as uid={0}. Then Cloudera Manager will search for the user anywhere in the tree starting from the Base DN. Suppose you have two OUs—ou=Engineering and ou=Operations—Cloudera Manager will find User "foo" if it exists in either of these OUs, that is, uid=foo,ou=Engineering,dc=corp,dc=com or uid=foo,ou=Operations,dc=corp,dc=com.

     You can use a user search filter along with a DN pattern, so that the search filter provides a fallback if the DN pattern search fails.

     The Groups filters let you search to determine if a DN or username is a member of a target group. In this case, the filter you provide can be something like member={0} where {0} will be replaced with the DN of the user you are authenticating. For a filter requiring the username, {1} may be used, as memberUid={1}. This will return a list of groups the user belongs to, which will be compared to the list in the group properties discussed in step 8 of Configuring Authentication Using Active Directory.

     OR

   • Alternatively, specify a single base Distinguished Name (DN) and then provide a "Distinguished Name Pattern" in the LDAP Distinguished Name Pattern property.

     Use {0} in the pattern to indicate where the username should go. For example, to search for a distinguished name where the uid attribute is the username, you might provide a pattern similar to uid={0},ou=People,dc=corp,dc=com. Cloudera Manager substitutes the name provided at login into this pattern and performs a search for that specific user. So if a user provides the username "foo" at the Cloudera Manager login page, Cloudera Manager will search for the DN uid=foo,ou=People,dc=corp,dc=com.

     If you provided a base DN along with the URL, the pattern only needs to specify the rest of the DN pattern. For example, if the URL you provide is ldap://ldap-server.corp.com/dc=corp,dc=com, and the pattern is uid={0},ou=People, then the search DN will be uid=foo,ou=People,dc=corp,dc=com.

9. Restart the Cloudera Manager Server.

Cloudera Manager supports the Security Assertion Markup Language (SAML), an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider (IDP) and a service provider (SP). The SAML specification defines three roles: the principal (typically a user), the IDP, and the SP. In the use case addressed by SAML, the principal (user agent) requests a service from the service provider. The service provider requests and obtains an identity assertion from the IDP. On the basis of this assertion, the SP can make an access control decision—in other words it can decide whether to perform some service for the connected principal.

The primary SAML use case is called web browser single sign-on (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML SP. The SP, wanting to know the identity of the requesting user, issues an authentication request to a SAML IDP through the user agent. In the context of this terminology, Cloudera Manager operates as a SP. This topic discusses the Cloudera Manager part of the configuration process; it assumes that you are familiar with SAML and SAML configuration in a general sense, and that you have a functioning IDP already deployed.