Created 09-07-2018 02:27 PM
In my environment, because of some constraints AD Integration on OS is not allowed.
Can I use Ranger group policies in this case?
Note: Ranger group policies fail in case AD integration on OS is not done via SSSD or other source.
Created 09-07-2018 05:41 PM
You should be able to use ranger group policies in this scenario..., are your end users using any edge nodes to access the HDP environment? they would still need to kinit (which would require AD credentials) on those edge nodes, so the local host account may not be AD authorized but access into any HDP service would be
Created 09-07-2018 05:54 PM
I mean, users perform analysis using Zeppelin tool only. Servers on OS level are not integrated with AD.
Created 09-07-2018 06:38 PM
Then yes, that is supported as far as I'm aware
Created 09-07-2018 05:45 PM
@rtheron. We are not using Kerberos and they use only zeppelin.
Created 09-07-2018 10:46 PM
Working Shiro.ini for my AD.COM domain, I have scrambled sensitive data, you can use it as if after substituting values to match your AD domain admin user/password and valid ldapsearch for your users and groups
See attached shiro.ini
I commented out under [users] all local accounts so authentication is through AD, and in the last part under [urls] I commented everything except /**=authc which compels to logins to be authenticated by AD
Created 09-07-2018 11:03 PM
Thanks for your time. My primary question is "Is OS integration with AD is mandatory for group policies in Ranger to work?"
Created 09-10-2018 06:22 PM
Ranger user/group policies work as long as the user/group name that hadoop is requesting authorization for (in general it is the hdfs groups from hadoop) should be available in Ranger with case sensitivity. It doesn't matter where hadoop or ranger is pulling these users or groups from.
Created 09-10-2018 06:26 PM
I did two test cases -
Test case1: OS is integrated with AD using SSSD and group policy worked.
Test Case2: OS is not integrated with AD ( id <username> ) does not give any user details and hdfs groups <username> does not give user details and in this case group policy failed, but if I attach the policy to user then it worked.
Why this difference?
Created 09-10-2018 06:45 PM
For authorization in ranger to work, the prerequisite is that hadoop and Ranger user group mapping should be in sync. During authorization in Ranger, each component, like hdfs, sends username and groupnames (groupnames are the ones that are returned from hdfs groups) to ranger. Ranger then evaluates the configured policies for either or both username and groupnames and responds with allow or deny.
In the test case2, if hdfs groups doesn't return the groups properly, then ranger won't get the groupnames as part of the authorization request and hence fails to find the matching policy. You can verify this in ranger audit logs as well as enabling debug logs for ranger in hdfs component.
Hope this helps.
Created 09-10-2018 06:33 PM
This would depend on your Ranger configuration, your Group dn and membership/member of attribute need to be correct for your AD setup, try testing your configuration using ldap search commands with the parameters you've configured to ensure you are getting the proper membership response from your config
Created 09-10-2018 06:36 PM
ldapsearch command does not work on server via command.
Created 09-10-2018 06:38 PM
Install ldap utils via yum (you may need to Google or check whatprovides ldapsearch, I think it's ldaputils), or you can test it from another server that does have ldapsearch installed. If you're not familiar with the ldapsearch syntax you will have to do a bit of research on how to structure the group membership filter correctly
Created 09-10-2018 06:43 PM
Thanks I will try that.
Any idea on question related to two test cases, above?
Created 09-10-2018 06:50 PM
@spolavarapu....thanks your explanation on hdfs groups helped me. Thanks.