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.
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
I mean, users perform analysis using Zeppelin tool only. Servers on OS level are not integrated with AD.
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
Thanks for your time. My primary question is "Is OS integration with AD is mandatory for group policies in Ranger to work?"
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.
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?
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.