ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Hughes (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-1224) Ranger UI: DN as Username
Date Tue, 06 Dec 2016 00:27:58 GMT

    [ https://issues.apache.org/jira/browse/RANGER-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15723844#comment-15723844
] 

Nicholas Hughes commented on RANGER-1224:
-----------------------------------------

Hi Balaji,

That mapping pattern will work in some scenarios. However, we found that some Microsoft Active
Directory implementations build the CN from the First and Last names instead of the sAMAccountName.

For instance:
CN=Nick Hughes
instead of:
CN=nhughes

In the above case, there's no good way to extrapolate the sAMAccountName from the CN.

With kind regards,
Nicholas Hughes


> Ranger UI: DN as Username
> -------------------------
>
>                 Key: RANGER-1224
>                 URL: https://issues.apache.org/jira/browse/RANGER-1224
>             Project: Ranger
>          Issue Type: Bug
>         Environment: CentOS 6
> ranger_2_0_1_0_12-usersync-0.6.0.2.0.1.0-12.el6.x86_64
> ranger_2_0_1_0_12-admin-0.6.0.2.0.1.0-12.el6.x86_64
>            Reporter: Nicholas Hughes
>
> We deployed Ranger in our HDF cluster for authorization in NiFi. We're testing user authentication
and authorization with Microsoft Active Directory (AD) accounts in Ranger and NiFi.
> NiFi is able to use the sAMAccountName for authentication. However, it seems to only
send the CN and DN to Ranger for authorization. [1]
> Until that issue is fixed in NiFi, we were thinking that we could have UserSync in Ranger
import users from AD with the full DN (instead of the more desirable sAMAccountName) so NiFi
can authorize users properly. Setting the "ranger.usersync.ldap.user.nameattribute" value
to "distinguishedName" imports the users in this fashion. However, this has the unintended
effect of breaking the ability to edit policies after initial creation.
> This behavior can be observed by creating a user account containing a comma as you would
find in a DN (e.g. CN=Nick Hughes,OU=Users,OU=Accounts,DC=example,DC=com), adding it to a
resource based policy, and then attempting to edit that policy. You'll only get a "spinning
wheel" in the "Permissions" section of the "Allow Conditions".
> Specifically, the comma in the DN seems to be the issue. The API call only shows the
DN up to the first comma:
> http://192.168.1.177:6080/service/xusers/users/userName/CN=Nick Hughes
> ...and returns a 400 error stating that user is not found. Manually editing the URL above
to include the full DN returns the user information as expected.
> Can anyone confirm this behavior?
> Versions:
> ranger_2_0_1_0_12-usersync-0.6.0.2.0.1.0-12.el6.x86_64
> ranger_2_0_1_0_12-admin-0.6.0.2.0.1.0-12.el6.x86_64
> -Nick
> [1] https://issues.apache.org/jira/browse/NIFI-3020
> Hi Nicholas,
> Thank you for letting us know the issue. I tried in one of my setup and I see the same
behavior. Looks like the get request is not built correct may be not urlencoding the comma
character?
> I see the following in the ranger admin access logs:
> [18/Nov/2016:00:39:02 +0000] "GET /service/xusers/users/userName/CN=userou5 HTTP/1.1"
400 166
> Where as the actual username is: CN=userou5,OU=OU1,DC=ranger,DC=com
> Please enter a ticket as this is a valid issue and needs to be fixed.
> Just a side note though - in general comma (,) is treated as special character and is
not allowed in the username in unix as well as in AD. Hence the use case might not be valid
but should be handled in the code properly.
> Thanks,
> Sailaja.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message