- Subscribe to RSS Feed
- Mark Question as New
- Mark Question as Read
- Float this Question for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
The application won't work without a running HiveServer2 and Access denied erors after enabling LDAP
- Labels:
-
Apache Hive
-
Cloudera Hue
Created on ‎09-05-2018 12:35 AM - edited ‎09-16-2022 06:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cloudera Express 5.9.3
Hue 3.11
Sentry is enabled, admin groups are added to Admin Groups and admin users are added into Allowed Connecting Users in the Setry configuration.
SSSD is enabled on the servers, this means that users exist only in LDAP, but can log in into OS using their LDAP credentials. Admin users accounts exist in servers OS and match admin users accounts made in LDAP (and also match admin users accounts in Hue).
System account such as hue, hive, cloudera-scm etc aslo made in LDAP.
After enabling LDAP for Hue adn Hive I recieve errors
Potential misconfiguration detected. Fix and restart Hue.
Hive | The application won't work without a running HiveServer2. |
When trying to enter Security - Hive tables an error Access denied to user occure.
Query Editors- Hive Bad status: 3 (PLAIN auth failed: LDAP Authentication failed for user) (code THRIFTTRANSPORT): TTransportException('Bad status: 3 (PLAIN auth failed: LDAP Authentication failed for user)',)
Hive log:
org.apache.thrift.transport.TTransportException: PLAIN auth failed: LDAP Authentication failed for user
I have tried all the advices, posted here, nothing helped.
Created ‎10-09-2018 11:19 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Long journey, so I hope this does the trick.
While not exposed in Cloudera Manager, you can identify an alternative userid attribute. By default, for posix objecdts, the default is memberUid (which won't work for you unless memberUid contains the numeric id).
Try this:
- In Cloudera Manager, navigate to:
Clusters --> HDFS --> Configuration
- Search for:
Cluster-wide Advanced Configuration Snippet (Safety Valve) for core-site.xml
- Add the following:
Name: hadoop.security.group.mapping.ldap.posix.attr.uid.name
Value: uid
- Save
- Restart the cluster (so the servers can detect the new settings)
BACKGROUND:
As you observed, by default HDFS assumes that the memberUid attribute will have a value of the uidNumber of the user account. The configuration I mentioned above lets you adjust this so that rather than searching for "memberUid=1004" the search will contain "uid=maslova"
You can find more information here:
This is the description:
"The attribute of posixAccount to use when groups for membership. Mostly useful for schemas wherein groups have memberUids that use an attribute other than uidNumber."
As you can see, the configuration for hdfs meets the needs of your situation.
Cheers,
Ben
Created ‎10-09-2018 11:24 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the mistake... I meant that now with the suggested change, the resulting group lookup filter will be:
(&(objectClass=posixGroup)(|(gidNumber=1004)(memberUid=maslova)))
This is because the hadoop.security.group.mapping.ldap.posix.attr.uid.name property tells ldapgroupmapping which user attribute to use to obtain the value for group lookup. In your LDAP config that is "uid"
Created ‎10-09-2018 11:19 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Long journey, so I hope this does the trick.
While not exposed in Cloudera Manager, you can identify an alternative userid attribute. By default, for posix objecdts, the default is memberUid (which won't work for you unless memberUid contains the numeric id).
Try this:
- In Cloudera Manager, navigate to:
Clusters --> HDFS --> Configuration
- Search for:
Cluster-wide Advanced Configuration Snippet (Safety Valve) for core-site.xml
- Add the following:
Name: hadoop.security.group.mapping.ldap.posix.attr.uid.name
Value: uid
- Save
- Restart the cluster (so the servers can detect the new settings)
BACKGROUND:
As you observed, by default HDFS assumes that the memberUid attribute will have a value of the uidNumber of the user account. The configuration I mentioned above lets you adjust this so that rather than searching for "memberUid=1004" the search will contain "uid=maslova"
You can find more information here:
This is the description:
"The attribute of posixAccount to use when groups for membership. Mostly useful for schemas wherein groups have memberUids that use an attribute other than uidNumber."
As you can see, the configuration for hdfs meets the needs of your situation.
Cheers,
Ben
Created ‎10-09-2018 11:24 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the mistake... I meant that now with the suggested change, the resulting group lookup filter will be:
(&(objectClass=posixGroup)(|(gidNumber=1004)(memberUid=maslova)))
This is because the hadoop.security.group.mapping.ldap.posix.attr.uid.name property tells ldapgroupmapping which user attribute to use to obtain the value for group lookup. In your LDAP config that is "uid"

- « Previous
- Next »