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; } } }

Is there a "group" that represents all authenticated users? (Trying to give anyone who is logged in permissions)

NathanG

I'd like to give all authenticated users permission to create issues in my JIRA project.

Is there a group or permission that represents this?

Note: I'm using Active Directory to sync my users to JIRA... I'm using a somewhat complex LDAP Query and there are some of my users that sync to JIRA, but they aren't members of ANY group.

Theses users (the ones that have accounts in JIRA, but aren't in any group), can't really do anything in JIRA because I haven't given "Anyone" permissions to do things because I want users to be logged in.

So, these users are logged in, but they still can't do anything.

Is there any way to give a logged in user permission to do stuff without having to add them to an existing JIRA group and without letting anonymous users do the same things?

Thanks~!

Accepted answers

NathanG

I think I know... Microsoft Active Directory with "Ready Only with Local Groups" will sync users to JIRA including the configured AD groups, but they won't count against a license until they login (during login they are added to a group that has login permissions). This option is GREAT if you want users to be in JIRA before they login (say, you want them to show up in a user picker list)

Internal with LDAP Authentication is similar, except users aren't pre-synced. This option is great if you do NOT want users to be in JIRA before they login (the downside is that they will not be in a user pick list).

We've decided to use both... we are going to expand our user object filter to sync more users to JIRA, however, we have a few users that won't sync (their accounts are in a separate place in AD), so when they login, they'll use the Internal with LDAP Authentication directory.

AWESOME!

All comments

Joe Pitt

All users that can logon would be members of the jira-users group (default). You can give that group permission, but doing so can cause problems if you need to exclude some people in the future. It is a common problem.

NathanG

Here is what my user looks like after they've synced...

I wish they were in a group... but they aren't.

So, I suppose I was wrong... it seems that these users can't login, even though they are syncing to jira.

Hmmm... how can I let these users login?

Andrew Wolpers

I think your Global Permissions are a little out of whack. When you navigate to Global Permissions (g+g Global Permissions), what do you see under the "Jira Users" permission? To the right there should be the default group users join and use to login.

NathanG

Things look okay here...

I think the issue is that I'm syncing my users with AD, but my User Object Filter contains users that aren't in any of the groups from my Group Object Filter.

So users will sync, but they aren't being added to any groups.

Andrew Wolpers

I'd look into that object filter a bit more. I know in the past that "GroupofObjects" and "GroupOfUniqueObjects" has even been the fix I was looking for to pull it down. Also, make sure that menacing checkbox that pulls in the groups is checked.

William Crighton _CCC_

Nathan,

I've seen this something like this before where users wouldn't be put into any groups (i.e. the groups they were members of in external authenticator like AD/LDAP) until they logged in for the first time. I can't remember right now what _allowed_ them to log in for the first time - was probably membership in external group that'd been added to the Jira Users global permission.

Note Jira Users is not the only global permission giving people the ability to log in - both of the admin permissions also convey this ability and so count toward your total licensed user count.

How many users does JIRA think should be able to log in? Navigate to the License Details page of your JIRA instance - if it's what you expect (equal to number people in your ML-JIRA group) then it's probably just that they've never logged in - once they log in for the first time they'll show as being in the respective groups (users, ML-JIRA, and jira-users given your screen shots).

I hate the default group names - misleading - I always create a new group, jira-access, and have that as the only group listed in the Jira Users permission. Note this doesn't work with OnDemand, group names are somewhat hardcoded there.

hope that helps

-wc

Marcus Silveira

Hi Nathan,

If you don't plan to use your groups from the AD, only the authentication, you can try using an "Internal with LDAP authentication" user directory type, or a user directory with "Read only with local groups" permission.

This should enable you to automatically add your users to a group in the JIRA User global permission (like jira-users) and have that group with permission to create issues.

Hope this helps

NathanG

Question: what is the different between Internal with LDAP authentication" and using "Microsoft Active Directory" with "Ready Only, with Local Groups"?

Does the "Internal with LDAP Authentication" only add users to JIRA when they login, and the "read only with local groups" option add users to JIRA based on the user object filter?

Thanks!

NathanG

This is interesting... I have 883 users, but only "504 currently active".

That 504 number matches the number of people in my Active Directory "ML-JIRA" group.

As a test, I tried having one of the users who was NOT in ML-JIRA but was listed in the JIRA users page try to login... they got a permission denied error... which makes sense... that user is not in "ML-JIRA", nor "users", nor "jira-users"... so the global permissions config is denying this user access.

Also, my active-directory "user directory" is listed first... so I think what is happening is:

1) JIRA is syncing users based on my configuration: sync all the users based on my LDAP query (which includes users in ML-JIRA and users who aren't in ML-JIRA

2) JIRA is syncing groups based on my configuration: sync the ML-JIRA group. Users who ARE in jira (because of #1) but aren't in ML-JIRA (because of #2) show up without ANY group membership in JIRA

3) Because of #1 and #2, there are many users synced to JIRA that aren't in ML-JIRA

4) Only users in ML-JIRA can login (based on my global permissions)

5) Users are not being automatically added to "users" or "jira-users"... I think this is happening because I'm using "Read Only" LDAP Permissions?

NathanG

Interesting... I think this solves my problem... instead of using "Read Only", I can change this to "Read Only, With Local groups".

When I changed the LDAP Permissions to "Read Only with Local Groups", a new option appeared: "Default Group Membership"

So, I can type "jira-users" into the "Default Group Membership" so when the user logs in, they are automatically added to the "jira-users" group (and they won't ever be added to ML-JIRA unless we add them in AD).

This would seem to work... I'm going to test this out...

NathanG

AWESOME!

William Crighton _CCC_

Nathan,

Nice summary! That will be useful to the next guy for sure. The only suggestion I have is to now stop thinking about groups and start using roles.

If you spend more time now and get a good understanding of Project Roles you make your JIRA system much easier to administer while still being able to provide pinpoint control over who can access what project (and what they can do there).

As a rule when we setup JIRA for a client we never use the groups listed in the Jira Users global permission anywhere else in the system. That provides a strong layer of confidence that the 'Jira Users' group/s are only providing 'access' to the JIRA system - they don't provide any other permissions (such as visibility to issues in project X).

The other thing you will want to do is use the 'anyone' option for every permission you can - this can greatly improve performance due to how JIRA handles deriving whether a user has a permission or not when they go to perform an action (or when JIRA decides whether or not to display an action they can perform). Nice candiates for the 'anyone' group are ones with the word 'Own' in them such as:

Edit Own Comments
Delete Own Comments
Edit Own Attachments
and so on

-wc

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-administration