Impersonation Error while trying to access Ambari Views

[#1]

We are running into an impersonation error while trying to access Ambari Views.

500 User root is not allowed to impersonate admin or ldap user

Here’s the background:

HDP 2.3 installed via Ambari 2.1.

• Ambari setup to authenticate against LDAP
• Files view setup according to docs.hortonworks.com
• LDAP user is granted permission to Files view in Ambari
• LDAP user logs into Ambari and sees the View listed.
• LDAP user clicks on the view and receives the error.
• Ensured that Ambari is running as root.

I have successfully achieved this functionality locally on a virtual box cluster using HDP 2.2. In my setup, I do not find it necessary to create OS or HDFS users to use the views.

I did check the ambari-server logs, but there was only an error indicating the server 500 error. Nothing regarding an ldap or permissions error.

Any ideas or guidance on how to solve this is much appreciated.

[#2]

You need to create the proxy settings for 'root', since Ambari runs as root. This allows it to impersonate the user in hdfs.

hadoop.proxyuser.root.groups=*

hadoop.proxyuser.root.hosts=*

You'll also need to create the 'admin' user home directory in hdfs for Admin, if you haven't already done that. Since you're signed into Ambari as Admin, your jobs will be submitted/passed through as that user.

[#3]

Please note that one should never use * for these settings.

hosts= should be set to that of the Ambari Server groups= should only be the groups which Ambari (running as root) is allowed to impersonate.

[#4 · Accepted solution]

Make sure you're following the configuration steps outlined in this doc to set the appropriate stack settings as @gvetticaden@hortonworks.com and @dstreever@hortonworks.com recommended, and tune Ambari Server appropriately.

http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.1.0/bk_ambari_views_guide/content/ch_using_ambar...

[#5]

Impersonation is a key concept throughout the Hadoop ecosystem.

Impersonation grants a user (also known as a SuperUser or ProxyUser) right to access Hadoop user is granted on behalf of other users. It's similar to the idea of 'sudo' within Linux.

To enable it you set the 'proxyuser' setting based on the user the service is running as, the groups or users you want it to be able to act on behalf of, and the hosts it should be able to do that from.

For example, for Ambari Views with:

• Ambari running as the user 'root' (which is the default)
• Wanting to allow Ambari to act on behalf of users in the groups 'users', 'hive-users' (just an example as you may have similar groups in LDAP)
• Ambari hostname of 'ambarihost.domain.local'

You would set this in 'HDFS -> core-site' from Ambari:

hadoop.proxyuser.root.groups=users,hive-users
hadoop.proxyuser.root.hosts=ambarihost.domain.local

More detail is available in the documentation:

• Apache Hadoop: Proxy user - Superusers Acting On Behalf Of Other Users
• Apache Oozie: User ProxyUser Configuration
• Apache YARN: yarn-site
  • yarn.resourcemanager.webapp.proxyuser.USERNAME.groups
  • yarn.resourcemanager.webapp.proxyuser.USERNAME.hosts

[#6]

@Matt Carter just a bump to confirm if one of these answers worked, or reply to them for clarification.

[#7]

@Sean Roberts

Want to understand the impersonation configuration better. The problem is that it is not clear what is impersonating what. For example, when trying to access the Hive view as an admin user failed with "User: hive is not allowed to impersonate user admin". So, by extension, it would seem logical that we introduce another proxy variables hadoop.proxyuser.hive.groups & hosts, but what is the group that the hive user needs? Is that information available in the stack trace?

Is there a diagram of the view services that maps out the impersonation and user attributes in play?