[
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)
