[
https://issues.apache.org/jira/browse/RANGER-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15724783#comment-15724783
]
Don Bosco Durai commented on RANGER-1224:
-----------------------------------------
[~nicholasmhughes], I agree deriving sAMAccountName from the CN might not be a
good idea.
While we should fix the issue from the Ranger side to handle spaces, you should
be careful while sync'ing users from AD to Ranger with CN or DN as username. In
general, you should sync the username as it is understood by Hadoop and YARN.
This will ensure consistency and guarantee that it will work with all Hadoop
components.
Since NiFi uses certificates, you might have to sync both sAMAccountName and
whatever that is passed by NiFi. This will result in duplicate users. I would
recommend (after the bug is fixed) that you review your deployment to see how
many users will be using NiFI and only sync those users (or manually add them)
to avoid too many redundant users.
> 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)
