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



Applications must be explicitly assigned to users or groups to appear on the Access Panel and work with direct sign-in URLs

In order for an application to appear on the Azure AD access panel for a specific user or group of users, it must be assigned to the desired user or group using the Active Directory > [Directory] >Applications > [Application] > Users and Groups section of the Azure Management portal. This also applies to the direct Single Sign-On URLs that can be copied from the Dashboard section for each application in the Azure management portal. The only exception to this is if the application developer has implemented support for Azure AD "consent" as described in, and the user has consented to use this application. 

In order to assign all users in an organization to an application, Azure AD Premium provides an "All Users" group. This group can be assigned using the Active Directory > [Directory] >Applications > [Application] > Users and Groups section of the Azure Management portal.

↑ Back to top

When using password-based SSO, users cannot update usernames and  passwords that were set by an adminstrator

Password-based single sign-on supports two different modes: user-managed, and admin-managed. These modes are documented at

When the user-managed mode is configured for an application, the user is prompted to enter the username and password for that app on the Azure AD Access Panel. that user can also update the credentials used for that application at any time by clicking the "..." menu on the application tile in the Access Panel, and selecting "Update credentials".

When the admin-managed mode is configured for an application, only the administrator can update the credentials for the application. In this case, users are never prompted to enter credentials in the Azure AD Access Panel, nor do they see an "Update credentials" option in the menu for that application. If you want to enable users to update the password, the application must be assigned to the user in user-managed mode.

↑ Back to top

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