Ambari console and AD LDAP - stanislawbartkowski/hdpactivedirectory GitHub Wiki
The Ambari console can be easily integrated with AD/LDAP, OpenLDAP or any other LDAP database. It is described in detail here:
https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.1.0/ambari-authentication-ldap-ad/content/setting_up_ldap_user_authentication.html
Below I describe several practical steps on how to accomplish it.
How to prepare and set up a Docker version of OpenLDAP is described here:
https://github.com/stanislawbartkowski/wikis/wiki/Centos---Kerberos---LDAP#install-openldap-host-with-ldaps-enabled
To scan objects in the LDAP database, it is a good practice to have read-only bind user and avoid using LDAP admin user for that purpose.
Collect all necessary information
| Prompt | Information | Example |
|---|---|---|
| Primary URL Host | The fully qualified hostname for the LDAP server | ldap.sb.com |
| Primary | The port for the LDAP server | 389 (non-secure port) |
| User object class | The object class for users | posixAccount |
| User name attribute | The attribute for username | uid (default) |
| Group object class | The object class for groups | posixGroup (default) |
| Group name attribute | The attribute for group name | cn (default) |
| Group member attribute | The attribute in group object containing member objects | memberUid (default) |
| Distinguished name attribute | The attribute for the distinguished name | dn (default) |
| Search Base | The root search base in the directory for both users and groups | dc=sb,dc=com |
| Bind DN | The Distinguished Name (âDNâ) for the LDAP service account that can be used to search. | cn=proxy,dc=sb,dc=com |
| Bind DN Password | The password of proxy user | **** |
ambari-console setup-ldap
As "type of LDAP you want to use" choose "Generic LDAP". As "Use SSL" choose "false". Provide information above or accept defaults otherwise.
Example session:
[root@mdp1 ~]# ambari-server setup-ldap
Using python /usr/bin/python
Enter Ambari Admin login: admin
Enter Ambari Admin password:
Fetching LDAP configuration from DB.
Primary LDAP Host (ldap.sb.com):
Primary LDAP Port (636): 389
Secondary LDAP Host <Optional>:
Secondary LDAP Port <Optional>:
Use SSL [true/false] (true): false
User object class (posixAccount):
User ID attribute (uid):
Group object class (posixGroup):
Group name attribute (cn):
Group member attribute (memberUid):
Distinguished name attribute (dn):
Search Base (dc=sb,dc=com):
Referral method [follow/ignore] (follow):
Bind anonymously [true/false] (false):
Bind DN (cn=proxy,dc=sb,dc=com):
Enter Bind DN Password:
Confirm Bind DN Password:
Handling behavior for username collisions [convert/skip] for LDAP sync (skip):
Force lower-case user names [true/false]:
Results from LDAP are paginated when requested [true/false]:Unlike Linux, the group memebership for Ambari console is not resolved by comparing gid attribute. The users belonging to the group are searched in the memberUid attribute in the group object. If more then one user belongs to the group, the memberUid attribute in the group should be replicated.
Two users, user1 and user2, belong to ldapusers group. The equivalent Ambari console view after synchronization.
The bench user doesn't belong to any group.
Collect all necessary information
| Prompt | Information | Example |
|---|---|---|
| Primary URL Host | The fully qualified hostname for the LDAP server | verse1.fyre.net |
| Primary port | The port for the LDAP server | 389 (non-secure port) |
| User object class | The object class for users | user (default) |
| User name attribute | The attribute for username | sAMAccountName (default) |
| Group object class | The object class for groups | group (default) |
| Group name attribute | The attribute for group name | cn (default) |
| Group member attribute | The attribute in group object containing member objects | member (default) |
| Distinguished name attribute | The attribute for the distinguished name | distinguishedName (default) |
| Search Base | The root search base in the directory for both users and groups | CN=centos,DC=fyre,DC=net |
| Bind DN | The Distinguished Name (âDNâ) for the LDAP service account that can be used to search. | CN=hadoopsearch,CN=centos,DC=fyre,DC=net |
| Bind DN Password | The password of proxy user | **** |
ambari-server setup-ldap
As "type of LDAP" choose AD. Provide prepared information when required and accept defaults otherwise.
Sample session:
Currently 'no auth method' is configured, do you wish to use LDAP instead [y/n] (y)? y
Enter Ambari Admin login: admin
Enter Ambari Admin password:
Fetching LDAP configuration from DB. No configuration.
Please select the type of LDAP you want to use [AD/IPA/Generic](Generic):AD
Primary LDAP Host: verse1.fyre.net
Primary LDAP Port: 389
Secondary LDAP Host <Optional>:
Secondary LDAP Port <Optional>:
Use SSL [true/false] (false):
User object class (user):
User ID attribute (sAMAccountName):
Group object class (group):
Group name attribute (cn):
Group member attribute (member):
Distinguished name attribute (distinguishedName):
Search Base (dc=ambari,dc=apache,dc=org): CN=centos,DC=fyre,DC=net
Referral method [follow/ignore] (follow):
Bind anonymously [true/false] (false):
Bind DN (cn=ldapbind,dc=ambari,dc=apache,dc=org): CN=hadoopsearch,CN=centos,DC=fyre,DC=net
Enter Bind DN Password:
Confirm Bind DN Password:
Handling behavior for username collisions [convert/skip] for LDAP sync (skip):
Force lower-case user names [true/false]:
Results from LDAP are paginated when requested [true/false]:Firstly a secure LDAP connection with AD should be established. More details: https://github.com/stanislawbartkowski/wikis/wiki/HDP-2.6.5-3.1-and-Active-Directory#configure-secure-ldap-connection-between-ambari-host-and-active-directory
The same as above with several additional points:
| Prompt | Information | Example |
|---|---|---|
| Primary port | The secure port for the LDAP server | 635 (secure port) |
| Path to TrustStore | Filename of the truststore where AD certificate has been imported | /etc/openldap/truststore.jks |
| Password for TrustStore | Password to open trusttore | **** |
Answer "true" for "Use SSL" and provide information related to truststore.
Sample session:
Using python /usr/bin/python
Enter Ambari Admin login: admin
Enter Ambari Admin password:
Fetching LDAP configuration from DB.
Primary LDAP Host (verse1.fyre.net):
Primary LDAP Port (389): 636
Secondary LDAP Host <Optional>:
Secondary LDAP Port <Optional>:
Use SSL [true/false] (false): true
Disable endpoint identification during SSL handshake [true/false] (False):
Do you want to provide custom TrustStore for Ambari [y/n] (y)?n
The TrustStore is already configured:
ssl.trustStore.type = jks
ssl.trustStore.path = /etc/openldap/truststore.jks
ssl.trustStore.password = secret
Do you want to remove these properties [y/n] (y)? n
User object class (user):
User ID attribute (sAMAccountName):
Group object class (group):
Group name attribute (cn):
Group member attribute (member):
Distinguished name attribute (distinguishedName):
Search Base (CN=centos,DC=fyre,DC=net):
Referral method [follow/ignore] (follow):
Bind anonymously [true/false] (false):
Bind DN (CN=hadoopsearch,CN=centos,DC=fyre,DC=net):
Enter Bind DN Password:
Confirm Bind DN Password:
Handling behavior for username collisions [convert/skip] for LDAP sync (skip):
Force lower-case user names [true/false]:
Results from LDAP are paginated when requested [true/false]:The user are synchronized on demand by running the command:
ambari-server sync-ldap /parameters/
More details: https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.1.0/ambari-authentication-ldap-ad/content/authe_ldapad_synchronizing_ldap_users_and_groups.html
There is no single synchronization strategy.
If LDAP database is small and managed by Ambari administrator then --all strategy is enough.
In the case of an enterprise Active Directory or LDAP server, it is not recommended approach. Hundreds, or thousands of users, the majority of them having nothing in common with Hadoop cluster will be imported into Ambari console which is not appropriate.
One method is to create a separate container in AD/LDAP and use container DN as Search Base for synchronization and limiting the number of users eligible for synchronization.
Another method is to use --users or --groups parameter. For instance, create a separate group, ambariusers and use --groups option. Only users belonging to the ambariusers group would be imported.
The file should contain a comma-separated list of users/groups.
Example:
vi g.txt
dataadmin
ambari-server sync-ldap --groups g.txt
Using python /usr/bin/python
Syncing with LDAP...
Enter Ambari Admin login: admin
Enter Ambari Admin password:
Fetching LDAP configuration from DB.
Syncing specified users and groups...
Completed LDAP Sync.
Summary:
memberships:
removed = 0
created = 1
users:
skipped = 0
removed = 0
updated = 0
created = 1
groups:
updated = 0
removed = 0
created = 0
Ambari Server 'sync-ldap' completed successfully.
Only group datadmin is touched and the only users belonging to this group are imported. All other users or users not belonging to any group are ignored.
Users can be removed by means of Ambari REST/API. Command:
curl --insecure -u admin:$PASSWORD -H 'X-Requested-By: ambari' -X DELETE http://$AMBARI_HOST:8080/api/v1/users/$USER_NAME
Example:
curl --insecure -u admin:admin -H 'X-Requested-By: ambari' -X DELETE http://hurds1:8080/api/v1/users/sb
Syncing specified users and groups.ERROR: Exiting with exit code 1.
REASON: Sync event creation failed. Error details: hostname '127.0.0.1' doesn't match either of
https://community.hortonworks.com/questions/119756/ambari-server-sync-ldap-no-longer-working.html