You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Hari Sekhon (JIRA)" <ji...@apache.org> on 2017/09/07 10:45:00 UTC

[jira] [Created] (RANGER-1768) User Sync: add NSS standard user/group resolver mechanism to transparently support all Linux OS level identity management systems

Hari Sekhon created RANGER-1768:
-----------------------------------

             Summary: 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)