[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030827#comment-17030827
]
Velmurugan Periasamy commented on RANGER-2705:
----------------------------------------------
CC [~spolavarapu]
> Group sync does does not parse DNs properly
> -------------------------------------------
>
> Key: RANGER-2705
> URL: https://issues.apache.org/jira/browse/RANGER-2705
> Project: Ranger
> Issue Type: Bug
> Components: usersync
> Reporter: Lars Francke
> Priority: Major
>
> When we have enabled user & group search
> ({{ranger.usersync.group.search.first.enabled}} = false) we expect Ranger to
> get the groups and its members and compare them to what already exists.
> Our DN/CN looks like this:
> {code:java}
> CN=Francke\, Lars,OU=....bla bla.
> {code}
> Our CN contains a comma but the {{getShortUserName}} method in
> {{LdapDeltaUserGroupBuilder}} has this piece of code:
> {code:java}
> StringTokenizer stc = new StringTokenizer(longUserName, ",");
> String firstToken = stc.nextToken();{code}
> The intention is that it gets the "{{CN=Francke\, Lars}}" part (the first
> part of the comma-separated DN) but that doesn't work if that contains a
> comma itself. It is escaped but Ranger just splits at the comma. That's
> definitely a bug. It should use the {{LdapName}} class instead and/or parse
> according to the RFC 2253 but maybe even that is wrong what it really should
> probably do is the same as user sync?
> This way we currently cannot use (incremental) group sync at all because if
> we do we don't get any groups at all as the user search doesn't take its own
> groups when group sync is also enabled (this was another surprise).
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
