Application Access: Release Notes

Application Access: Release Notes

The objective of this article is to provide you with a list of best practices for managing the application access enhancements for Windows Azure Active Directory.

For feedback, click here



Some SaaS applications may attempt to contact end users via email

Some software as a service (SaaS) applications may attempt to contact end users who have been provisioned into the application via email.
For example, requires that each email address be validated.
If you are integrating with a SaaS application which sends emails directly to users, then you will need to ensure that the user's User Principal Name corresponds to a routable email address.
One way this can be done is by validating a domain, assigning user's UPNs to that domain, and subscribing users to an Office365 plan which includes an Exchange Online mailbox.
Another way to ensure users have mailboxes is by using DirSync to synchronize users into Windows Azure Active Directory from an Windows Server Active Directory, where users already have mailboxes (such as with an on-premises Exchange server) and their UPNs correspond to their email addresses.

↑ Back to top


UPNs must match email addresses if updating existing users

If you will be provisioning users into a SaaS application, it is necessary to ensure that user's UPNs correspond to their email addresses.
If users have existing accounts in the SaaS application, then their accounts' email addresses wil be updated as part of the user provisioning process.

↑ Back to top


Google Apps requires a validated domain and API access enabled

When integrating Windows Azure Active Directory with Google Apps for user provisioning, a target domain name is needed that has been validated in the Google Apps environment as well.
For instructions, see Adding custom domains in Tutorial: Windows Azure AD integration with Google Apps.
In addition to this, you also need to enable API access in your Google Apps tenant.
For instructions, see Enabling Google Apps API Access in Tutorial: Windows Azure AD integration with Google Apps.
The User Principal Names of users who will be provisioned to Google Apps must correspond to this domain name, otherwise their accounts will not be provisioned to Google Apps.

↑ Back to top


Yammer Single Sign on Browser Compatibility

There is a JavaScript incompatibility for Password-based Single Sign On to Yammer when using some browser and platform combinations, particularly Internet Explorer 10.
Internet Explorer 9 and Chrome do not appear to be affected.

↑ Back to top


Password SSO and change password on first logon

When configuring identity provisioning with password SSO some applications may require the user to change their password on first logon.
In these cases, the user has to store the updated password in the access panel by selecting the “update credentials” option under the wrench on the application tile.

↑ Back to top


Re-adding deleted applications

If you want to delete and re-add an application, you need to refresh the current page after the deletion.
The page refresh is necessary to bring the deleted application back into the list of applications you can add.

↑ Back to top


Issue with password-based single sign-on to Atlassian applications

There is a known issue with password-based single sign-on for several Atlassian applications where the Azure AD Access Panel redirects users to during sign-in, which does not actually sign users into the selected applications. Applications affected include JIRA, JIRA OnDemand, FishEye, Crucible, and Confluence. These applications have been temporarily removed from the Azure AD application gallery for new users while this issue is being addressed.

↑ Back to top


See Also

↑ Back to top


Sort by: Published Date | Most Recent | Most Useful
  • Would be nice for the Azure DB-SSO tutorial could link to this article to mention the broken link in Azure for downloading the SSL certificate:

    However, the SF SSL certificate that can be downloaded from this alternative location is not accepted by! When uploading it, it says "Certificate file no content (Related field: Identity Provider Certificate)" - though this certificate can be opened in Windows and does not appear corrupt (presumably, it is in the wrong format, or is missing some value is looking for). The other certificate that can be downloaded (for all apps other than is at least accepted by, though does not seem to work for SSO. Also, the screens have changed a bit since this tutorial - I am assuming the Entity ID that is an mandatory field in SF SSO settings now but was not there before should be

    It would be really nice if the instructions could be updated so that it is possible to configure Azure AD - SSO properly by following

    I know this is currently in preview, but is it actually currently working with for SSO?

  • Hackster, where is this tutorial? Can you go provide your feedback on the Library topic?


  • Hi Ed - the link to the integration tutorial is in my first comment. Unfortunately, that page does not allow me to leave any comments, so I had to leave it here, otherwise I would have tried to make the link.

    It would really be helpful for that page to make reference to the fact that the download link to the certificate is broken. The link on this page works, but the certificate is not accepted by If you download that, then open it and export it, it can be made to be accepted by Finally, the tutorial is out of date, the SSO SAML screenshots have changed, and there are some additional mandatory fields in the SAML SSO page.

    It would be great if the tutorial could be updated to reflect all of these issues. Can you help the relevant person review it, or at least, post this comment to help others getting stuck following the instructions?

  • thanks!

Page 1 of 1 (4 items)