[jira] [Commented] (RANGER-2705) Group sync does does not parse DNs properly
[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083897#comment-17083897
]
Pradeep Agrawal commented on RANGER-2705:
-
Patch committed :
[https://github.com/apache/ranger/commit/6827eb7351708c22d45481fda8cfa61467f60741#diff-d8dc3d69c5f905af1355c0e63418115c]
> 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
>Assignee: Sailaja Polavarapu
>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)
[jira] [Commented] (RANGER-2705) Group sync does does not parse DNs properly
[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034265#comment-17034265
]
Lars Francke commented on RANGER-2705:
--
Thanks for looking at this [~spolavarapu].
Yes, we're using groupSearchFirstEnabled because we only want to retrieve a
particular set of groups (I have to admit that I already forgot some of the
details but I can check again next week). If we do not use groupSearchFirst
Usersync retrieves all groups for the users and those go into the thousands
with this customer. So we'd like to do it the other way around: Only sync a
subset of groups.
"Francke\, Lars" is the DN but what we'd really like/need is the
"sAMAccountName". So this issue is only step one and I haven't checked whether
Ranger supports the next step. It now needs to map those DNs to the full user
names it retrieved from the user search and then look up their proper user name.
I hope that helps? If not I'm back with the customer next week and can check on
it then and provide a more detailed response.
> 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)
[jira] [Commented] (RANGER-2705) Group sync does does not parse DNs properly
[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034174#comment-17034174
]
Sailaja Polavarapu commented on RANGER-2705:
[~larsfrancke],
I agree there is an issue in the getShortUserName(). But if you notice, the
username returned from this method is only used when groupSearchFirstEnabled:
true, userSearchEnabled: false. Is this your configuration?
[https://github.com/apache/ranger/blob/master/ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapDeltaUserGroupBuilder.java#L770]
Also, if ranger sync the users with comma character properly like (Francke\,
Lars), how are these users configured in Hadoop for authorization with ranger?
Can you provide some details on what is the use case?
BTW - I completely agree that there is an issue with getShortUserName() and
will work on the fix. But trying to understand how these users are used in
hadoop as commas are generally not allowed for the unix users.
> 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)
[jira] [Commented] (RANGER-2705) Group sync does does not parse DNs properly
[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (RANGER-2705) Group sync does does not parse DNs properly
[
https://issues.apache.org/jira/browse/RANGER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022920#comment-17022920
]
Lars Francke commented on RANGER-2705:
--
btw. {{LdapUserGroupBuilder}} is also affected but only if groupSearchFirst is
enabled
> 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 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)
