Support 'sudoers' functionality
alainassaf opened this issue · comments
Description of the new feature / enhancement
The current granularity available with UAC, group policy, and NTFS permissions is lacking compared to utilizing a 'sudoers' file as supported in Linux implementations of sudo. It would be very useful for win admins to utilize 'sudoers' to further control permissions on a windows system and not grant administrative access to perform certain actions.
My perspective is more on the server side of things, but it could be useful for workstations and systems that don't have or use Active Directory.
Scenario when this would be used?
In an IT organization with multiple tiers of admins, there's a need to prevent certain admins from having Full administrative access.
- Server build team - creates builds from scratch and incorporates any organization's standards and security settings
- Server operations team - responsible for maintenance and operations (patching, resource allocation, etc) of systems. Should not be able to make changes to standards or security settings.
- Software Admin team - responsible for applications installed on the server. Can patch/upgrade software, but not windows or security patches. Should not be able to make changes to standards or security settings.
These 3 different teams currently have full admin access to a server. This can isolated with restricted groups in AD, but that still grants full administrative access to a system that a server operations or software admin team don't necessarily need.
Incorporating 'sudoers' allows granting certain folder and executable permissions to certain groups, users, or service accounts.
Supporting information
- RHEL - Managing sudo access
- Ubuntu - Sudoers
I agree with this.
This should be a topic for Windows Security Groups. Even computers outside domains have Security Policy, Local Policy, and Security Groups. So if all these (and similar) usage cases were to be implemented in the current framework it would already be an improvement. This includes pretty standard issue of giving non-privileged user a right to run just a single application "as Admin".
The logic is already there with JEA, but this could be a much simpler wrapper for it.
The logic is already there with JEA, but this could be a much simpler wrapper for it.
Not so sure about it. From JEA requirements:
PowerShell Remoting provides the foundation on which JEA is built. It's necessary to ensure PowerShell Remoting is enabled
As this would be local sudo, you wouldn't go through PS remote, and thus what seems as main requirement would be unavailable. If they can make it work locally IDK.