Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Azure SSO implementation - User not available in Jira error

I’ve been working with our IT engineer responsible for Azure to implement SSO in our Jira test environment. I first had to work through some of the prerequisites in accordance to the Microsoft instructions. For reference, we are on Jira Server 7.2.7.

I enabled HTTPS on our Jira server in accordance with the Atlassian instructions and verified the config settings in server.xml. secure = “true” appeared to be a common error and that statement is present.

I checked websudo but didn’t find an entry in I did find an entry in the jpm.xml file and it was set to false (Atlassian documents mentioned not to change the setting in this file.) I ended up adding the line = true to the file and verified the value appeared as true in the ViewSystemInfo.jsp page on the server.

Our Jira instance is configured to get directory info from a local LDAP server. User Schema settings are pasted below. The exact attribute of sAMAaccountName and objectGUID do not appear in our Azure configuration according to the IT engineer. He’s used onpremisessamaccountname and objectid as substitutes during the various configuration attempts. I’ve also tried setting the azure configuration for userid to various attribute values including the onpremisessamaccountname. When I manually point the userid reference to an attribute then the login error changes to attribute not found in SAML response packet.

I installed a SAML packet investigator add-on to Chrome and have been checking the packet details back from Azure with each change that we attempt. At one point I saw the email address being passed back as the NameID. In other cases the NameID value appears to be a random string and not the sAMAccountName expected. I sent our IT engineer the Microsoft page for editing the nameID but I’m not sure how much was done on that side. I don’t have access to our Azure configuration details so it’s difficult for me to verify those settings/details. (

The only thing I haven’t really tried was migrating our Jira instance to using email instead of sAMAccountName for userID. I’m a bit hesitant to do this migration from what I read in the Atlassian documentation about doing this.

This troubleshooting has been underway for a couple weeks (part time) now and it’s becoming maddening!

I appreciate any help/tips/leads that you can provide.


Jira User Schema.PNG

1 answer

Did you ever figure this out? I'm in the same boat, at about the same point. I can tell that the issue is that it's trying to use email address instead of just username. Tried UserPrinciplName, SAMAccountName, and every other attribute I could think of with same result of attribute not found.

This effort stalled once our IT group renewed the contract with our current SSO provider for another year. It is about to pick up again (tomorrow actually). We believe the issue was that our on premise Jira server uses the LDAP objectGUID as the unique user attribute. Our IT/Cyber teams didn't map this attribute into our Azure cloud system. I believe the solution will be for them to do so so that we can reference it in the SAML settings and they can reference it in the Azure Jira SSO config. Otherwise, it appears that reassigning the objectGUID to another value in Jira (while maintaining user associations with issues/roles/etc) is a bit of a lift requiring SQL and temporary mapping tables. 

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events