[GH-ISSUE #5326] [Feature Request]: Enforced Default JIT Admin Template per Tenant / Role Authorization #2564

Closed
opened 2026-03-02 13:53:22 +03:00 by kerem · 10 comments
Owner

Originally created by @m365mgmtprd on GitHub (Feb 4, 2026).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/5326

Originally assigned to: @Zacgoose on GitHub.

Please confirm:

  • I have searched existing feature requests (open and closed) and found no duplicates.
  • **me or my organization is currently an active sponsor of the product at the $99,- level.

Problem Statement

In the current CIPP implementation, a JIT Admin Template can be defined as the default for a tenant, but it can still be manually overridden by users with sufficient permissions. This creates an operational and security gap: Operation Services requires JIT Admin access for 2nd- and 3rd‑level support, but they should not be able to freely select any role. The absence of enforcement or an approval workflow makes it impossible to guarantee consistent, controlled role assignments.

Benefits for MSPs

  • Stronger Governance & Compliance: MSPs can enforce strict role boundaries and ensure that JIT privileges align with internal security policies and customer-specific requirements.
  • Reduced Human Error: Preventing manual overrides minimizes the risk of accidental assignment of high‑privilege roles.
  • Operational Efficiency: Standardised, enforced templates streamline support processes across multiple tenants, reducing overhead and potential misconfigurations.
  • Increased Customer Trust: Customers expect MSPs to control privileged access tightly; enforced templates demonstrate maturity and adherence to least‑privilege principles.

Value or Importance

This feature significantly enhances security posture for MSPs operating in multi‑tenant environments. Enforcing a JIT Admin Template—or introducing an approval process—ensures that privileged access remains predictable, auditable, and compliant with least‑privilege requirements. For organisations with dedicated support teams, it prevents unauthorized escalation and guarantees that JIT Admin roles align with predefined operational responsibilities. Overall, it strengthens CIPP’s role as a secure, enterprise‑ready management platform.

PowerShell Commands (Optional)

No response

Originally created by @m365mgmtprd on GitHub (Feb 4, 2026). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/5326 Originally assigned to: @Zacgoose on GitHub. ### Please confirm: - [x] **I have searched existing feature requests** (open and closed) and found no duplicates. - [x] **me or my organization is currently an active sponsor of the product at the $99,- level. ### Problem Statement In the current CIPP implementation, a JIT Admin Template can be defined as the default for a tenant, but it can still be manually overridden by users with sufficient permissions. This creates an operational and security gap: Operation Services requires JIT Admin access for 2nd- and 3rd‑level support, but they should not be able to freely select any role. The absence of enforcement or an approval workflow makes it impossible to guarantee consistent, controlled role assignments. ### Benefits for MSPs - Stronger Governance & Compliance: MSPs can enforce strict role boundaries and ensure that JIT privileges align with internal security policies and customer-specific requirements. - Reduced Human Error: Preventing manual overrides minimizes the risk of accidental assignment of high‑privilege roles. - Operational Efficiency: Standardised, enforced templates streamline support processes across multiple tenants, reducing overhead and potential misconfigurations. - Increased Customer Trust: Customers expect MSPs to control privileged access tightly; enforced templates demonstrate maturity and adherence to least‑privilege principles. ### Value or Importance This feature significantly enhances security posture for MSPs operating in multi‑tenant environments. Enforcing a JIT Admin Template—or introducing an approval process—ensures that privileged access remains predictable, auditable, and compliant with least‑privilege requirements. For organisations with dedicated support teams, it prevents unauthorized escalation and guarantees that JIT Admin roles align with predefined operational responsibilities. Overall, it strengthens CIPP’s role as a secure, enterprise‑ready management platform. ### PowerShell Commands (Optional) _No response_
Author
Owner

@Zacgoose commented on GitHub (Feb 5, 2026):

The current implementation was the intended design, it comes with the ability to enforce a max lifetime of accounts. If a tech is not trusted to make JIT accounts and or enforcing a max lifetime is not enough then my position if that you should restrict them from accessing the JIT account endpoint by making use of the RBAC controls in the admin permissions page.

<!-- gh-comment-id:3852206928 --> @Zacgoose commented on GitHub (Feb 5, 2026): The current implementation was the intended design, it comes with the ability to enforce a max lifetime of accounts. If a tech is not trusted to make JIT accounts and or enforcing a max lifetime is not enough then my position if that you should restrict them from accessing the JIT account endpoint by making use of the RBAC controls in the admin permissions page.
Author
Owner

@m365mgmtprd commented on GitHub (Feb 5, 2026):

Thanks for your feedback, @Zacgoose .

Now I understand your thinking/design.

However, our use case is as follows:

  • We don't have dedicated admin accounts for our customer tenant.
  • Technicians should be able to create JIT admin accounts
  • We have to follow a naming convention for display names and user names, but the JIT template can be overridden
  • Our technicians should not be able to obtain company admin rights; this can also be overridden

That is why we are asking whether the “Default” feature can be defined as mandatory rather than optional.

Translated with DeepL.com (free version)

<!-- gh-comment-id:3853527261 --> @m365mgmtprd commented on GitHub (Feb 5, 2026): Thanks for your feedback, @Zacgoose . Now I understand your thinking/design. However, our use case is as follows: - We don't have dedicated admin accounts for our customer tenant. - Technicians should be able to create JIT admin accounts - We have to follow a naming convention for display names and user names, but the JIT template can be overridden - Our technicians should not be able to obtain company admin rights; this can also be overridden That is why we are asking whether the “Default” feature can be defined as mandatory rather than optional. Translated with DeepL.com (free version)
Author
Owner

@Zacgoose commented on GitHub (Feb 5, 2026):

Okay we can add another switch/s in the admin page to restrict the ability to change the permissions and other aspects of a JIT template

<!-- gh-comment-id:3853630118 --> @Zacgoose commented on GitHub (Feb 5, 2026): Okay we can add another switch/s in the admin page to restrict the ability to change the permissions and other aspects of a JIT template
Author
Owner

@Zacgoose commented on GitHub (Feb 5, 2026):

I would like to work on this please!

<!-- gh-comment-id:3853650318 --> @Zacgoose commented on GitHub (Feb 5, 2026): I would like to work on this please!
Author
Owner

@github-actions[bot] commented on GitHub (Feb 5, 2026):

Great! I assigned you (@Zacgoose) to the issue. Have fun working on it!

<!-- gh-comment-id:3853651224 --> @github-actions[bot] commented on GitHub (Feb 5, 2026): Great! I assigned you (@Zacgoose) to the issue. Have fun working on it!
Author
Owner

@m365mgmtprd commented on GitHub (Feb 12, 2026):

Hello @Zacgoose , I just wanted to ask how things are progressing here? This is my first feature request, is there anything I can do? 😄

<!-- gh-comment-id:3888985503 --> @m365mgmtprd commented on GitHub (Feb 12, 2026): Hello @Zacgoose , I just wanted to ask how things are progressing here? This is my first feature request, is there anything I can do? 😄
Author
Owner

@Zacgoose commented on GitHub (Feb 13, 2026):

When I get time haha, I'll have more time soon ™️

<!-- gh-comment-id:3896571649 --> @Zacgoose commented on GitHub (Feb 13, 2026): When I get time haha, I'll have more time soon ™️
Author
Owner

@github-actions[bot] commented on GitHub (Feb 23, 2026):

This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.

<!-- gh-comment-id:3942186887 --> @github-actions[bot] commented on GitHub (Feb 23, 2026): This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.
Author
Owner

@m365mgmtprd commented on GitHub (Feb 23, 2026):

@Zacgoose should I do something about the message from the github action?

<!-- gh-comment-id:3942940106 --> @m365mgmtprd commented on GitHub (Feb 23, 2026): @Zacgoose should I do something about the message from the github action?
Author
Owner

@m365mgmtprd commented on GitHub (Feb 23, 2026):

hi @KelvinTegelaar Why has this request been closed? Therefore, this request will not be implemented?

<!-- gh-comment-id:3944340086 --> @m365mgmtprd commented on GitHub (Feb 23, 2026): hi @KelvinTegelaar Why has this request been closed? Therefore, this request will not be implemented?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/CIPP#2564
No description provided.