Sanity checking before entering a ticket.

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

Reply via email to