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
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
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.
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
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