[jira] [Updated] (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:all-tabpanel
]
Pradeep Agrawal updated RANGER-2705:
Fix Version/s: 2.1.0
> 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
> Fix For: 2.1.0
>
>
> 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] [Updated] (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:all-tabpanel
]
Lars Francke updated RANGER-2705:
-
Description:
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).
was:
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).
> 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] [Updated] (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:all-tabpanel
]
Lars Francke updated RANGER-2705:
-
Description:
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).
was:
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.
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).
> 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)
[jira] [Updated] (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:all-tabpanel
]
Lars Francke updated RANGER-2705:
-
Description:
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.
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).
was:
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.
> 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.
> 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)
[jira] [Updated] (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: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)
