You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Garima Dosi (JIRA)" <ji...@apache.org> on 2016/04/28 08:21:13 UTC
[jira] [Resolved] (RANGER-956) Ranger policies not being created on
groups pulled from AD
[ https://issues.apache.org/jira/browse/RANGER-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Garima Dosi resolved RANGER-956.
--------------------------------
Resolution: Not A Bug
This was not a bug. It was more of a configuration issue
> Ranger policies not being created on groups pulled from AD
> ----------------------------------------------------------
>
> Key: RANGER-956
> URL: https://issues.apache.org/jira/browse/RANGER-956
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
> Affects Versions: 0.5.0
> Reporter: Garima Dosi
>
> With AD user groups, it was found that Ranger policies cannot be solved although we have integrated AD with OS. The error trace is :
> ==> xa_portal.log <==
> 2016-04-27 04:05:44,156 [http-bio-6080-exec-6] ERROR org.apache.ranger.rest.ServiceREST (ServiceREST.java:1146) - updatePolicy(RangerPolicy={id={4} guid={1461692664540_532_520} isEnabled={true} createdBy={Admin} updatedBy={Admin} createTime={Tue Apr 26 17:44:24 IST 2016} updateTime={Tue Apr 26 22:34:43 IST 2016} version={28} service={service_hadoop} name={test} policyType={null} description={} resourceSignature={dd5b9b1d3a1a8cfea8e15aabcce2215a} isAuditEnabled={true} resources={path={RangerPolicyResource={values={/user/guru } isExcludes={false} isRecursive={true} }} } policyItems={RangerPolicyItem={accessTypes={RangerPolicyItemAccess={type={read} isAllowed={true} }RangerPolicyItemAccess={type={write} isAllowed={true} }} users={} groups={cn=dev ou=idc ou=zaloni dc=zalonilabs dc=com } conditions={} delegateAdmin={false} }} }) failed
> java.lang.Exception: cn=dev: group does not exist. policy='test' service='service_hadoop'
> at org.apache.ranger.biz.ServiceDBStore.createNewPolicyItemsForPolicy(ServiceDBStore.java:1871)
> at org.apache.ranger.biz.ServiceDBStore.updatePolicy(ServiceDBStore.java:1444)
> at org.apache.ranger.rest.ServiceREST.updatePolicy(ServiceREST.java:1142)
>
> 2016-04-27 10:41:12,353 [http-bio-6080-exec-1] ERROR org.apache.ranger.rest.ServiceREST (ServiceREST.java:1146) - updatePolicy(RangerPolicy={id={43} guid={1461666998918_924_525} isEnabled={true} createdBy={Admin} updatedBy={Admin} createTime={Tue Apr 26 10:36:38 IST 2016} updateTime={Tue Apr 26 14:23:04 IST 2016} version={19} service={itcluster_hadoop} name={testnew} policyType={null} description={} resourceSignature={75f8cc05bc84109b53ae5e9b934d6d58} isAuditEnabled={true} resources={path={RangerPolicyResource={values={/user/jiten } isExcludes={false} isRecursive={true} }} } policyItems={RangerPolicyItem={accessTypes={RangerPolicyItemAccess={type={read} isAllowed={true} }RangerPolicyItemAccess={type={write} isAllowed={true} }RangerPolicyItemAccess={type={execute} isAllowed={true} }} users={} groups={cn=sslvpn-users ou=idc ou=zaloni dc=zalonilabs dc=com } conditions={} delegateAdmin={false} }} }) failed
> java.lang.Exception: cn=sslvpn-users: group does not exist. policy='testnew' service='itcluster_hadoop' at org.apache.ranger.biz.ServiceDBStore.createNewPolicyItemsForPolicy(ServiceDBStore.java:1871)
> at org.apache.ranger.biz.ServiceDBStore.updatePolicy(ServiceDBStore.java:1444) at org.apache.ranger.rest.ServiceREST.updatePolicy(ServiceREST.java:1142)
> at org.apache.ranger.rest.ServiceREST$$FastClassByCGLIB$$92dab672.invoke(<generated>)
> ...
>
> However, despite having made config changes so that both OS and Hadoop now recognize AD groups, Ranger still complains that the group being used in the policy doesnt exist.
> OS knows AD Groups (configured via authconfig on all 4 cluster node i.e. Samba-winbind)
> [root@du-bedrock-n1 admin]# id someuser
> uid=16777217(someuser) gid=16777218(domain users) groups=16777218(domain users),16777220(sslvpn-users),16777225(domain controllers),16777224(dev),16777222(domain admins),16777223(denied rodc password replication group),16777217(BUILTIN\users),16777216(BUILTIN\administrators)
> [root@du-bedrock-n1 admin]# getent group | grep dev
> dev:*:16777224:someuser
> Hadoop knows AD groups
> [root@du-bedrock-n1 admin]# hdfs groups someuser
> someuser : domain users sslvpn-users domain controllers dev domain admins denied rodc password replication group BUILTIN\users BUILTIN\administrators
>
> cn=dev,ou=idc,ou=z_org,dc=z_labs,dc=com
>
> Ranger policies not being created for groups pulled from AD
>
> However, despite having made config changes so that both OS and Hadoop now recognize AD groups, Ranger still complains that the group being used in the policy doesnt exist.
> OS knows AD Groups (configured via authconfig on all 4 cluster node i.e. Samba-winbind)
> [root@du-bedrock-n1 admin]# id someuser
> uid=16777217(someuser) gid=16777218(domain users) groups=16777218(domain users),16777220(sslvpn-users),16777225(domain controllers),16777224(dev),16777222(domain admins),16777223(denied rodc password replication group),16777217(BUILTIN\users),16777216(BUILTIN\administrators)
> [root@du-bedrock-n1 admin]# getent group | grep dev
> dev:*:16777224:someuser
> Hadoop knows AD groups
> [root@du-bedrock-n1 admin]# hdfs groups someuser
> someuser : domain users sslvpn-users domain controllers dev domain admins denied rodc password replication group BUILTIN\users BUILTIN\administrators
> So, on further debugging through the source code, it was discovered that group search query that is fired is using the group name "cn=dev" and it does an exact search. However, the group_name field in x_group table for AD contain entire string like so - "cn=dev,ou=idc,ou=z_org,dc=z_labs,dc=com" and hence, the following piece of code fails to get the group from database due to which policies are not saved.
> XXGroup xGrp = daoMgr.getXXGroup().findByGroupName(group);
> if(xGrp == null) {
> throw new Exception(group + ": group does not exist. policy='"+ policy.getName() + "' service='"+ policy.getService() + "'");
> }
> As a workaround the group_name(s) entry in ranger database were modified to match the OS entry so that the database now contains dev instead of "cn=dev,ou=idc,ou=z_org,dc=z_labs,dc=com" and the policies could be saved and executed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)