[jira] [Created] (RANGER-4757) Use Ranger roles similar to RBAC for administering Ranger APIs instead of role assignment rules
Sailaja Polavarapu created RANGER-4757: -- Summary: Use Ranger roles similar to RBAC for administering Ranger APIs instead of role assignment rules Key: RANGER-4757 URL: https://issues.apache.org/jira/browse/RANGER-4757 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Sailaja Polavarapu Currently users accessing/administering Ranger requires special privileges like ROLE_USER, ROLE_SYS_ADMIN, ROLE_KEY_ADMIN, ROLE_ADMIN_AUDITOR, or ROLE_KEY_ADMIN_AUDITOR. These roles are assigned to the user based on role assignment rules by Ranger Usersync process while syncing the users and groups from the sync source. This creates major overhead on Ranger User sync to compute the roles every time a group memberships are updated as well on Ranger admin to update the database to reflect the roles for each user. As part of RANGER-2414, we introduced support for Role based authorization for plugins which basically checks the user/group in the authorization request is part of a role and uses that role information for authorization. Proposal: -- Create default special roles (ROLE_USER, ROLE_SYS_ADMIN, ROLE_KEY_ADMIN, ROLE_ADMIN_AUDITOR, or ROLE_KEY_ADMIN_AUDITOR) in Ranger DB as part of the setup and add default admin, rangerusersync, rangertagsync, and keyadmin users to the corresponding roles. Similar to plugin role computation, when a user is accessing any Ranger API, get the groups that this user belongs to (from ranger DB) and check if the user/group is part of any of these special roles to authorize these APIs. Pros: 1. Role of a user is computed at the time of API access which in some cases can be dynamic 2. Reduces performance overhead on Ranger Usersync and Ranger Admin 3. Uniform user experience for Ranger APIs authorization as well as data authorization 4. Avoids inconsistency of setting a specific role for a user via Ranger UI and thru role assignment rules. 5. Can consolidate few DB tables that currently saves role information for a user Cons: 1. Requires decent amount of code changes 2. Regression testing impact 3. Migrating role assignment rules to Roles as part of upgrade -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4026) Provide option to update group memberships when same users/groups are synced from different sync sources
Sailaja Polavarapu created RANGER-4026: -- Summary: Provide option to update group memberships when same users/groups are synced from different sync sources Key: RANGER-4026 URL: https://issues.apache.org/jira/browse/RANGER-4026 Project: Ranger Issue Type: Improvement Components: usersync Reporter: Sailaja Polavarapu RANGER-3254 implemented a change in user/group mapping so that sync source is taken into account when a group name matches multiple sources. LDAP users belonging to a group like "CN=mygroup" will not be synced in Ranger if there is an existing "mygroup" that was imported by UnixUserGroupBuilder. This breaks a very common use case where posix users and groups are synced to the OS from an LDAP backend using SSSD, Centrify, or similar utilities. In those cases, both the linux OS and LDAP/AD are using the same identity repository. If Ranger imported a set of users and groups from one sync source, and then later switches to another, group mappings break and users don't get all of their groups. Provide an option for customers to treat users/groups from multiple sync sources as same for updating group memberships. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4026) Provide option to update group memberships when same users/groups are synced from different sync sources
[ https://issues.apache.org/jira/browse/RANGER-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-4026: -- Assignee: Sailaja Polavarapu > Provide option to update group memberships when same users/groups are synced > from different sync sources > > > Key: RANGER-4026 > URL: https://issues.apache.org/jira/browse/RANGER-4026 > Project: Ranger > Issue Type: Improvement > Components: usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > RANGER-3254 implemented a change in user/group mapping so that sync source is > taken into account when a group name matches multiple sources. LDAP users > belonging to a group like "CN=mygroup" will not be synced in Ranger if there > is an existing "mygroup" that was imported by UnixUserGroupBuilder. > This breaks a very common use case where posix users and groups are synced to > the OS from an LDAP backend using SSSD, Centrify, or similar utilities. In > those cases, both the linux OS and LDAP/AD are using the same identity > repository. If Ranger imported a set of users and groups from one sync > source, and then later switches to another, group mappings break and users > don't get all of their groups. > Provide an option for customers to treat users/groups from multiple sync > sources as same for updating group memberships. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3920) When sync'ing users from Ldap, intermittent User/Group/UserGroup membership is missing
[ https://issues.apache.org/jira/browse/RANGER-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607239#comment-17607239 ] Sailaja Polavarapu commented on RANGER-3920: Hi [~ankita] , This might be duplicate for RANGER-3469. Can you please check the below review request and may be merge both if needed? https://reviews.apache.org/r/73677/ > When sync'ing users from Ldap, intermittent User/Group/UserGroup membership > is missing > > > Key: RANGER-3920 > URL: https://issues.apache.org/jira/browse/RANGER-3920 > Project: Ranger > Issue Type: Bug > Components: admin, Ranger, usersync >Reporter: Ankita Sinha >Assignee: Ankita Sinha >Priority: Major > Fix For: 2.4.0 > > > Problem Statement: > Currently, Usersync sync's users/groups/usergroup in batches. In doing so, > the user/group/usergroup at the end of the batch is not sync'ed. > For example consider batch is of size 1000, so batch starts from 0-999 and > then next batch starts from 1001-1999. So in each batch one > user/group/usergroup is missing. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3387) Ranger Admin Header Validation.
[ https://issues.apache.org/jira/browse/RANGER-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17566563#comment-17566563 ] Sailaja Polavarapu edited comment on RANGER-3387 at 7/14/22 12:19 AM: -- Merged follow-up changes to master to handle requests from Knox gateway was (Author: spolavarapu): Merged changes to master. > Ranger Admin Header Validation. > --- > > Key: RANGER-3387 > URL: https://issues.apache.org/jira/browse/RANGER-3387 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Mateen N Mansoori >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3387-Added-extra-validation-for-handling-PUT-.patch, > 0001-RANGER-3387-Ranger-Admin-Header-Validation.patch > > > Ranger Admin Header Validation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3659) Ranger Admin goes to OOM when usersync is trying to delete existing group mappings from ranger DB
[
https://issues.apache.org/jira/browse/RANGER-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu updated RANGER-3659:
---
Attachment: 0001-RANGER-3659-Improved-create-update-or-delete-group-u.patch
> Ranger Admin goes to OOM when usersync is trying to delete existing group
> mappings from ranger DB
> -
>
> Key: RANGER-3659
> URL: https://issues.apache.org/jira/browse/RANGER-3659
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments:
> 0001-RANGER-3659-Improved-create-update-or-delete-group-u.patch
>
>
> Ranger Admin goes to OOM when usersync is trying to delete existing group
> mappings from ranger DB.
> From heapdump the thread that is running OOM:
> {code:java}
> https-jsse-nio-6182-exec-3
> at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48)
> at java.util.IdentityHashMap.resize(I)Z (IdentityHashMap.java:472)
> at
> java.util.IdentityHashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
> (IdentityHashMap.java:441)
> at
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(Ljava/util/Map;Lorg/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet;ZZ)Lorg/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet;
> (UnitOfWorkImpl.java:731)
> at
> org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges()V
> (RepeatableWriteUnitOfWork.java:443)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush()V
> (EntityManagerImpl.java:975)
> at org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush()V
> (QueryImpl.java:976)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery()Ljava/lang/Object;
> (QueryImpl.java:211)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getSingleResult()Ljava/lang/Object;
> (QueryImpl.java:530)
> at
> org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult()Ljava/lang/Object;
> (EJBQueryImpl.java:404)
> at
> org.apache.ranger.db.XXUserDao.findByUserName(Ljava/lang/String;)Lorg/apache/ranger/entity/XXUser;
> (XXUserDao.java:52)
> at
> org.apache.ranger.service.XUserService.getXUserByUserName(Ljava/lang/String;)Lorg/apache/ranger/view/VXUser;
> (XUserService.java:150)
> at
> org.apache.ranger.biz.XUserMgr.deleteXGroupAndXUser(Ljava/lang/String;Ljava/lang/String;)V
> (XUserMgr.java:855)
> at
> org.apache.ranger.biz.XUserMgr.createOrDeleteXGroupUsers(Lorg/apache/ranger/ugsyncutil/model/GroupUserInfo;Ljava/util/Map;)V
> (XUserMgr.java:2835)
> at
> org.apache.ranger.biz.XUserMgr.createOrDeleteXGroupUserList(Ljava/util/List;)I
> (XUserMgr.java:2860)
> at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke(ILjava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (Unknown Source)
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Lorg/springframework/cglib/proxy/MethodProxy;)Ljava/lang/Object;
> (CglibAopProxy.java:668)
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$b2c8ac3b.createOrDeleteXGroupUserList(Ljava/util/List;)I
> (Unknown Source)
> at
> org.apache.ranger.rest.XUserREST.addOrUpdateGroupUsersList(Ljava/util/List;)I
> (XUserREST.java:1464)
> at
> org.apache.ranger.rest.XUserREST$$FastClassBySpringCGLIB$$b2a65360.invoke(ILjava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (Unknown Source)
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint()Ljava/lang/Object;
> (CglibAopProxy.java:737){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (RANGER-3657) Support for recursive ACL check for subpaths in Ozone plugin
[
https://issues.apache.org/jira/browse/RANGER-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu updated RANGER-3657:
---
Attachment: 0001-RANGER-3657-Recursive-delete-support-with-end-to-end.patch
> Support for recursive ACL check for subpaths in Ozone plugin
>
>
> Key: RANGER-3657
> URL: https://issues.apache.org/jira/browse/RANGER-3657
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments:
> 0001-RANGER-3657-Recursive-delete-support-with-end-to-end.patch
>
>
> This task is to implement {{recursive}} ACL check in
> {{{}RangerOzoneAuthorizer{}}}, using the below interface. OzoneRanger can
> build an optimized recursive ACL check similar to HDFS -
> [Reference|https://github.com/apache/ranger/blob/master/hdfs-agent/src/main/java/org/apache/ranger/authorization/hadoop/RangerHdfsAuthorizer.java#L444]
>
> {code:java}
> IAccessAuthorizer#checkAccess(IOzoneObj ozoneObject, RequestContext context)
> public class RequestContext {
> …...
> /**
> * Represents recursive access check required for all the sub-paths of
> the
> * given path. If the given path is not a directory, there is no effect
> for
> * this flag. A true value represents recursive check, false represents
> * non-recursive check.
> */
> private final boolean recursiveAccessCheck; // introducing new
> attribute for recursive access checks.
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (RANGER-3659) Ranger Admin goes to OOM when usersync is trying to delete existing group mappings from ranger DB
[
https://issues.apache.org/jira/browse/RANGER-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu reassigned RANGER-3659:
--
Assignee: Sailaja Polavarapu
> Ranger Admin goes to OOM when usersync is trying to delete existing group
> mappings from ranger DB
> -
>
> Key: RANGER-3659
> URL: https://issues.apache.org/jira/browse/RANGER-3659
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> Ranger Admin goes to OOM when usersync is trying to delete existing group
> mappings from ranger DB.
> From heapdump the thread that is running OOM:
> {code:java}
> https-jsse-nio-6182-exec-3
> at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48)
> at java.util.IdentityHashMap.resize(I)Z (IdentityHashMap.java:472)
> at
> java.util.IdentityHashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
> (IdentityHashMap.java:441)
> at
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(Ljava/util/Map;Lorg/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet;ZZ)Lorg/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet;
> (UnitOfWorkImpl.java:731)
> at
> org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges()V
> (RepeatableWriteUnitOfWork.java:443)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush()V
> (EntityManagerImpl.java:975)
> at org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush()V
> (QueryImpl.java:976)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery()Ljava/lang/Object;
> (QueryImpl.java:211)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getSingleResult()Ljava/lang/Object;
> (QueryImpl.java:530)
> at
> org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult()Ljava/lang/Object;
> (EJBQueryImpl.java:404)
> at
> org.apache.ranger.db.XXUserDao.findByUserName(Ljava/lang/String;)Lorg/apache/ranger/entity/XXUser;
> (XXUserDao.java:52)
> at
> org.apache.ranger.service.XUserService.getXUserByUserName(Ljava/lang/String;)Lorg/apache/ranger/view/VXUser;
> (XUserService.java:150)
> at
> org.apache.ranger.biz.XUserMgr.deleteXGroupAndXUser(Ljava/lang/String;Ljava/lang/String;)V
> (XUserMgr.java:855)
> at
> org.apache.ranger.biz.XUserMgr.createOrDeleteXGroupUsers(Lorg/apache/ranger/ugsyncutil/model/GroupUserInfo;Ljava/util/Map;)V
> (XUserMgr.java:2835)
> at
> org.apache.ranger.biz.XUserMgr.createOrDeleteXGroupUserList(Ljava/util/List;)I
> (XUserMgr.java:2860)
> at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke(ILjava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (Unknown Source)
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Lorg/springframework/cglib/proxy/MethodProxy;)Ljava/lang/Object;
> (CglibAopProxy.java:668)
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$b2c8ac3b.createOrDeleteXGroupUserList(Ljava/util/List;)I
> (Unknown Source)
> at
> org.apache.ranger.rest.XUserREST.addOrUpdateGroupUsersList(Ljava/util/List;)I
> (XUserREST.java:1464)
> at
> org.apache.ranger.rest.XUserREST$$FastClassBySpringCGLIB$$b2a65360.invoke(ILjava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (Unknown Source)
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint()Ljava/lang/Object;
> (CglibAopProxy.java:737){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (RANGER-3659) Ranger Admin goes to OOM when usersync is trying to delete existing group mappings from ranger DB
Sailaja Polavarapu created RANGER-3659:
--
Summary: Ranger Admin goes to OOM when usersync is trying to
delete existing group mappings from ranger DB
Key: RANGER-3659
URL: https://issues.apache.org/jira/browse/RANGER-3659
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Sailaja Polavarapu
Ranger Admin goes to OOM when usersync is trying to delete existing group
mappings from ranger DB.
>From heapdump the thread that is running OOM:
{code:java}
https-jsse-nio-6182-exec-3
at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48)
at java.util.IdentityHashMap.resize(I)Z (IdentityHashMap.java:472)
at
java.util.IdentityHashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
(IdentityHashMap.java:441)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(Ljava/util/Map;Lorg/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet;ZZ)Lorg/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet;
(UnitOfWorkImpl.java:731)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges()V
(RepeatableWriteUnitOfWork.java:443)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush()V
(EntityManagerImpl.java:975)
at org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush()V
(QueryImpl.java:976)
at
org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery()Ljava/lang/Object;
(QueryImpl.java:211)
at
org.eclipse.persistence.internal.jpa.QueryImpl.getSingleResult()Ljava/lang/Object;
(QueryImpl.java:530)
at
org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult()Ljava/lang/Object;
(EJBQueryImpl.java:404)
at
org.apache.ranger.db.XXUserDao.findByUserName(Ljava/lang/String;)Lorg/apache/ranger/entity/XXUser;
(XXUserDao.java:52)
at
org.apache.ranger.service.XUserService.getXUserByUserName(Ljava/lang/String;)Lorg/apache/ranger/view/VXUser;
(XUserService.java:150)
at
org.apache.ranger.biz.XUserMgr.deleteXGroupAndXUser(Ljava/lang/String;Ljava/lang/String;)V
(XUserMgr.java:855)
at
org.apache.ranger.biz.XUserMgr.createOrDeleteXGroupUsers(Lorg/apache/ranger/ugsyncutil/model/GroupUserInfo;Ljava/util/Map;)V
(XUserMgr.java:2835)
at
org.apache.ranger.biz.XUserMgr.createOrDeleteXGroupUserList(Ljava/util/List;)I
(XUserMgr.java:2860)
at
org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke(ILjava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
(Unknown Source)
at
org.springframework.cglib.proxy.MethodProxy.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
(MethodProxy.java:204)
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Lorg/springframework/cglib/proxy/MethodProxy;)Ljava/lang/Object;
(CglibAopProxy.java:668)
at
org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$b2c8ac3b.createOrDeleteXGroupUserList(Ljava/util/List;)I
(Unknown Source)
at
org.apache.ranger.rest.XUserREST.addOrUpdateGroupUsersList(Ljava/util/List;)I
(XUserREST.java:1464)
at
org.apache.ranger.rest.XUserREST$$FastClassBySpringCGLIB$$b2a65360.invoke(ILjava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
(Unknown Source)
at
org.springframework.cglib.proxy.MethodProxy.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
(MethodProxy.java:204)
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint()Ljava/lang/Object;
(CglibAopProxy.java:737){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[ https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3630: --- Fix Version/s: 3.0.0 > Support wildcards, group short names, and list of memberof attribute DNs for > computing user search filter > - > > Key: RANGER-3630 > URL: https://issues.apache.org/jira/browse/RANGER-3630 > Project: Ranger > Issue Type: New Feature > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3630-Added-code-to-support-wildcards-group-sh.patch, > RANGER-3630_proposal.pdf > > > Ranger Usersync provides multiple configuration properties to sync users & > groups from AD/LDAP. One of the key configuration properties is the User > Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value > of user search filter must be a valid ldap search filter and is used by > ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. > Example values include: > # samaccountname=* > ** Syncs all users from a given user search base > # (|(memberof=CN=finance,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop > Groups,dc=apache,dc=org)) > ** Sync users that are members of finance, eng_dev, and eng_testing groups > According to [Microsoft > documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx], > the wildcard character * is not allowed when the is a DN > attribute. Examples of DN attributes are distinguishedName, manager, > directReports, member, and memberOf. If users need to be sync'd from multiple > Active Directory groups with memberOf filters, this value can quickly become > a long string of OR concatenated group DNs. A single misplaced character in > this cryptic string results in all users failing to sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3657) Support for recursive ACL check for subpaths in Ozone plugin
[
https://issues.apache.org/jira/browse/RANGER-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu reassigned RANGER-3657:
--
Assignee: Sailaja Polavarapu
> Support for recursive ACL check for subpaths in Ozone plugin
>
>
> Key: RANGER-3657
> URL: https://issues.apache.org/jira/browse/RANGER-3657
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> This task is to implement {{recursive}} ACL check in
> {{{}RangerOzoneAuthorizer{}}}, using the below interface. OzoneRanger can
> build an optimized recursive ACL check similar to HDFS -
> [Reference|https://github.com/apache/ranger/blob/master/hdfs-agent/src/main/java/org/apache/ranger/authorization/hadoop/RangerHdfsAuthorizer.java#L444]
>
> {code:java}
> IAccessAuthorizer#checkAccess(IOzoneObj ozoneObject, RequestContext context)
> public class RequestContext {
> …...
> /**
> * Represents recursive access check required for all the sub-paths of
> the
> * given path. If the given path is not a directory, there is no effect
> for
> * this flag. A true value represents recursive check, false represents
> * non-recursive check.
> */
> private final boolean recursiveAccessCheck; // introducing new
> attribute for recursive access checks.
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (RANGER-3657) Support for recursive ACL check for subpaths in Ozone plugin
Sailaja Polavarapu created RANGER-3657:
--
Summary: Support for recursive ACL check for subpaths in Ozone
plugin
Key: RANGER-3657
URL: https://issues.apache.org/jira/browse/RANGER-3657
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Sailaja Polavarapu
This task is to implement {{recursive}} ACL check in
{{{}RangerOzoneAuthorizer{}}}, using the below interface. OzoneRanger can build
an optimized recursive ACL check similar to HDFS -
[Reference|https://github.com/apache/ranger/blob/master/hdfs-agent/src/main/java/org/apache/ranger/authorization/hadoop/RangerHdfsAuthorizer.java#L444]
{code:java}
IAccessAuthorizer#checkAccess(IOzoneObj ozoneObject, RequestContext context)
public class RequestContext {
…...
/**
* Represents recursive access check required for all the sub-paths of the
* given path. If the given path is not a directory, there is no effect for
* this flag. A true value represents recursive check, false represents
* non-recursive check.
*/
private final boolean recursiveAccessCheck; // introducing new attribute
for recursive access checks.
}{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[ https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3630: --- Attachment: 0001-RANGER-3630-Added-code-to-support-wildcards-group-sh.patch > Support wildcards, group short names, and list of memberof attribute DNs for > computing user search filter > - > > Key: RANGER-3630 > URL: https://issues.apache.org/jira/browse/RANGER-3630 > Project: Ranger > Issue Type: New Feature > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3630-Added-code-to-support-wildcards-group-sh.patch, > RANGER-3630_proposal.pdf > > > Ranger Usersync provides multiple configuration properties to sync users & > groups from AD/LDAP. One of the key configuration properties is the User > Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value > of user search filter must be a valid ldap search filter and is used by > ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. > Example values include: > # samaccountname=* > ** Syncs all users from a given user search base > # (|(memberof=CN=finance,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop > Groups,dc=apache,dc=org)) > ** Sync users that are members of finance, eng_dev, and eng_testing groups > According to [Microsoft > documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx], > the wildcard character * is not allowed when the is a DN > attribute. Examples of DN attributes are distinguishedName, manager, > directReports, member, and memberOf. If users need to be sync'd from multiple > Active Directory groups with memberOf filters, this value can quickly become > a long string of OR concatenated group DNs. A single misplaced character in > this cryptic string results in all users failing to sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3638) Solr Ranger document level security breaks solr if collection is reloaded
[ https://issues.apache.org/jira/browse/RANGER-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3638: --- Attachment: 0001-RANGER-3638-Avoid-calling-rangerSolrAuthorizerImpl-c.patch > Solr Ranger document level security breaks solr if collection is reloaded > - > > Key: RANGER-3638 > URL: https://issues.apache.org/jira/browse/RANGER-3638 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3638-Avoid-calling-rangerSolrAuthorizerImpl-c.patch > > > Solr stops working if using a collection with document level security enabled > when: > adding fields to collection schema > making changes to collection config > reloading collection > This does not happens if the reload is done to the non document level > security collection, with other collection with document level security. > -solr can no longer send ranger audits to solr-infra showing 403 errror from > solr-infra > -solr can no longer save audits to hdfs showing issue with the hdfs sink. > -solr answer 403 to any query to the collection with document level security > and other collections, admin commands too > -zookeeper znodes warnings are seen on the logs. > After solr restart all collections with and without document level security > are available again and answer queries. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (RANGER-3638) Solr Ranger document level security breaks solr if collection is reloaded
Sailaja Polavarapu created RANGER-3638: -- Summary: Solr Ranger document level security breaks solr if collection is reloaded Key: RANGER-3638 URL: https://issues.apache.org/jira/browse/RANGER-3638 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 2.2.0 Reporter: Sailaja Polavarapu Solr stops working if using a collection with document level security enabled when: adding fields to collection schema making changes to collection config reloading collection This does not happens if the reload is done to the non document level security collection, with other collection with document level security. -solr can no longer send ranger audits to solr-infra showing 403 errror from solr-infra -solr can no longer save audits to hdfs showing issue with the hdfs sink. -solr answer 403 to any query to the collection with document level security and other collections, admin commands too -zookeeper znodes warnings are seen on the logs. After solr restart all collections with and without document level security are available again and answer queries. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3638) Solr Ranger document level security breaks solr if collection is reloaded
[ https://issues.apache.org/jira/browse/RANGER-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3638: -- Assignee: Sailaja Polavarapu > Solr Ranger document level security breaks solr if collection is reloaded > - > > Key: RANGER-3638 > URL: https://issues.apache.org/jira/browse/RANGER-3638 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Solr stops working if using a collection with document level security enabled > when: > adding fields to collection schema > making changes to collection config > reloading collection > This does not happens if the reload is done to the non document level > security collection, with other collection with document level security. > -solr can no longer send ranger audits to solr-infra showing 403 errror from > solr-infra > -solr can no longer save audits to hdfs showing issue with the hdfs sink. > -solr answer 403 to any query to the collection with document level security > and other collections, admin commands too > -zookeeper znodes warnings are seen on the logs. > After solr restart all collections with and without document level security > are available again and answer queries. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[ https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3630: --- Attachment: RANGER-3630_proposal.pdf > Support wildcards, group short names, and list of memberof attribute DNs for > computing user search filter > - > > Key: RANGER-3630 > URL: https://issues.apache.org/jira/browse/RANGER-3630 > Project: Ranger > Issue Type: New Feature > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: RANGER-3630_proposal.pdf > > > Ranger Usersync provides multiple configuration properties to sync users & > groups from AD/LDAP. One of the key configuration properties is the User > Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value > of user search filter must be a valid ldap search filter and is used by > ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. > Example values include: > # samaccountname=* > ** Syncs all users from a given user search base > # (|(memberof=CN=finance,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop > Groups,dc=apache,dc=org)) > ** Sync users that are members of finance, eng_dev, and eng_testing groups > According to [Microsoft > documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx], > the wildcard character * is not allowed when the is a DN > attribute. Examples of DN attributes are distinguishedName, manager, > directReports, member, and memberOf. If users need to be sync'd from multiple > Active Directory groups with memberOf filters, this value can quickly become > a long string of OR concatenated group DNs. A single misplaced character in > this cryptic string results in all users failing to sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[ https://issues.apache.org/jira/browse/RANGER-3630 ]
Sailaja Polavarapu deleted comment on RANGER-3630:
was (Author: spolavarapu):
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#ff}{*};{*}{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{color:#de350b}*;*{color}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org"
# Short names of the groups -
"CN=finance{color:#de350b}*;*{color}CN=eng_dev{color:#de350b}*;*{color}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts AD/LDAP server to retrieve the
DN of the specified groups.
# Build user search filter by prepending each DN with “memberof=” and
concatenating with and OR(|) operator
Notes:
# This new configuration(ranger.usersync.ldap.groupnames) is read by usersync
only when “ranger.usersync.ldap.user.searchfilter” configuration value is
empty.
# When “ranger.usersync.ldap.user.searchfilter” configuration value is not
empty, then usersync will ignore the value for
“ranger.usersync.ldap.groupnames” configuration.
# All the configured group names(ranger.usersync.ldap.groupnames) are
concatenated with only OR (|) operator and are hardcoded for “memberof”
attribute.
> Support wildcards, group short names, and list of memberof attribute DNs for
> computing user search filter
> -
>
> Key: RANGER-3630
> URL: https://issues.apache.org/jira/browse/RANGER-3630
> Project: Ranger
> Issue Type: New Feature
> Components: Ranger, usersync
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> Ranger Usersync provides multiple configuration properties to sync users &
> groups from AD/LDAP. One of the key configuration properties is the User
> Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value
> of user search filter must be a valid ldap search filter and is used by
> ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP.
> Example values include:
> # samaccountname=*
> ** Syncs all users from a given user search base
> # (|(memberof=CN=finance,ou=Hadoop
> Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
> Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
> Groups,dc=apache,dc=org))
> ** Sync users that are members of finance, eng_dev, and eng_testing groups
> According to [Microsoft
> documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx],
> the wildcard character * is not allowed when the is a DN
> attribute. Examples of DN attributes are distinguishedName, manager,
> directReports, member, and memberOf. If users need to be sync'd from multiple
> Active Directory groups with memberOf filters, this value can quickly become
> a long string of OR concatenated group DNs. A single misplaced character in
> this cryptic string results in all users failing to sync.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[
https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493992#comment-17493992
]
Sailaja Polavarapu edited comment on RANGER-3630 at 2/17/22, 3:05 PM:
--
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#ff}*;*
{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{color:#de350b}*;*{color}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org"
# Short names of the groups - "CN=finance{*};{*}CN=eng_dev{*};{*}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts AD/LDAP server to retrieve the
DN of the specified groups.
# Build user search filter by prepending each DN with “memberof=” and
concatenating with and OR(|) operator
Notes:
# This new configuration(ranger.usersync.ldap.groupnames) is read by usersync
only when “ranger.usersync.ldap.user.searchfilter” configuration value is
empty.
# When “ranger.usersync.ldap.user.searchfilter” configuration value is not
empty, then usersync will ignore the value for
“ranger.usersync.ldap.groupnames” configuration.
# All the configured group names(ranger.usersync.ldap.groupnames) are
concatenated with only OR (|) operator and are hardcoded for “memberof”
attribute.
was (Author: spolavarapu):
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#ff}{*};{*}{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{*};{*}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org"
# Short names of the groups -
"CN=finance{*};{*}CN=eng_dev{color:#ff}*;*{color}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts AD/LDAP server to retrieve the
DN of
[jira] [Comment Edited] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[
https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493992#comment-17493992
]
Sailaja Polavarapu edited comment on RANGER-3630 at 2/17/22, 3:05 PM:
--
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#ff}{*};{*}{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{color:#de350b}*;*{color}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org"
# Short names of the groups -
"CN=finance{color:#de350b}*;*{color}CN=eng_dev{color:#de350b}*;*{color}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts AD/LDAP server to retrieve the
DN of the specified groups.
# Build user search filter by prepending each DN with “memberof=” and
concatenating with and OR(|) operator
Notes:
# This new configuration(ranger.usersync.ldap.groupnames) is read by usersync
only when “ranger.usersync.ldap.user.searchfilter” configuration value is
empty.
# When “ranger.usersync.ldap.user.searchfilter” configuration value is not
empty, then usersync will ignore the value for
“ranger.usersync.ldap.groupnames” configuration.
# All the configured group names(ranger.usersync.ldap.groupnames) are
concatenated with only OR (|) operator and are hardcoded for “memberof”
attribute.
was (Author: spolavarapu):
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#ff}*;*
{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{color:#de350b}*;*{color}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org"
# Short names of the groups - "CN=finance{*};{*}CN=eng_dev{*};{*}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts
[jira] [Comment Edited] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[
https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493992#comment-17493992
]
Sailaja Polavarapu edited comment on RANGER-3630 at 2/17/22, 3:04 PM:
--
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#ff}{*};{*}{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{*};{*}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org"
# Short names of the groups -
"CN=finance{*};{*}CN=eng_dev{color:#ff}*;*{color}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts AD/LDAP server to retrieve the
DN of the specified groups.
# Build user search filter by prepending each DN with “memberof=” and
concatenating with and OR(|) operator
Notes:
# This new configuration(ranger.usersync.ldap.groupnames) is read by usersync
only when “ranger.usersync.ldap.user.searchfilter” configuration value is
empty.
# When “ranger.usersync.ldap.user.searchfilter” configuration value is not
empty, then usersync will ignore the value for
“ranger.usersync.ldap.groupnames” configuration.
# All the configured group names(ranger.usersync.ldap.groupnames) are
concatenated with only OR (|) operator and are hardcoded for “memberof”
attribute.
was (Author: spolavarapu):
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#FF}{*};{*}{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{color:#FF}{*};{*}{color:#172b4d}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}"
# Short names of the groups -
"CN=finance{color:#FF}*;*{color}CN=eng_dev{color:#FF}*;*{color}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case
[jira] [Commented] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[
https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493992#comment-17493992
]
Sailaja Polavarapu commented on RANGER-3630:
*Proposal:*
Majority of the use cases to filter users using the “memberof” attribute fall
into two categories:
# Unique pattern for the group name - example, “eng_dev” and “finance”
# Group names with wildcard character - example, “eng_dev” and “eng_testing”
As noted down earlier, since Active directory doesn’t support either wildcards
or short names of the groups with memberof attributes, Ranger usersync must be
improved to generate user search filter internally by taking list of individual
group names or group names with wildcard character.
Instead of configuring user search filter as one big string, a new
configuration “ranger.usersync.ldap.groupnames” can be introduced for usersync.
Values can be either list of DN of the groups, list of short name of the
groups, or list of group names with wildcard character with ";" separated like
below:
# DN of the groups - "memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org{color:#FF}{*};{*}{color:#172b4d}memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}{color:#FF}{*};{*}{color:#172b4d}memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org{color}{color}"
# Short names of the groups -
"CN=finance{color:#FF}*;*{color}CN=eng_dev{color:#FF}*;*{color}CN=eng_testing"
# Group names with wildcard character -
CN=eng*{color:#de350b}*;*{color}CN=finance"
*Usersync Changes:*
Usersync reads these new configuration values and determines the format of the
specified values as DN of the groups, short names of the groups, or group names
with wildcard character.
# Values specified as DN of the groups
# In this case ranger usersync builds the user search filter by concatenating
each DN with an OR (|) operator
# Example - (|(memberof=CN=finance,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
Groups,dc=apache,dc=org))
# Values specified as short names of the groups or with wildcard character
# In this case ranger usersync first contacts AD/LDAP server to retrieve the
DN of the specified groups.
# Build user search filter by prepending each DN with “memberof=” and
concatenating with and OR(|) operator
Notes:
# This new configuration(ranger.usersync.ldap.groupnames) is read by usersync
only when “ranger.usersync.ldap.user.searchfilter” configuration value is
empty.
# When “ranger.usersync.ldap.user.searchfilter” configuration value is not
empty, then usersync will ignore the value for
“ranger.usersync.ldap.groupnames” configuration.
# All the configured group names(ranger.usersync.ldap.groupnames) are
concatenated with only OR (|) operator and are hardcoded for “memberof”
attribute.
> Support wildcards, group short names, and list of memberof attribute DNs for
> computing user search filter
> -
>
> Key: RANGER-3630
> URL: https://issues.apache.org/jira/browse/RANGER-3630
> Project: Ranger
> Issue Type: New Feature
> Components: Ranger, usersync
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> Ranger Usersync provides multiple configuration properties to sync users &
> groups from AD/LDAP. One of the key configuration properties is the User
> Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value
> of user search filter must be a valid ldap search filter and is used by
> ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP.
> Example values include:
> # samaccountname=*
> ** Syncs all users from a given user search base
> # (|(memberof=CN=finance,ou=Hadoop
> Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop
> Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop
> Groups,dc=apache,dc=org))
> ** Sync users that are members of finance, eng_dev, and eng_testing groups
> According to [Microsoft
> documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx],
> the wildcard character * is not allowed when the is a DN
> attribute. Examples of DN attributes are distinguishedName, manager,
> directReports, member, and memberOf. If users need to be sync'd from multiple
> Active Directory groups with memberOf filters, this value can quickly become
> a long string of OR concatenated group DNs. A single misplaced character in
> this cryptic string results in all users failing to sync.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
Sailaja Polavarapu created RANGER-3630: -- Summary: Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter Key: RANGER-3630 URL: https://issues.apache.org/jira/browse/RANGER-3630 Project: Ranger Issue Type: New Feature Components: Ranger, usersync Reporter: Sailaja Polavarapu Ranger Usersync provides multiple configuration properties to sync users & groups from AD/LDAP. One of the key configuration properties is the User Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value of user search filter must be a valid ldap search filter and is used by ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. Example values include: # samaccountname=* ** Syncs all users from a given user search base # (|(memberof=CN=finance,ou=Hadoop Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop Groups,dc=apache,dc=org)) ** Sync users that are members of finance, eng_dev, and eng_testing groups According to [Microsoft documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx], the wildcard character * is not allowed when the is a DN attribute. Examples of DN attributes are distinguishedName, manager, directReports, member, and memberOf. If users need to be sync'd from multiple Active Directory groups with memberOf filters, this value can quickly become a long string of OR concatenated group DNs. A single misplaced character in this cryptic string results in all users failing to sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[ https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3630: -- Assignee: Sailaja Polavarapu > Support wildcards, group short names, and list of memberof attribute DNs for > computing user search filter > - > > Key: RANGER-3630 > URL: https://issues.apache.org/jira/browse/RANGER-3630 > Project: Ranger > Issue Type: New Feature > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Ranger Usersync provides multiple configuration properties to sync users & > groups from AD/LDAP. One of the key configuration properties is the User > Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value > of user search filter must be a valid ldap search filter and is used by > ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. > Example values include: > # samaccountname=* > ** Syncs all users from a given user search base > # (|(memberof=CN=finance,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop > Groups,dc=apache,dc=org)) > ** Sync users that are members of finance, eng_dev, and eng_testing groups > According to [Microsoft > documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx], > the wildcard character * is not allowed when the is a DN > attribute. Examples of DN attributes are distinguishedName, manager, > directReports, member, and memberOf. If users need to be sync'd from multiple > Active Directory groups with memberOf filters, this value can quickly become > a long string of OR concatenated group DNs. A single misplaced character in > this cryptic string results in all users failing to sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3574) Group-role mapping in Ranger Admin doesn't work
[
https://issues.apache.org/jira/browse/RANGER-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu reassigned RANGER-3574:
--
Assignee: Sailaja Polavarapu
> Group-role mapping in Ranger Admin doesn't work
> ---
>
> Key: RANGER-3574
> URL: https://issues.apache.org/jira/browse/RANGER-3574
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Reporter: Andre Araujo
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> The intent of the Ranger Admin properties
> {{{}ranger.ldap.group.searchbase{}}}, {{ranger.ldap.group.searchfilter}} and
> {{ranger.ldap.group.roleattribute}} is to provide a mechanism to map the
> user's LDAP groups to Ranger roles dynamically. For example, if the user
> belongs to the LDAP group {{{}sys_admin{}}}, it will automatically be
> assigned to the {{ROLE_SYS_ADMIN}} role in Ranger.
> The
> [{{RangerAuthenticationProvider.getLdapAuthentication()}}|https://github.com/apache/ranger/blob/e9b1e1d5f2009e90c6bbf912d5039bdafe319a5c/security-admin/src/main/java/org/apache/ranger/security/handler/RangerAuthenticationProvider.java#L185]
> and
> [{{RangerAuthenticationProvider.getLdapBindAuthentication()}}|https://github.com/apache/ranger/blob/e9b1e1d5f2009e90c6bbf912d5039bdafe319a5c/security-admin/src/main/java/org/apache/ranger/security/handler/RangerAuthenticationProvider.java#L512]
> methods define the parameters above and use them to correctly configure a
> {{{}DefaultLdapAuthoritiesPopulator{}}}.
> The configured populator, though, is never used to fetch the
> {{GrantedAuthorities}} from LDAP. The [{{getAuthorities()}}
> method|https://github.com/apache/ranger/blob/e9b1e1d5f2009e90c6bbf912d5039bdafe319a5c/security-admin/src/main/java/org/apache/ranger/security/handler/RangerAuthenticationProvider.java#L639-L646]
> simply returns the roles assigned in Ranger and completely ignores the
> populator configured previously.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (RANGER-3387) Ranger Admin Header Validation.
[ https://issues.apache.org/jira/browse/RANGER-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3387: --- Attachment: 0001-RANGER-3387-Added-extra-validation-for-handling-PUT-.patch > Ranger Admin Header Validation. > --- > > Key: RANGER-3387 > URL: https://issues.apache.org/jira/browse/RANGER-3387 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Mateen N Mansoori >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3387-Added-extra-validation-for-handling-PUT-.patch, > 0001-RANGER-3387-Ranger-Admin-Header-Validation.patch > > > Ranger Admin Header Validation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (RANGER-3387) Ranger Admin Header Validation.
[ https://issues.apache.org/jira/browse/RANGER-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reopened RANGER-3387: Assignee: Sailaja Polavarapu (was: Mateen Mansoori) Reopening as the fix needs to be updated to handle requests coming from Knox (as gateway proxy) > Ranger Admin Header Validation. > --- > > Key: RANGER-3387 > URL: https://issues.apache.org/jira/browse/RANGER-3387 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Mateen N Mansoori >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3387-Ranger-Admin-Header-Validation.patch > > > Ranger Admin Header Validation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3403) Ranger usersync role based rules not working as expected
[ https://issues.apache.org/jira/browse/RANGER-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3403: --- Attachment: 0001-RANGER-3403-Made-code-changes-to-handle-role-assignm.patch > Ranger usersync role based rules not working as expected > > > Key: RANGER-3403 > URL: https://issues.apache.org/jira/browse/RANGER-3403 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3403-Fixed-issue-where-role-assignments-are-n.patch, > 0001-RANGER-3403-Made-code-changes-to-handle-role-assignm.patch > > > When add a group in Ranger Usersync Group based role assignment Rules, all > members in the group will have the admin role, but if remove the group from > Ranger Usersync Group based role assignment Rules, the members will still be > admin. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (RANGER-3403) Ranger usersync role based rules not working as expected
[ https://issues.apache.org/jira/browse/RANGER-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412260#comment-17412260 ] Sailaja Polavarapu edited comment on RANGER-3403 at 1/8/22, 12:13 AM: -- Review request available at: https://reviews.apache.org/r/73793/ was (Author: spolavarapu): Review request available at: https://reviews.apache.org/r/73575/ > Ranger usersync role based rules not working as expected > > > Key: RANGER-3403 > URL: https://issues.apache.org/jira/browse/RANGER-3403 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3403-Fixed-issue-where-role-assignments-are-n.patch, > 0001-RANGER-3403-Made-code-changes-to-handle-role-assignm.patch > > > When add a group in Ranger Usersync Group based role assignment Rules, all > members in the group will have the admin role, but if remove the group from > Ranger Usersync Group based role assignment Rules, the members will still be > admin. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3468) When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox Logout page
[ https://issues.apache.org/jira/browse/RANGER-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3468: --- Attachment: 0001-RANGER-3468-Fixed-an-issue-where-inactivity-timeout-.patch > When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox > Logout page > > > Key: RANGER-3468 > URL: https://issues.apache.org/jira/browse/RANGER-3468 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3468-Fixed-an-issue-where-inactivity-timeout-.patch > > > When multiple Ranger tabs are open and session timeout happens some tabs are > not getting redirected to Knox logout page but we see new session has been > created > Steps > 1.Open 3 tabs of Ranger > 2.Wait for idle session timeout > 3.When checked all the tabs some tabs are not redirected to knox logout page. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3503) Make "hadoop.security.authorization" config as an optional config in cm_ozone service definition
[ https://issues.apache.org/jira/browse/RANGER-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3503: --- Fix Version/s: 3.0.0 > Make "hadoop.security.authorization" config as an optional config in cm_ozone > service definition > > > Key: RANGER-3503 > URL: https://issues.apache.org/jira/browse/RANGER-3503 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3503-Updated-Ozone-servicedef-to-make-hadoop..patch > > > Today, the "hadoop.security.authorization" config is defined as mandatory in > cm_ozone service def, which prevents Ozone Ranger plugin to be setup in a > pure Ozone cluster (without HDFS) when "hadoop.security.authorization" is set > to empty. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3505) Ranger usersync fails to sync users when a duplicate user exists in ranger
[ https://issues.apache.org/jira/browse/RANGER-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3505: --- Attachment: 0001-RANGER-3505-modified-code-to-ignore-case-while-valid.patch > Ranger usersync fails to sync users when a duplicate user exists in ranger > -- > > Key: RANGER-3505 > URL: https://issues.apache.org/jira/browse/RANGER-3505 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3505-modified-code-to-ignore-case-while-valid.patch > > > Ranger is having issue with syncing user with case sensitive when the backend > database for ranger is MySQL / Maria DB. Initially users are sync'd with > default configuration (without any case conversion). Later usersync is > configured to sync users with upper case. At this time, usersync fails to > sync any users throwing duplicate user exception. For resolving this, > existing user from ranger must be deleted and then restarted the usersync > service. Instead, ranger code should update existing user with case > conversion and continue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3505) Ranger usersync fails to sync users when a duplicate user exists in ranger
Sailaja Polavarapu created RANGER-3505: -- Summary: Ranger usersync fails to sync users when a duplicate user exists in ranger Key: RANGER-3505 URL: https://issues.apache.org/jira/browse/RANGER-3505 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Ranger is having issue with syncing user with case sensitive when the backend database for ranger is MySQL / Maria DB. Initially users are sync'd with default configuration (without any case conversion). Later usersync is configured to sync users with upper case. At this time, usersync fails to sync any users throwing duplicate user exception. For resolving this, existing user from ranger must be deleted and then restarted the usersync service. Instead, ranger code should update existing user with case conversion and continue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3505) Ranger usersync fails to sync users when a duplicate user exists in ranger
[ https://issues.apache.org/jira/browse/RANGER-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3505: -- Assignee: Sailaja Polavarapu > Ranger usersync fails to sync users when a duplicate user exists in ranger > -- > > Key: RANGER-3505 > URL: https://issues.apache.org/jira/browse/RANGER-3505 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Ranger is having issue with syncing user with case sensitive when the backend > database for ranger is MySQL / Maria DB. Initially users are sync'd with > default configuration (without any case conversion). Later usersync is > configured to sync users with upper case. At this time, usersync fails to > sync any users throwing duplicate user exception. For resolving this, > existing user from ranger must be deleted and then restarted the usersync > service. Instead, ranger code should update existing user with case > conversion and continue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3503) Make "hadoop.security.authorization" config as an optional config in cm_ozone service definition
[ https://issues.apache.org/jira/browse/RANGER-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3503: --- Attachment: 0001-RANGER-3503-Updated-Ozone-servicedef-to-make-hadoop..patch > Make "hadoop.security.authorization" config as an optional config in cm_ozone > service definition > > > Key: RANGER-3503 > URL: https://issues.apache.org/jira/browse/RANGER-3503 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3503-Updated-Ozone-servicedef-to-make-hadoop..patch > > > Today, the "hadoop.security.authorization" config is defined as mandatory in > cm_ozone service def, which prevents Ozone Ranger plugin to be setup in a > pure Ozone cluster (without HDFS) when "hadoop.security.authorization" is set > to empty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3503) Make "hadoop.security.authorization" config as an optional config in cm_ozone service definition
Sailaja Polavarapu created RANGER-3503: -- Summary: Make "hadoop.security.authorization" config as an optional config in cm_ozone service definition Key: RANGER-3503 URL: https://issues.apache.org/jira/browse/RANGER-3503 Project: Ranger Issue Type: Bug Components: Ranger Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu Today, the "hadoop.security.authorization" config is defined as mandatory in cm_ozone service def, which prevents Ozone Ranger plugin to be setup in a pure Ozone cluster (without HDFS) when "hadoop.security.authorization" is set to empty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (RANGER-3319) Ranger usersync cookie default duration for sync
[ https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu resolved RANGER-3319. Fix Version/s: 2.2.0 Resolution: Fixed > Ranger usersync cookie default duration for sync > > > Key: RANGER-3319 > URL: https://issues.apache.org/jira/browse/RANGER-3319 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1 >Reporter: Konstantin Tsypin >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 2.2.0 > > > Hi! > At this moment we cant initial sync out of the box our LDAP with 10k+ users & > groups. > It's because sync works as three steps: > 1) Sync groups > 2) Sync users > 3) Map users as one request and send it to rangeradmin > From time to time our third step on initial sync generate this single request > for a long time > It can be easily three or four hours. > Acrossing this timegate we have an error with timeout usersync cookie (that > by default is 60 minutes) and failed 3rd step. > > The workaround - is > ranger_admin_directory/ews/webapp/WEB-INF/web.xml > change > default > 60 > to just in case > 1440 > BUT im was really frustrated with this behavior whan faced it first time, and > i want to have a mechanism to split mapping step for a smaller part, and > update cookie from time to time. > > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3319) Ranger usersync cookie default duration for sync
[ https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3319: -- Assignee: Sailaja Polavarapu > Ranger usersync cookie default duration for sync > > > Key: RANGER-3319 > URL: https://issues.apache.org/jira/browse/RANGER-3319 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1 >Reporter: Konstantin Tsypin >Assignee: Sailaja Polavarapu >Priority: Major > > Hi! > At this moment we cant initial sync out of the box our LDAP with 10k+ users & > groups. > It's because sync works as three steps: > 1) Sync groups > 2) Sync users > 3) Map users as one request and send it to rangeradmin > From time to time our third step on initial sync generate this single request > for a long time > It can be easily three or four hours. > Acrossing this timegate we have an error with timeout usersync cookie (that > by default is 60 minutes) and failed 3rd step. > > The workaround - is > ranger_admin_directory/ews/webapp/WEB-INF/web.xml > change > default > 60 > to just in case > 1440 > BUT im was really frustrated with this behavior whan faced it first time, and > i want to have a mechanism to split mapping step for a smaller part, and > update cookie from time to time. > > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (RANGER-3319) Ranger usersync cookie default duration for sync
[ https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17434898#comment-17434898 ] Sailaja Polavarapu edited comment on RANGER-3319 at 10/27/21, 3:08 PM: --- [~fullhouse], >> 3) Map users as one request and send it to rangeradmin >From time to time our third step on initial sync generate this single request >for a long time It can be easily three or four hours. >>> This issue is fixed as part of RANGER-3374 Please give it a try and re-open if the issue still exists. was (Author: spolavarapu): [~fullhouse], >> 3) Map users as one request and send it to rangeradmin >From time to time our third step on initial sync generate this single request >for a long time It can be easily three or four hours. >>> This issue is fixed as part of RANGER-3374 > Ranger usersync cookie default duration for sync > > > Key: RANGER-3319 > URL: https://issues.apache.org/jira/browse/RANGER-3319 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1 >Reporter: Konstantin Tsypin >Priority: Major > > Hi! > At this moment we cant initial sync out of the box our LDAP with 10k+ users & > groups. > It's because sync works as three steps: > 1) Sync groups > 2) Sync users > 3) Map users as one request and send it to rangeradmin > From time to time our third step on initial sync generate this single request > for a long time > It can be easily three or four hours. > Acrossing this timegate we have an error with timeout usersync cookie (that > by default is 60 minutes) and failed 3rd step. > > The workaround - is > ranger_admin_directory/ews/webapp/WEB-INF/web.xml > change > default > 60 > to just in case > 1440 > BUT im was really frustrated with this behavior whan faced it first time, and > i want to have a mechanism to split mapping step for a smaller part, and > update cookie from time to time. > > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3319) Ranger usersync cookie default duration for sync
[ https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17434898#comment-17434898 ] Sailaja Polavarapu commented on RANGER-3319: [~fullhouse], >> 3) Map users as one request and send it to rangeradmin >From time to time our third step on initial sync generate this single request >for a long time It can be easily three or four hours. >>> This issue is fixed as part of RANGER-3374 > Ranger usersync cookie default duration for sync > > > Key: RANGER-3319 > URL: https://issues.apache.org/jira/browse/RANGER-3319 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1 >Reporter: Konstantin Tsypin >Priority: Major > > Hi! > At this moment we cant initial sync out of the box our LDAP with 10k+ users & > groups. > It's because sync works as three steps: > 1) Sync groups > 2) Sync users > 3) Map users as one request and send it to rangeradmin > From time to time our third step on initial sync generate this single request > for a long time > It can be easily three or four hours. > Acrossing this timegate we have an error with timeout usersync cookie (that > by default is 60 minutes) and failed 3rd step. > > The workaround - is > ranger_admin_directory/ews/webapp/WEB-INF/web.xml > change > default > 60 > to just in case > 1440 > BUT im was really frustrated with this behavior whan faced it first time, and > i want to have a mechanism to split mapping step for a smaller part, and > update cookie from time to time. > > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3468) When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox Logout page
[ https://issues.apache.org/jira/browse/RANGER-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3468: -- Assignee: Sailaja Polavarapu > When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox > Logout page > > > Key: RANGER-3468 > URL: https://issues.apache.org/jira/browse/RANGER-3468 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > When multiple Ranger tabs are open and session timeout happens some tabs are > not getting redirected to Knox logout page but we see new session has been > created > Steps > 1.Open 3 tabs of Ranger > 2.Wait for idle session timeout > 3.When checked all the tabs some tabs are not redirected to knox logout page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3468) When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox Logout page
Sailaja Polavarapu created RANGER-3468: -- Summary: When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox Logout page Key: RANGER-3468 URL: https://issues.apache.org/jira/browse/RANGER-3468 Project: Ranger Issue Type: Bug Components: Ranger Reporter: Sailaja Polavarapu When multiple Ranger tabs are open and session timeout happens some tabs are not getting redirected to Knox logout page but we see new session has been created Steps 1.Open 3 tabs of Ranger 2.Wait for idle session timeout 3.When checked all the tabs some tabs are not redirected to knox logout page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3438) In Knox plugin group lookup sometimes takes long time
[ https://issues.apache.org/jira/browse/RANGER-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3438: --- Attachment: 0001-RANGER-3438-Optimized-code-to-extract-GroupPrincipal.patch > In Knox plugin group lookup sometimes takes long time > - > > Key: RANGER-3438 > URL: https://issues.apache.org/jira/browse/RANGER-3438 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3438-Optimized-code-to-extract-GroupPrincipal.patch > > > When trusted proxy is enabled for various UI services, all the request go > through knox. plugin authorization. In some cases group lookup is taking long > time and the UI is very sluggish. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3438) In Knox plugin group lookup sometimes takes long time
[ https://issues.apache.org/jira/browse/RANGER-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3438: -- Assignee: Sailaja Polavarapu > In Knox plugin group lookup sometimes takes long time > - > > Key: RANGER-3438 > URL: https://issues.apache.org/jira/browse/RANGER-3438 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > When trusted proxy is enabled for various UI services, all the request go > through knox. plugin authorization. In some cases group lookup is taking long > time and the UI is very sluggish. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3438) In Knox plugin group lookup sometimes takes long time
Sailaja Polavarapu created RANGER-3438: -- Summary: In Knox plugin group lookup sometimes takes long time Key: RANGER-3438 URL: https://issues.apache.org/jira/browse/RANGER-3438 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Sailaja Polavarapu When trusted proxy is enabled for various UI services, all the request go through knox. plugin authorization. In some cases group lookup is taking long time and the UI is very sluggish. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3403) Ranger usersync role based rules not working as expected
[ https://issues.apache.org/jira/browse/RANGER-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3403: --- Attachment: 0001-RANGER-3403-Fixed-issue-where-role-assignments-are-n.patch > Ranger usersync role based rules not working as expected > > > Key: RANGER-3403 > URL: https://issues.apache.org/jira/browse/RANGER-3403 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3403-Fixed-issue-where-role-assignments-are-n.patch > > > When add a group in Ranger Usersync Group based role assignment Rules, all > members in the group will have the admin role, but if remove the group from > Ranger Usersync Group based role assignment Rules, the members will still be > admin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3403) Ranger usersync role based rules not working as expected
Sailaja Polavarapu created RANGER-3403: -- Summary: Ranger usersync role based rules not working as expected Key: RANGER-3403 URL: https://issues.apache.org/jira/browse/RANGER-3403 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu When add a group in Ranger Usersync Group based role assignment Rules, all members in the group will have the admin role, but if remove the group from Ranger Usersync Group based role assignment Rules, the members will still be admin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3363) Support Session Inactivity Timeout for Ranger
[ https://issues.apache.org/jira/browse/RANGER-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3363: --- Attachment: 0001-RANGER-3363-Added-support-for-handling-session-timeo.patch > Support Session Inactivity Timeout for Ranger > - > > Key: RANGER-3363 > URL: https://issues.apache.org/jira/browse/RANGER-3363 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3363-Added-support-for-handling-session-timeo.patch > > > Ranger users who login via one of the supported authentication flavors stay > logged in until they choose to log out. > In the scenario where user has logged in and has left their desk, the > inactivity does not result in early log out. > This implementation addresses that problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3374) Syncing 300K+ user group mappings to ranger is causing ranger to go out of memory
[ https://issues.apache.org/jira/browse/RANGER-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3374: --- Attachment: 0001-RANGER-3374-Creating-new-DB-transaction-for-add-upda.patch > Syncing 300K+ user group mappings to ranger is causing ranger to go out of > memory > -- > > Key: RANGER-3374 > URL: https://issues.apache.org/jira/browse/RANGER-3374 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3374-Creating-new-DB-transaction-for-add-upda.patch > > > When there are 300k+ user group mappings to be updated to Ranger from > usersync, ranger crashes with out of memory errors. Also noticed that when > the user group mappings are around 100k, it is taking very long time for the > request to complete. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3374) Syncing 300K+ user group mappings to ranger is causing ranger to go out of memory
Sailaja Polavarapu created RANGER-3374: -- Summary: Syncing 300K+ user group mappings to ranger is causing ranger to go out of memory Key: RANGER-3374 URL: https://issues.apache.org/jira/browse/RANGER-3374 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu When there are 300k+ user group mappings to be updated to Ranger from usersync, ranger crashes with out of memory errors. Also noticed that when the user group mappings are around 100k, it is taking very long time for the request to complete. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3363) Support Session Inactivity Timeout for Ranger
[ https://issues.apache.org/jira/browse/RANGER-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3363: -- Assignee: Sailaja Polavarapu > Support Session Inactivity Timeout for Ranger > - > > Key: RANGER-3363 > URL: https://issues.apache.org/jira/browse/RANGER-3363 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Ranger users who login via one of the supported authentication flavors stay > logged in until they choose to log out. > In the scenario where user has logged in and has left their desk, the > inactivity does not result in early log out. > This implementation addresses that problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3363) Support Session Inactivity Timeout for Ranger
Sailaja Polavarapu created RANGER-3363: -- Summary: Support Session Inactivity Timeout for Ranger Key: RANGER-3363 URL: https://issues.apache.org/jira/browse/RANGER-3363 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Sailaja Polavarapu Ranger users who login via one of the supported authentication flavors stay logged in until they choose to log out. In the scenario where user has logged in and has left their desk, the inactivity does not result in early log out. This implementation addresses that problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3333) Ozone Ranger Audits are not showing up in Ranger Admin UI for "om" service user
[ https://issues.apache.org/jira/browse/RANGER-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-: --- Attachment: 0001-RANGER--Removed-default-audit-filter-om-service-.patch > Ozone Ranger Audits are not showing up in Ranger Admin UI for "om" service > user > --- > > Key: RANGER- > URL: https://issues.apache.org/jira/browse/RANGER- > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER--Removed-default-audit-filter-om-service-.patch > > > Ranger Audits for Ozone are not captured and displayed in the audits section > of Ranger Admin UI. There are no errors reported in ozone-ranger.log or OM > logs. This is happening for the ozone requests made by "om" service user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3333) Ozone Ranger Audits are not showing up in Ranger Admin UI for "om" service user
[ https://issues.apache.org/jira/browse/RANGER-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-: -- Assignee: Sailaja Polavarapu > Ozone Ranger Audits are not showing up in Ranger Admin UI for "om" service > user > --- > > Key: RANGER- > URL: https://issues.apache.org/jira/browse/RANGER- > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Ranger Audits for Ozone are not captured and displayed in the audits section > of Ranger Admin UI. There are no errors reported in ozone-ranger.log or OM > logs. This is happening for the ozone requests made by "om" service user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3333) Ozone Ranger Audits are not showing up in Ranger Admin UI for "om" service user
Sailaja Polavarapu created RANGER-: -- Summary: Ozone Ranger Audits are not showing up in Ranger Admin UI for "om" service user Key: RANGER- URL: https://issues.apache.org/jira/browse/RANGER- Project: Ranger Issue Type: Bug Components: Ranger Reporter: Sailaja Polavarapu Ranger Audits for Ozone are not captured and displayed in the audits section of Ranger Admin UI. There are no errors reported in ozone-ranger.log or OM logs. This is happening for the ozone requests made by "om" service user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3311) Ranger Usersync not retrying failed updates for unix or file sync source
[ https://issues.apache.org/jira/browse/RANGER-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3311: --- Attachment: 0001-RANGER-3311-Fixed-a-minor-issue-where-retry-flag-is-.patch > Ranger Usersync not retrying failed updates for unix or file sync source > > > Key: RANGER-3311 > URL: https://issues.apache.org/jira/browse/RANGER-3311 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Affects Versions: 2.1.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3311-Fixed-a-minor-issue-where-retry-flag-is-.patch > > > Following are the steps I noticed to reproduce this issue: > 1. Usersync was configured to sync users/groups from unix or file sync source. > 2. During one of the sync cycle, usersync group membership updates to ranger > admin failed > 3. Then usersync is not retrying the failed updates until there is another > change at the sync source. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3311) Ranger Usersync not retrying failed updates for unix or file sync source
[ https://issues.apache.org/jira/browse/RANGER-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3311: -- Assignee: Sailaja Polavarapu > Ranger Usersync not retrying failed updates for unix or file sync source > > > Key: RANGER-3311 > URL: https://issues.apache.org/jira/browse/RANGER-3311 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Affects Versions: 2.1.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Following are the steps I noticed to reproduce this issue: > 1. Usersync was configured to sync users/groups from unix or file sync source. > 2. During one of the sync cycle, usersync group membership updates to ranger > admin failed > 3. Then usersync is not retrying the failed updates until there is another > change at the sync source. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3311) Ranger Usersync not retrying failed updates for unix or file sync source
Sailaja Polavarapu created RANGER-3311: -- Summary: Ranger Usersync not retrying failed updates for unix or file sync source Key: RANGER-3311 URL: https://issues.apache.org/jira/browse/RANGER-3311 Project: Ranger Issue Type: Bug Components: Ranger, usersync Affects Versions: 2.1.0 Reporter: Sailaja Polavarapu Following are the steps I noticed to reproduce this issue: 1. Usersync was configured to sync users/groups from unix or file sync source. 2. During one of the sync cycle, usersync group membership updates to ranger admin failed 3. Then usersync is not retrying the failed updates until there is another change at the sync source. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3297) Internal user is not marked as external after the user sync source details are changed
[ https://issues.apache.org/jira/browse/RANGER-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3297: --- Attachment: 0001-RANGER-3297-Updating-user-source-when-same-user-exis.patch > Internal user is not marked as external after the user sync source details > are changed > -- > > Key: RANGER-3297 > URL: https://issues.apache.org/jira/browse/RANGER-3297 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3297-Updating-user-source-when-same-user-exis.patch > > > If we add an internal user from UI, say Mike.[mike user will not have any > sync source details] > Now if add the same Mike user in our sync source, in the next sync cycle. > 1. Mike user attributes are updated and it is pointing to current sync source. > 2. Mike user is still showing as internal user in UI. > If Mike user details are updated then it should be marked as external user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3297) Internal user is not marked as external after the user sync source details are changed
[ https://issues.apache.org/jira/browse/RANGER-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3297: -- Assignee: Sailaja Polavarapu > Internal user is not marked as external after the user sync source details > are changed > -- > > Key: RANGER-3297 > URL: https://issues.apache.org/jira/browse/RANGER-3297 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > > If we add an internal user from UI, say Mike.[mike user will not have any > sync source details] > Now if add the same Mike user in our sync source, in the next sync cycle. > 1. Mike user attributes are updated and it is pointing to current sync source. > 2. Mike user is still showing as internal user in UI. > If Mike user details are updated then it should be marked as external user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3277) Number of users/groups marked for delete are not shown in logs
[ https://issues.apache.org/jira/browse/RANGER-3277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3277: --- Attachment: 0001-RANGER-3277-Added-more-information-to-usersync-audit.patch > Number of users/groups marked for delete are not shown in logs > -- > > Key: RANGER-3277 > URL: https://issues.apache.org/jira/browse/RANGER-3277 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3277-Added-more-information-to-usersync-audit.patch > > > When usersync computes users/groups that are deleted and the sync source, > this information is not logged in the usersync logs or usersync audits that > are shown in ranger UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3277) Number of users/groups marked for delete are not shown in logs
Sailaja Polavarapu created RANGER-3277: -- Summary: Number of users/groups marked for delete are not shown in logs Key: RANGER-3277 URL: https://issues.apache.org/jira/browse/RANGER-3277 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu When usersync computes users/groups that are deleted and the sync source, this information is not logged in the usersync logs or usersync audits that are shown in ranger UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3266) Solr inter-node communication not working after enabling Ranger
[ https://issues.apache.org/jira/browse/RANGER-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3266: --- Attachment: 0001-RANGER-3266-Removed-code-to-overwrite-the-Solr-s-Jaa.patch > Solr inter-node communication not working after enabling Ranger > --- > > Key: RANGER-3266 > URL: https://issues.apache.org/jira/browse/RANGER-3266 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.1.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3266-Removed-code-to-overwrite-the-Solr-s-Jaa.patch > > > When there are 2 Solr services, infra solr and solr in a cluster, and Ranger > plugin is enabled on non-infra solr, Ranger Audits are not shown in Ranger UI. > After debugging, we noticed that there is an internode communication failure > with ConfigurableInternodeAuthHadoopPlugin. The related solr side issue is > SOLR-15233. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3262) Ranger group memberships are not working for LDAP sync
[ https://issues.apache.org/jira/browse/RANGER-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3262: --- Attachment: 0001-RANGER-3262-Fixed-issue-where-group-memberships-are-.patch > Ranger group memberships are not working for LDAP sync > -- > > Key: RANGER-3262 > URL: https://issues.apache.org/jira/browse/RANGER-3262 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3262-Fixed-issue-where-group-memberships-are-.patch > > > In order to sync group memberships from LDAP, usersync uses the value > configured for "ranger.usersync.group.memberattributename" (generally it is > memberUid in case of LDAP). In majority of LDAP servers, memberUid typically > returns the shortname of the user. This was causing an issue while computing > group membership in usersync. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3266) Solr inter-node communication not working after enabling Ranger
Sailaja Polavarapu created RANGER-3266: -- Summary: Solr inter-node communication not working after enabling Ranger Key: RANGER-3266 URL: https://issues.apache.org/jira/browse/RANGER-3266 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 2.1.0 Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu When there are 2 Solr services, infra solr and solr in a cluster, and Ranger plugin is enabled on non-infra solr, Ranger Audits are not shown in Ranger UI. After debugging, we noticed that there is an internode communication failure with ConfigurableInternodeAuthHadoopPlugin. The related solr side issue is SOLR-15233. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3254) sync source changes when same group is present in different sync source
[ https://issues.apache.org/jira/browse/RANGER-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3254: --- Attachment: (was: 0001-RANGER-3254-Fixed-issue-where-user-or-group-name-is-.patch) > sync source changes when same group is present in different sync source > --- > > Key: RANGER-3254 > URL: https://issues.apache.org/jira/browse/RANGER-3254 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3254-RANGER-3232-Fixed-issue-where-user-or-gr.patch > > > Test steps :- > 1. configure unix sync source. > 2. Add group "grp1" > 3. check sync source of group 'grp1'. it will be Unix. > 4. change sync source to LDAP, having "grp1" already present. > 5. restart user sync service. > 6. check sync source of group 'grp1'. it will be updated to "LDAP", Which is > not the accepted behaviour. > Ideally grp1 should not be synced as it is already present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3254) sync source changes when same group is present in different sync source
[ https://issues.apache.org/jira/browse/RANGER-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3254: --- Attachment: 0001-RANGER-3254-RANGER-3232-Fixed-issue-where-user-or-gr.patch > sync source changes when same group is present in different sync source > --- > > Key: RANGER-3254 > URL: https://issues.apache.org/jira/browse/RANGER-3254 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3254-RANGER-3232-Fixed-issue-where-user-or-gr.patch > > > Test steps :- > 1. configure unix sync source. > 2. Add group "grp1" > 3. check sync source of group 'grp1'. it will be Unix. > 4. change sync source to LDAP, having "grp1" already present. > 5. restart user sync service. > 6. check sync source of group 'grp1'. it will be updated to "LDAP", Which is > not the accepted behaviour. > Ideally grp1 should not be synced as it is already present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3262) Ranger group memberships are not working for LDAP sync
Sailaja Polavarapu created RANGER-3262: -- Summary: Ranger group memberships are not working for LDAP sync Key: RANGER-3262 URL: https://issues.apache.org/jira/browse/RANGER-3262 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu In order to sync group memberships from LDAP, usersync uses the value configured for "ranger.usersync.group.memberattributename" (generally it is memberUid in case of LDAP). In majority of LDAP servers, memberUid typically returns the shortname of the user. This was causing an issue while computing group membership in usersync. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3262) Ranger group memberships are not working for LDAP sync
[ https://issues.apache.org/jira/browse/RANGER-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3262: -- Assignee: Sailaja Polavarapu > Ranger group memberships are not working for LDAP sync > -- > > Key: RANGER-3262 > URL: https://issues.apache.org/jira/browse/RANGER-3262 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > In order to sync group memberships from LDAP, usersync uses the value > configured for "ranger.usersync.group.memberattributename" (generally it is > memberUid in case of LDAP). In majority of LDAP servers, memberUid typically > returns the shortname of the user. This was causing an issue while computing > group membership in usersync. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3254) sync source changes when same group is present in different sync source
[ https://issues.apache.org/jira/browse/RANGER-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3254: --- Attachment: 0001-RANGER-3254-Fixed-issue-where-user-or-group-name-is-.patch > sync source changes when same group is present in different sync source > --- > > Key: RANGER-3254 > URL: https://issues.apache.org/jira/browse/RANGER-3254 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3254-Fixed-issue-where-user-or-group-name-is-.patch > > > Test steps :- > 1. configure unix sync source. > 2. Add group "grp1" > 3. check sync source of group 'grp1'. it will be Unix. > 4. change sync source to LDAP, having "grp1" already present. > 5. restart user sync service. > 6. check sync source of group 'grp1'. it will be updated to "LDAP", Which is > not the accepted behaviour. > Ideally grp1 should not be synced as it is already present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3254) sync source changes when same group is present in different sync source
[ https://issues.apache.org/jira/browse/RANGER-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3254: -- Assignee: Sailaja Polavarapu > sync source changes when same group is present in different sync source > --- > > Key: RANGER-3254 > URL: https://issues.apache.org/jira/browse/RANGER-3254 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Test steps :- > 1. configure unix sync source. > 2. Add group "grp1" > 3. check sync source of group 'grp1'. it will be Unix. > 4. change sync source to LDAP, having "grp1" already present. > 5. restart user sync service. > 6. check sync source of group 'grp1'. it will be updated to "LDAP", Which is > not the accepted behaviour. > Ideally grp1 should not be synced as it is already present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3254) sync source changes when same group is present in different sync source
Sailaja Polavarapu created RANGER-3254: -- Summary: sync source changes when same group is present in different sync source Key: RANGER-3254 URL: https://issues.apache.org/jira/browse/RANGER-3254 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Test steps :- 1. configure unix sync source. 2. Add group "grp1" 3. check sync source of group 'grp1'. it will be Unix. 4. change sync source to LDAP, having "grp1" already present. 5. restart user sync service. 6. check sync source of group 'grp1'. it will be updated to "LDAP", Which is not the accepted behaviour. Ideally grp1 should not be synced as it is already present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3207) Graceful handling of invalid usernames for usersync
[ https://issues.apache.org/jira/browse/RANGER-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3207: --- Attachment: 0001-RANGER-3207-Added-code-to-validate-user-and-group-na.patch > Graceful handling of invalid usernames for usersync > --- > > Key: RANGER-3207 > URL: https://issues.apache.org/jira/browse/RANGER-3207 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Balazs Jeszenszky >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3207-Added-code-to-validate-user-and-group-na.patch > > > Currently, if there is an invalid username in a batch of users that usersync > tries to create in ranger admin, the entire batch of users will fail to > create. Usersync will then perpetually retry creating these users. This leads > to no alerts in Ranger, CM, or anywhere else besides usersync/admin logs, > both of which lack necessary details like the offending username. > In the current state, usersync is unusable if there is a single bad username > in the source database. > Usersync has to be more robust against malformed user names. IMO two ways > forward could be: > * (preferred) Allow partial failures, ie. create users that have well-formed > names even if a batch has a malformed user name, or > * Have a filter built into usersync that catches these before they reach > admin > Regardless of the solution, the error message should include the offending > username, and usersync should not keep trying to create users that are known > to cause failures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304409#comment-17304409 ] Sailaja Polavarapu commented on RANGER-3203: Merged follow-up minor fix ([https://reviews.apache.org/r/73240/)] to both master and ranger-2.2 branches > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3203-Added-back-support-to-allow-group-search.patch > > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra configuration overhead. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3203: --- Attachment: 0001-RANGER-3203-Added-back-support-to-allow-group-search.patch > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3203-Added-back-support-to-allow-group-search.patch > > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra configuration overhead. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302899#comment-17302899 ] Sailaja Polavarapu commented on RANGER-3203: Review request available at: https://reviews.apache.org/r/73235/ > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3203-Added-back-support-to-allow-group-search.patch > > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra configuration overhead. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-980) User sync does not delete users if they do not exist anymore
[ https://issues.apache.org/jira/browse/RANGER-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302750#comment-17302750 ] Sailaja Polavarapu commented on RANGER-980: --- Fixed a minor issue while computing deltas for users & groups. https://reviews.apache.org/r/73234/ > User sync does not delete users if they do not exist anymore > > > Key: RANGER-980 > URL: https://issues.apache.org/jira/browse/RANGER-980 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 0.6.0, 0.5.3 >Reporter: Bolke de Bruin >Assignee: Sailaja Polavarapu >Priority: Critical > Labels: security > Attachments: > 0001-RANGER-980-Support-for-deleted-users-groups-in-Range.patch, > 0001-RANGER-980-User-sync-does-not-delete-users-if-they-d.patch, Deleted > users and groups support in Ranger (RANGER-980).pdf, RANGER-980.patch > > > usersync for all sources creates users and groups, but does not delete them > from Ranger's database if these users and groups do not exists anymore in the > original source. > So if you have for example a user called "bob" and bob leaves the company his > access rights will continue to exist in Ranger. If a new employee comes in > that is also "bob" he is immediately granted the same access as the previous > employee. This creates security incidents. > In a reasonable complex company it cannot be expected that another user > administration is being taken care of, while deletion could and should happen > automatically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3207) Graceful handling of invalid usernames for usersync
[ https://issues.apache.org/jira/browse/RANGER-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3207: -- Assignee: Sailaja Polavarapu > Graceful handling of invalid usernames for usersync > --- > > Key: RANGER-3207 > URL: https://issues.apache.org/jira/browse/RANGER-3207 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > Currently, if there is an invalid username in a batch of users that usersync > tries to create in ranger admin, the entire batch of users will fail to > create. Usersync will then perpetually retry creating these users. This leads > to no alerts in Ranger, CM, or anywhere else besides usersync/admin logs, > both of which lack necessary details like the offending username. > In the current state, usersync is unusable if there is a single bad username > in the source database. > Usersync has to be more robust against malformed user names. IMO two ways > forward could be: > * (preferred) Allow partial failures, ie. create users that have well-formed > names even if a batch has a malformed user name, or > * Have a filter built into usersync that catches these before they reach > admin > Regardless of the solution, the error message should include the offending > username, and usersync should not keep trying to create users that are known > to cause failures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3207) Graceful handling of invalid usernames for usersync
Sailaja Polavarapu created RANGER-3207: -- Summary: Graceful handling of invalid usernames for usersync Key: RANGER-3207 URL: https://issues.apache.org/jira/browse/RANGER-3207 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Currently, if there is an invalid username in a batch of users that usersync tries to create in ranger admin, the entire batch of users will fail to create. Usersync will then perpetually retry creating these users. This leads to no alerts in Ranger, CM, or anywhere else besides usersync/admin logs, both of which lack necessary details like the offending username. In the current state, usersync is unusable if there is a single bad username in the source database. Usersync has to be more robust against malformed user names. IMO two ways forward could be: * (preferred) Allow partial failures, ie. create users that have well-formed names even if a batch has a malformed user name, or * Have a filter built into usersync that catches these before they reach admin Regardless of the solution, the error message should include the offending username, and usersync should not keep trying to create users that are known to cause failures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3203: --- Description: As part of RANGER-2986, group search is made mandatory. This is breaking an usecase to sync users and all the corresponding groups from AD/LDAP. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra configuration overhead. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) was: As part of RANGER-2986, group search is made mandatory. This is breaking an usecase to sync users and all the corresponding groups from AD/LDAP. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra overhead. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra configuration overhead. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3203: --- Description: As part of RANGER-2986, group search is made mandatory. This is breaking an usecase to sync users and all the corresponding groups from AD/LDAP. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra overhead. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) was: As part of RANGER-2986, group search is made mandatory. This is breaking an usecase to sync users and all the corresponding groups from AD/LDAP. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra overhead for the customers. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra overhead. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3203: --- Description: As part of RANGER-2986, group search is made mandatory. This is breaking an usecase to sync users and all the corresponding groups from AD/LDAP. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra overhead for the customers. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) was: As part of RANGER-2986, group search is made mandatory. This is breaking an usecase where customer wants to sync users and all the corresponding groups. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra overhead for the customers. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra overhead for the customers. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
Sailaja Polavarapu created RANGER-3203: -- Summary: Add back the support to provide option to retrieve groups from user memberof attribute Key: RANGER-3203 URL: https://issues.apache.org/jira/browse/RANGER-3203 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu As part of RANGER-2986, group search is made mandatory. This is breaking an usecase where customer wants to sync users and all the corresponding groups. Previously, this could be achieved by setting ranger.usersync.group.searchenabled to false and configure ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync used to sync the users based on the user search base and user search filter and use the "memberof" attribute of the user to sync all the groups each user belongs to. Now, if you want to achieve the same functionality, group search base and group search filter have to be configured with appropriate filters for sync'ing the groups which might be an extra overhead for the customers. This is same for both full sync and incremental sync. Note:- When incremental sync is enabled, it is highly recommended to enable group search and configure group search base and group search filter accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3163) Ranger Database deadlock when Service creation and user sync are running parallel
[
https://issues.apache.org/jira/browse/RANGER-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu updated RANGER-3163:
---
Attachment: 0001-RANGER-3163-Created-individual-DB-transactions-for-e.patch
> Ranger Database deadlock when Service creation and user sync are running
> parallel
> -
>
> Key: RANGER-3163
> URL: https://issues.apache.org/jira/browse/RANGER-3163
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments:
> 0001-RANGER-3163-Created-individual-DB-transactions-for-e.patch
>
>
> Following is the error and some observations:
> *Error :*
> 2021-01-20 13:00:44,036 ERROR org.apache.ranger.rest.ServiceREST:
> createService(RangerService={id=
> {null}
> guid=\{null} isEnabled=\{true} createdBy=\{null} updatedBy=\{null}
> createTime=\{null} updateTime=\{null} version=\{1} name=\{cm_hdfs}
> displayName=\{cm_hdfs} type=\{hdfs} description=\{Hdfs repo}
> tagService=\{null} configs={tag.download.auth.users=
> {hdfs}
> password=LOG-REDACTED policy.download.auth.users=\{hdfs}
> hadoop.security.authentication=\{kerberos}
> hadoop.rpc.protection=\{authentication}
> [fs.default.name|http://fs.default.name/]=\{hdfs://dy-upg41-3.dy-upg41.root.hwx.site:8020}
> hadoop.security.authorization=\{true} username=\{hdfs} }
> policyVersion=\{null} policyUpdateTime=\{null} tagVersion=\{1}
> tagUpdateTime=\{null} }) failed
> javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse
> Persistence Services - 2.7.7.v20200504-69f2c2b80d):
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception:
> com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock
> found when trying to get lock; try restarting transaction
> Error Code: 1213
> Call: INSERT INTO x_portal_user (ADDED_BY_ID, CREATE_TIME, EMAIL, FIRST_NAME,
> LAST_NAME, LOGIN_ID, NOTES, OTHER_ATTRIBUTES, PASSWORD, PUB_SCR_NAME, STATUS,
> UPDATE_TIME, UPD_BY_ID, USER_SRC) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?)
>
> *Observation:* 1. ** Service creation and user sync are running parallel, the
> issue is occurring when the number of users are more (around 1000) to sync.
> This issue leads to failure in cm_hdfs service creation along with migration
> failure.
> 2. Everytime issue occurs at the time when user sync
> tries to update admin users in x_portal_user.
> 3. I have tried increasing the
> innodb_lock_wait_timeout time from 50(default) to 120 on the cluster
> dy-upg41-3.dy-upg41.root.hwx.site, then migrated the cluster. Still the same
> issue occurred.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (RANGER-3175) Add back the support to provide option to retrieve users from group member attribute
[ https://issues.apache.org/jira/browse/RANGER-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3175: --- Attachment: 0001-RANGER-3175-Adding-back-support-to-retrieve-users-us.patch > Add back the support to provide option to retrieve users from group member > attribute > > > Key: RANGER-3175 > URL: https://issues.apache.org/jira/browse/RANGER-3175 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3175-Adding-back-support-to-retrieve-users-us.patch > > > As part of usersync performance improvements (RANGER-2986), disabling > usersearch option is removed. This forces customers to configure user search > related properties and complex user search filter in order to retrieve users > from a group if there is no "memberof" overlay supported in the LDAP server. > Add support to provide option to disable user search and instead use group > member attribute to retrieve users from a group. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3175) Add back the support to provide option to retrieve users from group member attribute
Sailaja Polavarapu created RANGER-3175: -- Summary: Add back the support to provide option to retrieve users from group member attribute Key: RANGER-3175 URL: https://issues.apache.org/jira/browse/RANGER-3175 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu Fix For: 3.0.0, 2.2.0 As part of usersync performance improvements (RANGER-2986), disabling usersearch option is removed. This forces customers to configure user search related properties and complex user search filter in order to retrieve users from a group if there is no "memberof" overlay supported in the LDAP server. Add support to provide option to disable user search and instead use group member attribute to retrieve users from a group. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3169) Ranger Usersync config for keystore type and truststore type for LDAPS are not effective
[ https://issues.apache.org/jira/browse/RANGER-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3169: --- Attachment: 0001-RANGER-3169-Fixed-issue-where-we-are-not-reading-the.patch > Ranger Usersync config for keystore type and truststore type for LDAPS are > not effective > > > Key: RANGER-3169 > URL: https://issues.apache.org/jira/browse/RANGER-3169 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3169-Fixed-issue-where-we-are-not-reading-the.patch > > > Ranger Usersync configuration for keystore type and trusstore type values are > ignored and are always default to jceks. When FIPS is enabled, connecting to > LDAP with secure connection fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3169) Ranger Usersync config for keystore type and truststore type for LDAPS are not effective
Sailaja Polavarapu created RANGER-3169: -- Summary: Ranger Usersync config for keystore type and truststore type for LDAPS are not effective Key: RANGER-3169 URL: https://issues.apache.org/jira/browse/RANGER-3169 Project: Ranger Issue Type: Bug Components: Ranger, usersync Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu Ranger Usersync configuration for keystore type and trusstore type values are ignored and are always default to jceks. When FIPS is enabled, connecting to LDAP with secure connection fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3163) Ranger Database deadlock when Service creation and user sync are running parallel
Sailaja Polavarapu created RANGER-3163:
--
Summary: Ranger Database deadlock when Service creation and user
sync are running parallel
Key: RANGER-3163
URL: https://issues.apache.org/jira/browse/RANGER-3163
Project: Ranger
Issue Type: Bug
Components: Ranger
Reporter: Sailaja Polavarapu
Assignee: Sailaja Polavarapu
Fix For: 3.0.0, 2.2.0
Following is the error and some observations:
*Error :*
2021-01-20 13:00:44,036 ERROR org.apache.ranger.rest.ServiceREST:
createService(RangerService={id=
{null}
guid=\{null} isEnabled=\{true} createdBy=\{null} updatedBy=\{null}
createTime=\{null} updateTime=\{null} version=\{1} name=\{cm_hdfs}
displayName=\{cm_hdfs} type=\{hdfs} description=\{Hdfs repo} tagService=\{null}
configs={tag.download.auth.users=
{hdfs}
password=LOG-REDACTED policy.download.auth.users=\{hdfs}
hadoop.security.authentication=\{kerberos}
hadoop.rpc.protection=\{authentication}
[fs.default.name|http://fs.default.name/]=\{hdfs://dy-upg41-3.dy-upg41.root.hwx.site:8020}
hadoop.security.authorization=\{true} username=\{hdfs} } policyVersion=\{null}
policyUpdateTime=\{null} tagVersion=\{1} tagUpdateTime=\{null} }) failed
javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse
Persistence Services - 2.7.7.v20200504-69f2c2b80d):
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception:
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock
found when trying to get lock; try restarting transaction
Error Code: 1213
Call: INSERT INTO x_portal_user (ADDED_BY_ID, CREATE_TIME, EMAIL, FIRST_NAME,
LAST_NAME, LOGIN_ID, NOTES, OTHER_ATTRIBUTES, PASSWORD, PUB_SCR_NAME, STATUS,
UPDATE_TIME, UPD_BY_ID, USER_SRC) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?)
*Observation:* 1. ** Service creation and user sync are running parallel, the
issue is occurring when the number of users are more (around 1000) to sync.
This issue leads to failure in cm_hdfs service creation along with migration
failure.
2. Everytime issue occurs at the time when user sync
tries to update admin users in x_portal_user.
3. I have tried increasing the innodb_lock_wait_timeout
time from 50(default) to 120 on the cluster dy-upg41-3.dy-upg41.root.hwx.site,
then migrated the cluster. Still the same issue occurred.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (RANGER-3153) Upgrade to TLS to version 1.2 and above
[ https://issues.apache.org/jira/browse/RANGER-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3153: --- Attachment: 0001-RANGER-3153-Updated-TLS-version-to-1.2-for-ranger.patch > Upgrade to TLS to version 1.2 and above > > > Key: RANGER-3153 > URL: https://issues.apache.org/jira/browse/RANGER-3153 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3153-Updated-TLS-version-to-1.2-for-ranger.patch > > > Ranger offers a TLS v1.0 protocol to provide communications security over a > computer network. > It is recommended to switch all communications to a newer version of the > protocol (v 1.2 or 1.3) which is more secure than the older versions. > Ranger's Admin Unix Auth Service(ranger.unixauth.service.port) runs on port > 5151 which found to have TLS 1.0 enabled. > TLS1.0 needs to be disabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3153) Upgrade to TLS to version 1.2 and above
[ https://issues.apache.org/jira/browse/RANGER-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu reassigned RANGER-3153: -- Assignee: Sailaja Polavarapu > Upgrade to TLS to version 1.2 and above > > > Key: RANGER-3153 > URL: https://issues.apache.org/jira/browse/RANGER-3153 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Ranger offers a TLS v1.0 protocol to provide communications security over a > computer network. > It is recommended to switch all communications to a newer version of the > protocol (v 1.2 or 1.3) which is more secure than the older versions. > Ranger's Admin Unix Auth Service(ranger.unixauth.service.port) runs on port > 5151 which found to have TLS 1.0 enabled. > TLS1.0 needs to be disabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3153) Upgrade to TLS to version 1.2 and above
Sailaja Polavarapu created RANGER-3153: -- Summary: Upgrade to TLS to version 1.2 and above Key: RANGER-3153 URL: https://issues.apache.org/jira/browse/RANGER-3153 Project: Ranger Issue Type: Bug Components: Ranger Reporter: Sailaja Polavarapu Fix For: 3.0.0, 2.2.0 Ranger offers a TLS v1.0 protocol to provide communications security over a computer network. It is recommended to switch all communications to a newer version of the protocol (v 1.2 or 1.3) which is more secure than the older versions. Ranger's Admin Unix Auth Service(ranger.unixauth.service.port) runs on port 5151 which found to have TLS 1.0 enabled. TLS1.0 needs to be disabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3143) Ranger usersync, user group mapping for user deletion is not syncing up, if only one user is present in the group
[ https://issues.apache.org/jira/browse/RANGER-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3143: --- Attachment: 0001-RANGER-3143-Fixed-issue-while-retrieving-groups-with.patch > Ranger usersync, user group mapping for user deletion is not syncing up, if > only one user is present in the group > - > > Key: RANGER-3143 > URL: https://issues.apache.org/jira/browse/RANGER-3143 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Affects Versions: 3.0.0, 2.2.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3143-Fixed-issue-while-retrieving-groups-with.patch > > > Steps to reproduce :- > Using unix as a source for syncing user and groups. > 1. Add a new group and user. > 2. Add user to the group. > 3. wait for sync to happen.(check ranger UI, user should be part of group) > 4. delete the user from group. > 5. You will still be able to see user is present in the group(from ranger UI). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3143) Ranger usersync, user group mapping for user deletion is not syncing up, if only one user is present in the group
Sailaja Polavarapu created RANGER-3143: -- Summary: Ranger usersync, user group mapping for user deletion is not syncing up, if only one user is present in the group Key: RANGER-3143 URL: https://issues.apache.org/jira/browse/RANGER-3143 Project: Ranger Issue Type: Bug Components: Ranger, usersync Affects Versions: 3.0.0, 2.2.0 Reporter: Sailaja Polavarapu Assignee: Sailaja Polavarapu Steps to reproduce :- Using unix as a source for syncing user and groups. 1. Add a new group and user. 2. Add user to the group. 3. wait for sync to happen.(check ranger UI, user should be part of group) 4. delete the user from group. 5. You will still be able to see user is present in the group(from ranger UI). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-980) User sync does not delete users if they do not exist anymore
[ https://issues.apache.org/jira/browse/RANGER-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-980: -- Attachment: 0001-RANGER-980-Support-for-deleted-users-groups-in-Range.patch > User sync does not delete users if they do not exist anymore > > > Key: RANGER-980 > URL: https://issues.apache.org/jira/browse/RANGER-980 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 0.6.0, 0.5.3 >Reporter: Bolke de Bruin >Assignee: Sailaja Polavarapu >Priority: Critical > Labels: security > Attachments: > 0001-RANGER-980-Support-for-deleted-users-groups-in-Range.patch, > 0001-RANGER-980-User-sync-does-not-delete-users-if-they-d.patch, Deleted > users and groups support in Ranger (RANGER-980).pdf, RANGER-980.patch > > > usersync for all sources creates users and groups, but does not delete them > from Ranger's database if these users and groups do not exists anymore in the > original source. > So if you have for example a user called "bob" and bob leaves the company his > access rights will continue to exist in Ranger. If a new employee comes in > that is also "bob" he is immediately granted the same access as the previous > employee. This creates security incidents. > In a reasonable complex company it cannot be expected that another user > administration is being taken care of, while deletion could and should happen > automatically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-980) User sync does not delete users if they do not exist anymore
[ https://issues.apache.org/jira/browse/RANGER-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253200#comment-17253200 ] Sailaja Polavarapu commented on RANGER-980: --- Attaching the high level design document on the approach for supporting deleted users/groups in Ranger. > User sync does not delete users if they do not exist anymore > > > Key: RANGER-980 > URL: https://issues.apache.org/jira/browse/RANGER-980 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 0.6.0, 0.5.3 >Reporter: Bolke de Bruin >Assignee: Sailaja Polavarapu >Priority: Critical > Labels: security > Attachments: > 0001-RANGER-980-User-sync-does-not-delete-users-if-they-d.patch, Deleted > users and groups support in Ranger (RANGER-980).pdf, RANGER-980.patch > > > usersync for all sources creates users and groups, but does not delete them > from Ranger's database if these users and groups do not exists anymore in the > original source. > So if you have for example a user called "bob" and bob leaves the company his > access rights will continue to exist in Ranger. If a new employee comes in > that is also "bob" he is immediately granted the same access as the previous > employee. This creates security incidents. > In a reasonable complex company it cannot be expected that another user > administration is being taken care of, while deletion could and should happen > automatically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-980) User sync does not delete users if they do not exist anymore
[ https://issues.apache.org/jira/browse/RANGER-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-980: -- Attachment: Deleted users and groups support in Ranger (RANGER-980).pdf > User sync does not delete users if they do not exist anymore > > > Key: RANGER-980 > URL: https://issues.apache.org/jira/browse/RANGER-980 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 0.6.0, 0.5.3 >Reporter: Bolke de Bruin >Assignee: Sailaja Polavarapu >Priority: Critical > Labels: security > Attachments: > 0001-RANGER-980-User-sync-does-not-delete-users-if-they-d.patch, Deleted > users and groups support in Ranger (RANGER-980).pdf, RANGER-980.patch > > > usersync for all sources creates users and groups, but does not delete them > from Ranger's database if these users and groups do not exists anymore in the > original source. > So if you have for example a user called "bob" and bob leaves the company his > access rights will continue to exist in Ranger. If a new employee comes in > that is also "bob" he is immediately granted the same access as the previous > employee. This creates security incidents. > In a reasonable complex company it cannot be expected that another user > administration is being taken care of, while deletion could and should happen > automatically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3101) Ranger usersync not recovering from initial errors in subsequent syncs
[ https://issues.apache.org/jira/browse/RANGER-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3101: --- Fix Version/s: 2.2.0 3.0.0 > Ranger usersync not recovering from initial errors in subsequent syncs > -- > > Key: RANGER-3101 > URL: https://issues.apache.org/jira/browse/RANGER-3101 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Affects Versions: 3.0.0, 2.2.0 >Reporter: Abhishek Shukla >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3101-Added-code-to-handle-updating-users-in-c.patch > > > One issue noticed was that during initial sync a deadlock was detected while > updating x_portal_user table which caused the initial sync failure. The > subsequent syncs should have been successful, but because of a missing error > case check during update of this user, subsequent syncs are also failing. > From the logs, I noticed that the initial DB deadlock happened for a service > user. This user is being created by usersync during which I also see service > creation request which also creates the service user if doesn't exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3112) Ranger usersync unit test cases are failing on mac
[ https://issues.apache.org/jira/browse/RANGER-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3112: --- Fix Version/s: 2.2.0 3.0.0 > Ranger usersync unit test cases are failing on mac > -- > > Key: RANGER-3112 > URL: https://issues.apache.org/jira/browse/RANGER-3112 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Affects Versions: 3.0.0, 2.2.0 >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3112-Fixed-usersync-unit-test-failures.patch > > > Following unix sync unit tests are failing when compiling on mac: > [INFO] Running > org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder[INFO] Running > org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder[ERROR] Tests > run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 5.058 s <<< > FAILURE! - in > org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder[ERROR] > testBuilderNss(org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder) > Time elapsed: 1.674 s <<< FAILURE!java.lang.AssertionError at > org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder.testBuilderNss(TestUnixUserGroupBuilder.java:83) > [ERROR] > testBuilderPasswd(org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder) > Time elapsed: 0.004 s <<< FAILURE!java.lang.AssertionError at > org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder.testBuilderPasswd(TestUnixUserGroupBuilder.java:65) > [INFO][INFO] Results:[INFO][ERROR] Failures:[ERROR] > TestUnixUserGroupBuilder.testBuilderNss:83[ERROR] > TestUnixUserGroupBuilder.testBuilderPasswd:65[INFO][ERROR] Tests run: 28, > Failures: 2, Errors: 0, Skipped: 0[INFO][INFO] > [INFO] > BUILD FAILURE[INFO] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-3112) Ranger usersync unit test cases are failing on mac
Sailaja Polavarapu created RANGER-3112: -- Summary: Ranger usersync unit test cases are failing on mac Key: RANGER-3112 URL: https://issues.apache.org/jira/browse/RANGER-3112 Project: Ranger Issue Type: Bug Components: Ranger, usersync Affects Versions: 3.0.0, 2.2.0 Reporter: Sailaja Polavarapu Following unix sync unit tests are failing when compiling on mac: [INFO] Running org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder[INFO] Running org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder[ERROR] Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 5.058 s <<< FAILURE! - in org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder[ERROR] testBuilderNss(org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder) Time elapsed: 1.674 s <<< FAILURE!java.lang.AssertionError at org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder.testBuilderNss(TestUnixUserGroupBuilder.java:83) [ERROR] testBuilderPasswd(org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder) Time elapsed: 0.004 s <<< FAILURE!java.lang.AssertionError at org.apache.ranger.unixusersync.process.TestUnixUserGroupBuilder.testBuilderPasswd(TestUnixUserGroupBuilder.java:65) [INFO][INFO] Results:[INFO][ERROR] Failures:[ERROR] TestUnixUserGroupBuilder.testBuilderNss:83[ERROR] TestUnixUserGroupBuilder.testBuilderPasswd:65[INFO][ERROR] Tests run: 28, Failures: 2, Errors: 0, Skipped: 0[INFO][INFO] [INFO] BUILD FAILURE[INFO] -- This message was sent by Atlassian Jira (v8.3.4#803005)
