restricted access for admin?

[dD]

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!

[Florian PEREZ · Accepted solution]

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. 

[dD]

This helped me a lot, thank you!

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

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

You say 

"n that case Jira figures out what user you are based on password"

No, it does not. 

It finds the first matching user in the directories and stops there.  If you have three directories all containing "Bob", and "Bob" tries to log in, then Bob will need to use the password for the account in the first directory on the list.  Bob in directories 2 and 3 will be completely ignored.

It is the same with the groups - the first matching group will be used, and it will mask the groups in lower directories.

[Nic Brough -Adaptavist- · Accepted solution]

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.

[dD]

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