Ranger Group Permissions issue - AD and SSSD

[#1]

Having an issue with applying Ranger policy permissions through groups. I see that there are several questions on this. I am having the same basic issue--Policies get applied when user is specified, but not using a group. I have gone through all of the debugging steps suggested in the questions, but still having issues.

SSSD - We do have this running and are able to see the groups (note: NN, HS2, and Ranger are all on this same host)

$ hdfs groups batyr_amp_admin
batyr_amp_admin : domain users batyr_amp_admins

$ id batyr_amp_admin
uid=1080619417(batyr_amp_admin) gid=1080600513(domain users) groups=1080600513(domain users),1080619409(batyr_amp_admins)

QUESTION: If SSSD is running, do you ALSO have to setup the core-site.mapping?

From Hiveserver2.log

2016-10-07 09:46:55,322 WARN  [HiveServer2-Handler-Pool: Thread-5841]: thrift.ThriftCLIService (ThriftCLIService.java:ExecuteStatement(512)) - Error executing statement: 
org.apache.hive.service.cli.HiveSQLException: Error while compiling statement: FAILED: HiveAccessControlException Permission denied: user [batyr_amp_admin] does not have [USE] privilege on [amp_land]
at org.apache.hive.service.cli.operation.Operation.toSQLException(Operation.java:335)
at org.apache.hive.service.cli.operation.SQLOperation.prepare(SQLOperation.java:148)
at org.apache.hive.service.cli.operation.SQLOperation.runInternal(SQLOperation.java:226)
at org.apache.hive.service.cli.operation.Operation.run(Operation.java:276)
at org.apache.hive.service.cli.session.HiveSessionImpl.executeStatementInternal(HiveSessionImpl.java:468)
at org.apache.hive.service.cli.session.HiveSessionImpl.executeStatementAsync(HiveSessionImpl.java:456)
at org.apache.hive.service.cli.CLIService.executeStatementAsync(CLIService.java:298)
at org.apache.hive.service.cli.thrift.ThriftCLIService.ExecuteStatement(ThriftCLIService.java:506)
at org.apache.hive.service.cli.thrift.TCLIService$Processor$ExecuteStatement.getResult(TCLIService.java:1317)
at org.apache.hive.service.cli.thrift.TCLIService$Processor$ExecuteStatement.getResult(TCLIService.java:1302)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingProcessor.process(HadoopThriftAuthBridge.java:562)
at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:286)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.hadoop.hive.ql.security.authorization.plugin.HiveAccessControlException: Permission denied: user [batyr_amp_admin] does not have [USE] privilege on [amp_land]
at org.apache.ranger.authorization.hive.authorizer.RangerHiveAuthorizer.checkPrivileges(RangerHiveAuthorizer.java:412)
at org.apache.hadoop.hive.ql.Driver.doAuthorizationV2(Driver.java:855)
at org.apache.hadoop.hive.ql.Driver.doAuthorization(Driver.java:643)
at org.apache.hadoop.hive.ql.Driver.compile(Driver.java:510)
at org.apache.hadoop.hive.ql.Driver.compile(Driver.java:320)
at org.apache.hadoop.hive.ql.Driver.compileInternal(Driver.java:1219)
at org.apache.hadoop.hive.ql.Driver.compileAndRespond(Driver.java:1213)
at org.apache.hive.service.cli.operation.SQLOperation.prepare(SQLOperation.java:146)
... 15 more

[#2]

@jbarnett

To answer your question - no, if you have SSSD configured you do not need to also configure core-site mapping with LDAP.

Regarding your issue, it could be related to the space in your group name - could you try remove the space in the 'domain users' or test with a group that doesn't contain any spaces.

[#3]

'domain users' is one of the groups that all users are associated with. However, it is NOT the one we are using for the policy. That group is 'batyr_amp_admins' (underscores and no spaces.) Would this still be an issue?

[#4]

I don't think underscores will present an issue. Do you see any errors in the component logs?

[#5]

See snippet from HS2 log added to main question.

[#6]

Is the group sync'd in ranger same case as hdfs groups? As you might already know the policy resolution in Ranger is case sensitive.

[#7]

In Ranger, group name is 'BATYR_AMP_ADMINS' (both under groups and when added to policy)

It is uppercase in Active Directory, and shows uppercase in the usersync.log

ranger.usersync.ldap.groupname.caseconversion=none

HOWEVER,

As you can see in the main question, the hdfs groups command and linux id command show lowercase.

Is this expected behaviour?

[#8 · Accepted solution]

When SSSD is configured, the request that comes to ranger will have the same case as the hdfs groups and this should match the one that is stored in ranger DB. But looks like ranger DB has upper case as that is sync'd from AD with case conversion as none. In this case the behavior seen above is expected behavior. Can you please set case conversion to "lower" and try?

[#9]

WINNER! That did the trick.

• Changed

ranger.usersync.ldap.username.caseconversion=lower

ranger.usersync.ldap.groupname.caseconversion=lower

• Restarted Ranger (which performs usersync)
• All group names are now lowercase in both Ranger and HDFS

[#10]

I have a similar issue in our environmet: we are thinking to usersync ranger with AD. below is the issue I have:

AD group name: cfyG_GG-HDP_HadoopAdmins

SSD mapped group on linux machine: hadoopadmin

This command yields $hdfs groups hdpadmin

hdpadmin : hdpadmin hadoopadmin hadoopdev hadoopusers

------------------

Now the problem is I can save the AD group to lower case in ranger as : cfyg_gg-hdp-hadoopadmins

but, if I use this group to give permission it wont work, since the linux group name is hadoopadmin, as mapped in SSSD. How can I over come this issue?

any help is appreciated.

Suri