Configuring Ambari to authenticate external users

By default, Ambari uses an internal database as the user store for authentication and authorization. You can configure Ambari to authenticate external users stored in LDAP, Active Directory (AD), or FreeIPA datastores.

For each case, you must run the ambari-server setup-ldap command line utility on the Ambari host, and be prepared to provide information for each prompt described in the following table. Generally, you will run this cli utility and provide values appropriate for your environment and external user datastore. The wizard sets default configuration values appropriate for the LDAP type you select. You must then customize the default configuration values to optimize or tune your environment.

On the Ambari Server host, open ambari-server setup-ldap with a command line editor.

Respond to each prompt.

Prompts marked with an asterisk (*) are required values.

Prompt	Description
Please select the type of LDAP you want to use *	Selecting a datastore type for the LDAP integration with helps Ambari provide the most appropriate default configuration values for the upcoming, default configurations. Supported options are AD, IPA and “Generic LDAP”.
Primary URL Host*	The fully qualified hostname for the LDAP server.
Primary URL Port*	The port for the LDAP server. By default, secured LDAPs runs on port 636. Unsecured LDAP runs on port 389.
Secondary URL Host	The hostname for an additional LDAP server, which should be a replica of your primary. This value is optional.
Secondary URL Port	The port for a secondary LDAP server. This value is optional.
Use SSL*	Set to true to connect to your LDAP server over a secured connection. A secured connection requires your LDAP server to present a valid certificate from a trusted CA to the Ambari server.
Do you want to provide custom TrustStore for Ambari [y/n]	If your LDAP server certificate was signed by a well-known CA, you can rely on the default java truststore to contain the public certs of those CAs. Otherwise, you must explicitly add the public certificate of the CA that signed the LDAP server’s certificate to the default java truststore on the Ambari host. Alternatively, create a custom truststore, and then use this option to configure Ambari to use it.
TrustStore type	Format of the truststore [jks/jceks/pkcs12]
Path to TrustStore	Path on the Ambari host where you placed the custom truststore that Ambari should use.
Password for TrustStore	Password for the custom truststore. Default is changeit.
User object class*	The object class you define for users.
User name attribute*	The attribute you define for username.
Group object class*	The object class you define for groups.
Group name attribute*	The attribute you define for group name.
Group member attribute*	The attribute you define for group membership.
Distinguished name attribute*	The attribute you define for the distinguished name.
Search Base*	The root search base in the directory for both users and groups.
Referral method*	Enter follow or ignore for your LDAP referrals.
Bind anonymously*	If true, bind to the LDAP server anonymously. If false, bind to the LDAP server non-anonymously.
Bind DN*:	If you set Bind anonymously to false, enter the Distinguished Name (“DN”) for the LDAP service account that can be used to search. This account should exist in LDAP and have sufficient privilege to search the directory tree, but does not require any administrative or login privileges.
Bind DN Password*:	Enter the password for your LDAP manager DN. If this password eventually expires or gets changed in the LDAP server, it should be updated here also.
Handling behavior for username collisions*:	When Ambari finds duplicate user accounts, what strategy should Ambari use. (convert/skip)
Force lower-case user names	Standardizes all username characters on lowercase, such that Admin==admin.
Results from LDAP are paginated when requested	Determines when pagination should be used when reading responses to ldapsearch operations. Generally, we recommend pagination for large Active Directory trees. You should ensure that your LDAP implementations support pagination.
Disable endpoint identification during SSL handshake.	This option is available in Ambari 2.7.3+ and can be used to bypass the newer java requirements that the certificate of the LDAP server contains the IP of the server as a SAN. Equivalent of passing in this flag on jvm startup options: `-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true`