[
https://issues.apache.org/jira/browse/RANGER-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15446726#comment-15446726
]
Sailaja Polavarapu commented on RANGER-980:
-------------------------------------------
Currently x_portal_user contains more details about the user like first name,
last name, login id, etc... and I think it is better to add uid or DN also to
this table.
One quick question - Currently all the user/group attributes are configurable
in ranger and Ranger syncs only the attributes that are configured. Does the
new approach means that we always sync an extra attribute (UID or DN) without
making it configurable? Currently we are already saving DN in memory in
usersync for group membership computation. This info can be propagated to
ranger admin as well if we are planning to save DN in the ranger DB. For unix
based ldap servers anyway we recommend to configure uid as the username
attribute in ranger.
One more thing to point out is - currently when same user name is present in
multiple OUs, we are overwriting the already sync'd user with the latest
information. This ambiguity can be avoided by storing the DN information.
Thanks,
Sailaja.
> 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
> Priority: Critical
> Labels: security
> Attachments:
> 0001-RANGER-980-User-sync-does-not-delete-users-if-they-d.patch,
> 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
(v6.3.4#6332)
