Learn more about these different git repos.
Other Git URLs
(Apologies in advance from a first time submitter if this approach is not the right way of making this request, I'm just not sure how else to reach the people I know are most likely to be able to provide an authoritative/sensible answer...)
After a good deal of trawling around it is now clear to me that SSSD does not currently include a sudo group provider plugin capable of handling non-POSIX groups (does not include a sudo group provider plugin at all, right?), hence the oft-stated requirement that any AD group specified in a sudo rule must be resolvable by the id command/NSS.
My question is therefore simply: Are there any plans to create one?!
In my environment such a thing would be extremely useful, and I'm kinda surprised that there doesn't seem to be more demand for one?....I work in a large, heterogeneous, highly regulated environment that is badly hampered by legacy and in which shared filesystem usage is widespread. POSIX ID number consistency is therefore critical and handled externally by a system that does not link up with the one that handles privilege assignment. So to mandate that the privilege assignment system must also set gidNumber number is a BIG deal, so big in fact that they will probably prefer to spend money on QAS (includes a sudo plugin as you probably already know), which is something I have been trying REALLY hard to avoid!
Do you hear many other similar stories?! I found several threads where people were initially trying to do something very similar, but many of them seemed to be able to assign a GID to their group.
(Sorry, I would love to be able to write it myself but unfortunately I am not a C man)
The short answer is no - we have no plans for such plugin. There was not any demand so far since our customers/users either use idmapping (generating unix id from SID) or as you wrote they have posix id assigned.
Can you describe your use case and your environment in more detail?
Thanks for getting back to me Pavel and sorry for the slow response. I just wanted to let you know that this is still something I am keen to discuss, but as I am about to go on a short holiday I probably wont get time to answer your question in more detail until next week.
Hi Pavel, apologies again for the long silence.
Our environment (a large to medium sized bank) consists of approximately 12000 Linux hosts, 38000 POSIX users and 5000 POSIX groups, stored in a handful of AD domains. We also make extensive use of shared filesystems – NAS devices serving NFS exports that are mounted by anything up to several thousand Linux hosts. Some of the NFS exports are also mounted via an SMB interface by Windows servers.
Most of our technical challenges derive from the following facts:
The widespread use of shared filesystems makes UID/GID consistency critical, but the handicaps of architectural legacy and inertia mean that the task of migrating away from the existing ID number space to one allocated algorithmically by SSSD would be at best a highly laborious and risky undertaking – one would probably need to identify all file objects on all Linux hosts and NAS resources with a particular ID number, then chown them all, potentially during a single change window. Lack of budget and risk appetite mean that ID mapping isn’t something we can consider at this stage.
So for the foreseeable future, our POSIX attributes will continue to be managed by an external process/tool that is itself legacy and barely supportable, but most significantly is entirely separate to the system that is used to manage user privileges (by AD group membership). That tool (relatively modern and well supported) manages a set of AD groups that does not (and cannot) overlap with the set of POSIX groups managed by the legacy tool, which is where our requirement for non-POSIX groups in sudo rules comes from – privileged access must be managed by the central (non-legacy) system, which we would like to be able to also cover the Linux platform, therefore our sudo rules need to work with non-POSIX groups.
Hopefully this makes things a little clearer
I am fairly sure that there are certain features of our environment that will be common to many other banks, definitely in the UK, so I would hope this would be a popular new feature. I do see several posts where sssd users were initially just wanting to use AD groups in their sudo rules, groups that were not already POSIX enabled, but often they are able to live with the workaround of assigning a GID. Unfortunately for us the only workaround would seem to be to tie ourselves into a commercial product such as QAS.
Is there anything more I can/should do to promote this feature request please?
Here's how I understand it:
1) You have an AD domain that contains a) POSIX users/group which uid and gid is managed by your application b) non-POSIX users and groups. 2) You want to use non-POSIX groups for sudo rules. 3) You can't convert to SSSD's algorithmic SID->ID mapping due to extensive usage of shared filesystems where it is not possible (or difficult) to switch to IDs generated by SSSD.
Do I understand it correctly?
If yes,why do you need to use non-POSIX group for sudo? Are non-POSIX groups part of different AD domain then POSIX groups?
Thanks Pavel. Yes you understand correctly but perhaps I need to elaborate about the process we use to manage privileged access...
Due to the strict regulations and need for an audit trail behind every change we make, assigning privileged access is something that’s taken very seriously. Therefore significant investment has already been made in a centrally managed automated self service system that meets all those regulatory requirements and already services a number of different platforms and environments. It works simply by managing a specific set of AD groups in various domains.
We are therefore very keen to bring all our Linux environments into the fold, but the largest of those has its POSIX users/groups/netgroups managed by an ancient NIS based external system (which is a whole tale of woe in itself but suffice to say that getting rid of that will be as hard as changing UID numbers!) that regularly push syncs those users and groups into AD. Therefore any attempts by the privilege management system to alter the memberships of those POSIX groups in AD would be futile since the periodic sync from the external tool would revert the changes.
Hopefully that makes our problem a little clearer?
Thank you. So ideally, you should move away from ancient systems but I see how that can be a problem in a short term. I think other will benefit from this as well.
I'm not yet sure if group policy plugin is needed since SSSD is already evaluating the rules by itself to some level (to allow fully qualified domains) so perhaps we could leverage this.
Since you are a RHEL customer, please use customer portal and let support engineers to open an RFE bug, this will make this ticket prioritized.
Thanks again Pavel. I have just added an update in my customer ticket that will hopefully result in the RFE BZ being raised shortly: https://access.redhat.com/support/cases/#/case/02593991?commentId=a0a2K00000UQF9iQAH
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/5119
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.