Nicholas Hughes created RANGER-1224:
---------------------------------------
Summary: 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)
