You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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 jira-config.properties. 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 jira.websudo.is.disabled = true to the jira-config.properties 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. (https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization)
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.