[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Francke updated RANGER-2705:
---------------------------------
Summary: Group sync does does not parse DNs properly (was: Group sync does
not respect ldap.user.nameattribute)
> 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.
> Unfortunately, we have set the user.nameattribute to the usual sAMAccountName
> which returns something along the lines of "AB12" for us (user Ids). The
> members' list that is returned from the groups, however, includes a full DN
> for each member:
>
> {code:java}
> CN=Francke\, Lars,OU=....bla bla.
> {code}
>
> There are two problems here:
> 1. 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.
>
> 2. Even if 1. would work there is no user "Francke, Lars" in Ranger. Ranger
> would need to use that DN to look up the user and then apply the
> {{user.nameattribute}} to match it to existing users.
> Update: I believe point 2 to be incorrect as it looks up the "fullUserName"
> in the "userNameMap".
>
> This way we currently cannot use 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 is made much harder by being all completely underdocumented ;)
> I guess it'd make sense to create two issues for this and I can do that
> tomorrow.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
