[
https://issues.apache.org/jira/browse/RANGER-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158291#comment-16158291
]
Hari Sekhon commented on RANGER-1768:
-------------------------------------
Thanks [~vperiasamy]
I didn't see much in the way of documentation on these ... have they been
widely tested yet?
> User Sync: add NSS standard user/group resolver mechanism to transparently
> support all Linux OS level identity management systems
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: RANGER-1768
> URL: https://issues.apache.org/jira/browse/RANGER-1768
> Project: Ranger
> Issue Type: New Feature
> Components: usersync
> Affects Versions: 0.7.0
> Environment: HDP 2.6
> Reporter: Hari Sekhon
>
> Feature Request to add UserSync support for the standard Linux NSS user/group
> resolver mechanism to allow offloading user/group integration to the standard
> OS tools like SSSD.
> This will allow Ranger to sync users and groups from the Linux OS integration
> layer using the standard user/group resolver modules which will cover all
> possible mechanisms which can include anything that the widely used SSSD can
> do including both local and LDAP users (which would obsolete having to
> configure LDAP manually in Ranger as it would be transparent regardless of
> whether using Active Directory, Redhat IPA, OpenLDAP it would require no
> different schema configuration in Ranger etc) and it also allows more
> flexibility as the integration then becomes the more widely used standard
> Linux mechanisms, you can even mix different identity mechanisms through this
> one usersync method, including local accounts and AD / LDAP accounts if
> needed (some clients have asked for this).
> This is more similar to what Hadoop does, just ask the OS, and is much more
> flexible, simpler to configure as it's transparent to Ranger once it switches
> to just doing the NSS lookup, rather than doing its own separate extra LDAP
> configuration integration directly and ending with up with issues like
> RANGER-1735 group nesting problems when SSSD solved that back in 2011.
> Although this group nesting problem is severe enough to likely be fixed soon
> (it affects customers I'm representing right now too), the point remains that
> offloading the integration to NSS is by definition more robust, feature
> complete and more widely tested across many other applications that leverage
> it.
> This is also a Redhat recommendation, see:
> http://rhelblog.redhat.com/2016/04/26/why-use-sssd-instead-of-a-direct-ldap-configuration-for-applications/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
