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
4,368,764
Community Members
 
Community Events
168
Community Groups

Manual login works, SAML doesn't

I'm so close to getting this to work but I'm missing something. 

I can log into my Jira instance manually with my Azure AD username and password with no problem.  My issue is that if select the SSO, it errors with User is not available in JIRA. Please contact your JIRA admin and kicks me back to the login screen.   

 

All I can think of is that SSO is submitting my full email (myemailaddr@mydomain.com) while if I manually login, I'm just using user account name without the domain name.  The Azure AD configuration isn't coughing up errors until I try to log in and the add-on configuration reports it's happy.  Any suggestions on where to look next?  Could it have something to do with the SAML UserID Location?  I currently have it sent to the default User ID is in the NameIdentifier element of the Subject statement.

 

Here is an excerpt from the log when I try to log in.  Thank you!

 


2022-08-09 16:34:37,379-0400 http-nio-8080-exec-21 ERROR anonymous 994x4817x1 - 160.91.2.3 /plugins/servlet/saml/auth [c.m.saml.operations.SAMLResponseProcessor] MS_ERROR : nbAttribute: NotBefore="2022-08-09T20:29:37.152Z"
2022-08-09 16:34:37,381-0400 http-nio-8080-exec-21 ERROR anonymous 994x4817x1 - 160.91.2.3 /plugins/servlet/saml/auth [c.m.saml.util.SignatureValidator] MS_INFO : SignatureValidator started to validate signature tags
2022-08-09 16:34:37,381-0400 http-nio-8080-exec-21 ERROR anonymous 994x4817x1 - 160.91.2.3 /plugins/servlet/saml/auth [c.m.saml.util.SignatureValidator] MS_INFO : SignatureValidator Completed validation of signature tags
2022-08-09 16:34:37,382-0400 http-nio-8080-exec-21 ERROR anonymous 994x4817x1 - 160.91.2.3 /plugins/servlet/saml/auth [c.m.a.jira.servlet.JiraSSOLoginServlet] MS_INFO :Authenticating user
2022-08-09 16:34:37,382-0400 http-nio-8080-exec-21 ERROR anonymous 994x4817x1 - 160.91.2.3 /plugins/servlet/saml/auth [c.m.a.jira.servlet.JiraSSOLoginServlet] MS_ERROR : User is not available in JIRA. Please contact your JIRA admin :myemailaddrj@mydomain.com
2022-08-09 16:34:37,387-0400 http-nio-8080-exec-21 ERROR anonymous 994x4817x1 - 160.91.2.3 /plugins/servlet/saml/auth [c.m.atlassianplugin.applicationinsight.ApplicationInsightUtil] MS_ERROR : Exception message = User is not available in JIRA. Please contact your JIRA admin.

 


 

2 answers

2 accepted

1 vote
Answer accepted

Looks like this is the same issue I'm having but for someone 4 years ago.

How to use Azure AD SSO SAML for Jira, when Jira is also already setup to use local AD 

0 votes
Answer accepted

@Michael Johnston 

Log in manually, proceed to Administration/User Management/User – look at any user, what do they have as the username? Based on the information you've provided it's sAMAccountName

When using SAML, your Azure AD can be configured to send any attribute in the username – email, user principal name, or onPremisesSamAccountName (the attribute in Azure that corresponds to sAMAccountName in on premises AD – this is what the article linked by you above). Yours must have been configured to send the email or user principal name (also looks like an email usually).

Please note the onPremisesSamAccountName will only have a value for the users that are synchronised from your on premises AD, so sending this via SAML might not be the correct choice, depending on what users may be present in your AD in the future, e.g., guest accounts, or Azure only accounts.

You may prefer to switch your Jira users to use email as the username in Jira. This is a change in Jira's User Directory (what attribute to use as the username). If this directory is of a connector type – it should rename all your users on the next sync, with no adverse results if everything else is setup correctly. PLEASE DO TEST THIS IN A TEST ENVIRONMENT.

However, not every user in Azure AD will have the mail attribute set (e.g. Office365 users vs. on premises users vs. guest users) – so in SAML configuration you may want to specify transformation rule that would check these attributes and choose one that is not empty, and could ultimately fallback to the UPN.

You could also switch both SAML and Jira AD integration to use UPN as the username.

Thank you for taking the time to answer my question.  I put in the "name.onPremisesSamAccountName" in Azure, and it all started working.  But thanks to you, I now understand why.    

Suggest an answer

Log in or Sign up to answer