You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Sailaja Polavarapu (JIRA)" <ji...@apache.org> on 2016/04/27 20:19:12 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15260652#comment-15260652 ]
Sailaja Polavarapu commented on RANGER-956:
-------------------------------------------
Ranger Usersync has set of properties that can be configured to retrieve user & group details from AD. One of the property is "ranger.usersync.group.nameattribute". This property specifies which attribute of AD group to be used for group name in the ranger DB. For example if "ranger.usersync.group.nameattribute" is set to "DN", then the value that is retrieved from AD for group name is the value of the "DN" attribute.
When group search is not enabled, we get the group name from memberof attribute in which case we are generating short name of the group. In this case we know that in general memberof attribute contains full dn and hence we generate the short name
But when group search is enabled, then we are using the value retrieved from group name attribute as is.
> 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)