Ranger Usersync

A vital part of the Ranger architecture is the ability to get users and groups from the corporate AD to use in policy definitions.

Ranger usersync runs as separate daemon:

It can also be (re)started separately from Ambari:

Usersync has a lot of moving parts and can have very different outcomes. Two main sets of properties govern the way users and groups are synchronized.

Without Enable Group Search First (a setting on the tab Group Configs) the primary access pattern is user based and groups will only be searched/added based on the users it finds first. In contrast, with Enable Group Search First enabled, the primary access pattern is group based (in turn based on the group search filter) and users will only be searched/added based on the group memberships it finds first

Value of ‘User Search Base’:
OU=CorpUsers,DC=field,DC=hortonworks,DC=com

Value of ‘User Search Filter’:
(|(memberOf=CN=Hdp_admins,OU=Company,OU=User Accounts,OU=CorpUsers,DC=field,DC=hortonworks,DC=com)(memberOf=CN=Hdp_users,OU=Company,OU=User Accounts,OU=CorpUsers,DC=field,DC=hortonworks,DC=com))

Value of ‘User Group Name Attribute’:
sAMAccountName

Value of ‘Group Search Base’:
(|(CN=Hdp_users)(CN=Hdp_admins))

Beware that the filters on group level limit the returns on the user search and vice versa. In the graph above if the left oval would be the results of all users queried by the settings on the User configs and the right oval all users queried by Group configs settings, the eventual set of users that make it to the Ranger usersync is the overlap between the two.

Hortonworks therefore recommends to have the filters on both ends set exactly the same to potentially have a 100% overlap in the ovals.

In the example configuration given the scope of the usersync would be all members of both the groups ‘Hdp_admins’ and ‘Hdp_users’.

The result in Ranger User list:

Regarding the other switches on the user and group sync pages, best of both worlds is to have Enable Group Search First and Enable User Search enabled at the same time.

The logging of a run of the usersync deamon can be retrieved from /var/log/ranger/usersync/usersync.log on the server hosting Ranger Admin. A successful run might output logging like below:

From that log it clearly shows that the groups are synced first and that all users belonging to those groups are then retrieved according to its own settings, after which the user parts are enriched/overwritten by the returns from the user queries.

Beware:

If you don’t enable Enable User Search that enrichment does NOT happen. Logging for such a run looks like this:

The result in Ranger UI are other user names (LongUserName) derived from ‘member’ group attributes full DN. You get the long name ‘James Kirk’ in the Ranger userlist in stead of j.kirk.

Ranger does not treat those as one and the same user:

Policies that were defined for user ‘k.reshi’ will not map to the user ‘Kvothe Reshi’ and vice versa. To prevent any confusion it is probably best to delete the long username versions from Rangers userlist.

Beware:

On the first page of Rangers user list there are lots of HDP system users. Most of them were put there by the Ranger installer and during the plugins installs:

Do NOT remove those system users!

There are basic access policies based on those system users designed to keep a Ranger governed HDP component working after Ranger is given all control over that components authorizations. Without those policies/users many HDP components will be in serious trouble.