1. Proposed title of this feature request

[RFE] Group Policy Plugin in sssd


2. Who is the customer behind the request?

Account: RBOS FM ,#729867
TAM customer: yes
CSM customer: yes
Strategic:    yes
 
3. What is the nature and description of the request?

This request is for an enhancement to sssd-ad that would enable it to honour the 'nonunix_group' and 'nonunix_gid' syntax directives detailed in the sudoers man page, allowing non-POSIX groups to be specified in sudoers rules.


The default Sudo security policy plugin (sudoers) provides for the implementation of 'group provider' plugins specifically to enable non-UNIX group lookups (for more details see https://www.sudo.ws/man/sudo_plugin.man.html#Sudoers_group_plugin_API)


Please note that this request has been raised specifically to track upstream ticket https://pagure.io/SSSD/sssd/issue/4164  

4. Why does the customer need this? (List the business requirements here)

The banking sector is necessarily highly regulated, change control is the often subject to extreme scrutiny, audits are frequent. A fundamental requirement is that we are able, for a period of several years after the event, to provide full details of all changes made to production systems - what, when, by whom and with what authorisation. To that end, my company has already made a significant investment in a centralised system for managing privileged/elevated access across most of our platforms, which grants privilege using Active Directory group membership.


We would very much like to use the same system to manage privileged access across our Linux estate, where native sudo is the privilege escalation tool of choice, but for a number of mainly non-technical reasons the POSIX groups that are consumed by our Linux servers are not managed in Active Directory. Therefore in order for those servers to have their privileged access managed by the aforementioned centralised system, they would need to specify non-POSIX groups in their sudo rules.


The only viable alternative solutions at this stage are commercial products, eg Quest Authentication Services, which would entail a significant cost overhead in a large environment such as ours.



5. How would the customer like to achieve this? (List the functional requirements here)

The standard sudoers file format allows for the following directives to be used when specifying the User part of a sudoers rule:


         '!'* %:nonunix_group |
         '!'* %:#nonunix_gid |
...and, continuing the sudoers man page: 



The actual nonunix_group and nonunix_gid syntax depends on the underlying group provider plugin. For instance, the QAS AD plugin supports the following formats:





Group in the same domain: "%:Group Name"

Group in any domain: "%:Group Name.DOMAIN"

Group SID: "%:S-1-2-34-5678901234-5678901234-5678901234-567"



Obviously the sssd-ad implementation wouldn’t need to follow the QAS example precisely (although it is fairly comprehensive and useful), but from a personal perspective my main requirement is that it is able to rapidly resolve membership of non-POSIX groups, including indirect membership (suggesting use of an extensible match filter using OID 1.2.840.113556.1.4.1941)



6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

NA

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

NA

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

No specific timeline, just as soon as possible please.


RHEL 8



9. Is the sales team involved in this request and do they have any additional input?

No

10. List any affected packages or components.

sssd

11. Would the customer be able to assist in testing this functionality if implemented?

Yes