Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 'sudoers' functionality #36

Open
alainassaf opened this issue Feb 9, 2024 · 4 comments
Open

Support 'sudoers' functionality #36

alainassaf opened this issue Feb 9, 2024 · 4 comments
Labels
Issue-Feature New feature or request. Complex enough to require planning and actual budgeted, scheduled work.
Milestone

Comments

@alainassaf
Copy link

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

@alainassaf alainassaf added Issue-Feature New feature or request. Complex enough to require planning and actual budgeted, scheduled work. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Feb 9, 2024
@PH7N
Copy link

PH7N commented Feb 12, 2024

I agree with this.

@luxzg
Copy link

luxzg commented Feb 14, 2024

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".

@peterruzicska
Copy link

The logic is already there with JEA, but this could be a much simpler wrapper for it.

@luxzg
Copy link

luxzg commented Feb 22, 2024

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.

@joadoumie joadoumie added this to the Backlog milestone Mar 20, 2024
@joadoumie joadoumie removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature New feature or request. Complex enough to require planning and actual budgeted, scheduled work.
Projects
None yet
Development

No branches or pull requests

5 participants