nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

restricted access for admin?

dD_fzic1p

Dear Community,

I was wondering if it is possible to restrict access to certain projects for Jira admins in the Jira software?

The reason is that I am a student working for my university in a Jira project where we automate administrative processes. Therefore I need admin rights to use scriptrunner, user management and so on....

So I need to have access to these tools and functions, but I am not allowed to see other projects where sensitive information is stored. Is there any solution for this problem?

Best thanks in advance!

Accepted answers

Nic Brough -Adaptavist-

No, the role of an admin is to administrate the system. Most of the things they can do are about changing global things, they can't be limited to projects.

You can set it up so an admin can't see projects when acting as a non-admin user, but they will always be able to administrate those projects, and hence be able to get access to them (permission schemes are one of the things admins can control, and they're shared)

The only real solution is that you have to trust your admins.

Florian PEREZ _Valiantys Administrator_

You can restrict access on the project for admin by adding a security scheme to your issues. You can even try to restrict the access to a group map only in a AD where they can't interract.

Yeah administrators can still add a jira group with the same name as you AD group add themself in this group in order to get the vision on the issues but it will be a voltary action and you should be able to find who has done this modification just by looking at the audit log.

But let's be honnest, as Nick said you should trust the Jira administrators in general. Restricting thing to them will just make support much harder for them if they need to help you later.

All comments

Nic Brough -Adaptavist-

No, the role of an admin is to administrate the system. Most of the things they can do are about changing global things, they can't be limited to projects.

The only real solution is that you have to trust your admins.

Florian PEREZ _Valiantys Administrator_

You can restrict access on the project for admin by adding a security scheme to your issues. You can even try to restrict the access to a group map only in a AD where they can't interract.

But let's be honnest, as Nick said you should trust the Jira administrators in general. Restricting thing to them will just make support much harder for them if they need to help you later.

dD_fzic1p

This helped me a lot, thank you!

dD_fzic1p

Yes, that is correct! Thank you for your answer.

Slava Gefen

You can restrict access on the project for admin by adding a security scheme to your issues.

But other admins can add themselves to this security level or add new one) The only way is to demote them to project admin or trust them - it's true!

Bruce Hoenig

While true that you might be able to create a local group with the same name as one coming from A/D, directory priority should come into play on this. By making A/D first in the priority list, A/D may help limit what Jira considers, either A/D or Jira local / internal crowd and ultimately if the member of the local group is actually in the same named group would truly be a member of the privileged (duplicate) group. I've not tested this, but I'm basing part of this answer on how Jira reacts to users in multiple directories. In that case Jira figures out what user you are based on password and from my observations assigns permissions based on that. Basically user1 (A/D) does not equal user2 (local/crowd), so with that assumption, I would guess that group1 does not equal group2. JIra gets quite nasty with userid "duplication" between directories, ultimately the unique attribute helps to sort this out. I ran into this when migrating across multiple A/D directories In order for users to not lose their Jira tickets, the User Unique ID Attribute is the thing that needs to be consistent in both directories, when migrating from one A/D domain to another.

In my case the "same" userid name came from 2 different A/D instances. Jira does get picky when doing things like this. Including making new userid's that look the same, but are not.

Out of curiosity, I attempted to create a new local jira-administrators group. This did NOT work with Jira complaining that "group or user with this name already exists".

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software

jira-core

restriction

administration