Microsoft Azure1 PDF

Contents
Application Management Documentation

Overview
About application management
Quickstarts
Add a gallery application - portal
View tenant apps - portal
Tutorials
Configure single sign-on - portal
Add an on-premises app - portal
Concepts
Plan a cloud app integration
What happens when you add an app
Guidance for developers
Plan an on-premises app integration
Application Proxy
Connectors
Connector groups
Security
Network topology
Comparison of remote access solutions
Provisioning users and groups
Automatic user provisioning
SaaS apps
SCIM-enabled apps
Customize application attributes
Write expressions for attribute mappings
Scoping filters
Report on automatic user provisioning
Troubleshoot user provisioning
Application security
App access options
Certificate signing options
Manage certificates
Tenant restrictions
Configure SAML token encryption (Preview)
Single sign-on
End-user portals
How-to guides
Cloud app integration
Adding an app
Choose app type
Common problems - gallery apps
Common problems - non-gallery apps
Change name or logo
On-premises app integration
Configure connectors
Configure claims-aware apps
Register connector - silent install
Configure native client apps
Configure custom home page
Translate inline links
Configure cookie settings
Publish using wildcards
Remove personal data
Configure custom domain
Configuration errors
Publishing walkthroughs
Integrate with Cloud App Security
Integrate with Remote Desktop
Integrate with SharePoint
Integrate with Teams
Integrate with Tableau
Integrate with Qlik
Application Proxy troubleshooting
Problem displaying app page
Application load is too long
Links on application page not working
What ports to open for my app
No working connector in a connector group for my app
Configure in admin portal
Configure single sign-on to my app
Problem creating an app in admin portal
Configure Kerberos Constrained Delegation
Configure with PingAccess
Can't Access this Corporate Application error
Problem installing the Application Proxy Agent Connector
Sign-in problem
User provisioning
How long it takes
Taking hours - gallery app
Configure user provisioning - gallery app
Problem configuring user provisioning - gallery app
Problem saving administrator credentials while configuring user provisioning gallery
app
Users are not provisioned - gallery app
Wrong users provisioned - gallery app
Application access
Application types
Configure user consent
Methods for assigning users and groups to an app
Assign a user to an app
Methods for removing a user's access to an app
Unexpected user assigned
Remove user or group access
Hide app from a user
Disable user sign-on
Configure self-service app assignment
Home Realm Discovery
Single sign-on
Configure non-gallery apps
Configure federated - gallery apps
Configuring federated common problems - gallery apps
Configure federated - non-gallery apps
Configure federated common problems - non-gallery apps
Configure password - gallery apps
Configure password common problems - gallery apps
Configure password - non-gallery apps
Configure password common problems - non-gallery apps
Application Proxy
Kerberos constrained Delegation (KCD)
Password vaulting
Headers
Access panel
Manage browser extension
App not appearing
Unexpected app appearing
Can't sign in
Error installing browser extension
How to use self-service app access
Error using self-service app access
Migration
Migration resources
Migrate an ADFS app to Azure
Troubleshoot user sign-in
Unexpected consent prompt
User consent error
Problems signing in from custom portal
Problems signing in from access panel
Error on application sign-in page
Problem with password single sign-on - non-gallery app
Problem with password single sign-on - gallery app
Problem signing into a Microsoft app
Problem with federated single sign-on - non-gallery app
Problem with federated single sign-on - gallery app
Problem with custom-developed app
Resources
Azure AD deployment plans
Azure feedback forum
Azure Roadmap
MSDN forum
Pricing
Pricing calculator
Service updates
Stack Overflow
Videos
Application management with Azure Active
Directory
2/12/2019 • 2 minutes to read
Azure Active Directory (Azure AD ) provides secure and seamless access to cloud and on-premises applications.
Users can sign in once to access Office 365 and other business applications from Microsoft, software as a service
(SaaS ) applications, on-premises applications, and line of business (LOB ) apps. Reduce administrative costs by
automating user provisioning. Use multi-factor authentication and conditional access policies to provide secure
application access.
Why manage applications with a cloud solution?

Organizations often have hundreds of applications that users depend on to get their work done. Users access
these applications from many devices and locations. New applications are added, developed, and sunset every
day. With so many applications and access points, it is more critical than ever to use a cloud-based solution to
manage user access to all applications.
Manage risk with conditional access policies

Coupling Azure AD single sign-on (SSO ) with conditional access policies provides high levels of security for
accessing applications. Security capabilities include cloud-scale identity protection, risk-based access control,
native multi-factor authentication, and conditional access policies. These capabilities allow for granular control
policies based on applications, or on groups that need higher levels of security.
Improve productivity with single sign-on

Enabling single sign-on (SSO ) across applications and Office 365 provides a superior sign-in experience for
existing users by reducing or eliminating sign-in prompts. The user’s environment feels more cohesive and is less
distracting without multiple prompts, or the need to manage multiple passwords. The business group can manage
and approve access through self-service and dynamic membership. Allowing the right people in the business to
manage access to an application improves the security of the identity system.
SSO improves security. Without single sign-on, administrators need to create and update user accounts for each
individual application, which takes time. Also, users have to track multiple credentials to access their applications.
As a result, users tend to write down their passwords or use other password management solutions, which
introduce data security risks.
Address governance and compliance

With Azure AD, you can monitor application sign-ins through reports that leverage Security Incident and Event
Monitoring (SIEM ) tools. You can access the reports from the portal, or from APIs. Programmatically audit who
has access to your applications, and remove access to inactive users via access reviews.
Manage costs
By migrating to Azure AD, you can save costs and remove the hassle of managing your on-premises
infrastructure. Azure AD also provides self-service access to applications, which saves time for both
administrators and users. Single sign-on eliminates application-specific passwords. This ability to sign on once
saves costs related to password reset for applications, and lost productivity while retrieving passwords.
Quickstart: Add an application to your Azure Active
Directory tenant
Azure Active Directory (Azure AD ) has a gallery that contains thousands of pre-integrated applications. Some of
the applications your organization uses are probably in the gallery. This quickstart uses the Azure portal to add a
gallery application to your Azure Active Directory (Azure AD ) tenant.
After an application is added to your Azure AD tenant, you can:
Manage user access to the application with a conditional access policy.
Configure users to single sign-on to the application with their Azure AD accounts.
Before you begin

To add an application to your tenant, you need:
An Azure AD subscription
A single sign-on enabled subscription for your application
Sign in to the Azure portal as a global admin for your Azure AD tenant, a cloud application admin, or an
application admin.
To test the steps in this tutorial, we recommend using a non-production environment. If you don't have an Azure
AD non-production environment, you can get a one-month trial.
Add an application to your Azure AD tenant

To add a gallery application to your Azure AD tenant:
1. In the Azure portal, on the left navigation panel, click Azure Active Directory.
2. In the Azure Active Directory blade, click Enterprise applications.
3. The All applications blade opens to show a random sample of the applications in your Azure AD tenant.
4. Click New application at the top of the All applications blade.
5. To see a list of applications in the gallery, it's easiest to use the Categories since the icons under Featured
applications are a random sample of gallery applications.
To see more applications, you could click Show more. We don't recommend searching this way since there
are thousands of applications in the gallery.
6. To search for an application, under Add from the gallery enter the name of the application you want to
add. Select the application from the results, and click Add. The following example shows the Add app form
that appears after searching for github.com.
7. In the application-specific form, you can change property information. For example, you can edit the name
of the application to match the needs of your organization. This example uses the name GitHub-test.
8. When you are finished making changes to the properties, click Add.
9. A getting started page appears with the options for configuring the application for your organization.
You have finished adding your application. Feel free to take a break. The next sections show you how to change the
logo and edit other properties for your application.
Find your Azure AD tenant application

Let's assume you had to leave and now you're returning to continue configuring your application. The first thing
you need to do is find your application.
3. From the Application Type drop-down menu, select All Applications, and click Apply. To learn more
about the viewing options, see View tenant applications.
4. You can now see a list of all the applications in your Azure AD tenant. The list is a random sample. To see
more applications, click Show more one or more times.
5. To quickly find an application in your tenant, enter the application name in the search box and click Apply.
This example finds the GitHub-test application that we added previously.
Configure user sign-in properties
Now that you have found the application, you can open it and configure application properties.
To edit the application properties
1. Click the application to open it.
2. Click Properties to open the properties blade for editing.
3. Take a moment to understand the sign-in options. The Enabled for users to sign-in, User assignment
required, and Visible to user combine to determine whether users who are assigned or unassigned to the
application can sign in. They also determine if the user can see the application in the access panel.
Enabled for users to sign-in determines whether users assigned to the application can sign in.
User assignment required determines whether users who are not assigned to the application can sign
in.
Visible to user determines whether users assigned to an app can see it in the access panel and O365
launcher.
4. Use the following tables to help you choose the options that are best for your needs.
Behavior for assigned users:
APPLICATION
PROPERTY ASSIGNED-USER
SETTINGS EXPERIENCE
Enabled for users User assignment Visible to users? Can assigned users Can assigned users
to sign-in? required? sign in? see the
application?*
yes yes yes yes yes

APPLICATION
PROPERTY ASSIGNED-USER
SETTINGS EXPERIENCE
yes yes no yes no
yes no yes yes yes
yes no no yes no
no yes yes no no
no yes no no no
no no yes no no
no no no no no
Behavior for unassigned users:
APPLICATION
PROPERTY UNASSIGNED-USER
SETTINGS EXPERIENCE
Enabled for users User assignment Visible to users? Can unassigned Can unassigned
to sign-in? required? users sign in? users see the
application?*
yes yes yes no no
yes yes no no no
yes no yes yes no
yes no no yes no
no yes yes no no
no yes no no no
no no yes no no
no no no no no
*Can the user see the application in the access panel and the Office 365 app launcher?
Use a custom logo

To use a custom logo:
1. Create a logo that is 215 by 215 pixels, and save it in PNG format.
2. Since you have already found your application, click on the application.
3. In the left blade, click Properties.
4. Upload the logo.
5. When you're finished, click Save.
5. When you're finished, click Save.
Next steps
In this quickstart, you've learned how to add a gallery application to your Azure AD tenant. You learned how to
edit the properties for an application.
Now, you're ready to configure the application for single sign-on.
Configure single sign-on
View your Azure Active Directory tenant applications
This quickstart uses the Azure portal to view the applications in your Azure Active Directory (Azure AD ) tenant.
Before you begin

To see results, you need to have at least one application in your Azure AD tenant. To add an application, see the
Add an application quickstart.
Sign in to the Azure portal as a global admin for your Azure AD tenant, a cloud application admin, or an
application admin.
Find the list of tenant applications

Your Azure AD tenant applications are viewable in the Enterprise apps section of the Azure portal.
To find your tenant applications:
3. From the Application Type drop-down menu, select All Applications, and click Apply. A random sample
of your tenant applications appears.
4. To view more applications, click Show more at the bottom of the list. Depending on the number of
applications in your tenant, it might be easier to search for a particular application, instead of scrolling
through the list.
Select viewing options

In this section, select the options according to what you are looking for.
1. You can view the applications according to options for Application Type, Application Status, and
Application visibility.
2. Under Application Type, choose one of these options:

Enterprise Applications shows non-Microsoft applications.
Microsoft Applications shows Microsoft applications.
All Applications shows both non-Microsoft and Microsoft applications.
3. Under Application Status, choose Any, Disabled, or Enabled. The Any option includes both disabled
and enabled applications.
4. Under Application Visibility, choose Any, or Hidden. The Hidden option shows applications that are in
the tenant, but are not visible to users.
5. After choosing the options you want, click Apply.
Search for a tenant application

To search for an particular application:
1. In the Application Type menu, select All applications, and click Apply.
2. Enter the name of the application you want to find. If the application has been added to your Azure AD
tenant, it will appear in the search results. This example shows that GitHub has not been added to the tenant
applications.
3. Try entering the first few letters of an application name. This example shows all the applications that start
with Sales.
Next steps
In this quickstart, you learned how to view the applications in your Azure AD tenant, and how to filter the list of
applications by application type, status, and visibility. You also learned how to search for a particular application.
Now that you have found the application you were looking for, you can continue to Add more applications to your
tenant, or click the application to view or edit properties and configuration options. For example, you could
configure single sign-on.
Tutorial: Configure SAML-based single sign-on for
an application with Azure Active Directory
This tutorial uses the Azure portal to configure SAML -based single sign-on for an application with Azure Active
Directory (Azure AD ). Use this tutorial when an application-specific tutorial isn't available.
This tutorial uses the Azure portal to:
Select the SAML -based single sign-on mode
Configure application-specific domain and URLs
Configure user attributes
Create a SAML signing certificate
Assign users to the application
Configure the application for SAML -based single sign-on
Test the SAML settings
Before you begin

1. If the application hasn't been added to your Azure AD tenant, see Quickstart: Add an application to your
Azure AD tenant.
2. Ask your application vendor for the information described in Configure domain and URLS.
3. To test the steps in this tutorial, we recommend using a non-production environment. If you don't have an
Azure AD non-production environment, you can get a one-month trial.
4. Sign in to the Azure portal as a cloud application admin, or an application admin for your Azure AD tenant.
Select a single sign-on mode

After an application is added to your Azure AD tenant, you're ready to configure single sign-on for the application.
To open the single sign-on settings:
2. In the Azure Active Directory blade, click Enterprise applications. The All applications blade opens to
show a random sample of the applications in your Azure AD tenant.
3. In the Application Type menu, select All applications, and click Apply.
4. Enter the name of the application for which you want to configure single sign-on. Choose your own
application, or enter GitHub-test to configure the application you added in the add application quickstart.
5. Click Single sign-on. Under Single Sign-on Mode, SAML -based Sign-on appears as the default
option.
6. Click Save at the top of the blade.
Configure domain and URLs

To configure the domain and URLs:
1. Contact the application vendor to get the correct information for the following settings:
CONFIGURATION SETTING SP-INITIATED IDP-INITIATED DESCRIPTION
Sign-on URL Required Don't specify When a user opens this

URL, the service provider
redirects to Azure AD to
authenticate and sign on
the user. Azure AD uses
the URL to start the
application from Office
365 or the Azure AD
Access Panel. When blank,
Azure AD relies on the
identity provider to initiate
single sign-on when a user
launches the application.
CONFIGURATION SETTING SP-INITIATED IDP-INITIATED DESCRIPTION
Identifier (Entity ID) Required for some apps Required for some apps Uniquely identifies the
application for which
single sign-on is being
configured. Azure AD
sends the identifier to the
application as the
Audience parameter of the
SAML token. The
application is expected to
validate it. This value also
appears as the Entity ID in
any SAML metadata
provided by the
application.
Reply URL Optional Required Specifies where the

application expects to
receive the SAML token.
The reply URL is also
referred to as the
Assertion Consumer
Service (ACS) URL.
Relay State Optional Optional Specifies to the application

where to redirect the user
after authentication is
completed. Typically the
value is a valid URL for the
application, however some
applications use this field
differently. For more
information, ask the
application vendor.
2. Enter the information. To see all the settings, click Show advanced URL settings.
3. At the top of the blade, click Save.

4. There's a Test SAML Settings button in this section. Run this test later in the tutorial in the Test single
sign-on section.
Configure user attributes

User attributes allow you to control what information Azure AD sends to the application in the SAML token each
time a user signs on. For example, Azure AD could send the name, email, and employee ID of the user to the
application.
These attributes may be required or optional to make single sign-on work properly. For more information, see the
application-specific tutorial, or ask the application vendor.
1. To view all the options, click View and edit all other user attributes.
2. Enter User Identifier.

The user identifier uniquely identifies each user within the application. For example, if the email address is
both the username and the unique identifier, set the value to user.mail.
3. For more SAML token attributes, click View and edit all other user attributes.
4. To add an attribute to the SAML Token Attributes, click Add attribute. Enter the Name and select the
Value from the menu.
5. Click Save. You see the new attribute in the table.
Create a SAML signing certificate

Azure AD uses a certificate to sign the SAML tokens that it sends to the application.
1. To see all the options, click Show advanced certificate signing options.
2. To configure a certificate, click Create new certificate.
3. In the Create New Certificate blade, set expiration date, and click Save.
4. Click Make new certificate active.
5. To learn more, see Advanced certificate signing options.
6. To keep the changes you have made so far, be sure to click Save at the top of the Single sign-on blade.

Microsoft recommends testing the single sign-on with several users or groups before rolling out the application
to your organization.
To assign a user or group to the application:
1. Open the application in the portal, if it isn't already open.
2. In the left application blade, click Users and groups.
3. Click Add user.
4. In the Add Assignment blade, click Users and groups.
5. To find a specific user, type the user name into the Select box, click the checkbox next to the user’s profile
photo or logo, and click Select.
6. Find your current username and select it. You can optionally select more users.
7. In the Add Assignment blade, click Assign. When completed, the selected users appear in the Users and
groups list.
Configure the application to use Azure AD

You're almost done. As a final step, you need to configure the application to use Azure AD as a SAML identity
provider.
1. Scroll down to the end of the Single sign-on blade for your application.
2. Click Configure application in the portal, and follow the instructions.

3. Manually create user accounts in the application to test single sign-on. Create the user accounts you assigned
to the application in the previous section.
Test single sign-on

You are ready to test your settings.
1. Open the single sign-on settings for your application.
2. Scroll to the Configure domain and URLs section.
3. Click Test SAML Settings. The testing options appear.
4. Click Sign in as current user. This test lets you first see if single sign-on works for you, the admin.
5. If there's an error, an error message appears. Copy and paste the specifics into theWhat does the error
look like? box.
6. Click Get resolution guidance. The root cause and resolution guidance appear. In this example, the user
wasn't assigned to the application.
7. Read the resolution guidance and then, if appropriate, click Fix it.
8. Run the test again until it completes successfully.
Next steps
In this tutorial, you configured the single sign-on settings for an application. After finishing the configuration, you
assigned a user to the application, and configured the application to use SAML -based single sign-on. When all of
this work was finished, you verified the SAML sign-on is working properly.
You did these things:
Selected SAML for the single sign-on mode
Contacted the application vendor to configure domain and URLs
Configured user attributes
Created a SAML signing certificate
Manually assigned users or groups to the application
Configured the application to use Azure AD as a SAML identity provider
Tested the SAML -based single sign-on
To roll out the application to more users in your organization, we recommend using automatic user provisioning.
Learn how to assign users with automatic provisioning
Tutorial: Add an on-premises application for remote
access through Application Proxy in Azure Active
Directory
Azure Active Directory (Azure AD ) has an Application Proxy service that enables users to access on-premises
applications by signing in with their Azure AD account. This tutorial prepares your environment for use with
Application Proxy. Once your environment is ready, you'll use the Azure portal to add an on-premises application
to your Azure AD tenant.
This tutorial:
Opens ports for outbound traffic and allows access to specific URLs.
Installs the connector on your Windows server, and registers it with Application Proxy.
Verifies the connector installed and registered correctly.
Adds an on-premises application to your Azure AD tenant.
Verifies a test user can sign on to the application by using an Azure AD account.
Before you begin

To add an application to your tenant, you need:
A Microsoft Azure AD basic or premium subscription.
An application administrator account.
Windows server
To use Application Proxy, you need a Windows server running Windows Server 2012 R2 or later. You'll install the
Application Proxy connector on the server. This connector server needs to connect to the Application Proxy
services in Azure, and the on-premises applications that you plan to publish.
For high availability in your production environment, we recommend having more than one Windows server. For
this tutorial, one Windows server is sufficient.
Recommendations for the connector server
1. Physically locate the connector server close to the application servers to optimize performance between the
connector and the application. For more information, see Network topology considerations.
2. The connector server and the web applications servers should belong to the same Active Directory domain.
Having the servers in the same domain is a requirement for using single sign-on (SSO ) with Integrated
Windows Authentication (IWA) and Kerberos Constrained Delegation (KCD ). If the connector server and
web application servers are in different Active Directory domains, you need to use resource-based
delegation for single sign-on. For more information, see KCD for single sign-on with Application Proxy.
Software requirements
The Windows connector server needs to have TLS 1.2 enabled before you install the Application Proxy connector.
Existing connectors with versions below 1.5.612.0 will continue to work on prior versions of TLS until further
notice.
To enable TLS 1.2:
1. Set the following registry keys:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
2. Restart the server
Prepare your on-premises environment

To prepare your environment for Azure AD Application Proxy, you first need to enable communication to Azure
data centers. If there's a firewall in the path, make sure it's open so the connector can make HTTPS (TCP ) requests
to the Application Proxy.
Open ports
Open the following ports to outbound traffic.
PORT NUMBER HOW IT'S USED
80 Downloading certificate revocation lists (CRLs) while validating

the SSL certificate
443 All outbound communication with the Application Proxy

service
If your firewall enforces traffic according to originating users, also open ports 80 and 443 for traffic from Windows
services that run as a Network Service.
If you're already using Application Proxy, you might have an older version of the connector installed. Follow this
tutorial to install the latest version of the connector. Versions earlier than 1.5.132.0 also require the following open
ports: 5671, 8080, 9090-9091, 9350, 9352, 10100–10120.
Allow access to URLs
Allow access to the following URLs:
URL HOW IT'S USED
*.msappproxy.net Communication between the connector and the Application

*.servicebus.windows.net Proxy cloud service
mscrl.microsoft.com:80 Azure uses these URLs to verify certificates

crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
login.windows.net The connector uses these URLs during the registration

login.microsoftonline.com process.
If your firewall or proxy allows DNS whitelisting, you can whitelist connections to *.msappproxy.net and
*.servicebus.windows.net. If not, you need to allow access to the Azure DataCenter IP ranges. The IP ranges are
updated each week.
Install and register a connector
To use Application Proxy, you need to install a connector on each Windows server you choose to use with the
Application Proxy service. The connector is an agent that manages the outbound connection from the on-premises
application servers to Application Proxy in Azure AD. You can install a connector on servers that also have other
authentication agents installed such as Azure AD Connect.
To install the connector:
1. Sign in to the Azure portal as an application administrator of the directory that uses Application Proxy. For
example, if the tenant domain is contoso.com, the admin should be admin@contoso.com or any other admin
alias on that domain.
2. Your current directory appears under your username in the upper right corner. Verify you're signed in to
directory that uses Application Proxy. If you need to change directories, select that icon.
3. In left blade click Azure Active Directory, and then Application proxy.
4. Click Download connector service.
5. Read the Terms of Service. When you're ready, click Accept terms & Download.
6. At the bottom of the window, you'll see a prompt to download
AADApplicationProxyConnectorInstaller.exe. Click Run to install the connector. An install wizard opens.
7. Follow the instructions in the wizard to install. When you're prompted to register the connector with the
Application Proxy for your Azure AD tenant, provide your application administrator credentials.
For Internet Explorer (IE ), if IE Enhanced Security Configuration is set to On, you may not see the
registration screen. To get access, follow the instructions in the error message. Make sure that Internet
Explorer Enhanced Security is set to Off.
General remarks
If you've previously installed a connector, reinstall to get the latest version.
If you choose to have more than one Windows server for your on-premises applications, you'll need to install and
register the connector on each server. You can organize the connectors into connector groups. For more
information, see Connector groups.
If your organization uses proxy servers to connect to the internet, you need to configure them for Application
Proxy. For more information, see Work with existing on-premises proxy servers.
For information about connectors, capacity planning, and how they stay up-to-date, see Understand Azure AD
Application Proxy connectors.
If you're using the Qlik Sense application, always install the latest connector. Qlik Sense uses WebSockets, which is
only supported on connector versions 1.5.612.0 or later.
Verify the connector installed and registered correctly

You can use the Azure portal or your Windows server to confirm that a new connector installed correctly.
Verify - Azure portal
To confirm the connector installed and registered correctly:
1. Sign in to your tenant directory in the Azure portal.
2. Click Azure Active Directory and then Application Proxy. All of your connectors and connector groups
appear on this page.
3. Select a connector to verify its details. An active green label indicates that your connector can connect to the
service. However, even though the label is green, a network issue could still block the connector from
receiving messages.
For more help with installing a connector, see Problems installing an Application Proxy Connector.
Verify - Windows server
To confirm the connector installed and registered correctly:
1. Open the Windows Services Manager by clicking the Windows key and entering services.msc.
2. Check to see if the status for the following two services is Running.
Microsoft AAD Application Proxy Connector enables connectivity
Microsoft AAD Application Proxy Connector Updater is an automated update service. The
updater checks for new versions of the connector and updates the connector as needed.
3. If the status for the services isn't running, right-click each service and choose start.
Add an on-premises app to Azure AD

Now that you've prepared your environment and installed a connector, you're ready to add on-premises
applications to Azure AD.
1. Sign in as an administrator in the Azure portal.
2. Select Azure Active Directory > Enterprise applications > New application.
3. Select All, then select On-premises application.
4. In the Add your own on-premises application blade, provide the following information about your
application:
FIELD DESCRIPTION
Name The name of the application that will appear on the access
panel and in the Azure portal.
Internal URL The URL for accessing the application from inside your
private network. You can provide a specific path on the
backend server to publish, while the rest of the server is
unpublished. In this way, you can publish different sites on
the same server as different apps, and give each one its
own name and access rules.
If you publish a path, make sure that it includes all the

necessary images, scripts, and style sheets for your
application. For example, if your app is at
https://yourapp/app and uses images located at
https://yourapp/media, then you should publish
https://yourapp/ as the path. This internal URL doesn't
have to be the landing page your users see. For more
information, see Set a custom home page for published
apps.
External URL The address for users to access the app from outside your
network. If you don't want to use the default Application
Proxy domain, read about custom domains in Azure AD
Application Proxy.
Pre Authentication How Application Proxy verifies users before giving them
access to your application.
Azure Active Directory - Application Proxy redirects

users to sign in with Azure AD, which authenticates their
permissions for the directory and application. We
recommend keeping this option as the default, so that you
can take advantage of Azure AD security features like
conditional access and Multi-Factor Authentication. Azure
Active Directory is required for monitoring the
application with Microsoft Cloud Application Security.
Passthrough - Users don't have to authenticate against

Azure Active Directory to access the application. You can
still set up authentication requirements on the backend.
FIELD DESCRIPTION
Connector Group Connectors process the remote access to your application,

and connector groups help you organize connectors and
apps by region, network, or purpose. If you don't have any
connector groups created yet, your app is assigned to
Default.
If your application uses WebSockets to connect, all

connectors in the group must be version 1.5.612.0 or later.
5. If necessary, configure Additional settings. For most applications, you should keep these settings in their
default states.
FIELD DESCRIPTION
Backend Application Timeout Set this value to Long only if your application is slow to
authenticate and connect.
Use HTTP-Only Cookie Set this value to Yes to have Application Proxy cookies
include the HTTPOnly flag in the HTTP response header. If
using Remote Desktop Services, set this value to No.
Use Secure Cookie Set this value to Yes to transmit cookies over a secure
channel such as an encrypted HTTPS request.
Use Persistent Cookie Keep this value set to No. This setting should only be used
for applications that cannot share cookies between
processes. For more information about cookie settings see
Cookie settings for accessing on-premises applications in
Azure Active Directory
Translate URLs in Headers Keep this value as Yes unless your application required the
original host header in the authentication request.
Translate URLs in Application Body Keep this value as No unless you have hardcoded HTML
links to other on-premises applications, and don't use
custom domains. For more information, see Link
translation with Application Proxy.
Set this value to Yes if you plan to monitor this application

with Microsoft Cloud App Security (MCAS). For more
information, see Configure real-time application access
monitoring with Microsoft Cloud App Security and Azure
Active Directory
6. Select Add.
Test the application

You're ready to test the application is added correctly. In the following steps, you'll add a user account to the
application, and try signing in.
Add a user for testing
Before adding a user to the application, verify the user account already has permissions to access the application
from inside the corporate network.
To add a test user:
1. Back on the Quick start blade, select Assign a user for testing.
2. On the Users and groups blade, select Add user.
3. On the Add assignment blade, select Users and groups, and then choose the account you want to add.
4. Select Assign.
Test the sign-on
To test sign-on to the application:
1. In your browser, navigate to the external URL that you configured during the publish step.
2. You should see the start screen.
3. Try signing in as the user you created in the previous section.
For troubleshooting, see Troubleshoot Application Proxy problems and error messages.
Next steps
In this tutorial, you prepared your on-premises environment to work with Application Proxy, and then installed and
registered the Application Proxy connector. Next, you added an application to your Azure AD tenant. You verified
that a user can sign on to the application by using an Azure AD account.
You did these things:
Opened ports for outbound traffic and allowed access to specific URLs
Installed the connector on your Windows server, and registered it with Application Proxy
Verified the connector installed and registered correctly
Added an on-premises application to your Azure AD tenant
Verified a test user can sign on to the application by using an Azure AD account.
You're ready to configure the application for single sign-on. Use the following link to choose a single sign-on
method, and to find single sign-on tutorials.
Integrating Azure Active Directory with applications
getting started guide
This topic summarizes the process for integrating applications with Azure Active Directory (AD ). Each of the
sections below contain a brief summary of a more detailed topic so you can identify which parts of this getting
started guide are relevant to you.
To download in-depth deployment plans, see Next steps.
Take inventory
Before integrating applications with Azure AD, it is important to know where you are and where you want to go.
The following questions are intended to help you think about your Azure AD application integration project.
Application inventory
Where are all of your applications? Who owns them?
What kind of authentication do your applications require?
Who needs access to which applications?
Do you want to deploy a new application?
Will you build it in-house and deploy it on an Azure compute instance?
Will you use one that is available in the Azure Application Gallery?
User and group inventory
Where do your user accounts reside?
On-premises Active Directory
Azure AD
Within a separate application database that you own
In unsanctioned applications
All of the above
What permissions and role assignments do individual users currently have? Do you need to review their access
or are you sure that your user access and role assignments are appropriate now?
Are groups already established in your on-premises Active Directory?
How are your groups organized?
Who are the group members?
What permissions/role assignments do the groups currently have?
Will you need to clean up user/group databases before integrating? (This is a pretty important question.
Garbage in, garbage out.)
Access management inventory
How do you currently manage user access to applications? Does that need to change? Have you considered
other ways to manage access, such as with RBAC for example?
Who needs access to what?
Maybe you don't have the answers to all of these questions up front but that's okay. This guide can help you
answer some of those questions and make some informed decisions.
Find unsanctioned cloud applications with Cloud Discovery
As mentioned above, there may be applications that haven't been managed by your organization until now. As part
of the inventory process, it is possible to find unsanctioned cloud applications. See Set up Cloud Discovery.
Integrating applications with Azure AD

The following articles discuss the different ways applications integrate with Azure AD, and provide some guidance.
Determining which Active Directory to use
Using applications in the Azure application gallery
Integrating SaaS applications tutorials list
Authentication Types
Each of your applications may have different authentication requirements. With Azure AD, signing certificates can
be used with applications that use SAML 2.0, WS -Federation, or OpenID Connect Protocols as well as Password
Single Sign On. For more information about application authentication types for use with Azure AD see Managing
Certificates for Federated Single Sign-On in Azure Active Directory and Password based single sign on.
Enabling SSO with Azure AD App Proxy
With Microsoft Azure AD Application Proxy, you can provide access to applications located inside your private
network securely, from anywhere and on any device. After you have installed an application proxy connector within
your environment, it can be easily configured with Azure AD.
Integrating custom applications
If you are writing a new application and want to assist developers in leveraging the power Azure AD, see Guiding
developers.
If you want to add your custom application to the Azure Application Gallery, see “Bring your own app” with Azure
AD Self-Service SAML configuration.
Managing access to applications

The following articles describe ways you can manage access to applications once they have been integrated with
Azure AD using Azure AD Connectors and Azure AD.
Managing access to apps using Azure AD
Automating with Azure AD Connectors
Assigning users to an application
Assigning groups to an application
Sharing accounts
Next steps
For in-depth information, you can download Azure Active Directory deployment plans from GitHub. For gallery
applications, you can download deployment plans for single sign-on, conditional access, and user provisioning
through the Azure portal.
To download a deployment plan from the Azure portal:
1. Sign in to the Azure portal.
2. Select Enterprise Applications | Pick an App | Deployment Plan.
Please provide feedback on deployment plans by taking the Deployment plan survey.
Develop line-of-business apps for Azure Active
Directory
This guide provides an overview of developing line-of-business (LoB ) applications for Azure Active Directory
(AD ).The intended audience is Active Directory/Office 365 global administrators.
Overview
Building applications integrated with Azure AD gives users in your organization single sign-on with Office 365.
Having the application in Azure AD gives you control over the authentication policy for the application. To learn
more about conditional access and how to protect apps with multi-factor authentication (MFA) see Configuring
access rules.
Register your application to use Azure Active Directory. Registering the application means that your developers can
use Azure AD to authenticate users and request access to user resources such as email, calendar, and documents.
Any member of your directory (not guests) can register an application, otherwise known as creating an application
object.
Registering an application allows any user to do the following:
Get an identity for their application that Azure AD recognizes
Get one or more secrets/keys that the application can use to authenticate itself to AD
Brand the application in the Azure portal with a custom name, logo, etc.
Apply Azure AD authorization features to their app, including:
Role-Based Access Control (RBAC )
Azure Active Directory as oAuth authorization server (secure an API exposed by the application)
Declare required permissions necessary for the application to function as expected, including:
App permissions (global administrators only). For example: Role membership in another Azure AD
application or role membership relative to an Azure Resource, Resource Group, or Subscription
Delegated permissions (any user). For example: Azure AD, Sign-in, and Read Profile
NOTE
By default, any member can register an application. To learn how to restrict permissions for registering applications to specific
members, see How applications are added to Azure AD.
Here’s what you, the global administrator, need to do to help developers make their application ready for
production:
Configure access rules (access policy/MFA)
Configure the app to require user assignment and assign users
Suppress the default user consent experience
Configure access rules

Configure per-application access rules to your SaaS apps. For example, you can require MFA or only allow access
to users on trusted networks. The details for this are available in the document Configuring access rules.
Configure the app to require user assignment and assign users

By default, users can access applications without being assigned. However, if the application exposes roles or if you
want the application to appear on a user’s access panel, you should require user assignment.
If you’re an Azure AD Premium or Enterprise Mobility Suite (EMS ) subscriber, we strongly recommend using
groups. Assigning groups to the application allows you to delegate ongoing access management to the owner of
the group. You can create the group or ask the responsible party in your organization to create the group using
your group management facility.
Assigning users and groups to an application
Suppress user consent

By default, each user goes through a consent experience to sign in. The consent experience, asking users to grant
permissions to an application, can be disconcerting for users who are unfamiliar with making such decisions.
For applications that you trust, you can simplify the user experience by consenting to the application on behalf of
your organization.
For more information about user consent and the consent experience in Azure, see Integrating Applications with
Azure Active Directory.
Related Articles
Enable secure remote access to on-premises applications with Azure AD Application Proxy
Managing access to apps with Azure AD
Remote access to on-premises applications through
Azure Active Directory's Application Proxy
Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications. After
a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL
or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to
Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB ) applications.
Azure AD Application Proxy is:
Simple to use. Users can access your on-premises applications the same way they access O365 and other
SaaS apps integrated with Azure AD. You don't need to change or update your applications to work with
Application Proxy.
Secure. On-premises applications can use Azure's authorization controls and security analytics. For
example, on-premises applications can use conditional access and two-step verification. Application Proxy
doesn't require you to open inbound connections through your firewall.
Cost-effective. On-premises solutions typically require you to set up and maintain demilitarized zones
(DMZs), edge servers, or other complex infrastructures. Application Proxy runs in the cloud, which makes it
easy to use. To use Application Proxy, you don't need to change the network infrastructure or install
additional appliances in your on-premises environment.
What is Application Proxy?

Application Proxy is a feature of Azure AD that enables users to access on-premises web applications from a
remote client. Application Proxy includes both the Application Proxy service which runs in the cloud, and the
Application Proxy connector which runs on an on-premises server. Azure AD, the Application Proxy service, and
the Application Proxy connector work together to securely pass the user sign-on token from Azure AD to the web
application.
Application Proxy works with:
Web applications that use Integrated Windows Authentication for authentication
Web applications that use form-based or header-based access
Web APIs that you want to expose to rich applications on different devices
Applications hosted behind a Remote Desktop Gateway
Rich client apps that are integrated with the Active Directory Authentication Library (ADAL )
Application Proxy supports single sign-on. For more information on supported methods, see Choosing a single
sign-on method.
How Application Proxy works

The following diagram shows how Azure AD and Application Proxy work together to provide single sign-on to
on-premises applications.
1. After the user has accessed the application through an endpoint, the user is directed to the Azure AD sign-in
page.
2. After a successful sign-in, Azure AD sends a token to the user's client device.
3. The client sends the token to the Application Proxy service, which retrieves the user principal name (UPN ) and
security principal name (SPN ) from the token. Application Proxy then sends the request to the Application
Proxy connector.
4. If you have configured single sign-on, the connector performs any additional authentication required on behalf
of the user.
5. The connector sends the request to the on-premises application.
6. The response is sent through the connector and Application Proxy service to the user.
COMPONENT DESCRIPTION
Endpoint The endpoint is a URL or an end-user portal. Users can reach

applications while outside of your network by accessing an
external URL. Users within your network can access the
application through a URL or an end-user portal. When users
go to one of these endpoints, they authenticate in Azure AD
and then are routed through the connector to the on-
premises application.
Azure AD Azure AD performs the authentication using the tenant

directory stored in the cloud.
Application Proxy service This Application Proxy service runs in the cloud as part of
Azure AD. It passes the sign-on token from the user to the
Application Proxy Connector. Application Proxy forwards any
accessible headers on the request and sets the headers as per
its protocol, to the client IP address. If the incoming request
to the proxy already has that header, the client IP address is
added to the end of the comma separated list that is the
value of the header.
Application Proxy Connector The connector is a lightweight agent that runs on a Windows
Server inside your network. The connector manages
communication between the Application Proxy service in the
cloud and the on-premises application. The connector only
uses outbound connections, so you don't have to open any
inbound ports or put anything in the DMZ. The connectors
are stateless and pull information from the cloud as
necessary. For more information about connectors, like how
they load-balance and authenticate, see Understand Azure
AD Application Proxy connectors.
COMPONENT DESCRIPTION
Active Directory (AD) Active Directory runs on-premises to perform authentication

for domain accounts. When single sign-on is configured, the
connector communicates with AD to perform any additional
authentication required.
On-premises application Finally, the user is able to access an on-premises application.
Next steps
To start using Application Proxy, see Tutorial: Add an on-premises application for remote access through
Application Proxy.
For the latest news and updates, see the Application Proxy blog
Understand Azure AD Application Proxy connectors
Connectors are what make Azure AD Application Proxy possible. They're simple, easy to deploy and maintain,
and super powerful. This article discusses what connectors are, how they work, and some suggestions for how to
optimize your deployment.
What is an Application Proxy connector?

Connectors are lightweight agents that sit on-premises and facilitate the outbound connection to the Application
Proxy service. Connectors must be installed on a Windows Server that has access to the backend application.
You can organize connectors into connector groups, with each group handling traffic to specific applications.
Requirements and deployment

To deploy Application Proxy successfully, you need at least one connector, but we recommend two or more for
greater resiliency. Install the connector on a Windows Server 2012 R2 or 2016 machine. The connector needs to
communicate with the Application Proxy service and the on-premises applications that you publish.
Windows server
You need a server running Windows Server 2012 R2 or later on which you can install the Application Proxy
connector. The server needs to connect to the Application Proxy services in Azure, and the on-premises
applications that you're publishing.
The windows server needs to have TLS 1.2 enabled before you install the Application Proxy connector. Existing
connectors with versions below 1.5.612.0 will continue to work on prior versions of TLS until further notice. To
enable TLS 1.2:
1. Set the following registry keys:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
2. Restart the server

For more information about the network requirements for the connector server, see Get started with Application
Proxy and install a connector.
Maintenance
The connectors and the service take care of all the high availability tasks. They can be added or removed
dynamically. Each time a new request arrives it is routed to one of the connectors that is currently available. If a
connector is temporarily not available, it doesn't respond to this traffic.
The connectors are stateless and have no configuration data on the machine. The only data they store is the
settings for connecting the service and its authentication certificate. When they connect to the service, they pull
all the required configuration data and refresh it every couple of minutes.
Connectors also poll the server to find out whether there is a newer version of the connector. If one is found, the
connectors update themselves.
You can monitor your connectors from the machine they are running on, using either the event log and
performance counters. Or you can view their status from the Application Proxy page of the Azure portal:
You don't have to manually delete connectors that are unused. When a connector is running, it remains active as
it connects to the service. Unused connectors are tagged as inactive and are removed after 10 days of inactivity.
If you do want to uninstall a connector, though, uninstall both the Connector service and the Updater service
from the server. Restart your computer to fully remove the service.
Automatic updates
Azure AD provides automatic updates for all the connectors that you deploy. As long as the Application Proxy
Connector Updater service is running, your connectors update automatically. If you don’t see the Connector
Updater service on your server, you need to reinstall your connector to get any updates.
If you don't want to wait for an automatic update to come to your connector, you can do a manual upgrade. Go
to the connector download page on the server where your connector is located and select Download. This
process kicks off an upgrade for the local connector.
For tenants with multiple connectors, the automatic updates target one connector at a time in each group to
prevent downtime in your environment.
You may experience downtime when your connector updates if:
You only have one connector we recommend you install a second connector and create a connector group.
This will avoid downtime and provide higher availability.
A connector was in the middle of a transaction when the update began. Although the initial transaction is lost,
your browser should automatically retry the operation or you can refresh your page. When the request is
resent, the traffic is routed to a backup connector.
Creating connector groups

Connector groups enable you to assign specific connectors to serve specific applications. You can group a
number of connectors together, and then assign each application to a group.
Connector groups make it easier to manage large deployments. They also improve latency for tenants that have
applications hosted in different regions, because you can create location-based connector groups to serve only
local applications.
To learn more about connector groups, see Publish applications on separate networks and locations using
connector groups.
Capacity Planning
It is important to make sure you have planned enough capacity between connectors to handle the expected
traffic volume. In general, the more users you have, the larger a machine you'll need. Below is a table giving an
outline of the volume different machines can handle. Note it is all based on expected Transactions Per Second
(TPS ) rather than by user since usage patterns vary and can't be used to predict load. There will also be some
differences based on the size of the responses and the backend application response time - larger response sizes
and slower response times will result in a lower Max TPS. We recommend having additional machines so that
the distributed load across the machines is about 50%. The extra capacity will ensure that you have high
availability and resiliency.
CORES RAM EXPECTED LATENCY (MS)-P99 MAX TPS
2 8 325 586
4 16 320 1150
8 32 270 1190
16 64 245 1200*
* This machine used a custom setting to raise some of the default connection limits beyond .Net recommended
settings. We recommend running a test with the default settings before contacting support to get this limit
changed for your tenant.
NOTE
There is not much difference in the maximum TPS between 4, 8, and 16 core machines. The main difference between those
is in the expected latency.
Security and networking

Connectors can be installed anywhere on the network that allows them to send requests to the Application Proxy
service. What's important is that the computer running the connector also has access to your apps. You can
install connectors inside of your corporate network or on a virtual machine that runs in the cloud. Connectors
can run within a demilitarized zone (DMZ ), but it's not necessary because all traffic is outbound so your network
stays secure.
Connectors only send outbound requests. The outbound traffic is sent to the Application Proxy service and to the
published applications. You don't have to open inbound ports because traffic flows both ways once a session is
established. You also don't have to configure inbound access through your firewalls.
For more information about configuring outbound firewall rules, see Work with existing on-premises proxy
servers.
Performance and scalability

Scale for the Application Proxy service is transparent, but scale is a factor for connectors. You need to have
enough connectors to handle peak traffic. Since connectors are stateless, they aren't affected by the number of
users or sessions. Instead, they respond to the number of requests and their payload size. With standard web
traffic, an average machine can handle a couple thousand requests per second. The specific capacity depends on
the exact machine characteristics.
The connector performance is bound by CPU and networking. CPU performance is needed for SSL encryption
and decryption, while networking is important to get fast connectivity to the applications and the online service
in Azure.
In contrast, memory is less of an issue for connectors. The online service takes care of much of the processing
and all unauthenticated traffic. Everything that can be done in the cloud is done in the cloud.
If for any reason that connector or machine becomes unavailable, the traffic will start going to another connector
in the group. This resiliency is also why we recommend having multiple connectors.
Another factor that affects performance is the quality of the networking between the connectors, including:
The online service: Slow or high-latency connections to the Application Proxy service in Azure influence the
connector performance. For the best performance, connect your organization to Azure with Express Route.
Otherwise, have your networking team ensure that connections to Azure are handled as efficiently as
possible.
The backend applications: In some cases, there are additional proxies between the connector and the
backend applications that can slow or prevent connections. To troubleshoot this scenario, open a browser
from the connector server and try to access the application. If you run the connectors in Azure but the
applications are on-premises, the experience might not be what your users expect.
The domain controllers: If the connectors perform single sign-on (SSO ) using Kerberos Constrained
Delegation, they contact the domain controllers before sending the request to the backend. The connectors
have a cache of Kerberos tickets, but in a busy environment the responsiveness of the domain controllers can
affect performance. This issue is more common for connectors that run in Azure but communicate with
domain controllers that are on-premises.
For more information about optimizing your network, see Network topology considerations when using Azure
Active Directory Application Proxy.
Domain joining
Connectors can run on a machine that is not domain-joined. However, if you want single sign-on (SSO ) to
applications that use Integrated Windows Authentication (IWA), you need a domain-joined machine. In this case,
the connector machines must be joined to a domain that can perform Kerberos Constrained Delegation on
behalf of the users for the published applications.
Connectors can also be joined to domains or forests that have a partial trust, or to read-only domain controllers.
Connector deployments on hardened environments

Usually, connector deployment is straightforward and requires no special configuration. However, there are
some unique conditions that should be considered:
Organizations that limit the outbound traffic must open required ports.
FIPS -compliant machines might be required to change their configuration to allow the connector processes
to generate and store a certificate.
Organizations that lock down their environment based on the processes that issue the networking requests
have to make sure that both connector services are enabled to access all required ports and IPs.
In some cases, outbound forward proxies may break the two-way certificate authentication and cause the
communication to fail.
Connector authentication
To provide a secure service, connectors have to authenticate toward the service, and the service has to
authenticate toward the connector. This authentication is done using client and server certificates when the
connectors initiate the connection. This way the administrator’s username and password are not stored on the
connector machine.
The certificates used are specific to the Application Proxy service. They get created during the initial registration
and are automatically renewed by the connectors every couple of months.
If a connector is not connected to the service for several months, its certificates may be outdated. In this case,
uninstall and reinstall the connector to trigger registration. You can run the following PowerShell commands:
Import-module AppProxyPSModule
Register-AppProxyConnector
Under the hood

Connectors are based on Windows Server Web Application Proxy, so they have most of the same management
tools including Windows Event Logs
and Windows performance counters.

The connectors have both admin and session logs. The admin logs include key events and their errors. The
session logs include all the transactions and their processing details.
To see the logs, go to the Event Viewer, open the View menu, and enable Show analytic and debug logs.
Then, enable them to start collecting events. These logs do not appear in Web Application Proxy in Windows
Server 2012 R2, as the connectors are based on a more recent version.
You can examine the state of the service in the Services window. The connector is made up of two Windows
Services: the actual connector, and the updater. Both of them must run all the time.
Next steps
Publish applications on separate networks and locations using connector groups
Work with existing on-premises proxy servers
Troubleshoot Application Proxy and connector errors
How to silently install the Azure AD Application Proxy Connector
Publish applications on separate networks and
locations using connector groups
Customers utilize Azure AD's Application Proxy for more and more scenarios and applications. So we've made
App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups so
that you can assign specific connectors to serve specific applications. This capability gives you more control and
ways to optimize your Application Proxy deployment.
Each Application Proxy connector is assigned to a connector group. All the connectors that belong to the same
connector group act as a separate unit for high-availability and load balancing. All connectors belong to a
connector group. If you don't create groups, then all your connectors are in a default group. Your admin can create
new groups and assign connectors to them in the Azure portal.
All applications are assigned to a connector group. If you don't create groups, then all your applications are
assigned to a default group. But if you organize your connectors into groups, you can set each application to work
with a specific connector group. In this case, only the connectors in that group serve the application upon request.
This feature is useful if your applications are hosted in different locations. You can create connector groups based
on location, so that applications are always served by connectors that are physically close to them.
TIP
If you have a large Application Proxy deployment, don't assign any applications to the default connector group. That way,
new connectors don't receive any live traffic until you assign them to an active connector group. This configuration also
enables you to put connectors in an idle mode by moving them back to the default group, so that you can perform
maintenance without impacting your users.
Prerequisites
To group your connectors, you have to make sure you installed multiple connectors. When you install a new
connector, it automatically joins the Default connector group.
Create connector groups

Use these steps to create as many connector groups as you want.
2. Select Azure Active Directory > Enterprise applications > Application proxy.
3. Select New connector group. The New Connector Group blade appears.
4. Give your new connector group a name, then use the dropdown menu to select which connectors belong
in this group.
5. Select Save.
Assign applications to your connector groups
Use these steps for each application that you've published with Application Proxy. You can assign an application
to a connector group when you first publish it, or you can use these steps to change the assignment whenever
you want.
1. From the management dashboard for your directory, select Enterprise applications > All applications >
the application you want to assign to a connector group > Application Proxy.
2. Use the Connector Group dropdown menu to select the group you want the application to use.
3. Select Save to apply the change.
Use cases for connector groups

Connector groups are useful for various scenarios, including:
Sites with multiple interconnected datacenters
Many organizations have a number of interconnected datacenters. In this case, you want to keep as much traffic
within the datacenter as possible because cross-datacenter links are expensive and slow. You can deploy
connectors in each datacenter to serve only the applications that reside within the datacenter. This approach
minimizes cross-datacenter links and provides an entirely transparent experience to your users.
Applications installed on isolated networks
Applications can be hosted in networks that are not part of the main corporate network. You can use connector
groups to install dedicated connectors on isolated networks to also isolate applications to the network. This
usually happens when a third-party vendor maintains a specific application for your organization.
Connector groups allow you to install dedicated connectors for those networks that publish only specific
applications, making it easier and more secure to outsource application management to third-party vendors.
Applications installed on IaaS
For applications installed on IaaS for cloud access, connector groups provide a common service to secure the
access to all the apps. Connector groups don't create additional dependency on your corporate network, or
fragment the app experience. Connectors can be installed on every cloud datacenter and serve only applications
that reside in that network. You can install several connectors to achieve high availability.
Take as an example an organization that has several virtual machines connected to their own IaaS hosted virtual
network. To allow employees to use these applications, these private networks are connected to the corporate
network using site-to-site VPN. This provides a good experience for employees that are located on-premises. But,
it may not be ideal for remote employees, because it requires additional on-premises infrastructure to route
access, as you can see in the diagram below:
With Azure AD Application Proxy connector groups, you can enable a common service to secure the access to all
applications without creating additional dependency on your corporate network:
Multi-forest – different connector groups for each forest

Most customers who have deployed Application Proxy are using its single-sign-on (SSO ) capabilities by
performing Kerberos Constrained Delegation (KCD ). To achieve this, the connector’s machines need to be joined
to a domain that can delegate the users toward the application. KCD supports cross-forest capabilities. But for
companies who have distinct multi-forest environments with no trust between them, a single connector cannot be
used for all forests.
In this case, specific connectors can be deployed per forest, and set to serve applications that were published to
serve only the users of that specific forest. Each connector group represents a different forest. While the tenant
and most of the experience is unified for all forests, users can be assigned to their forest applications using Azure
AD groups.
Disaster Recovery sites
There are two different approaches you can take with a disaster recovery (DR ) site, depending on how your sites
are implemented:
If your DR site is built in active-active mode where it is exactly like the main site and has the same networking
and AD settings, you can create the connectors on the DR site in the same connector group as the main site.
This enables Azure AD to detect failovers for you.
If your DR site is separate from the main site, you can create a different connector group in the DR site, and
either 1) have backup applications or 2) manually divert the existing application to the DR connector group as
needed.
Serve multiple companies from a single tenant
There are many different ways to implement a model in which a single service provider deploys and maintains
Azure AD related services for multiple companies. Connector groups help the admin segregate the connectors
and applications into different groups. One way, which is suitable for small companies, is to have a single Azure
AD tenant while the different companies have their own domain name and networks. This is also true for M&A
scenarios and situations where a single IT division serves several companies for regulatory or business reasons.
Sample configurations
Some examples that you can implement, include the following connector groups.
Default configuration – no use for connector groups
If you don’t use connector groups, your configuration would look like this:
This configuration is sufficient for small deployments and tests. It will also work well if your organization has a flat
network topology.
Default configuration and an isolated network
This configuration is an evolution of the default one, in which there is a specific app that runs in an isolated
network such as IaaS virtual network:
Recommended configuration – several specific groups and a default group for idle
The recommended configuration for large and complex organizations is to have the default connector group as a
group that doesn’t serve any applications and is used for idle or newly installed connectors. All applications are
served using customized connector groups. This enables all the complexity of the scenarios described above.
In the example below, the company has two datacenters, A and B, with two connectors that serve each site. Each
site has different applications that run on it.
Next steps
Enable single-sign on
Security considerations for accessing apps remotely
with Azure AD Application Proxy
This article explains the components that work to keep your users and applications safe when you use Azure Active
Directory Application Proxy.
The following diagram shows how Azure AD enables secure remote access to your on-premises applications.
Security benefits
Azure AD Application Proxy offers the following security benefits:
Authenticated access
If you choose to use Azure Active Directory preauthentication, then only authenticated connections can access your
network.
Azure AD Application Proxy relies on the Azure AD security token service (STS ) for all authentication.
Preauthentication, by its very nature, blocks a significant number of anonymous attacks, because only
authenticated identities can access the back-end application.
If you choose Passthrough as your preauthentication method, you don't get this benefit.
Conditional access
Apply richer policy controls before connections to your network are established.
With conditional access, you can define restrictions on what traffic is allowed to access your back-end applications.
You can create policies that restrict sign-ins based on location, strength of authentication, and user risk profile.
You can also use conditional access to configure Multi-Factor Authentication policies, adding another layer of
security to your user authentications. Additionally, your applications can also be routed to Microsoft Cloud App
Security via Azure AD conditional access to provide real-time monitoring and controls, via access and session
policies
Traffic termination
All traffic is terminated in the cloud.
Because Azure AD Application Proxy is a reverse-proxy, all traffic to back-end applications is terminated at the
service. The session can get reestablished only with the back-end server, which means that your back-end servers
are not exposed to direct HTTP traffic. This configuration means that you are better protected from targeted
attacks.
All access is outbound
You don't need to open inbound connections to the corporate network.
Application Proxy connectors only use outbound connections to the Azure AD Application Proxy service, which
means that there is no need to open firewall ports for incoming connections. Traditional proxies required a
perimeter network (also known as DMZ, demilitarized zone, or screened subnet) and allowed access to
unauthenticated connections at the network edge. This scenario required investments in web application firewall
products to analyze traffic and protect the environment. With Application Proxy, you don't need a perimeter
network because all connections are outbound and take place over a secure channel.
For more information about connectors, see Understand Azure AD Application Proxy connectors.
Cloud-scale analytics and machine learning
Get cutting-edge security protection.
Because it's part of Azure Active Directory, Application Proxy can leverage Azure AD Identity Protection, with data
from the Microsoft Security Response Center and Digital Crimes Unit. Together we proactively identify
compromised accounts and offer protection from high-risk sign-ins. We take into account numerous factors to
determine which sign-in attempts are high risk. These factors include flagging infected devices, anonymizing
networks, and atypical or unlikely locations.
Many of these reports and events are already available through an API for integration with your security
information and event management (SIEM ) systems.
Remote access as a service
You don’t have to worry about maintaining and patching on-premises servers.
Unpatched software still accounts for a large number of attacks. Azure AD Application Proxy is an Internet-scale
service that Microsoft owns, so you always get the latest security patches and upgrades.
To improve the security of applications published by Azure AD Application Proxy, we block web crawler robots
from indexing and archiving your applications. Each time a web crawler robot tries to retrieve the robot's settings
for a published app, Application Proxy replies with a robots.txt file that includes User-agent: * Disallow: / .
DDOS prevention
Applications published through Application Proxy are protected against Distributed Denial of Service (DDOS )
attacks.
The Application Proxy service monitors the amount of traffic attempting to reach your applications and network. If
the number of devices requesting remote access to your applications spikes, Microsoft throttles access to your
network.
Microsoft watches traffic patterns for individual applications and for your subscription as a whole. If one
application receives higher than normal requests, then requests to access that application are denied for a short
period of time. If you receive higher than normal requests across your whole subscription, then requests to access
any of your apps are denied. This preventative measure keeps your application servers from being overloaded by
remote access requests, so that your on-premises users can keep accessing their apps.
Under the hood

Azure AD Application Proxy consists of two parts:
The cloud-based service: This service runs in Azure, and is where the external client/user connections are made.
The on-premises connector: An on-premises component, the connector listens for requests from the Azure AD
Application Proxy service and handles connections to the internal applications.
A flow between the connector and the Application Proxy service is established when:
The connector is first set up.
The connector pulls configuration information from the Application Proxy service.
A user accesses a published application.
NOTE
All communications occur over SSL, and they always originate at the connector to the Application Proxy service. The service is
outbound only.
The connector uses a client certificate to authenticate to the Application Proxy service for nearly all calls. The only
exception to this process is the initial setup step, where the client certificate is established.
Installing the connector
When the connector is first set up, the following flow events take place:
1. The connector registration to the service happens as part of the installation of the connector. Users are
prompted to enter their Azure AD admin credentials. The token acquired from this authentication is then
presented to the Azure AD Application Proxy service.
2. The Application Proxy service evaluates the token. It checks whether the user is a company administrator in the
tenant. If the user is not an administrator, the process is terminated.
3. The connector generates a client certificate request and passes it, along with the token, to the Application Proxy
service. The service in turn verifies the token and signs the client certificate request.
4. The connector uses the client certificate for future communication with the Application Proxy service.
5. The connector performs an initial pull of the system configuration data from the service using its client
certificate, and it is now ready to take requests.
Updating the configuration settings
Whenever the Application Proxy service updates the configuration settings, the following flow events take place:
1. The connector connects to the configuration endpoint within the Application Proxy service by using its client
certificate.
2. After the client certificate is validated, the Application Proxy service returns configuration data to the connector
(for example, the connector group that the connector should be part of).
3. If the current certificate is more than 180 days old, the connector generates a new certificate request, which
effectively updates the client certificate every 180 days.
Accessing published applications
When users access a published application, the following events take place between the Application Proxy service
and the Application Proxy connector:
1. The service authenticates the user for the app
2. The service places a request in the connector queue
3. A connector processes the request from the queue
4. The connector waits for a response
5. The service streams data to the user
To learn more about what takes place in each of these steps, keep reading.
1. The service authenticates the user for the app
If you configured the app to use Passthrough as its preauthentication method, the steps in this section are skipped.
If you configured the app to preauthenticate with Azure AD, users are redirected to the Azure AD STS to
authenticate, and the following steps take place:
1. Application Proxy checks for any conditional access policy requirements for the specific application. This
step ensures that the user has been assigned to the application. If two-step verification is required, the
authentication sequence prompts the user for a second authentication method.
2. After all checks have passed, the Azure AD STS issues a signed token for the application and redirects the
user back to the Application Proxy service.
3. Application Proxy verifies that the token was issued to the correct application. It performs other checks also,
such as ensuring that the token was signed by Azure AD, and that it is still within the valid window.
4. Application Proxy sets an encrypted authentication cookie to indicate that authentication to the application
has occurred. The cookie includes an expiration timestamp that's based on the token from Azure AD and
other data, such as the user name that the authentication is based on. The cookie is encrypted with a private
key known only to the Application Proxy service.
5. Application Proxy redirects the user back to the originally requested URL.
If any part of the preauthentication steps fails, the user’s request is denied, and the user is shown a message
indicating the source of the problem.
2. The service places a request in the connector queue
Connectors keep an outbound connection open to the Application Proxy service. When a request comes in, the
service queues up the request on one of the open connections for the connector to pick up.
The request includes items from the application, such as the request headers, data from the encrypted cookie, the
user making the request, and the request ID. Although data from the encrypted cookie is sent with the request, the
authentication cookie itself is not.
3. The connector processes the request from the queue.
Based on the request, Application Proxy performs one of the following actions:
If the request is a simple operation (for example, there is no data within the body as is with a RESTful GET
request), the connector makes a connection to the target internal resource and then waits for a response.
If the request has data associated with it in the body (for example, a RESTful POST operation), the connector
makes an outbound connection by using the client certificate to the Application Proxy instance. It makes this
connection to request the data and open a connection to the internal resource. After it receives the request
from the connector, the Application Proxy service begins accepting content from the user and forwards data
to the connector. The connector, in turn, forwards the data to the internal resource.
4. The connector waits for a response.
After the request and transmission of all content to the back end is complete, the connector waits for a response.
After it receives a response, the connector makes an outbound connection to the Application Proxy service, to
return the header details and begin streaming the return data.
5. The service streams data to the user.
Some processing of the application may occur here. If you configured Application Proxy to translate headers or
URLs in your application, that processing happens as needed during this step.
Next steps
Network topology considerations when using Azure AD Application Proxy
Network topology considerations when using Azure
Active Directory Application Proxy
This article explains network topology considerations when using Azure Active Directory (Azure AD ) Application
Proxy for publishing and accessing your applications remotely.
Traffic flow
When an application is published through Azure AD Application Proxy, traffic from the users to the applications
flows through three connections:
1. The user connects to the Azure AD Application Proxy service public endpoint on Azure
2. The Application Proxy service connects to the Application Proxy connector
3. The Application Proxy connector connects to the target application
Tenant location and Application Proxy service

When you sign up for an Azure AD tenant, the region of your tenant is determined by the country you specify.
When you enable Application Proxy, the Application Proxy service instances for your tenant are chosen or created
in the same region as your Azure AD tenant, or the closest region to it.
For example, if your Azure AD tenant’s country or region is the United Kingdom, all your Application Proxy
connectors use service instances in EU data centers. When your users access published applications, their traffic
goes through the Application Proxy service instances in this location.
Considerations for reducing latency

All proxy solutions introduce latency into your network connection. No matter which proxy or VPN solution you
choose as your remote access solution, it always includes a set of servers enabling the connection to inside your
corporate network.
Organizations typically include server endpoints in their perimeter network. With Azure AD Application Proxy,
however, traffic flows through the proxy service in the cloud while the connectors reside on your corporate
network. No perimeter network is required.
The next sections contain additional suggestions to help you reduce latency even further.
Connector placement
Application Proxy chooses the location of instances for you, based on your tenant location. However, you get to
decide where to install the connector, giving you the power to define the latency characteristics of your network
traffic.
When setting up the Application Proxy service, ask the following questions:
Where is the app located?
Where are most users who access the app located?
Where is the Application Proxy instance located?
Do you already have a dedicated network connection to Azure datacenters set up, like Azure ExpressRoute or a
similar VPN?
The connector has to communicate with both Azure and your applications (steps 2 and 3 in the Traffic flow
diagram), so the placement of the connector affects the latency of those two connections. When evaluating the
placement of the connector, keep in mind the following points:
If you want to use Kerberos constrained delegation (KCD ) for single sign-on, then the connector needs a line of
sight to a datacenter. Additionally, the connector server needs to be domain joined.
When in doubt, install the connector closer to the application.
General approach to minimize latency
You can minimize the latency of the end-to-end traffic by optimizing each network connection. Each connection
can be optimized by:
Reducing the distance between the two ends of the hop.
Choosing the right network to traverse. For example, traversing a private network rather than the public
Internet may be faster, due to dedicated links.
If you have a dedicated VPN or ExpressRoute link between Azure and your corporate network, you may want to
use that.
Focus your optimization strategy

There's little that you can do to control the connection between your users and the Application Proxy service.
Users may access your apps from a home network, a coffee shop, or a different country. Instead, you can optimize
the connections from the Application Proxy service to the Application Proxy connectors to the apps. Consider
incorporating the following patterns in your environment.
Pattern 1: Put the connector close to the application
Place the connector close to the target application in the customer network. This configuration minimizes step 3 in
the topography diagram, because the connector and application are close.
If your connector needs a line of sight to the domain controller, then this pattern is advantageous. Most of our
customers use this pattern, because it works well for most scenarios. This pattern can also be combined with
pattern 2 to optimize traffic between the service and the connector.
Pattern 2: Take advantage of ExpressRoute with Microsoft peering
If you have ExpressRoute set up with Microsoft peering, you can use the faster ExpressRoute connection for traffic
between Application Proxy and the connector. The connector is still on your network, close to the app.
Pattern 3: Take advantage of ExpressRoute with private peering
If you have a dedicated VPN or ExpressRoute set up with private peering between Azure and your corporate
network, you have another option. In this configuration, the virtual network in Azure is typically considered as an
extension of the corporate network. So you can install the connector in the Azure datacenter, and still satisfy the
low latency requirements of the connector-to-app connection.
Latency is not compromised because traffic is flowing over a dedicated connection. You also get improved
Application Proxy service-to-connector latency because the connector is installed in an Azure datacenter close to
your Azure AD tenant location.
Other approaches
Although the focus of this article is connector placement, you can also change the placement of the application to
get better latency characteristics.
Increasingly, organizations are moving their networks into hosted environments. This enables them to place their
apps in a hosted environment that is also part of their corporate network, and still be within the domain. In this
case, the patterns discussed in the preceding sections can be applied to the new application location. If you're
considering this option, see Azure AD Domain Services.
Additionally, consider organizing your connectors using connector groups to target apps that are in different
locations and networks.
Common use cases

In this section, we walk through a few common scenarios. Assume that the Azure AD tenant (and therefore proxy
service endpoint) is located in the United States (US ). The considerations discussed in these use cases also apply
to other regions around the globe.
For these scenarios, we call each connection a "hop" and number them for easier discussion:
Hop 1: User to the Application Proxy service
Hop 2: Application Proxy service to the Application Proxy connector
Hop 3: Application Proxy connector to the target application
Use case 1
Scenario: The app is in an organization's network in the US, with users in the same region. No ExpressRoute or
VPN exists between the Azure datacenter and the corporate network.
Recommendation: Follow pattern 1, explained in the previous section. For improved latency, consider using
ExpressRoute, if needed.
This is a simple pattern. You optimize hop 3 by placing the connector near the app. This is also a natural choice,
because the connector typically is installed with line of sight to the app and to the datacenter to perform KCD
operations.
Use case 2
Scenario: The app is in an organization's network in the US, with users spread out globally. No ExpressRoute or
VPN exists between the Azure datacenter and the corporate network.
Recommendation: Follow pattern 1, explained in the previous section.
Again, the common pattern is to optimize hop 3, where you place the connector near the app. Hop 3 is not
typically expensive, if it is all within the same region. However, hop 1 can be more expensive depending on where
the user is, because users across the world must access the Application Proxy instance in the US. It's worth noting
that any proxy solution has similar characteristics regarding users being spread out globally.
Use case 3
Scenario: The app is in an organization's network in the US. ExpressRoute with Microsoft peering exists between
Azure and the corporate network.
Recommendation: Follow patterns 1 and 2, explained in the previous section.
First, place the connector as close as possible to the app. Then, the system automatically uses ExpressRoute for
hop 2.
If the ExpressRoute link is using Microsoft peering, the traffic between the proxy and the connector flows over that
link. Hop 2 has optimized latency.
Use case 4
Scenario: The app is in an organization's network in the US. ExpressRoute with private peering exists between
Azure and the corporate network.
Recommendation: Follow pattern 3, explained in the previous section.
Place the connector in the Azure datacenter that is connected to the corporate network through ExpressRoute
private peering.
The connector can be placed in the Azure datacenter. Since the connector still has a line of sight to the application
and the datacenter through the private network, hop 3 remains optimized. In addition, hop 2 is optimized further.
Use case 5
Scenario: The app is in an organization's network in the EU, with the Application Proxy instance and most users in
the US.
Recommendation: Place the connector near the app. Because US users are accessing an Application Proxy
instance that happens to be in the same region, hop 1 is not too expensive. Hop 3 is optimized. Consider using
ExpressRoute to optimize hop 2.
You can also consider using one other variant in this situation. If most users in the organization are in the US, then
chances are that your network extends to the US as well. Place the connector in the US, and use the dedicated
internal corporate network line to the application in the EU. This way hops 2 and 3 are optimized.
Next steps
Enable Application Proxy
Enable conditional access
Troubleshoot issues you're having with Application Proxy
Compare remote access solutions
Azure Active Directory Application Proxy is one of two remote access solutions that Microsoft offers. The other is
Web Application Proxy, the on-premises version. These two solutions replace earlier products that Microsoft
offered: Microsoft Forefront Threat Management Gateway (TMG ) and Unified Access Gateway (UAG ). Use this
article to understand how these four solutions compare to each other. For those of you still using the deprecated
TMG or UAG solutions, use this article to help plan your migration to one of the Application Proxy.
Feature comparison
Use this table to understand how Threat Management Gateway (TMG ), Unified Access Gateway (UAG ), Web
Application Proxy (WAP ), and Azure AD Application Proxy (AP ) compare to each other.
FEATURE TMG UAG WAP AP
Certificate Yes Yes - -

authentication
Selectively publish Yes Yes Yes Yes

browser apps
Preauthentication and Yes Yes Yes Yes

single sign-on
Layer 2/3 firewall Yes Yes - -
Forward proxy Yes - - -

capabilities
VPN capabilities Yes Yes - -
Rich protocol support - Yes Yes, if running over Yes, if running over
HTTP HTTP or through
Remote Desktop
Gateway
Serves as ADFS proxy - Yes Yes -

server
One portal for - Yes - Yes

application access
Response body link Yes Yes - Yes

translation
Authentication with - Yes - Yes, with PingAccess

headers
Cloud-scale security - - - Yes

FEATURE TMG UAG WAP AP
Conditional access - Yes - Yes
No components in - - - Yes
the demilitarized zone
(DMZ)
No inbound - - - Yes
connections
For most scenarios, we recommend Azure AD Application as the modern solution. Web Application Proxy is only
preferred in scenarios that require a proxy server for AD FS, and you can't use custom domains in Azure Active
Directory.
Azure AD Application Proxy offers unique benefits when compared to similar products, including:
Extending Azure AD to on-premises resources
Cloud-scale security and protection
Features like conditional access and Multi-Factor Authentication are easy to enable
No components in the demilitarized zone
No inbound connections required
One access panel that your users can go to for all their applications, including O365, Azure AD integrated SaaS
apps, and your on-premises web apps.
Next steps
Use Azure AD Application to provide secure remote access to on-premises applications
Transition from Forefront TMG and UAG to Application Proxy.
Managing user account provisioning for enterprise
apps in the Azure portal
This article describes how to use the Azure portal to manage automatic user account provisioning and de-
provisioning for applications that support it. To learn more about automatic user account provisioning and how it
works, see Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active Directory.
Finding your apps in the portal

All applications that are configured for single sign-on in a directory can be viewed and managed in the Azure
portal. The applications can be found in the All Services > Enterprise Applications section of the portal.
Enterprise apps are apps that are deployed and used within your organization.
Selecting the All applications link on the left shows a list of all apps that have been configured, including apps
that had been added from the gallery. Selecting an app loads the resource pane for that app, where reports can be
viewed for that app and a variety of settings can be managed.
User account provisioning settings can be managed by selecting Provisioning on the left.
Provisioning modes
The Provisioning pane begins with a Mode menu, which shows what provisioning modes are supported for an
enterprise application, and allows them to be configured. The available options include:
Automatic - This option appears if Azure AD supports automatic API-based provisioning and/or de-
provisioning of user accounts to this application. Selecting this mode displays an interface that guides
administrators through configuring Azure AD to connect to the application's user management API, creating
account mappings and workflows that define how user account data should flow between Azure AD and the
app, and managing the Azure AD provisioning service.
Manual - This option is shown if Azure AD does not support automatic provisioning of user accounts to this
application. This option means that user account records stored in the application must be managed using an
external process, based on the user management and provisioning capabilities provided by that application
(which can include SAML Just-In-Time provisioning).
Configuring automatic user account provisioning

Selecting the Automatic option displays a screen that is divided in four sections:
Admin Credentials
This section is where the credentials required for Azure AD to connect to the application's user management API
are entered. The input required varies depending on the application. To learn about the credential types and
requirements for specific applications, see the configuration tutorial for that specific application.
Selecting the Test Connection button allows you to test the credentials by having Azure AD attempt to connect to
the app's provisioning app using the supplied credentials.
Mappings
This section is where admins can view and edit what user attributes flow between Azure AD and the target
application, when user accounts are provisioned or updated.
There is a preconfigured set of mappings between Azure AD user objects and each SaaS app’s user objects. Some
apps manage other types of objects, such as Groups or Contacts. Selecting one of these mappings in the table
shows the mapping editor to the right, where they can be viewed and customized.
Supported customizations include:
Enabling and disabling mappings for specific objects, such as the Azure AD user object to the SaaS app's user
object.
Editing the attributes that flow from the Azure AD user object to the app's user object. For more information on
attribute mapping, see Understanding attribute mapping types.
Filter the provisioning actions that Azure AD performs on the targeted application. Instead of having Azure AD
fully synchronize objects, you can limit the actions performed. For example, by only selecting Update, Azure
AD only updates existing user accounts in an application and does not create new ones. By only selecting
Create, Azure only creates new user accounts but does not update existing ones. This feature allows admins to
create different mappings for account creation and update workflows.
Settings
This section allows admins to start and stop the Azure AD provisioning service for the selected application, as well
as optionally clear the provisioning cache and restart the service.
If provisioning is being enabled for the first time for an application, turn on the service by changing the
Provisioning Status to On. This change causes the Azure AD provisioning service to perform an initial sync,
where it reads the users assigned in the Users and groups section, queries the target application for them, and
then performs the provisioning actions defined in the Azure AD Mappings section. During this process, the
provisioning service stores cached data about what user accounts it is managing, so non-managed accounts inside
the target applications that were never in scope for assignment aren't affected by de-provisioning operations. After
the initial sync, the provisioning service automatically synchronizes user and group objects on a ten-minute
interval.
Changing the Provisioning Status to Off simply pauses the provisioning service. In this state, Azure does not
create, update, or remove any user or group objects in the app. Changing the state back to on causes the service to
pick up where it left off.
Selecting the Clear current state and restart synchronization checkbox and saving stops the provisioning
service, dumps the cached data about what accounts Azure AD is managing, restarts the services and performs the
initial synchronization again. This option allows admins to start the provisioning deployment process over again.
Synchronization Details
This section provides addition details about the operation of the provisioning service, including the first and last
times the provisioning service ran against the application, and how many user and group objects are being
managed.
Links are provided to the Provisioning activity report that provides a log of all users and groups created,
updated, and removed between Azure AD and the target application, and to the Provisioning error report that
provides more detailed error messages for user and group objects that failed to be read, created, updated, or
removed.
Automate user provisioning and deprovisioning to
SaaS applications with Azure Active Directory
What is automated user provisioning for SaaS apps?

Azure Active Directory (Azure AD ) allows you to automate the creation, maintenance, and removal of user
identities in cloud (SaaS ) applications such as Dropbox, Salesforce, ServiceNow, and more.
Below are some examples of what this feature allows you to do:
Automatically create new accounts in the right systems for new people when they join your team or
organization.
Automatically deactivate accounts in the right systems when people leave the team or organization.
Ensure that the identities in your apps and systems are kept up-to-date based on changes in the directory, or
your human resources system.
Provision non-user objects, such as groups, to applications that support them.
Automated user provisioning also includes the following functionality:
The ability to match existing identities between source and target systems.
Customizable attribute mappings that define what user data should flow from the source system to the
target system.
Optional email alerts for provisioning errors.
Reporting and activity logs to help with monitoring and troubleshooting.
Why use automated provisioning?

Some common motivations for using this feature include:
Avoiding the costs, inefficiencies, and human error associated with manual provisioning processes.
Avoiding the costs associated with hosting and maintaining custom-developed provisioning solutions and
scripts.
To secure your organization by instantly removing users' identities from key SaaS apps when they leave the
organization.
To easily import a large number of users into a particular SaaS application or system.
To enjoy having a single set of policies to determine who is provisioned and who can sign in to an app.
How does automatic provisioning work?

The Azure AD Provisioning Service provisions users to SaaS apps and other systems, by connecting to user
management API endpoints provided by each application vendor. These user management API endpoints allow
Azure AD to programmatically create, update, and remove users. For selected applications the provisioning
service can also create, update, and remove additional identity-related objects, such as groups and roles.
Figure 1: The Azure AD Provisioning Service
Figure 2: "Outbound" user provisioning workflow from Azure AD to popular SaaS applications
Figure 3: "Inbound" user provisioning workflow from popular Human Capital Management (HCM ) applications
to Azure Active Directory and Windows Server Active Directory
What applications and systems can I use with Azure AD automatic

user provisioning?
Azure AD features pre-integrated support for a variety of popular SaaS apps and human resources systems, as
well as generic support for apps that implement specific parts of the SCIM 2.0 standard.
Pre -integrated applications
For a list of all applications for which Azure AD supports a pre-integrated provisioning connector, see the list of
application tutorials for user provisioning.
To contact the Azure AD engineering team to request provisioning support for additional applications, submit a
message through the Azure Active Directory feedback forum.
NOTE
In order for an application to support automated user provisioning, it must first provide the necessary user management
APIs that allow for external programs to automate the creation, maintenance, and removal of users. Therefore, not all SaaS
apps are compatible with this feature. For apps that do support user management APIs, the Azure AD engineering team
will then be able to build a provisioning connector to those apps, and this work is prioritized by the needs of current and
prospective customers.
Connecting applications that support SCIM 2.0

For information on how to generically connect applications that implement SCIM 2.0 -based user management
APIs, see Using SCIM to automatically provision users and groups from Azure Active Directory to applications.
How do I set up automatic provisioning to an application?

Configuration of the Azure AD provisioning service for a selected application starts in the Azure portal. In the
Azure Active Directory > Enterprise Applications section, select Add, then All, and then add either of the
following depending on your scenario:
All applications in the Featured applications section support automatic provisioning. See the list of
application tutorials for user provisioning for additional ones.
Use the “non-gallery application” option for custom-developed SCIM integrations
In the application management screen, provisioning is configured in the Provisioning tab.

Admin credentials must be provided to the Azure AD provisioning service that will allow it to connect
to the user management API provided by the application. This section also allows you to enable email
notifications if the credentials fail, or the provisioning job goes into quarantine.
Attribute mappings can be configured that specify which fields in the source system (example: Azure
AD ) will have their contents synchronized to which fields in the target system (example: ServiceNow ). If
the target application supports it, this section will allow you to optionally configure provisioning of
groups in addition to user accounts. "Matching properties" allow you to select which fields are used to
match accounts between the systems. "Expressions" allow you to modify and transform the values
retrieved from the source system before they are written to the target system. For more information, see
Customizing Attribute Mappings.
Scoping filters tell the provisioning service which users and groups in the source system should be
provisioned and/or deprovisioned to the target system. There are two aspects to scoping filters that are
evaluated together that determine who is in scope for provisioning:
Filter on attribute values - The "Source Object Scope" menu in the attribute mappings allows
filtering on specific attribute values. For example, you can specify that only users with a
"Department" attribute of "Sales" should be in scope for provisioning. For more information, see
Using scoping filters.
Filter on assignments - The "Scope" menu in the Provisioning > Settings section of the portal
allows you to specify whether only "assigned" users and groups should be in scope for
provisioning, or if all users in the Azure AD directory should be provisioned. For information on
"assigning" users and groups, see Assign a user or group to an enterprise app in Azure Active
Directory.
Settings control the operation of the provisioning service for an application, including whether it is
currently running or not.
Audit logs provide records of every operation performed by the Azure AD provisioning service. For
more details, see the provisioning reporting guide.
NOTE
The Azure AD user provisioning service can also be configured and managed using the Microsoft Graph API.
What happens during provisioning?

When Azure AD is the source system, the provisioning service uses the Differential Query feature of the Azure
AD Graph API to monitor users and groups. The provisioning service runs an initial sync against the source
system and target system, followed by periodic incremental syncs.
Initial sync
When the provisioning service is started, the first sync ever performed will:
1. Query all users and groups from the source system, retrieving all attributes defined in the attribute
mappings.
2. Filter the users and groups returned, using any configured assignments or attribute-based scoping filters.
3. When a user is found to be assigned or in scope for provisioning, the service queries the target system for a
matching user using the designated matching attributes. Example: If the userPrincipal name in the source
system is the matching attribute and maps to userName in the target system, then the provisioning service
queries the target system for userNames that match the userPrincipal name values in the source system.
4. If a matching user is not found in the target system, it is created using the attributes returned from the source
system. After the user account is created, the provisioning service detects and caches the target system's ID
for the new user, which is used to perform all future operations on that user.
5. If a matching user is found, it is updated using the attributes provided by the source system. After the user
account is matched, the provisioning service detects and caches the target system's ID for the new user,
which is used to perform all future operations on that user.
6. If the attribute mappings contain "reference" attributes, the service performs additional updates on the target
system to create and link the referenced objects. For example, a user may have a "Manager" attribute in the
target system, which is linked to another user created in the target system.
7. Persist a watermark at the end of the initial sync, which provides the starting point for the subsequent
incremental syncs.
Some applications such as ServiceNow, Google Apps, and Box support not only provisioning users, but also
provisioning groups and their members. In those cases, if group provisioning is enabled in the mappings, the
provisioning service synchronizes the users and the groups, and then subsequently synchronizes the group
memberships.
Incremental syncs
After the initial sync, all subsequent syncs will:
1. Query the source system for any users and groups that were updated since the last watermark was stored.
2. Filter the users and groups returned, using any configured assignments or attribute-based scoping filters.
3. When a user is found to be assigned or in scope for provisioning, the service queries the target system for a
matching user using the designated matching attributes.
4. If a matching user is not found in the target system, it is created using the attributes returned from the source
system. After the user account is created, the provisioning service detects and caches the target system's ID
for the new user, which is used to perform all future operations on that user.
5. If a matching user is found, it is updated using the attributes provided by the source system. If it is a newly-
assigned account that is matched, the provisioning service detects and caches the target system's ID for the
new user, which is used to perform all future operations on that user.
6. If the attribute mappings contain "reference" attributes, the service performs additional updates on the target
system to create and link the referenced objects. For example, a user may have a "Manager" attribute in the
target system, which is linked to another user created in the target system.
7. If a user that was previously in scope for provisioning is removed from scope (including being unassigned),
the service disables the user in the target system via an update.
8. If a user that was previously in scope for provisioning is disabled or soft-deleted in the source system, the
service disables the user in the target system via an update.
9. If a user that was previously in scope for provisioning is hard-deleted in the source system, the service
deletes the user in the target system. In Azure AD, users are hard-deleted 30 days after they are soft-deleted.
10. Persist a new watermark at the end of the incremental sync, which provides the starting point for the
subsequent incremental syncs.
NOTE
You can optionally disable the create, update, or delete operations by using the Target object actions check boxes in the
Attribute Mappings section. The logic to disable a user during an update is also controlled via an attribute mapping from a
field such as "accountEnabled".
The provisioning service will continue to run back-to-back incremental syncs indefinitely, at intervals defined in
the tutorial specific to each application, until one of the following events occurs:
The service is manually stopped using the Azure portal, or using the appropriate Graph API command
A new initial sync is triggered using the Clear state and restart option in the Azure portal, or using the
appropriate Graph API command. This clears any stored watermark and causes all source objects to be
evaluated again.
A new initial sync is triggered due to a change in attribute mappings or scoping filters. This also clears any
stored watermark and causes all source objects to be evaluated again.
The provisioning process goes into quarantine (see below ) due to a high error rate, and stays in quarantine
for more than four weeks. In this event, the service will be automatically disabled.
Errors and retries
If an individual user can't be added, updated, or deleted in the target system due to an error in the target system,
then the operation will be retried in the next sync cycle. If the user continues to fail, then the retries will begin to
occur at a reduced frequency, gradually scaling back to just one attempt per day. To resolve the failure,
administrators will need to check the audit logs for "process escrow" events to determine the root cause and
take the appropriate action. Common failures can include:
Users not having an attribute populated in the source system that is required in the target system
Users having an attribute value in the source system for which there is a unique constraint in the target
system, and the same value is present in another user record
These failures can be resolved by adjusting the attribute values for the affected user in the source system, or by
adjusting the attribute mappings to not cause conflicts.
Quarantine
If most or all of the calls made against the target system consistently fail due to an error (such as in the case of
invalid admin credentials), then the provisioning job goes into a "quarantine" state. This is indicated in the
provisioning summary report, and via email if email notifications were configured in the Azure portal.
When in quarantine, the frequency of incremental syncs is gradually reduced to once per day.
The provisioning job will be removed from quarantine after all of the offending errors being fixed, and the next
sync cycle starts. If the provisioning job stays in quarantine for more than four weeks, the provisioning job is
disabled.
How long will it take to provision users?

Performance depends on whether your provisioning job is performing an initial sync or an incremental sync, as
described in the previous section.
For initial syncs, the job time depends on a variety of factors, including the number of users and groups in
scope for provisioning, and the total number of users and group in the source system. A comprehensive list of
factors that affect initial sync performance are summarized later in this section.
For incremental syncs, the job time depends on the number of changes detected in that sync cycle. If there are
fewer than 5,000 user or group membership changes, the job can finish within a single incremental sync cycle.
The following table summarizes synchronization times for common provisioning scenarios. In these scenarios,
the source system is Azure AD and the target system is a SaaS application. The sync times are derived from a
statistical analysis of sync jobs for the SaaS applications ServiceNow, Workplace, Salesforce, and Google Apps.
USERS, GROUPS, AND

SCOPE CONFIGURATION MEMBERS IN SCOPE INITIAL SYNC TIME INCREMENTAL SYNC TIME
Sync assigned users and < 1,000 < 30 minutes < 30 minutes
groups only
Sync assigned users and 1,000 - 10,000 142 - 708 minutes < 30 minutes
groups only
Sync assigned users and 10,000 - 100,000 1,170 - 2,340 minutes < 30 minutes
groups only
Sync all users and groups in < 1,000 < 30 minutes < 30 minutes
Azure AD
Sync all users and groups in 1,000 - 10,000 < 30 - 120 minutes < 30 minutes
Azure AD
Sync all users and groups in 10,000 - 100,000 713 - 1,425 minutes < 30 minutes
Azure AD
Sync all users in Azure AD < 1,000 < 30 minutes < 30 minutes
Sync all users in Azure AD 1,000 - 10,000 43 - 86 minutes < 30 minutes
For the configuration Sync assigned user and groups only, you can use the following formulas to determine
the approximate minimum and maximum expected initial sync times:
Minimum minutes = 0.01 x [Number of assigned users, groups, and group members]
Maximum minutes = 0.08 x [Number of assigned users, groups, and group members]
Summary of factors that influence the time it takes to complete an initial sync:
The total number of users and groups in scope for provisioning.
The total number of users, groups, and group members present in the source system (Azure AD ).
Whether or not users in scope for provisioning are matched to existing users in the target application, or
need to be created for the first time. Sync jobs for which all users are created for the first time take
approximately twice as long as sync jobs for which all users are matched to existing users.
Number of errors in the audit logs. Performance is slower if there are many errors and the provisioning
service has gone into a quarantine state.
Request rate limits and throttling implemented by the target system. Some target systems implement
request rate limits and throttling which can impact performance during large sync operations. Under
these conditions, an app that receives too many requests too fast might slow its response rate or close the
connection. To improve performance, the connector needs to adjust by not sending the app requests
faster than the app can process them. Provisioning connectors built by Microsoft make this adjustment.
The number and sizes of assigned groups. Syncing assigned groups takes longer than syncing users. Both
the number and the sizes of the assigned groups impact performance. If an application has mappings
enabled for group object sync, group properties such as group names and memberships are synced in
addition to users. These additional syncs will take longer than only syncing user objects.
How can I tell if users are being provisioned properly?

All operations performed by the user provisioning service are recorded in the Azure AD audit logs. This includes
all read and write operations made to the source and target systems, as well as what user data was read or
written during each operation.
For information on how the read the audit logs in the Azure portal, see the provisioning reporting guide.
How do I troubleshoot issues with user provisioning?

For scenario-based guidance on how to troubleshoot automatic user provisioning, see Problems configuring
and provisioning users to an application.
What are the best practices for rolling out automatic user
provisioning?
For an example step-by-step deployment plan for outbound user provisioning to an application, see the Identity
Deployment Guide for User Provisioning.
More frequently asked questions

Does automatic user provisioning to SaaS apps work with B2B users in Azure AD?
Yes, it is possible to use the Azure AD user provisioning service to provision B2B (or guest) users in Azure AD to
SaaS applications.
However, for B2B users to be able to sign in to the SaaS application using Azure AD, the SaaS application must
have its SAML -based single sign-on capability configured in a specific way. For more information on how to
configure SaaS applications to support sign-ins from B2B users, see Configure SaaS apps for B2B collaboration.
Does automatic user provisioning to SaaS apps work with dynamic groups in Azure AD?
Yes. When configured to "sync only assigned users and groups", the Azure AD user provisioning service can
provision or de-provision users in a SaaS application based on whether or not they are members of a dynamic
group. Dynamic groups also work with the "sync all users and groups" option.
However, usage of dynamic groups can impact the overall performance of end-to-end user provisioning from
the Azure AD to SaaS applications. When using dynamic groups, please keep these caveats and
recommendations in mind:
How fast a user in a dynamic group is provisioned or deprovisioned in a SaaS application depends on
how fast the dynamic group can evaluate membership changes. For information on how to check the
processing status of a dynamic group, see Check processing status for a membership rule.
When using dynamic groups, the rules must be carefully considered with user provisioning and de-
provisioning in mind, as a loss of membership will result in a deprovisioning event.
Does automatic user provisioning to SaaS apps work with nested groups in Azure AD?
No. When configured to "sync only assigned users and groups", the Azure AD user provisioning service is not
able to read or provision users that are in nested groups. It is only able to read and provision users that are
immediate members of the explicitly-assigned group.
This is a limitation of "group-based assignments to applications", which also affects single sign-on and is
described in Using a group to manage access to SaaS applications.
As a workaround, you should explicitly-assign (or otherwise scope in) the groups that contain the users who
need to be provisioned.
Related articles
List of Tutorials on How to Integrate SaaS Apps
Customizing Attribute Mappings for User Provisioning
Writing Expressions for Attribute Mappings
Scoping Filters for User Provisioning
Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to
applications
Azure AD synchronization API overview
Using System for Cross-Domain Identity
Management (SCIM) to automatically provision users
and groups from Azure Active Directory to
applications
Overview
SCIM is standardized protocol and schema that aims to drive greater consistency in how identities are managed
across systems. When an application supports a SCIM endpoint for user management, the Azure AD user
provisioning service can send requests to create, modify, or delete assigned users and groups to this endpoint.
Many of the applications for which Azure AD supports pre-integrated automatic user provisioning implement
SCIM as the means to receive user change notifications. In addition to these, customers can connect applications
that support a specific profile of the SCIM 2.0 protocol specification using the generic "non-gallery" integration
option in the Azure portal.
The main focus of this document is on the profile of SCIM 2.0 that Azure AD implements as part of its generic
SCIM connector for non-gallery apps. However, successful testing of an application that supports SCIM with the
generic Azure AD connector is a step to getting an app listed in the Azure AD gallery as supporting user
provisioning. For more information on getting your application listed in the Azure AD application gallery, see the
Microsoft Application Network.
IMPORTANT
The behavior of the Azure AD SCIM implementation was last updated on December 18, 2018. For information on what
changed, see SCIM 2.0 protocol compliance of the Azure AD User Provisioning service.
Figure 1: Provisioning from Azure Active Directory to an application or identity store that implements SCIM
This article is split into four sections:
Provisioning users and groups to third-party applications that support SCIM 2.0 - If your
organization is using a third-party application that implements the profile of SCIM 2.0 that Azure AD
supports, you can start automating both provisioning and de-provisioning of users and groups today.
Understanding the Azure AD SCIM implementation - If you are building an application that supports
a SCIM 2.0 user management API, this section describes in detail how the Azure AD SCIM client is
implemented, and how you should model your SCIM protocol request handling and responses.
Building a SCIM endpoint using Microsoft CLI libraries - To help you develop a SCIM endpoint, there
are Common Language Infrastructure (CLI) libraries along with code samples that show you how to do
provide a SCIM endpoint and translate SCIM messages.
User and group schema reference - Describes the user and group schema supported by the Azure AD
SCIM implementation for non-gallery apps.
Provisioning users and groups to applications that support SCIM

Azure AD can be configured to automatically provision assigned users and groups to applications that implement
a specific profile of the SCIM 2.0 protocol. The specifics of the profile are documented in Understanding the Azure
AD SCIM implementation.
Check with your application provider, or your application provider's documentation for statements of compatibility
with these requirements.
IMPORTANT
The Azure AD SCIM implementation is built on top of the Azure AD user provisioning service, which is designed to
perpetually keep users in sync between Azure AD and the target application, and implements a very specific set of standard
operations. it is important to understand these behaviors in order to understand the behavior of the Azure AD SCIM client.
For more information, see What happens during user provisioning?.
Getting started
Applications that support the SCIM profile described in this article can be connected to Azure Active Directory
using the "non-gallery application" feature in the Azure AD application gallery. Once connected, Azure AD runs a
synchronization process every 40 minutes where it queries the application's SCIM endpoint for assigned users
and groups, and creates or modifies them according to the assignment details.
To connect an application that supports SCIM:
2. Browse to Azure Active Directory > Enterprise Applications, and select New application > All > Non-
gallery application.
3. Enter a name for your application, and click Add icon to create an app object.
Figure 2: Azure AD application gallery
4. In the resulting screen, select the Provisioning tab in the left column.
5. In the Provisioning Mode menu, select Automatic.
Figure 3: Configuring provisioning in the Azure portal

6. In the Tenant URL field, enter the URL of the application's SCIM endpoint. Example:
https://api.contoso.com/scim/v2/
7. If the SCIM endpoint requires an OAuth bearer token from an issuer other than Azure AD, then copy the
required OAuth bearer token into the optional Secret Token field. If this field is left blank, then Azure AD
includes an OAuth bearer token issued from Azure AD with each request. Apps that use Azure AD as an
identity provider can validate this Azure AD -issued token.
8. Click the Test Connection button to have Azure Active Directory attempt to connect to the SCIM
endpoint. If the attempts fail, error information is displayed.
NOTE
Test Connection queries the SCIM endpoint for a user that doesn't exist, using a random GUID as the matching
property selected in the Azure AD configuration. The expected correct response is HTTP 200 OK with an empty
SCIM ListResponse message.
9. If the attempts to connect to the application succeed, then click Save to save the admin credentials.
10. In the Mappings section, there are two selectable sets of attribute mappings: one for user objects and one
for group objects. Select each one to review the attributes that are synchronized from Azure Active
Directory to your app. The attributes selected as Matching properties are used to match the users and
groups in your app for update operations. Select the Save button to commit any changes.
NOTE
You can optionally disable syncing of group objects by disabling the "groups" mapping.
11. Under Settings, the Scope field defines which users and groups are synchronized. Selecting "Sync only
assigned users and groups" (recommended) will only sync users and groups assigned in the Users and
groups tab.
12. Once your configuration is complete, change the Provisioning Status to On.
13. Click Save to start the Azure AD provisioning service.
14. If syncing only assigned users and groups (recommended), be sure to select the Users and groups tab and
assign the users and/or groups you wish to sync.
Once the initial synchronization has started, you can use the Audit logs tab to monitor progress, which shows all
actions performed by the provisioning service on your app. For more information on how to read the Azure AD
provisioning logs, see Reporting on automatic user account provisioning.
NOTE
The initial sync takes longer to perform than subsequent syncs, which occur approximately every 40 minutes as long as the
service is running.
Understanding the Azure AD SCIM implementation

If you are building an application that supports a SCIM 2.0 user management API, this section describes in detail
how the Azure AD SCIM client is implemented, and how you should model your SCIM protocol request handling
and responses. Once you have implemented your SCIM endpoint, you can test it by following the procedure
described in the previous section.
Within the SCIM 2.0 protocol specification, your application must meet these requirements:
Supports creating users, and optionally also groups, as per section 3.3 of the SCIM protocol.
Supports modifying users and/or groups with PATCH requests as per section 3.5.2 of the SCIM protocol.
Supports retrieving a known resource for a user or group created earlier, as per section 3.4.1 of the SCIM
protocol.
Supports querying users and/or groups, as per section 3.4.2 of the SCIM protocol. By default, users are
retrieved by their id and queried by their username and externalid , and groups are queried by displayName .
Supports querying user by ID and by manager as per section 3.4.2 of the SCIM protocol.
Supports querying groups by ID and by member as per section 3.4.2 of the SCIM protocol.
Accepts a single bearer token for authentication and authorization of Azure AD to your application.
In addition, follow these general guidelines when implementing a SCIM endpoint to ensure compatibility with
Azure AD:
id is a required property for all the resources; every response that returns a resource should ensure each
resource has this property, except for ListResponse with zero members.
Response to a query/filter request should always be a ListResponse .
Groups are optional, but only supported if the SCIM implementation supports PATCH requests.
It is not necessary to include the entire resource in the PATCH response.
Microsoft Azure AD only uses the following operators
eq
and
Do not require a case-sensitive match on structural elements in SCIM, in particular PATCH op operation
values, as defined in https://tools.ietf.org/html/rfc7644#section-3.5.2. Azure AD emits the values of 'op' as
Add , Replace , and Remove .
Microsoft Azure AD makes requests to fetch a random user and group to ensure that the endpoint and the
credentials are valid. It is also done as a part of Test Connection flow in the Azure portal.
The attribute that the resources can be queried on should be set as a matching attribute on the application in
the Azure portal. For more information, see Customizing User Provisioning Attribute Mappings
User provisioning and de -provisioning
The following illustration shows the messages that Azure Active Directory sends to a SCIM service to manage the
lifecycle of a user in your application's identity store.
Figure 4: User provisioning and de-provisioning sequence
Group provisioning and de -provisioning
Group provisioning and de-provisioning are optional. When implemented and enabled, the following illustration
shows the messages that Azure AD sends to a SCIM service to manage the lifecycle of a group in your
application's identity store. Those messages differ from the messages pertaining to users in two ways:
Requests to retrieve groups stipulate that the members attribute is to be excluded from any resource provided
in response to the request.
Requests to determine whether a reference attribute has a certain value are requests about the members
attribute.
Figure 5: Group provisioning and de-provisioning sequence
SCIM protocol requests and responses
This section provides example SCIM requests emitted by the Azure AD SCIM client, as well as example expected
responses. For best results, you should code your app to handle these requests in this format and emit the
expected responses.
IMPORTANT
To understand how and when the Azure AD user provisioning service emits the operations described below, see What
happens during user provisioning?.
User Operations
Create User
Request
Response
Get User
Request
Response
Get User by query
Request
Response
Get User by query - Zero results
Request
Response
Update User [Multi-valued properties]
Request
Response
Update User [Single-valued properties]
Request
Response
Delete User
Request
Response
Group Operations
Create Group
Request
Response
Get Group
Request
Response
Get Group by displayName
Request
Response
Update Group [Non-member attributes]
Request
Response
Update Group [Add Members]
Request
Response
Update Group [Remove Members]
Request
Response
Delete Group
Request
Response
User Operations
Users can be queried by userName or email[type eq "work"] attributes.
Create User
R eq u es t
POST /Users
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
"externalId": "0a21f0f2-8d2a-4f8e-bf98-7363c4aed4ef",
"userName": "Test_User_ab6490ee-1e48-479e-a20b-2d77186b5dd1",
"active": true,
"emails": [{
"primary": true,
"type": "work",
"value": "Test_User_fd0ea19b-0777-472c-9f96-4f70d2226f2e@testuser.com"
}],
"meta": {
"resourceType": "User"
},
"name": {
"formatted": "givenName familyName",
"familyName": "familyName",
"givenName": "givenName"
},
"roles": []
}
R e sp o n se
HTTP/1.1 201 Created
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "48af03ac28ad4fb88478",
"externalId": "0a21f0f2-8d2a-4f8e-bf98-7363c4aed4ef",
"meta": {
"resourceType": "User",
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
"userName": "Test_User_ab6490ee-1e48-479e-a20b-2d77186b5dd1",
"name": {
"givenName": "givenName",
},
"active": true,
"emails": [{
"value": "Test_User_fd0ea19b-0777-472c-9f96-4f70d2226f2e@testuser.com",
"type": "work",
"primary": true
}]
}
Get User
R eq u es t
GET /Users/5d48a0a8e9f04aa38008
R es p o n s e
HTTP/1.1 200 OK
{
"id": "5d48a0a8e9f04aa38008",
"externalId": "58342554-38d6-4ec8-948c-50044d0a33fd",
"meta": {
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
"userName": "Test_User_feed3ace-693c-4e5a-82e2-694be1b39934",
"name": {
},
"active": true,
"emails": [{
"value": "Test_User_22370c1a-9012-42b2-bf64-86099c2a1c22@testuser.com",
"type": "work",
"primary": true
}]
}
Get User by query

R e q u e st
GET /Users?filter=userName eq "Test_User_dfeef4c5 -5681 -4387 -b016 -bdf221e82081"

R e sp o n se
HTTP/1.1 200 OK
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults": 1,
"Resources": [{
"id": "2441309d85324e7793ae",
"externalId": "7fce0092-d52e-4f76-b727-3955bd72c939",
"meta": {
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
"userName": "Test_User_dfeef4c5-5681-4387-b016-bdf221e82081",
"name": {
},
"active": true,
"emails": [{
"value": "Test_User_91b67701-697b-46de-b864-bd0bbe4f99c1@testuser.com",
"type": "work",
"primary": true
}]
}],
"startIndex": 1,
"itemsPerPage": 20
}
Get User by query - Zero results

R e q u e st
GET /Users?filter=userName eq "non-existent user"

R e sp o n se
HTTP/1.1 200 OK
{
"totalResults": 0,
"Resources": [],
"startIndex": 1,
"itemsPerPage": 20
}
Update User [Multi-valued properties ]

R e q u e st
PATCH /Users/6764549bef60420686bc HTTP/1.1
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "Replace",
"path": "emails[type eq \"work\"].value",
"value": "updatedEmail@microsoft.com"
},
{
"op": "Replace",
"path": "name.familyName",
"value": "updatedFamilyName"
}
]
}
R e sp o n se
HTTP/1.1 200 OK
{
"id": "6764549bef60420686bc",
"externalId": "6c75de36-30fa-4d2d-a196-6bdcdb6b6539",
"meta": {
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
"userName": "Test_User_fbb9dda4-fcde-4f98-a68b-6c5599e17c27",
"name": {
"formatted": "givenName updatedFamilyName",
"familyName": "updatedFamilyName",
},
"active": true,
"emails": [{
"value": "updatedEmail@microsoft.com",
"type": "work",
"primary": true
}]
}
Update User [Single-valued properties ]

R e q u e st
PATCH /Users/5171a35d82074e068ce2 HTTP/1.1

{
"Operations": [{
"op": "Replace",
"path": "userName",
"value": "5b50642d-79fc-4410-9e90-4c077cdd1a59@testuser.com"
}]
}
R e sp o n se
HTTP/1.1 200 OK
{
"id": "5171a35d82074e068ce2",
"externalId": "aa1eca08-7179-4eeb-a0be-a519f7e5cd1a",
"meta": {
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
"userName": "5b50642d-79fc-4410-9e90-4c077cdd1a59@testuser.com",
"name": {
},
"active": true,
"emails": [{
"value": "Test_User_49dc1090-aada-4657-8434-4995c25a00f7@testuser.com",
"type": "work",
"primary": true
}]
}
Delete User
R e q u e st
DELETE /Users/5171a35d82074e068ce2 HTTP/1.1

R e sp o n se
HTTP/1.1 204 No Content

Group Operations
Groups shall always be created with an empty members list.
Groups can be queried by the displayName attribute.
Update to the group PATCH request should yield an HTTP 204 No Content in the response. Returning a body
with a list of all the members is not advisable.
It is not necessary to support returning all the members of the group.
Create Group
R e q u e st
POST /Groups HTTP/1.1

{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group",
"http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/2.0/Group"],
"externalId": "8aa1a0c0-c4c3-4bc0-b4a5-2ef676900159",
"id": "c4d56c3c-bf3b-4e96-9b64-837018d6060e",
"displayName": "displayName",
"members": [],
"meta": {
"resourceType": "Group"
}
}
R e sp o n se
HTTP/1.1 201 Created
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"id": "927fa2c08dcb4a7fae9e",
"externalId": "8aa1a0c0-c4c3-4bc0-b4a5-2ef676900159",
"meta": {
"resourceType": "Group",
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
"members": []
}
Get Group
R e q u e st
GET /Groups/40734ae655284ad3abcc?excludedAttributes=members HTTP/1.1

R e sp o n se
HTTP/1.1 200 OK
{
"id": "40734ae655284ad3abcc",
"externalId": "60f1bb27-2e1e-402d-bcc4-ec999564a194",
"meta": {
"created": "2018-03-27T19:59:26.000Z",
"lastModified": "2018-03-27T19:59:26.000Z"
},
}
Get Group by displayName

R e q u e st
GET /Groups?excludedAttributes=members&filter=displayName eq "displayName" HTTP/1.1

R e sp o n se
HTTP/1.1 200 OK
{
"totalResults": 1,
"Resources": [{
"id": "8c601452cc934a9ebef9",
"externalId": "0db508eb-91e2-46e4-809c-30dcbda0c685",
"meta": {
"created": "2018-03-27T22:02:32.000Z",
"lastModified": "2018-03-27T22:02:32.000Z",
},
}],
"startIndex": 1,
"itemsPerPage": 20
}
Update Group [Non-member attributes ]

R e q u e st
PATCH /Groups/fa2ce26709934589afc5 HTTP/1.1
{
"Operations": [{
"op": "Replace",
"path": "displayName",
"value": "1879db59-3bdf-4490-ad68-ab880a269474updatedDisplayName"
}]
}
R e sp o n se

Update Group [Add Members]
R e q u e st
PATCH /Groups/a99962b9f99d4c4fac67 HTTP/1.1
{
"Operations": [{
"op": "Add",
"path": "members",
"value": [{
"$ref": null,
"value": "f648f8d5ea4e4cd38e9c"
}]
}]
}
R e sp o n se

Update Group [Remove Members ]
R e q u e st
PATCH /Groups/a99962b9f99d4c4fac67 HTTP/1.1

{
"Operations": [{
"op": "Remove",
"path": "members",
"value": [{
"$ref": null,
"value": "f648f8d5ea4e4cd38e9c"
}]
}]
}
R e sp o n se

Delete Group
R e q u e st
DELETE /Groups/cdb1ce18f65944079d37 HTTP/1.1

R e sp o n se
Building a SCIM endpoint using Microsoft CLI libraries

By creating a SCIM web service that interfaces with Azure Active Directory, you can enable automatic user
provisioning for virtually any application or identity store.
Here’s how it works:
1. Azure AD provides a common language infrastructure (CLI) library named
Microsoft.SystemForCrossDomainIdentityManagement, included with the code samples describe below.
System integrators and developers can use this library to create and deploy a SCIM -based web service
endpoint capable of connecting Azure AD to any application’s identity store.
2. Mappings are implemented in the web service to map the standardized user schema to the user schema and
protocol required by the application.
3. The endpoint URL is registered in Azure AD as part of a custom application in the application gallery.
4. Users and groups are assigned to this application in Azure AD. Upon assignment, they are put into a queue to
be synchronized to the target application. The synchronization process handling the queue runs every 40
minutes.
Code Samples
To make this process easier, code samples are provided that create a SCIM web service endpoint and demonstrate
automatic provisioning. The sample is of a provider that maintains a file with rows of comma-separated values
representing users and groups.
Prerequisites
Visual Studio 2013 or later
Azure SDK for .NET
Windows machine that supports the ASP.NET framework 4.5 to be used as the SCIM endpoint. This machine
must be accessible from the cloud
An Azure subscription with a trial or licensed version of Azure AD Premium
Getting Started
The easiest way to implement a SCIM endpoint that can accept provisioning requests from Azure AD is to build
and deploy the code sample that outputs the provisioned users to a comma-separated value (CSV ) file.
To create a sample SCIM endpoint
1. Download the code sample package at https://github.com/Azure/AzureAD -BYOA-Provisioning-
Samples/tree/master
2. Unzip the package and place it on your Windows machine at a location such as C:\AzureAD -BYOA-
Provisioning-Samples.
3. In this folder, launch the FileProvisioning\Host\FileProvisioningService.csproj project in Visual Studio.
4. Select Tools > NuGet Package Manager > Package Manager Console, and execute the following
commands for the FileProvisioningService project to resolve the solution references:
Update-Package -Reinstall
5. Build the FileProvisioningService project.

6. Launch the Command Prompt application in Windows (as an Administrator), and use the cd command to
change the directory to your \AzureAD -BYOA -Provisioning-
Samples\FileProvisioning\Host\bin\Debug folder.
7. Run the following command, replacing with the IP address or domain name of the Windows machine:
FileSvc.exe http://<ip-address>:9000 TargetFile.csv
8. In Windows under Windows Settings > Network & Internet Settings, select the Windows Firewall >
Advanced Settings, and create an Inbound Rule that allows inbound access to port 9000.
9. If the Windows machine is behind a router, the router needs to be configured to perform Network Access
Translation between its port 9000 that is exposed to the internet, and port 9000 on the Windows machine. This
configuration is required for Azure AD to be able to access this endpoint in the cloud.
To register the sample SCIM endpoint in Azure AD
2. Browse to Azure Active Directory > Enterprise Applications, and select New application > All > Non-
gallery application.
3. Enter a name for your application, and click Add icon to create an app object. The application object created is
intended to represent the target app you would be provisioning to and implementing single sign-on for, and
not just the SCIM endpoint.
4. In the resulting screen, select the Provisioning tab in the left column.
5. In the Provisioning Mode menu, select Automatic.
Figure 6: Configuring provisioning in the Azure portal
6. In the Tenant URL field, enter the internet-exposed URL and port of your SCIM endpoint. The entry is
something like http://testmachine.contoso.com:9000 or http://<ip-address>:9000/, where <ip-address> is
the internet exposed IP address.
7. If the SCIM endpoint requires an OAuth bearer token from an issuer other than Azure AD, then copy the
required OAuth bearer token into the optional Secret Token field. If this field is left blank, then Azure AD will
include an OAuth bearer token issued from Azure AD with each request. Apps that use Azure AD as an identity
provider can validate this Azure AD -issued token.
8. Click the Test Connection button to have Azure Active Directory attempt to connect to the SCIM
endpoint. If the attempts fail, error information is displayed.
NOTE
Test Connection queries the SCIM endpoint for a user that doesn't exist, using a random GUID as the matching
property selected in the Azure AD configuration. The expected correct response is HTTP 200 OK with an empty
SCIM ListResponse message
9. If the attempts to connect to the application succeed, then click Save to save the admin credentials.
10. In the Mappings section, there are two selectable sets of attribute mappings: one for user objects and one for
group objects. Select each one to review the attributes that are synchronized from Azure Active Directory to
your app. The attributes selected as Matching properties are used to match the users and groups in your app
for update operations. Select the Save button to commit any changes.
11. Under Settings, the Scope field defines which users and or groups are synchronized. Selecting "Sync only
assigned users and groups" (recommended) will only sync users and groups assigned in the Users and
groups tab.
12. Once your configuration is complete, change the Provisioning Status to On.
13. Click Save to start the Azure AD provisioning service.
14. If syncing only assigned users and groups (recommended), be sure to select the Users and groups tab and
assign the users and/or groups you wish to sync.
Once the initial synchronization has started, you can use the Audit logs tab to monitor progress, which shows all
actions performed by the provisioning service on your app. For more information on how to read the Azure AD
provisioning logs, see Reporting on automatic user account provisioning.
The final step in verifying the sample is to open the TargetFile.csv file in the \AzureAD -BYOA-Provisioning-
Samples\ProvisioningAgent\bin\Debug folder on your Windows machine. Once the provisioning process is run,
this file shows the details of all assigned and provisioned users and groups.
Development libraries
To develop your own web service that conforms to the SCIM specification, first familiarize yourself with the
following libraries provided by Microsoft to help accelerate the development process:
1. Common Language Infrastructure (CLI) libraries are offered for use with languages based on that
infrastructure, such as C#. One of those libraries,
Microsoft.SystemForCrossDomainIdentityManagement.Service, declares an interface,
Microsoft.SystemForCrossDomainIdentityManagement.IProvider, shown in the following illustration. A
developer using the libraries would implement that interface with a class that may be referred to,
generically, as a provider. The libraries enable the developer to deploy a web service that conforms to the
SCIM specification. The web service can be either hosted within Internet Information Services, or any
executable CLI assembly. Request is translated into calls to the provider’s methods, which would be
programmed by the developer to operate on some identity store.
2. Express route handlers are available for parsing node.js request objects representing calls (as defined by
the SCIM specification), made to a node.js web service.
Building a Custom SCIM Endpoint
Using the CLI libraries, developers using those libraries can host their services within any executable CLI
assembly, or within Internet Information Services. Here is sample code for hosting a service within an executable
assembly, at the address http://localhost:9000:
private static void Main(string[] arguments)

{
// Microsoft.SystemForCrossDomainIdentityManagement.IMonitor,
// Microsoft.SystemForCrossDomainIdentityManagement.IProvider and
// Microsoft.SystemForCrossDomainIdentityManagement.Service are all defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Service.dll.
Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitor =
new DevelopersMonitor();
Microsoft.SystemForCrossDomainIdentityManagement.IProvider provider =
new DevelopersProvider(arguments[1]);
Microsoft.SystemForCrossDomainIdentityManagement.Service webService = null;
try
{
webService = new WebService(monitor, provider);
webService.Start("http://localhost:9000");
Console.ReadKey(true);
}
finally
{
if (webService != null)
{
webService.Dispose();
webService = null;
}
}
}
public class WebService : Microsoft.SystemForCrossDomainIdentityManagement.Service

{
private Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitor;
private Microsoft.SystemForCrossDomainIdentityManagement.IProvider provider;
public WebService(
Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitoringBehavior,
Microsoft.SystemForCrossDomainIdentityManagement.IProvider providerBehavior)
{
this.monitor = monitoringBehavior;
this.provider = providerBehavior;
}
public override IMonitor MonitoringBehavior

{
get
{
return this.monitor;
}
set
{
this.monitor = value;
}
}
public override IProvider ProviderBehavior

{
get
{
return this.provider;
}
set
{
this.provider = value;
}
}
}
This service must have an HTTP address and server authentication certificate of which the root certification
authority is one of the following names:
CNNIC
Comodo
CyberTrust
DigiCert
GeoTrust
GlobalSign
Go Daddy
VeriSign
WoSign
A server authentication certificate can be bound to a port on a Windows host using the network shell utility:
netsh http add sslcert ipport=0.0.0.0:443 certhash=0000000000003ed9cd0c315bbb6dc1c08da5e6 appid={00112233-

4455-6677-8899-AABBCCDDEEFF}
Here, the value provided for the certhash argument is the thumbprint of the certificate, while the value provided
for the appid argument is an arbitrary globally unique identifier.
To host the service within Internet Information Services, a developer would build a CLI code library assembly with
a class named Startup in the default namespace of the assembly. Here is a sample of such a class:
public class Startup

{
// Microsoft.SystemForCrossDomainIdentityManagement.IWebApplicationStarter,
// Microsoft.SystemForCrossDomainIdentityManagement.IMonitor and
// Microsoft.SystemForCrossDomainIdentityManagement.Service are all defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Service.dll.
Microsoft.SystemForCrossDomainIdentityManagement.IWebApplicationStarter starter;
public Startup()
{
Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitor =
new DevelopersMonitor();
Microsoft.SystemForCrossDomainIdentityManagement.IProvider provider =
new DevelopersProvider();
this.starter =
new Microsoft.SystemForCrossDomainIdentityManagement.WebApplicationStarter(
provider,
monitor);
}
public void Configuration(

Owin.IAppBuilder builder) // Defined in Owin.dll.
{
this.starter.ConfigureApplication(builder);
}
}
Handling endpoint authentication

Requests from Azure Active Directory include an OAuth 2.0 bearer token. Any service receiving the request
should authenticate the issuer as being Azure Active Directory on behalf of the expected Azure Active Directory
tenant, for access to the Azure Active Directory Graph web service. In the token, the issuer is identified by an iss
claim, like, "iss":"https://sts.windows.net/cbb1a5ac-f33b-45fa-9bf5-f37db0fed422/". In this example, the base
address of the claim value, https://sts.windows.net, identifies Azure Active Directory as the issuer, while the relative
address segment, cbb1a5ac-f33b-45fa-9bf5-f37db0fed422, is a unique identifier of the Azure Active Directory
tenant on behalf of which the token was issued. If the token was issued for accessing the Azure Active Directory
Graph web service, then the identifier of that service, 00000002-0000-0000-c000-000000000000, should be in
the value of the token’s aud claim. Note that each of the applications that are registered in a single tenant may
receive the same iss claim with SCIM requests.
Developers using the CLI libraries provided by Microsoft for building a SCIM service can authenticate requests
from Azure Active Directory using the Microsoft.Owin.Security.ActiveDirectory package by following these steps:
1. In a provider, implement the
Microsoft.SystemForCrossDomainIdentityManagement.IProvider.StartupBehavior property by having it
return a method to be called whenever the service is started:
public override Action\<Owin.IAppBuilder, System.Web.Http.HttpConfiguration.HttpConfiguration\>

StartupBehavior
{
get
{
return this.OnServiceStartup;
}
}
private void OnServiceStartup(

Owin.IAppBuilder applicationBuilder, // Defined in Owin.dll.
System.Web.Http.HttpConfiguration configuration) // Defined in System.Web.Http.dll.
{
}
2. Add the following code to that method to have any request to any of the service’s endpoints authenticated
as bearing a token issued by Azure Active Directory on behalf of a specified tenant, for access to the Azure
AD Graph web service:
private void OnServiceStartup(

Owin.IAppBuilder applicationBuilder IAppBuilder applicationBuilder,
System.Web.Http.HttpConfiguration HttpConfiguration configuration)
{
// IFilter is defined in System.Web.Http.dll.
System.Web.Http.Filters.IFilter authorizationFilter =
new System.Web.Http.AuthorizeAttribute(); // Defined in
System.Web.Http.dll.configuration.Filters.Add(authorizationFilter);
// SystemIdentityModel.Tokens.TokenValidationParameters is defined in
// System.IdentityModel.Token.Jwt.dll.
SystemIdentityModel.Tokens.TokenValidationParameters tokenValidationParameters =
new TokenValidationParameters()
{
ValidAudience = "00000002-0000-0000-c000-000000000000"
};
// WindowsAzureActiveDirectoryBearerAuthenticationOptions is defined in
// Microsoft.Owin.Security.ActiveDirectory.dll
Microsoft.Owin.Security.ActiveDirectory.
WindowsAzureActiveDirectoryBearerAuthenticationOptions authenticationOptions =
new WindowsAzureActiveDirectoryBearerAuthenticationOptions() {
TokenValidationParameters = tokenValidationParameters,
Tenant = "03F9FCBC-EA7B-46C2-8466-F81917F3C15E" // Substitute the appropriate tenant’s
// identifier for this one.
};
applicationBuilder.UseWindowsAzureActiveDirectoryBearerAuthentication(authenticationOptions);
}
Handling provisioning and deprovisioning of users

1. Azure Active Directory queries the service for a user with an externalId attribute value matching the
mailNickname attribute value of a user in Azure AD. The query is expressed as a Hypertext Transfer
Protocol (HTTP ) request such as this example, wherein jyoung is a sample of a mailNickname of a user in
Azure Active Directory.
NOTE
This is an example only. Not all users will have a mailNickname attribute, and the value a user has may not be unique
in the directory. Furthermore, the attribute used for matching (which in this case is externalId) is configurable in the
Azure AD attribute mappings.
GET https://.../scim/Users?filter=externalId eq jyoung HTTP/1.1

Authorization: Bearer ...
If the service was built using the CLI libraries provided by Microsoft for implementing SCIM services, then
the request is translated into a call to the Query method of the service’s provider. Here is the signature of
that method:
// System.Threading.Tasks.Tasks is defined in mscorlib.dll.

// Microsoft.SystemForCrossDomainIdentityManagement.Resource is defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Schemas.
// Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters is defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource[]> Query(
Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters parameters,
string correlationIdentifier);
Here is the definition of the Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters

interface:
public interface IQueryParameters:

Microsoft.SystemForCrossDomainIdentityManagement.IRetrievalParameters
{
System.Collections.Generic.IReadOnlyCollection
<Microsoft.SystemForCrossDomainIdentityManagement.IFilter> AlternateFilters
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IRetrievalParameters

{
system.Collections.Generic.IReadOnlyCollection<string> ExcludedAttributePaths
{ get; }
System.Collections.Generic.IReadOnlyCollection<string> RequestedAttributePaths
{ get; }
string SchemaIdentifier
{ get; }
}
```
GET https://.../scim/Users?filter=externalId eq jyoung HTTP/1.1
```
If the service was built using the Common Language Infrastructure libraries provided by Microsoft for
implementing SCIM services, then the request is translated into a call to the Query method of the
service’s provider. Here is the signature of that method:
```
// Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters is defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters parameters,
```
Here is the definition of the Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters

interface:
```
public interface IQueryParameters:
Microsoft.SystemForCrossDomainIdentityManagement.IRetrievalParameters
{
System.Collections.Generic.IReadOnlyCollection
<Microsoft.SystemForCrossDomainIdentityManagement.IFilter> AlternateFilters
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IRetrievalParameters

{
system.Collections.Generic.IReadOnlyCollection<string> ExcludedAttributePaths
{ get; }
System.Collections.Generic.IReadOnlyCollection<string> RequestedAttributePaths
{ get; }
string SchemaIdentifier
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IFilter

{
Microsoft.SystemForCrossDomainIdentityManagement.IFilter AdditionalFilter
{ get; set; }
string AttributePath
{ get; }
Microsoft.SystemForCrossDomainIdentityManagement.ComparisonOperator FilterOperator
{ get; }
string ComparisonValue
{ get; }
}
public enum Microsoft.SystemForCrossDomainIdentityManagement.ComparisonOperator

{
Equals
}
```
In the following sample of a query for a user with a given value for the externalId attribute, values
of the arguments passed to the Query method are:
* parameters.AlternateFilters.Count: 1
* parameters.AlternateFilters.ElementAt(0).AttributePath: "externalId"
* parameters.AlternateFilters.ElementAt(0).ComparisonOperator: ComparisonOperator.Equals
* parameters.AlternateFilter.ElementAt(0).ComparisonValue: "jyoung"
* correlationIdentifier: System.Net.Http.HttpRequestMessage.GetOwinEnvironment["owin.RequestId"]
2. If the response to a query to the web service for a user with an externalId attribute value that matches the
mailNickname attribute value of a user does not return any users, then Azure Active Directory requests that
the service provision a user corresponding to the one in Azure Active Directory. Here is an example of such
a request:
POST https://.../scim/Users HTTP/1.1
Content-type: application/scim+json
{
"schemas":
[
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0User"],
"externalId":"jyoung",
"userName":"jyoung",
"active":true,
"addresses":null,
"displayName":"Joy Young",
"emails": [
{
"type":"work",
"value":"jyoung@Contoso.com",
"primary":true}],
"meta": {
"resourceType":"User"},
"name":{
"familyName":"Young",
"givenName":"Joy"},
"phoneNumbers":null,
"preferredLanguage":null,
"title":null,
"department":null,
"manager":null}
The CLI libraries provided by Microsoft for implementing SCIM services would translate that request into
a call to the Create method of the service’s provider. The Create method has this signature:

System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource> Create(
Microsoft.SystemForCrossDomainIdentityManagement.Resource resource,
In a request to provision a user, the value of the resource argument is an instance of the
Microsoft.SystemForCrossDomainIdentityManagement. Core2EnterpriseUser class, defined in the
Microsoft.SystemForCrossDomainIdentityManagement.Schemas library. If the request to provision the
user succeeds, then the implementation of the method is expected to return an instance of the
Microsoft.SystemForCrossDomainIdentityManagement. Core2EnterpriseUser class, with the value of the
Identifier property set to the unique identifier of the newly provisioned user.
3. To update a user known to exist in an identity store fronted by an SCIM, Azure Active Directory proceeds
by requesting the current state of that user from the service with a request such as:
GET ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

In a service built using the CLI libraries provided by Microsoft for implementing SCIM services, the
request is translated into a call to the Retrieve method of the service’s provider. Here is the signature of the
Retrieve method:
// Microsoft.SystemForCrossDomainIdentityManagement.Resource and
// Microsoft.SystemForCrossDomainIdentityManagement.IResourceRetrievalParameters
// are defined in Microsoft.SystemForCrossDomainIdentityManagement.Schemas.
System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource>
Retrieve(
Microsoft.SystemForCrossDomainIdentityManagement.IResourceRetrievalParameters
parameters,
public interface
Microsoft.SystemForCrossDomainIdentityManagement.IResourceRetrievalParameters:
IRetrievalParameters
{
Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier
ResourceIdentifier
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier
{
string Identifier
{ get; set; }
string Microsoft.SystemForCrossDomainIdentityManagement.SchemaIdentifier
{ get; set; }
}
In the example of a request to retrieve the current state of a user, the values of the properties of the object
provided as the value of the parameters argument are as follows:
Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
4. If a reference attribute is to be updated, then Azure Active Directory queries the service to determine
whether or not the current value of the reference attribute in the identity store fronted by the service
already matches the value of that attribute in Azure Active Directory. For users, the only attribute of which
the current value is queried in this way is the manager attribute. Here is an example of a request to
determine whether the manager attribute of a particular user object currently has a certain value:
the request is translated into a call to the Query method of the service’s provider. The value of the
properties of the object provided as the value of the parameters argument are as follows:
parameters.AlternateFilters.Count: 2
parameters.AlternateFilters.ElementAt(x).AttributePath: "ID"
parameters.AlternateFilters.ElementAt(x).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(x).ComparisonValue: "54D382A4-2050-4C03-94D1-
E769F1D15682"
parameters.AlternateFilters.ElementAt(y).AttributePath: "manager"
parameters.AlternateFilters.ElementAt(y).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(y).ComparisonValue: "2819c223-7f76-453a-919d-
413861904646"
parameters.RequestedAttributePaths.ElementAt(0): "ID"
parameters.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
Here, the value of the index x may be 0 and the value of the index y may be 1, or the value of x may be 1
and the value of y may be 0, depending on the order of the expressions of the filter query parameter.
5. Here is an example of a request from Azure Active Directory to an SCIM service to update a user:
PATCH ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1
{
"schemas":
[
"urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":
[
{
"op":"Add",
"path":"manager",
"value":
[
{
"$ref":"http://.../scim/Users/2819c223-7f76-453a-919d-413861904646",
"value":"2819c223-7f76-453a-919d-413861904646"}]}]}
The Microsoft CLI libraries for implementing SCIM services would translate the request into a call to the
Update method of the service’s provider. Here is the signature of the Update method:
// System.Threading.Tasks.Tasks and
// System.Collections.Generic.IReadOnlyCollection<T>
// are defined in mscorlib.dll.
// Microsoft.SystemForCrossDomainIdentityManagement.IPatch,
// Microsoft.SystemForCrossDomainIdentityManagement.PatchRequestBase,
// Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier,
// Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation,
// Microsoft.SystemForCrossDomainIdentityManagement.OperationName,
// Microsoft.SystemForCrossDomainIdentityManagement.IPath and
// Microsoft.SystemForCrossDomainIdentityManagement.OperationValue
// are all defined in Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task Update(
Microsoft.SystemForCrossDomainIdentityManagement.IPatch patch,
public interface Microsoft.SystemForCrossDomainIdentityManagement.IPatch

{
Microsoft.SystemForCrossDomainIdentityManagement.PatchRequestBase
PatchRequest
{ get; set; }
ResourceIdentifier
{ get; set; }
}
public class PatchRequest2:

{
public System.Collections.Generic.IReadOnlyCollection
<Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation>
Operations
{ get;}
implementing SCIM services, then the request is translated into a call to the Query method of the service’s
provider. The value of the properties of the object provided as the value of the parameters argument are as
follows:
parameters.AlternateFilters.Count: 2
parameters.AlternateFilters.ElementAt(x).AttributePath: "ID"
parameters.AlternateFilters.ElementAt(x).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(x).ComparisonValue: "54D382A4-2050-4C03-94D1-E769F1D15682"
parameters.AlternateFilters.ElementAt(y).AttributePath: "manager"
parameters.AlternateFilters.ElementAt(y).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(y).ComparisonValue: "2819c223-7f76-453a-919d-413861904646"
parameters.RequestedAttributePaths.ElementAt(0): "ID"
parameters.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
Here, the value of the index x may be 0 and the value of the index y may be 1, or the value of x may be 1
and the value of y may be 0, depending on the order of the expressions of the filter query parameter.
1. Here is an example of a request from Azure Active Directory to an SCIM service to update a user:
PATCH ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

{
"schemas":
[
"urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":
[
{
"op":"Add",
"path":"manager",
"value":
[
{
"$ref":"http://.../scim/Users/2819c223-7f76-453a-919d-413861904646",
"value":"2819c223-7f76-453a-919d-413861904646"}]}]}
The Microsoft Common Language Infrastructure libraries for implementing SCIM services would translate
the request into a call to the Update method of the service’s provider. Here is the signature of the Update
method:
// System.Threading.Tasks.Tasks and
// System.Collections.Generic.IReadOnlyCollection<T>
// are defined in mscorlib.dll.
// Microsoft.SystemForCrossDomainIdentityManagement.IPatch,
// Microsoft.SystemForCrossDomainIdentityManagement.PatchRequestBase,
// Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation,
// Microsoft.SystemForCrossDomainIdentityManagement.OperationName,
// Microsoft.SystemForCrossDomainIdentityManagement.IPath and
// Microsoft.SystemForCrossDomainIdentityManagement.OperationValue
// are all defined in Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task Update(
Microsoft.SystemForCrossDomainIdentityManagement.IPatch patch,
public interface Microsoft.SystemForCrossDomainIdentityManagement.IPatch

{
PatchRequest
{ get; set; }
ResourceIdentifier
{ get; set; }
}
public class PatchRequest2:

{
<Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation>
Operations
{ get;}
public void AddOperation(

Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation operation);
}
public class PatchOperation

{
public Microsoft.SystemForCrossDomainIdentityManagement.OperationName
Name
{ get; set; }
public Microsoft.SystemForCrossDomainIdentityManagement.IPath
Path
{ get; set; }
<Microsoft.SystemForCrossDomainIdentityManagement.OperationValue> Value
{ get; }
public void AddValue(

Microsoft.SystemForCrossDomainIdentityManagement.OperationValue value);
}
public enum OperationName

{
Add,
Remove,
Replace
}
public interface IPath

{
string AttributePath { get; }
System.Collections.Generic.IReadOnlyCollection<IFilter> SubAttributes { get; }
Microsoft.SystemForCrossDomainIdentityManagement.IPath ValuePath { get; }
}
public class OperationValue

{
public string Reference
{ get; set; }
public string Value

{ get; set; }
}
In the example of a request to update a user, the object provided as the value of the patch argument has
these property values:
ResourceIdentifier.Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
ResourceIdentifier.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
(PatchRequest as PatchRequest2).Operations.Count: 1
(PatchRequest as PatchRequest2).Operations.ElementAt(0).OperationName: OperationName.Add
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Path.AttributePath: "manager"
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.Count: 1
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.ElementAt(0).Reference:
http://.../scim/Users/2819c223-7f76-453a-919d-413861904646
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.ElementAt(0).Value: 2819c223-7f76-
453a-919d-413861904646
2. To de-provision a user from an identity store fronted by an SCIM service, Azure AD sends a request such
as:
DELETE ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

implementing SCIM services, then the request is translated into a call to the Delete method of the service’s
provider. That method has this signature:

// is defined in Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task Delete(
resourceIdentifier,
The object provided as the value of the resourceIdentifier argument has these property values in the
example of a request to de-provision a user:
3. To de-provision a user from an identity store fronted by an SCIM service, Azure AD sends a request such
as:
DELETE ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

the request is translated into a call to the Delete method of the service’s provider. That method has this
signature:

// is defined in Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task Delete(
resourceIdentifier,
The object provided as the value of the resourceIdentifier argument has these property values in the
example of a request to de-provision a user:
ResourceIdentifier.Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
ResourceIdentifier.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
User and group schema reference

Azure Active Directory can provision two types of resources to SCIM web services. Those types of resources are
users and groups.
User resources are identified by the schema identifier,
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User , which is included in this protocol specification:
https://tools.ietf.org/html/rfc7643. The default mapping of the attributes of users in Azure Active Directory to the
attributes of user resources is provided in table 1 below.
Group resources are identified by the schema identifier, urn:ietf:params:scim:schemas:core:2.0:Group . Table 2
below shows the default mapping of the attributes of groups in Azure Active Directory to the attributes of group
resources.
Table 1: Default user attribute mapping
"URN:IETF:PARAMS:SCIM:SCHEMAS:EX TENSION:ENTERPRISE:2.0:US
AZURE ACTIVE DIRECTORY USER ER"
IsSoftDeleted active
displayName displayName
Facsimile-TelephoneNumber phoneNumbers[type eq "fax"].value
givenName name.givenName
jobTitle title
mail emails[type eq "work"].value
mailNickname externalId
manager manager
mobile phoneNumbers[type eq "mobile"].value
objectId ID
postalCode addresses[type eq "work"].postalCode
proxy-Addresses emails[type eq "other"].Value
physical-Delivery-OfficeName addresses[type eq "other"].Formatted
streetAddress addresses[type eq "work"].streetAddress
surname name.familyName
telephone-Number phoneNumbers[type eq "work"].value
user-PrincipalName userName
Table 2: Default group attribute mapping

AZURE ACTIVE DIRECTORY GROUP URN:IETF:PARAMS:SCIM:SCHEMAS:CORE:2.0:GROUP
displayName externalId
mail emails[type eq "work"].value
mailNickname displayName
AZURE ACTIVE DIRECTORY GROUP URN:IETF:PARAMS:SCIM:SCHEMAS:CORE:2.0:GROUP
members members
objectId ID
proxyAddresses emails[type eq "other"].Value
Related articles
Automate User Provisioning/Deprovisioning to SaaS Apps
Writing Expressions for Attribute Mappings
Account Provisioning Notifications
Customizing User Provisioning Attribute-Mappings
for SaaS Applications in Azure Active Directory
Microsoft Azure AD provides support for user provisioning to third-party SaaS applications such as Salesforce,
Google Apps and others. If you have user provisioning for a third-party SaaS application enabled, the Azure
portal controls its attribute values in form of attribute-mappings.
There is a pre-configured set of attributes and attribute-mappings between Azure AD user objects and each
SaaS app’s user objects. Some apps manage other types of objects in addition to Users, such as Groups.
You can customize the default attribute-mappings according to your business needs. This means, you can change
or delete existing attribute-mappings, or create new attribute-mappings.
Editing user attribute-mappings

In the Azure AD portal, you can access this feature by clicking a Mappings configuration under Provisioning in
the Manage section of an Enterprise application.
Clicking a Mappings configuration, opens the related Attribute-Mapping screen. There are attribute-
mappings that are required by a SaaS application to function correctly. For required attributes, the Delete
feature is unavailable.
In the example above, you can see that the Username attribute of a managed object in Salesforce is populated
with the userPrincipalName value of the linked Azure Active Directory Object.
You can customize existing Attribute-Mappings by clicking a mapping. This opens the Edit Attribute screen.
Understanding attribute -mapping types

With attribute-mappings, you control how attributes are populated in a third-party SaaS application. There are
four different mapping types supported:
Direct – the target attribute is populated with the value of an attribute of the linked object in Azure AD.
Constant – the target attribute is populated with a specific string you have specified.
Expression - the target attribute is populated based on the result of a script-like expression. For more
information, see Writing Expressions for Attribute-Mappings in Azure Active Directory.
None - the target attribute is left unmodified. However, if the target attribute is ever empty, it is populated
with the Default value that you specify.
In addition to these four basic types, custom attribute-mappings support the concept of an optional default
value assignment. The default value assignment ensures that a target attribute is populated with a value if there
is neither a value in Azure AD nor on the target object. The most common configuration is to leave this blank.
Understanding attribute -mapping properties
In the previous section, you have already been introduced to the attribute-mapping type property. In addition to
this property, attribute-mappings do also support the following attributes:
Source attribute - The user attribute from the source system (example: Azure Active Directory).
Target attribute – The user attribute in the target system (example: ServiceNow ).
Match objects using this attribute – Whether or not this mapping should be used to uniquely identify
users between the source and target systems. This is typically set on the userPrincipalName or mail attribute
in Azure AD, which is typically mapped to a username field in a target application.
Matching precedence – Multiple matching attributes can be set. When there are multiple, they are
evaluated in the order defined by this field. As soon as a match is found, no further matching attributes are
evaluated.
Apply this mapping
Always – Apply this mapping on both user creation and update actions
Only during creation - Apply this mapping only on user creation actions
Editing group attribute-mappings

A selected number of applications, such as ServiceNow, Box, and Google Apps, support the ability to provision
Group objects in addition to User objects. Group objects can contain group properties such as display names
and email aliases, in addition to group members.
Group provisioning can be optionally enabled or disabled by selecting the group mapping under Mappings,
and setting Enabled to the desired option in the Attribute-Mapping screen.
The attributes provisioned as part of Group objects can be customized in the same manner as User objects,
described previously.
TIP
Provisioning of group objects (properties and members) is a distinct concept from assigning groups to an application. It is
possible to assign a group to an application, but only provision the user objects contained in the group. Provisioning of full
group objects is not required to use groups in assignments.
Editing the list of supported attributes

The user attributes supported for a given application are pre-configured. Most application's user management
APIs do not support schema discovery, therefore the Azure AD provisioning service is not able to dynamically
generate the list of supported attributes by making calls to the application.
However, some applications support custom attributes. In order for the Azure AD provisioning service to be able
to read and write to custom attributes, their definitions must be entered into the Azure portal using the Show
advanced options check box at the bottom of the Attribute-Mapping screen.
Applications and systems that support customization of the attribute list include:
Salesforce
ServiceNow
Workday
Azure Active Directory (Azure AD Graph API default attributes and custom directory extensions are
supported)
Apps that support SCIM 2.0, where attributes defined in the core schema need to be added
NOTE
Editing the list of supported attributes is only recommended for administrators who have customized the schema of their
applications and systems, and have first-hand knowledge of how their custom attributes have been defined. This
sometimes requires familiarity with the APIs and developer tools provided by an application or system.
When editing the list of supported attributes, the following properties are provided:
Name - The system name of the attribute, as defined in the target object's schema.
Type - The type of data the attribute stores, as defined in the target object's schema. This can be one of the
following:
Binary - Attribute contains binary data.
Boolean - Attribute contains a True or False value.
DateTime - Attribute contains a date string.
Integer - Attribute contains an integer.
Reference - Attribute contains an ID that references a value stored in another table in the target
application.
String - Attribute contains a text string.
Primary Key? - Whether or not the attribute is defined as a primary key field in the target object's schema.
Required? - Whether or not the attribute is required to be populated in the target application or system.
Multi-value? - Whether or not the attribute supports multiple values.
Exact case? - Whether or not the attributes values are evaluated in a case-sensitive way.
API Expression - Do not use, unless instructed to do so by the documentation for a specific provisioning
connector (such as Workday).
Referenced Object Attribute - If this is a Reference type attribute, then this menu allows you to select the
table and attribute in the target application that contains the value associated with the attribute. For example,
if you have an attribute named "Department" whose stored value references an object in a separate
"Departments" table, you would select "Departments.Name". Note that the reference tables and the primary
ID fields supported for a given application are pre-configured and currently cannot be edited using the Azure
portal, but can be edited using the Graph API.
To add a new attribute, scroll to the end of the list of supported attributes, populate the fields above using the
provided inputs, and select Add Attribute. Select Save when finished adding attributes. You will then need to
reload the Provisioning tab for the new attributes to become available in the attribute-mapping editor.
Restoring the default attributes and attribute-mappings

Should you need to start over, and reset your existing mappings back to their default state, you can select the
Restore default mappings check box and save the configuration. This sets all mappings as if the application
had just been added to your Azure AD tenant from the application gallery.
Selecting this option will effectively force a re-synchronization of all users while the provisioning service is
running.
IMPORTANT
It is strongly recommended that Provisioning status be set to Off before invoking this option.
What you should know

Microsoft Azure AD provides an efficient implementation of a synchronization process. In an initialized
environment, only objects requiring updates are processed during a synchronization cycle.
Updating attribute-mappings has an impact on the performance of a synchronization cycle. An update to
the attribute-mapping configuration requires all managed objects to be reevaluated.
It is a recommended best practice to keep the number of consecutive changes to your attribute-mappings
at a minimum.
Next steps
Writing Expressions for Attribute-Mappings
Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to
applications
Writing Expressions for Attribute Mappings in Azure
Active Directory
When you configure provisioning to a SaaS application, one of the types of attribute mappings that you can
specify is an expression mapping. For these, you must write a script-like expression that allows you to transform
your users’ data into formats that are more acceptable for the SaaS application.
Syntax Overview
The syntax for Expressions for Attribute Mappings is reminiscent of Visual Basic for Applications (VBA) functions.
The entire expression must be defined in terms of functions, which consist of a name followed by arguments in
parentheses:
FunctionName( <<argument 1>> , <<argument N>> )
You may nest functions within each other. For example:
FunctionOne(FunctionTwo ( <<argument1>> ))
You can pass three different types of arguments into functions:
1. Attributes, which must be enclosed in square brackets. For example: [attributeName]
2. String constants, which must be enclosed in double quotes. For example: "United States"
3. Other Functions. For example: FunctionOne( <<argument1>> , FunctionTwo( <<argument2>> ))
For string constants, if you need a backslash ( \ ) or quotation mark ( " ) in the string, it must be escaped with
the backslash ( \ ) symbol. For example: "Company name: \"Contoso\""
List of Functions
Append FormatDateTime Join Mid NormalizeDiacritics Not Replace SelectUniqueValue
SingleAppRoleAssignment Split StripSpaces Switch ToLower ToUpper
Append
Function:
Append(source, suffix)
Description:
Takes a source string value and appends the suffix to the end of it.
Parameters:
NAME REQUIRED/ REPEATING TYPE NOTES
source Required String Usually name of the

attribute from the source
object.
suffix Required String The string that you want to

append to the end of the
source value.
FormatDateTime
Function:
FormatDateTime(source, inputFormat, outputFormat)
Description:
Takes a date string from one format and converts it into a different format.
Parameters:

object.
inputFormat Required String Expected format of the

source value. For supported
formats, see
https://msdn.microsoft.com/
library/8kb3ddd4%28v=vs.1
10%29.aspx.
outputFormat Required String Format of the output date.
Join
Function:
Join(separator, source1, source2, …)
Description:
Join() is similar to Append(), except that it can combine multiple source string values into a single string, and each
value will be separated by a separator string.
If one of the source values is a multi-value attribute, then every value in that attribute will be joined together,
separated by the separator value.
Parameters:
separator Required String String used to separate

source values when they are
concatenated into one
string. Can be "" if no
separator is required.
source1 … sourceN Required, variable-number String String values to be joined

of times together.
Mid
Function:
Mid(source, start, length)
Description:
Returns a substring of the source value. A substring is a string that contains only some of the characters from the
source string.
Parameters:

attribute.
start Required integer Index in the source string

where substring should
start. First character in the
string will have index of 1,
second character will have
index 2, and so on.
length Required integer Length of the substring. If

length ends outside the
source string, function will
return substring from start
index till end of source
string.
NormalizeDiacritics
Function:
NormalizeDiacritics(source)
Description:
Requires one string argument. Returns the string, but with any diacritical characters replaced with equivalent non-
diacritical characters. Typically used to convert first names and last names containing diacritical characters (accent
marks) into legal values that can be used in various user identifiers such as user principal names, SAM account
names, and email addresses.
Parameters:
source Required String Usually a first name or last

name attribute.
Not
Function:
Not(source)
Description:
Flips the boolean value of the source. If source value is "True", returns "False". Otherwise, returns "True".
Parameters:
source Required Boolean String Expected source values are

"True" or "False".
Replace
Function:
Replace(source, oldValue, regexPattern, regexGroupName, replacementValue, replacementAttributeName,
template)
Description:
Replaces values within a string. It works differently depending on the parameters provided:
When oldValue and replacementValue are provided:
Replaces all occurrences of oldValue in the source with replacementValue
When oldValue and template are provided:
Replaces all occurrences of the oldValue in the template with the source value
When regexPattern, regexGroupName, replacementValue are provided:
Replaces all values matching oldValueRegexPattern in the source string with replacementValue
When regexPattern, regexGroupName, replacementPropertyName are provided:
If source has no value, source is returned
If source has a value, uses regexPattern and regexGroupName to extract replacement value from
the property with replacementPropertyName. Replacement value is returned as the result
Parameters:

object.
oldValue Optional String Value to be replaced in

source or template.
regexPattern Optional String Regex pattern for the value

to be replaced in source.
Or, when
replacementPropertyName
is used, pattern to extract
value from replacement
property.
regexGroupName Optional String Name of the group inside

regexPattern. Only when
replacementPropertyName
is used, we will extract value
of this group as
replacementValue from
replacement property.
replacementValue Optional String New value to replace old

one with.
replacementAttributeNa Optional String Name of the attribute to be

me used for replacement value,
when source has no value.
template Optional String When template value is

provided, we will look for
oldValue inside the
template and replace it with
source value.
SelectUniqueValue
Function:
SelectUniqueValue(uniqueValueRule1, uniqueValueRule2, uniqueValueRule3, …)
Description:
Requires a minimum of two arguments, which are unique value generation rules defined using expressions. The
function evaluates each rule and then checks the value generated for uniqueness in the target app/directory. The
first unique value found will be the one returned. If all of the values already exist in the target, the entry will get
escrowed and the reason gets logged in the audit logs. There is no upper bound to the number of arguments that
can be provided.
NOTE
1. This is a top-level function, it cannot be nested.
2. This function is only meant to be used for entry creations. When using it with an attribute, set the Apply Mapping
property to Only during object creation.
Parameters:
uniqueValueRule1 … At least 2 are required, no String List of unique value

uniqueValueRuleN upper bound generation rules to evaluate.
SingleAppRoleAssignment
Function:
SingleAppRoleAssignment([appRoleAssignments])
Description:
Returns a single appRoleAssignment from the list of all appRoleAssignments assigned to a user for a given
application. This function is required to convert the appRoleAssignments object into a single role name string.
Note that the best practice is to ensure only one appRoleAssignment is assigned to one user at a time, and if
multiple roles are assigned the role string returned may not be predictable.
Parameters:
[appRoleAssignments] Required String [appRoleAssignments]

object.
Split
Function:
Split(source, delimiter)
Description:
Splits a string into a mulit-valued array, using the specified delimiter character.
Parameters:
source Required String source value to update.
delimiter Required String Specifies the character that

will be used to split the
string (example: ",")
StripSpaces
Function:
StripSpaces(source)
Description:
Removes all space (" ") characters from the source string.
Parameters:
source Required String source value to update.
Switch
Function:
Switch(source, defaultValue, key1, value1, key2, value2, …)
Description:
When source value matches a key, returns value for that key. If source value doesn't match any keys, returns
defaultValue. Key and value parameters must always come in pairs. The function always expects an even
number of parameters.
Parameters:
source Required String Source value to update.
defaultValue Optional String Default value to be used

when source doesn't match
any keys. Can be empty
string ("").
key Required String Key to compare source

value with.
value Required String Replacement value for the

source matching the key.
ToLower
Function:
ToLower(source, culture)
Description:
Takes a source string value and converts it to lower case using the culture rules that are specified. If there is no
culture info specified, then it will use Invariant culture.
Parameters:

object
culture Optional String The format for the culture

name based on RFC 4646 is
languagecode2-
country/regioncode2, where
languagecode2 is the two-
letter language code and
country/regioncode2 is the
two-letter subculture code.
Examples include ja-JP for
Japanese (Japan) and en-US
for English (United States).
In cases where a two-letter
language code is not
available, a three-letter code
derived from ISO 639-2 is
used.
ToUpper
Function:
ToUpper(source, culture)
Description:
Takes a source string value and converts it to upper case using the culture rules that are specified. If there is no
culture info specified, then it will use Invariant culture.
Parameters:

object.
culture Optional String The format for the culture

name based on RFC 4646 is
languagecode2-
country/regioncode2, where
languagecode2 is the two-
letter language code and
country/regioncode2 is the
two-letter subculture code.
Examples include ja-JP for
Japanese (Japan) and en-US
for English (United States).
In cases where a two-letter
language code is not
available, a three-letter code
derived from ISO 639-2 is
used.
Examples
Strip known domain name
You need to strip a known domain name from a user’s email to obtain a user name.
For example, if the domain is "contoso.com", then you could use the following expression:
Expression:
Replace([mail], "@contoso.com", , ,"", ,)
Sample input / output:

INPUT (mail): "john.doe@contoso.com"
OUTPUT: "john.doe"
Append constant suffix to user name
If you are using a Salesforce Sandbox, you might need to append an additional suffix to all your user names
before synchronizing them.
Expression:
Append([userPrincipalName], ".test")
Sample input/output:
INPUT: (userPrincipalName): "John.Doe@contoso.com"
OUTPUT: "John.Doe@contoso.com.test"
Generate user alias by concatenating parts of first and last name
You need to generate a user alias by taking first 3 letters of user's first name and first 5 letters of user's last name.
Expression:
Append(Mid([givenName], 1, 3), Mid([surname], 1, 5))
INPUT (givenName): "John"
INPUT (surname): "Doe"
OUTPUT: "JohDoe"
Remove diacritics from a string
You need to replace characters containing accent marks with equivalent characters that don't contain accent
marks.
Expression:
NormalizeDiacritics([givenName])
INPUT (givenName): "Zoë"
OUTPUT: "Zoe"
Split a string into a multi-valued array
You need to take a comma-delimited list of strings, and split them into an array that can be plugged into a multi-
value attribute like Salesforce's PermissionSets attribute. In this example, a list of permission sets has been
populated in extensionAttribute5 in Azure AD.
Expression:
Split([extensionAttribute5], ",")
INPUT (extensionAttribute5): "PermissionSetOne, PermisionSetTwo"
OUTPUT: ["PermissionSetOne", "PermissionSetTwo"]
Output date as a string in a certain format
You want to send dates to a SaaS application in a certain format.
For example, you want to format dates for ServiceNow.
Expression:
FormatDateTime([extensionAttribute1], "yyyyMMddHHmmss.fZ", "yyyy-MM-dd")
INPUT (extensionAttribute1): "20150123105347.1Z"
OUTPUT: "2015-01-23"
Replace a value based on predefined set of options
You need to define the time zone of the user based on the state code stored in Azure AD.
If the state code doesn't match any of the predefined options, use default value of "Australia/Sydney".
Expression:
Switch([state], "Australia/Sydney", "NSW", "Australia/Sydney","QLD", "Australia/Brisbane", "SA",
"Australia/Adelaide")
INPUT (state): "QLD"
OUTPUT: "Australia/Brisbane"
Replace characters using a regular expression
You need to find characters that match a regular expression value and remove them.
Expression:
Replace([mailNickname], , "[a-zA-Z_]*", , "", , )
INPUT (mailNickname: "john_doe72"
OUTPUT: "72"
Convert generated userPrincipalName (UPN ) value to lower case
In the example below, the UPN value is generated by concatenating the PreferredFirstName and
PreferredLastName source fields and the ToLower function operates on the generated string to convert all
characters to lower case.
ToLower(Join("@", NormalizeDiacritics(StripSpaces(Join(".", [PreferredFirstName], [PreferredLastName]))),
"contoso.com"))
INPUT (PreferredFirstName): "John"
INPUT (PreferredLastName): "Smith"
OUTPUT: "john.smith@contoso.com"
Generate unique value for userPrincipalName (UPN ) attribute
Based on the user's first name, middle name and last name, you need to generate a value for the UPN attribute
and check for its uniqueness in the target AD directory before assigning the value to the UPN attribute.
Expression:
SelectUniqueValue(
Join("@", NormalizeDiacritics(StripSpaces(Join(".", [PreferredFirstName], [PreferredLastName]))),
"contoso.com"),
Join("@", NormalizeDiacritics(StripSpaces(Join(".", Mid([PreferredFirstName], 1, 1),
[PreferredLastName]))), "contoso.com")
Join("@", NormalizeDiacritics(StripSpaces(Join(".", Mid([PreferredFirstName], 1, 2),
[PreferredLastName]))), "contoso.com")
)
INPUT (PreferredFirstName): "John"
INPUT (PreferredLastName): "Smith"
OUTPUT: "John.Smith@contoso.com" if UPN value of John.Smith@contoso.com doesn't already exist in the
directory
OUTPUT: "J.Smith@contoso.com" if UPN value of John.Smith@contoso.com already exists in the directory
OUTPUT: "Jo.Smith@contoso.com" if the above two UPN values already exist in the directory
Related Articles
Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to applications
Account Provisioning Notifications
Attribute-based application provisioning with
scoping filters
The objective of this article is to explain how to use scoping filters to define attribute-based rules that determine
which users are provisioned to an application.
Scoping filter use cases

A scoping filter allows the Azure Active Directory (Azure AD ) provisioning service to include or exclude any
users who have an attribute that matches a specific value. For example, when provisioning users from Azure AD
to a SaaS application used by a sales team, you can specify that only users with a "Department" attribute of
"Sales" should be in scope for provisioning.
Scoping filters can be used differently depending on the type of provisioning connector:
Outbound provisioning from Azure AD to SaaS applications. When Azure AD is the source system,
user and group assignments are the most common method for determining which users are in scope for
provisioning. These assignments also are used for enabling single sign-on and provide a single method to
manage access and provisioning. Scoping filters can be used optionally, in addition to assignments or
instead of them, to filter users based on attribute values.
TIP
You can disable provisioning based on assignments for an enterprise application by changing settings in the Scope
menu under the provisioning settings to Sync all users and groups. Using this option plus attribute-based
scoping filters offers faster performance than using group-based assignments.
Inbound provisioning from HCM applications to Azure AD and Active Directory. When an HCM
application such as Workday is the source system, scoping filters are the primary method for determining
which users should be provisioned from the HCM application to Active Directory or Azure AD.
By default, Azure AD provisioning connectors do not have any attribute-based scoping filters configured.
Scoping filter construction

A scoping filter consists of one or more clauses. Clauses determine which users are allowed to pass through the
scoping filter by evaluating each user's attributes. For example, you might have one clause that requires that a
user's "State" attribute equals "New York", so only New York users are provisioned into the application.
A single clause defines a single condition for a single attribute value. If multiple clauses are created in a single
scoping filter, they're evaluated together by using "AND" logic. This means all clauses must evaluate to "true" in
order for a user to be provisioned.
Finally, multiple scoping filters can be created for a single application. If multiple scoping filters are present,
they're evaluated together by using "OR" logic. This means that if all the clauses in any of the configured scoping
filters evaluate to "true", the user is provisioned.
Each user or group processed by the Azure AD provisioning service is always evaluated individually against each
scoping filter.
As an example, consider the following scoping filter:
According to this scoping filter, users must satisfy the following criteria to be provisioned:
They must be in New York.
They must work in the Engineering department.
Their company employee ID must be between 1,000,000 and 2,000,000.
Their job title must not be null or empty.
Create scoping filters

Scoping filters are configured as part of the attribute mappings for each Azure AD user provisioning connector.
The following procedure assumes that you already set up automatic provisioning for one of the supported
applications and are adding a scoping filter to it.
Create a scoping filter
1. In the Azure portal, go to the Azure Active Directory > Enterprise Applications > All applications
section.
2. Select the application for which you have configured automatic provisioning: for example, "ServiceNow".
3. Select the Provisioning tab.
4. In the Mappings section, select the mapping that you want to configure a scoping filter for: for example,
"Synchronize Azure Active Directory Users to ServiceNow".
5. Select the Source object scope menu.
6. Select Add scoping filter.
7. Define a clause by selecting a source Attribute Name, an Operator, and an Attribute Value to match
against. The following operators are supported:
a. EQUALS. Clause returns "true" if the evaluated attribute matches the input string value exactly (case
sensitive).
b. NOT EQUALS. Clause returns "true" if the evaluated attribute doesn't match the input string value
(case sensitive).
c. IS TRUE. Clause returns "true" if the evaluated attribute contains a Boolean value of true.
d. IS FALSE. Clause returns "true" if the evaluated attribute contains a Boolean value of false.
e. IS NULL. Clause returns "true" if the evaluated attribute is empty.
f. IS NOT NULL. Clause returns "true" if the evaluated attribute isn't empty.
g. REGEX MATCH. Clause returns "true" if the evaluated attribute matches a regular expression pattern.
For example: ([1-9][0-9]) matches any number between 10 and 99.
h. NOT REGEX MATCH. Clause returns "true" if the evaluated attribute doesn't match a regular
expression pattern.
8. Select Add new scoping clause.
9. Optionally, repeat steps 7-8 to add more scoping clauses.
10. In Scoping Filter Title, add a name for your scoping filter.
11. Select OK.
12. Select OK again on the Scoping Filters screen. Optionally, repeat steps 6-11 to add another scoping
filter.
13. Select Save on the Attribute Mapping screen.
IMPORTANT
Saving a new scoping filter triggers a new full sync for the application, where all users in the source system are evaluated
again against the new scoping filter. If a user in the application was previously in scope for provisioning, but falls out of
scope, their account is disabled or deprovisioned in the application.
Related articles
Automate user provisioning and deprovisioning to SaaS applications
Customize attribute mappings for user provisioning
Write expressions for attribute mappings
Account provisioning notifications
Use SCIM to enable automatic provisioning of users and groups from Azure Active Directory to applications
List of tutorials on how to integrate SaaS apps
Tutorial: Reporting on automatic user account
provisioning
Azure Active Directory includes a user account provisioning service that helps automate the provisioning de-
provisioning of user accounts in SaaS apps and other systems, for the purpose of end-to-end identity lifecycle
management. Azure AD supports pre-integrated user provisioning connectors for all of the applications and
systems in the "Featured" section of the Azure AD application gallery.
This article describes how to check the status of provisioning jobs after they have been set up, and how to
troubleshoot the provisioning of individual users and groups.
Overview
Provisioning connectors are set up and configured using the Azure portal, by following the provided
documentation for the supported application. Once configured and running, provisioning jobs can be reported
on using one of two methods:
Azure management portal - This article primarily describes retrieving report information from the
Azure portal, which provides both a provisioning summary report as well as detailed provisioning audit
logs for a given application.
Audit API - Azure Active Directory also provides an Audit API that enables programmatic retrieval of the
detailed provisioning audit logs. See Azure Active Directory audit API reference for documentation
specific to using this API. While this article does not specifically cover how to use the API, it does detail the
types of provisioning events that are recorded in the audit log.
Definitions
This article uses the following terms, defined below:
Source System - The repository of users that the Azure AD provisioning service synchronizes from.
Azure Active Directory is the source system for the majority of pre-integrated provisioning connectors,
however there are some exceptions (example: Workday Inbound Synchronization).
Target System - The repository of users that the Azure AD provisioning service synchronizes to. This is
typically a SaaS application (examples: Salesforce, ServiceNow, Google Apps, Dropbox for Business), but
in some cases can be an on-premises system such as Active Directory (example: Workday Inbound
Synchronization to Active Directory).
Getting provisioning reports from the Azure management portal

To get provisioning report information for a given application, start by launching the Azure management portal
and browsing to the Enterprise Application for which provisioning is configured. For example, if you are
provisioning users to LinkedIn Elevate, the navigation path to the application details is:
Azure Active Directory > Enterprise Applications > All applications > LinkedIn Elevate
From here, you can access both the Provisioning summary report, and the provisioning audit logs, both
described below.
Provisioning summary report

The provisioning summary report is visible in the Provisioning tab for given application. It is located in the
Synchronization Details section underneath Settings, and provides the following information:
The total number of users and/groups that have been synchronized and are currently in scope for
provisioning between the source system and the target system.
The last time the synchronization was run. Synchronizations typically occur every 20-40 minutes, after an
initial synchronization has completed.
Whether or not an initial synchronization has been completed.
Whether or not the provisioning process has been placed in quarantine, and what the reason for the
quarantine status is (for example, failure to communicate with target system due to invalid admin
credentials).
The provisioning summary report should be the first place admins look to check on the operational health of the
provisioning job.
Provisioning audit logs

All activities performed by the provisioning service are recorded in the Azure AD audit logs, which can be viewed
in the Audit logs tab under the Account Provisioning category. Logged activity event types include:
Import events - An "import" event is recorded each time the Azure AD provisioning service retrieves
information about an individual user or group from a source system or target system. During
synchronization, users are retrieved from the source system first, with the results recorded as "import"
events. The matching IDs of the retrieved users are then queried against the target system to check if they
exist, with the results also recorded as "import" events. These events record all mapped user attributes and
their values that were seen by the Azure AD provisioning service at the time of the event.
Synchronization rule events - These events report on the results of the attribute-mapping rules and any
configured scoping filters, after user data has been imported and evaluated from the source and target
systems. For example, if a user in a source system is deemed to be in scope for provisioning, and deemed
to not exist in the target system, then this event records that the user will be provisioned in the target
system.
Export events - An "export" event is recorded each time the Azure AD provisioning service writes a user
account or group object to a target system. These events record all user attributes and their values that
were written by the Azure AD provisioning service at the time of the event. If there was an error while
writing the user account or group object to the target system, it will be displayed here.
Process escrow events - Process escrows occur when the provisioning service encounters a failure while
attempting an operation, and begins to retry the operation on a back-off interval of time. An "escrow"
event is recorded each time a provisioning operation was retried.
When looking at provisioning events for an individual user, the events normally occur in this order:
1. Import event: User is retrieved from the source system.
2. Import event: Target system is queried to check for the existence of the retrieved user.
3. Synchronization rule event: User data from source and target systems are evaluated against the
configured attribute-mapping rules and scoping filters to determine what action, if any, should be
performed.
4. Export event: If the synchronization rule event dictated that an action should be performed (Add, Update,
Delete), then the results of the action are recorded in an Export event.
Looking up provisioning events for a specific user

The most common use case for the provisioning audit logs is to check the provisioning status of an individual
user account. To look up the last provisioning events for a specific user:
1. Go to the Audit logs section.
2. From the Category menu, select Account Provisioning.
3. In the Date Range menu, select the date range you want to search.
4. In the Search bar, enter the user ID of the user you wish to search for. The format of ID value should
match whatever you selected as the primary matching ID in the attribute-mapping configuration (for
example, userPrincipalName or employee ID number). The ID value required will be visible in the Target(s)
column.
5. Press Enter to search. The most recent provisioning events will be returned first.
6. If events are returned, note the activity types and whether they succeeded or failed. If no results are
returned, then it means the user either does not exist, or has not yet been detected by the provisioning
process if a full sync has not yet completed.
7. Click on individual events to view extended details, including all user properties that were retrieved,
evaluated, or written as part of the event.
For a demonstration on how to use the audit logs, see the video below. The audit logs are presented around the
5:30 mark:
Tips for viewing the provisioning audit logs

For best readability in the Azure portal, select the Columns button and choose these columns:
Date - Shows the date the event occurred.
Target(s) - Shows the app name and user ID that are the subjects of the event.
Activity - The activity type, as described previously.
Status - Whether the event succeeded or not.
Status Reason - A summary of what happened in the provisioning event.
Troubleshooting
The provisioning summary report and audit logs play a key role helping admins troubleshoot various user
account provisioning issues.
For scenario-based guidance on how to troubleshoot automatic user provisioning, see Problems configuring and
provisioning users to an application.
Additional Resources
Managing user account provisioning for Enterprise Apps
What is application access and single sign-on with Azure Active Directory?
Problem configuring user provisioning to an Azure
AD Gallery application
Configuring automatic user provisioning for an app (where supported), requires that specific instructions be
followed to prepare the application for automatic provisioning. Then you can use the Azure portal to configure the
provisioning service to synchronize user accounts to the application.
You should always start by finding the setup tutorial specific to setting up provisioning for your application. Then
follow those steps to configure both the app and Azure AD to create the provisioning connection. A list of app
tutorials can be found at List of Tutorials on How to Integrate SaaS Apps with Azure Active Directory.
How to see if provisioning is working

Once the service is configured, most insights into the operation of the service can be drawn from two places:
Audit logs – The provisioning audit logs record all the operations performed by the provisioning service,
including querying Azure AD for assigned users that are in scope for provisioning. Query the target app for
the existence of those users, comparing the user objects between the system. Then add, update, or disable
the user account in the target system based on the comparison. The provisioning audit logs can be accessed
in the Azure portal, in the Azure Active Directory > Enterprise Apps > [Application Name] > Audit
Logs tab. Filter the logs on the Account Provisioning category to only see the provisioning events for that
app.
Provisioning status – A summary of the last provisioning run for a given app can be seen in the Azure
Active Directory > Enterprise Apps > [Application Name] >Provisioning section, at the bottom of the
screen under the service settings. This section summarizes how many users (and/or groups) are currently
being synchronized between the two systems, and if there are any errors. Error details be in the audit logs.
Note that the provisioning status not be populated until one full initial synchronization has been completed
between Azure AD and the app.
General problem areas with provisioning to consider

Below is a list of the general problem areas that you can drill into if you have an idea of where to start.
Provisioning service does not appear to start
Can’t save configuration due to app credentials not working
Audit logs say users are “skipped” and not provisioned, even though they are assigned

If you set the Provisioning Status to be On in the Azure Active Directory > Enterprise Apps > [Application
Name] >Provisioning section of the Azure portal. However no other status details are shown on that page after
subsequent reloads. It is likely that the service is running but has not completed an initial synchronization yet.
Check the Audit logs described above to determine what operations the service is performing, and if there are any
errors.
NOTE
An initial sync can take anywhere from 20 minutes to several hours, depending on the size of the Azure AD directory and the
number of users in scope for provisioning. Subsequent syncs after the initial sync be faster, as the provisioning service stores
watermarks that represent the state of both systems after the initial sync, improving performance of subsequent syncs.

In order for provisioning to work, Azure AD requires valid credentials that allow it to connect to a user
management API provided by that app. If these credentials don’t work, or you don’t know what they are, review the
tutorial for setting up this app, described previously.
Audit logs say users are skipped and not provisioned even though they
are assigned
When a user shows up as “skipped” in the audit logs, it is very important to read the extended details in the log
message to determine the reason. Below are common reasons and resolutions:
A scoping filter has been configured that is filtering the user out based on an attribute value. For
more information on scoping filters, see https://docs.microsoft.com/azure/active-directory/active-directory-
saas-scoping-filters.
The user is “not effectively entitled”. If you see this specific error message, it is because there is a
problem with the user assignment record stored in Azure AD. To fix this issue, un-assign the user (or group)
from the app, and re-assign it again. For more information on assignment, see
https://docs.microsoft.com/azure/active-directory/active-directory-coreapps-assign-user-azure-portal.
A required attribute is missing or not populated for a user. An important thing to consider when
setting up provisioning be to review and configure the attribute mappings and workflows that define which
user (or group) properties flow from Azure AD to the application. This includes setting the “matching
property” that be used to uniquely identify and match users/groups between the two systems. For more
information on this important process, see https://docs.microsoft.com/azure/active-directory/active-
directory-saas-customizing-attribute-mappings.
Attribute mappings for groups: Provisioning of the group name and group details, in addition to the
members, if supported for some applications. You can enable or disable this functionality by enabling or
disabling the Mapping for group objects shown in the Provisioning tab. If provisioning groups is
enabled, be sure to review the attribute mappings to ensure an appropriate field is being used for the
“matching ID”. This can be the display name or email alias), as the group and its members not be
provisioned if the matching property is empty or not populated for a group in Azure AD.
Next steps
Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active Directory
Managing access to apps
Ongoing access management, usage evaluation, and reporting continue to be a challenge after an app is
integrated into your organization's identity system. In many cases, IT Administrators or helpdesk have to take an
ongoing active role in managing access to your apps. Sometimes, assignment is performed by a general or
divisional IT team. Often, the assignment decision is intended to be delegated to the business decision maker,
requiring their approval before IT makes the assignment. Other organizations invest in integration with an existing
automated identity and access management system, like Role-Based Access Control (RBAC ) or Attribute-Based
Access Control (ABAC ). Both the integration and rule development tend to be specialized and expensive.
Monitoring or reporting on either management approach is its own separate, costly, and complex investment.
How does Azure Active Directory help?

Azure AD supports extensive access management for configured applications, enabling organizations to easily
achieve the right access policies ranging from automatic, attribute-based assignment (ABAC or RBAC scenarios)
through delegation and including administrator management. With Azure AD, you can easily achieve complex
policies, combining multiple management models for a single application and can even reuse management rules
across applications with the same audiences.
Adding new or existing applications
Azure AD's application assignment focuses on two primary assignment modes:
Individual assignment An IT admin with directory Global Administrator permissions can select individual
user accounts and grant them access to the application.
Group-based assignment (paid Azure AD only) An IT admin with directory Global Administrator
permissions can assign a group to the application. Specific users' access is determined by whether they are
members of the group at the time they try to access the application. In other words, an administrator can
effectively create an assignment rule stating "any current member of the assigned group has access to the
application". Using this assignment option, administrators can benefit from any of Azure AD group
management options, including attribute-based dynamic groups, external system groups (for example, on-
premises Active Directory or Workday), or Administrator-managed or self-service-managed groups. A single
group can be easily assigned to multiple apps, making sure that applications with assignment affinity can share
assignment rules, reducing the overall management complexity. Note that nested group memberships aren't
supported for group-based assignment to applications at this time.
Using these two assignment modes, administrators can achieve any desirable assignment management approach.
With Azure AD, usage and assignment reporting is fully integrated, enabling administrators to easily report on
assignment state, assignment errors, and even usage.
Complex application assignment with Azure AD

Consider an application like Salesforce. In many organizations, Salesforce is primarily used by the marketing and
sales teams. Often, members of the marketing team have highly privileged access to Salesforce, while members of
the sales team have limited access. In many cases, a broad population of information workers has restricted access
to the application. Exceptions to these rules complicate matters. It's often the prerogative of the marketing or sales
leadership teams to grant a user access or change their roles independently of these generic rules.
With Azure AD, applications like Salesforce can be pre-configured for single sign-on (SSO ) and automated
provisioning. Once the application is configured, an Administrator can take the one-time action to create and
assign the appropriate groups. In this example, an administrator could execute the following assignments:
Dynamic groups can be defined to automatically represent all members of the marketing and sales teams
using attributes like department or role:
All members of marketing groups would be assigned to the "marketing" role in Salesforce
All members of sales team groups would be assigned to the "sales" role in Salesforce. A further
refinement could use multiple groups that represent regional sales teams assigned to different
Salesforce roles.
To enable the exception mechanism, a self-service group could be created for each role. For example, the
"Salesforce marketing exception" group can be created as a self-service group. The group can be assigned to
the Salesforce marketing role and the marketing leadership team can be made owner. Members of the
marketing leadership team could add or remove users, set a join policy, or even approve or deny individual
users' requests to join. This mechanism is supported through an information worker appropriate experience
that does not require specialized training for owners or members.
In this case, all assigned users would be automatically provisioned to Salesforce, as they are added to different
groups their role assignment would be updated in Salesforce. Users would be able to discover and access
Salesforce through the Microsoft application access panel, Office web clients, or even by navigating to their
organizational Salesforce login page. Administrators would be able to easily view usage and assignment status
using Azure AD reporting.
Administrators can employ Azure AD conditional access to set access policies for specific roles. These policies can
include whether access is permitted outside the corporate environment and even Multi-Factor Authentication or
device requirements to achieve access in various cases.
Next steps
Protecting apps with conditional access
Self-service group management/SSAA
Advanced certificate signing options in the SAML
token for gallery apps in Azure Active Directory
Today Azure Active Directory (Azure AD ) supports thousands of pre-integrated applications in the Azure Active
Directory App Gallery. This number includes more than 500 applications that support single sign-on by using the
SAML 2.0 protocol. When a user authenticates to an application through Azure AD by using SAML, Azure AD
sends a token to the application (via an HTTP POST). Then, the application validates and uses the token to log in
the user instead of prompting for a username and password. These SAML tokens are signed with the unique
certificate that's generated in Azure AD and by specific standard algorithms.
Azure AD uses some of the default settings for the gallery applications. The default values are set up based on the
application's requirements.
Azure AD supports advanced certificate signing settings. To select these options, first select the Show advanced
certificate signing settings check box:
After you select this check box, you can set up certificate signing options and the certificate signing algorithm.
Certificate signing options

Azure AD supports three certificate signing options:
Sign SAML assertion. This default option is set for most of the gallery applications. If this option is
selected, Azure AD as an IdP signs the SAML assertion and certificate with the X509 certificate of the
application. Also, it uses the signing algorithm, which is selected in the Signing Algorithm drop-down list.
Sign SAML response. If this option is selected, Azure AD as an IdP signs the SAML response with the
X509 certificate of the application. Also, it uses the signing algorithm, which is selected in the Signing
Algorithm drop-down list.
Sign SAML response and assertion. If this option is selected, Azure AD as an IdP signs the entire SAML
token with the X509 certificate of the application. Also, it uses the signing algorithm, which is selected in the
Signing Algorithm drop-down list.
Certificate signing algorithms

Azure AD supports two signing algorithms to sign the SAML response:
SHA -256. Azure AD uses this default algorithm to sign the SAML response. It's the newest algorithm and is
treated as more secure than SHA-1. Most of the applications support the SHA-256 algorithm. If an
application supports only SHA-1 as the signing algorithm, you can change it. Otherwise, we recommend
that you use the SHA-256 algorithm for signing the SAML response.
SHA -1. This is the older algorithm, and it's treated as less secure than SH-256. If an application supports
only this signing algorithm, you can select this option in the Signing Algorithm drop-down list. Azure AD
then signs the SAML response with the SHA-1 algorithm.
Next steps
Configure single sign-on to applications that are not in the Azure Active Directory App Gallery
Troubleshoot SAML -based single sign-on
Manage certificates for federated single sign-on in
This article covers common questions and information related to the certificates that Azure Active Directory
(Azure AD ) creates to establish federated single sign-on (SSO ) to your SaaS applications. Add applications from
the Azure AD app gallery or by using a non-gallery application template. Configure the application by using the
federated SSO option.
This article is relevant only to apps that are configured to use Azure AD SSO through SAML federation, as shown
in the following example:
Auto-generated certificate for gallery and non-gallery applications

When you add a new application from the gallery and configure a SAML -based sign-on, Azure AD generates a
certificate for the application that is valid for three years. You can download this certificate from the SAML
Signing Certificate section. For gallery applications, this section might show an option to download the
certificate or metadata, depending on the requirement of the application.
Customize the expiration date for your federation certificate and roll it
over to a new certificate
By default, certificates are set to expire after three years. You can choose a different expiration date for your
certificate by completing the following steps. The screenshots use Salesforce for the sake of example, but these
steps can apply to any federated SaaS app.
1. In the Azure portal, click Enterprise application in the left pane and then click New application on the
Overview page:
2. Search for the gallery application and then select the application that you want to add. If you cannot find the
required application, add the application by using the Non-gallery application option. This feature is
available only in the Azure AD Premium (P1 and P2) SKU.
3. Click the Single sign-on link in the left pane and change Single Sign-on Mode to SAML -based Sign-
on. This step generates a three-year certificate for your application.
4. To create a new certificate, click the Create new certificate link in the SAML Signing Certificate section.
5. The Create a new certificate link opens the calendar control. You can set any date and time up to three
years from the current date. The selected date and time is the new expiration date and time of your new
certificate. Click Save.
6. Now the new certificate is available to download. Click the Certificate link to download it. At this point,
your certificate is not active. When you want to roll over to this certificate, select the Make new certificate
active check box and click Save. From that point, Azure AD starts using the new certificate for signing the
response.
7. To learn how to upload the certificate to your particular SaaS application, click the View application
configuration tutorial link.
Certificate expiration notification email

Azure AD will send an email notification 60, 30, and 7 days before SAML certificate expires. To specify the email
address for where to send the notification:
On the Azure Active Directory application Single sign-on page, go to the Notification Email field.
Enter the email address that should receive the certificate expiration notification email. By default, this field uses
the email address of the admin who added the application.
You will receive the notification email from aadnotification@microsoft.com. To avoid the email going to your spam
location, be sure to add this email to your contacts.
Renew a certificate that will soon expire

The following renewal steps should result in no significant downtime for your users. The screenshots in this
section feature Salesforce as an example, but these steps can apply to any federated SaaS app.
1. On the Azure Active Directory application Single sign-on page, generate the new certificate for your
application. You can do this by clicking the Create new certificate link in the SAML Signing Certificate
section.
2. Select the desired expiration date and time for your new certificate and click Save. Selecting a date that
overlaps with the existing certificate will ensure that any downtime due to cert expiry is limited.
3. If the app can automatically roll over a certificate, set the new certificate to active. Sign in to the app to
check that it works.
4. If the app doesn’t automatically pickup the new cert, but can handle more than one signing cert, before the
old one expires, upload the new one to the app, then go back to the portal and make it the active certificate.
5. If the app can only handle one certificate at a time, pick a downtime window, download the new certificate,
upload it to the application, come back to the Azure Portal and set the new certificate as active.
6. To activate the new certificate in Azure AD, select the Make new certificate active check box and click the
Save button at the top of the page. This rolls over the new certificate on the Azure AD side. The status of
the certificate changes from New to Active. From that point, Azure AD starts using the new certificate for
signing the response.
Related articles
List of tutorials on how to integrate SaaS apps with Azure Active Directory
Application Management in Azure Active Directory
Application access and single sign-on with Azure Active Directory
Troubleshooting SAML -based single sign-on
Use Tenant Restrictions to manage access to SaaS
cloud applications
Large organizations that emphasize security want to move to cloud services like Office 365, but need to know that
their users only can access approved resources. Traditionally, companies restrict domain names or IP addresses
when they want to manage access. This approach fails in a world where SaaS apps are hosted in a public cloud,
running on shared domain names like outlook.office.com and login.microsoftonline.com. Blocking these addresses
would keep users from accessing Outlook on the web entirely, instead of merely restricting them to approved
identities and resources.
Azure Active Directory's solution to this challenge is a feature called Tenant Restrictions. Tenant Restrictions
enables organizations to control access to SaaS cloud applications, based on the Azure AD tenant the applications
use for single sign-on. For example, you may want to allow access to your organization’s Office 365 applications,
while preventing access to other organizations’ instances of these same applications.
Tenant Restrictions gives organizations the ability to specify the list of tenants that their users are permitted to
access. Azure AD then only grants access to these permitted tenants.
This article focuses on Tenant Restrictions for Office 365, but the feature should work with any SaaS cloud app that
uses modern authentication protocols with Azure AD for single sign-on. If you use SaaS apps with a different
Azure AD tenant from the tenant used by Office 365, make sure that all required tenants are permitted. For more
information about SaaS cloud apps, see the Active Directory Marketplace.
How it works
The overall solution comprises the following components:
1. Azure AD – If the Restrict-Access-To-Tenants: <permitted tenant list> is present, Azure AD only issues
security tokens for the permitted tenants.
2. On-premises proxy server infrastructure – a proxy device capable of SSL inspection, configured to insert
the header containing the list of permitted tenants into traffic destined for Azure AD.
3. Client software – to support Tenant Restrictions, client software must request tokens directly from Azure
AD, so that traffic can be intercepted by the proxy infrastructure. Tenant Restrictions is currently supported
by browser-based Office 365 applications and by Office clients when modern authentication (like OAuth
2.0) is used.
4. Modern Authentication – cloud services must use modern authentication to use Tenant Restrictions and
block access to all non-permitted tenants. Office 365 cloud services must be configured to use modern
authentication protocols by default. For the latest information on Office 365 support for modern
authentication, read Updated Office 365 modern authentication.
The following diagram illustrates the high-level traffic flow. SSL inspection is only required on traffic to Azure AD,
not to the Office 365 cloud services. This distinction is important because the traffic volume for authentication to
Azure AD is typically much lower than traffic volume to SaaS applications like Exchange Online and SharePoint
Online.
Set up Tenant Restrictions
There are two steps to get started with Tenant Restrictions. The first step is to make sure that your clients can
connect to the right addresses. The second is to configure your proxy infrastructure.
URLs and IP addresses
To use Tenant Restrictions, your clients must be able to connect to the following Azure AD URLs to authenticate:
login.microsoftonline.com, login.microsoft.com, and login.windows.net. Additionally, to access Office 365, your
clients must also be able to connect to the FQDNs/URLs and IP addresses defined in Office 365 URLs and IP
address ranges.
Proxy configuration and requirements
The following configuration is required to enable Tenant Restrictions through your proxy infrastructure. This
guidance is generic, so you should refer to your proxy vendor’s documentation for specific implementation steps.
Prerequisites
The proxy must be able to perform SSL interception, HTTP header insertion, and filter destinations using
FQDNs/URLs.
Clients must trust the certificate chain presented by the proxy for SSL communications. For example, if
certificates from an internal PKI are used, the internal issuing root certificate authority certificate must be
trusted.
This feature is included in Office 365 subscriptions, but if you want to use Tenant Restrictions to control
access to other SaaS apps then Azure AD Premium 1 licenses are required.
Configuration
For each incoming request to login.microsoftonline.com, login.microsoft.com, and login.windows.net, insert two
HTTP headers: Restrict-Access-To -Tenants and Restrict-Access-Context.
The headers should include the following elements:
For Restrict-Access-To -Tenants, a value of <permitted tenant list>, which is a comma-separated list of tenants
you want to allow users to access. Any domain that is registered with a tenant can be used to identify the tenant
in this list. For example, to permit access to both Contoso and Fabrikam tenants, the name/value pair looks like:
Restrict-Access-To-Tenants: contoso.onmicrosoft.com,fabrikam.onmicrosoft.com
For Restrict-Access-Context, a value of a single directory ID, declaring which tenant is setting the Tenant
Restrictions. For example, to declare Contoso as the tenant that set the Tenant Restrictions policy, the
name/value pair looks like: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d
TIP
You can find your directory ID in the Azure portal. Sign in as an administrator, select Azure Active Directory, then select
Properties.
To prevent users from inserting their own HTTP header with non-approved tenants, the proxy needs to replace the
Restrict-Access-To-Tenants header if it is already present in the incoming request.
Clients must be forced to use the proxy for all requests to login.microsoftonline.com, login.microsoft.com, and
login.windows.net. For example, if PAC files are used to direct clients to use the proxy, end users should not be able
to edit or disable the PAC files.
The user experience

This section shows the experience for both end users and admins.
End-user experience
An example user is on the Contoso network, but is trying to access the Fabrikam instance of a shared SaaS
application like Outlook online. If Fabrikam is a non-permitted tenant for the Contoso instance, the user sees the
following page:
Admin experience
While configuration of Tenant Restrictions is done on the corporate proxy infrastructure, admins can access the
Tenant Restrictions reports in the Azure portal directly. To view the reports, go to the Azure Active Directory
Overview page, then look under ‘Other capabilities’.
The admin for the tenant specified as the Restricted-Access-Context tenant can use this report to see sign-ins
blocked because of the Tenant Restrictions policy, including the identity used and the target directory ID. Sign-ins
are included if the tenant setting the restriction is either the user tenant or resource tenant for the sign-in.
Like other reports in the Azure portal, you can use filters to specify the scope of your report. You can filter on a
specific user, application, client, or time interval.
Office 365 support

Office 365 applications must meet two criteria to fully support Tenant Restrictions:
1. The client used supports modern authentication
2. Modern authentication is enabled as the default authentication protocol for the cloud service.
Refer to Updated Office 365 modern authentication for the latest information on which Office clients currently
support modern authentication. That page also includes links to instructions for enabling modern authentication on
specific Exchange Online and Skype for Business Online tenants. Modern authentication is already enabled by
default in SharePoint Online.
Tenant Restrictions is currently supported by Office 365 browser-based applications (the Office Portal, Yammer,
SharePoint sites, Outlook on the Web, etc.). For thick clients (Outlook, Skype for Business, Word, Excel, PowerPoint,
etc.) Tenant Restrictions can only be enforced when modern authentication is used.
Outlook and Skype for Business clients that support modern authentication may still able to use legacy protocols
against tenants where modern authentication is not enabled, effectively bypassing Tenant Restrictions. Applications
that use legacy protocols may be blocked by Tenant Restrictions if they contact login.microsoftonline.com,
login.microsoft.com, or login.windows.net during authentication.
For Outlook on Windows, customers may choose to implement restrictions preventing end users from adding
non-approved mail accounts to their profiles. For example, see the Prevent adding non-default Exchange accounts
group policy setting.
Testing
If you want to try out Tenant Restrictions before implementing it for your whole organization, there are two
options: a host-based approach using a tool like Fiddler, or a staged rollout of proxy settings.
Fiddler for a host-based approach
Fiddler is a free web debugging proxy that can be used to capture and modify HTTP/HTTPS traffic, including
inserting HTTP headers. To configure Fiddler to test Tenant Restrictions, perform the following steps:
1. Download and install Fiddler.
2. Configure Fiddler to decrypt HTTPS traffic, per Fiddler’s help documentation.
3. Configure Fiddler to insert the Restrict-Access-To -Tenants and Restrict-Access-Context headers using custom
rules:
a. In the Fiddler Web Debugger tool, select the Rules menu and select Customize Rules… to open the
CustomRules file.
b. Add the following lines at the beginning of the OnBeforeRequest function. Replace <tenant domain>
with a domain registered with your tenant, for example, contoso.onmicrosoft.com. Replace <directory
ID> with your tenant's Azure AD GUID identifier.
if (oSession.HostnameIs("login.microsoftonline.com") || oSession.HostnameIs("login.microsoft.com") ||
oSession.HostnameIs("login.windows.net")){ oSession.oRequest["Restrict-Access-To-Tenants"] = "
<tenant domain>"; oSession.oRequest["Restrict-Access-Context"] = "<directory ID>";}
If you need to allow multiple tenants, use a comma to separate the tenant names. For example:
oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";
4. Save and close the CustomRules file.

After you configure Fiddler, you can capture traffic by going to the File menu and selecting Capture Traffic.
Staged rollout of proxy settings
Depending on the capabilities of your proxy infrastructure, you may be able to stage the rollout of settings to your
users. Here are a couple high-level options for consideration:
1. Use PAC files to point test users to a test proxy infrastructure, while normal users continue to use the production
proxy infrastructure.
2. Some proxy servers may support different configurations using groups.
Refer to your proxy server documentation for specific details.
Next steps
Read about Updated Office 365 modern authentication
Review the Office 365 URLs and IP address ranges
How to: Configure Azure AD SAML token encryption
(Preview)
NOTE
Token encryption is an Azure Active Directory (Azure AD) premium feature. To learn more about Azure AD editions, features,
and pricing, see Azure AD pricing.
SAML token encryption enables the use of encrypted SAML assertions with an application that supports it. When
configured for an application, Azure AD will encrypt the SAML assertions it emits for that application using the
public key obtained from a certificate stored in Azure AD. The application must use the matching private key to
decrypt the token before it can be used as evidence of authentication for the signed in user.
Encrypting the SAML assertions between Azure AD and the application provides additional assurance that the
content of the token can't be intercepted, and personal or corporate data compromised.
Even without token encryption, Azure AD SAML tokens are never passed on the network in the clear. Azure AD
requires token request/response exchanges to take place over encrypted HTTPS/TLS channels so that
communications between the IDP, browser, and application take place over encrypted links. Consider the value of
token encryption for your situation compared with the overhead of managing additional certificates.
To configure token encryption, you need to upload an X.509 certificate file that contains the public key to the Azure
AD application object that represents the application. To obtain the X.509 certificate, you can download it from the
application itself, or get it from the application vendor in cases where the application vendor provides encryption
keys or in cases where the application expects you to provide a private key, it can be created using cryptography
tools, the private key portion uploaded to the application’s key store and the matching public key certificate
uploaded to Azure AD.
Azure AD uses AES -256 to encrypt the SAML assertion data.
Configure SAML token encryption

To configure SAML token encryption, follow these steps:
1. Obtain a public key certificate that matches a private key that's configured in the application.
Create an asymmetric key pair to use for encryption. Or, if the application supplies a public key to use for
encryption, follow the application's instructions to download the X.509 certificate.
The public key should be stored in an X.509 certificate file in .cer format.
If the application uses a key that you create for your instance, follow the instructions provided by your
application for installing the private key that the application will use to decrypt tokens from your Azure AD
tenant.
2. Add the certificate to the application configuration in Azure AD.
To configure token encryption in the Azure portal
You can add the public cert to your application configuration within the Azure portal.
1. Go to the Azure portal.
2. Go to the Azure Active Directory > Enterprise applications blade and then select the application that
you wish to configure token encryption for.
3. On the application's page, select Token encryption.
NOTE
The Token encryption option is only available for SAML applications that have been set up from the Enterprise
applications blade in the Azure portal, either from the Application Gallery or a Non-Gallery app. For other
applications, this menu option is disabled. For applications registered through the App registrations experience in
the Azure portal, you can configure encryption for SAML tokens using the application manifest, through Microsoft
Graph or through PowerShell.
4. On the Token encryption page, select Import Certificate to import the .cer file that contains your public
X.509 certificate.
5. Once the certificate is imported, and the private key is configured for use on the application side, activate
encryption by selecting the ... next to the thumbprint status, and then select Activate token encryption
from the options in the dropdown menu.
6. Select Yes to confirm activation of the token encryption certificate.
7. Confirm that the SAML assertions emitted for the application are encrypted.
To deactivate token encryption in the Azure portal
1. In the Azure portal, go to Azure Active Directory > Enterprise applications, and then select the
application that has SAML token encryption enabled.
2. On the application's page, select Token encryption, find the certificate, and then select the ... option to
show the dropdown menu.
3. Select Deactivate token encryption.
Configure SAML token encryption using Graph API, PowerShell, or app

manifest
Encryption certificates are stored on the application object in Azure AD with an encrypt usage tag. You can
configure multiple encryption certificates and the one that's active for encrypting tokens is identified by the
tokenEncryptionKeyID attribute.
You'll need the application's object ID to configure token encryption using Microsoft Graph API or PowerShell. You
can find this value programmatically, or by going to the application's Properties page in the Azure portal and
noting the Object ID value.
When you configure a keyCredential using Graph, PowerShell, or in the application manifest, you should generate
a GUID to use for the keyId.
To configure token encryption using Microsoft Graph
1. Update the application's keyCredentials with an X.509 certificate for encryption. The following example
shows how to do this.
Patch https://graph.microsoft.com/beta/applications/<application objectid>
{
"keyCredentials":[
{
"type":"AsymmetricX509Cert","usage":"Encrypt",
"keyId":"fdf8c5d8-f727-43fd-beaf-0f1521cf3d35", (Use a GUID generator to obtain a value for
the keyId)
"key": "MIICADCCAW2gAwIBAgIQ5j9/b+n2Q4pDvQUCcy3…" (Base64Encoded .cer file)
}
]
}
2. Identify the encryption certificate that's active for encrypting tokens. The following example shows how to
do this.
Patch https://graph.microsoft.com/beta/applications/<application objectid>
{
"tokenEncryptionKeyId":"fdf8c5d8-f727-43fd-beaf-0f1521cf3d35" (The keyId of the keyCredentials entry
to use)
}
To configure token encryption using PowerShell

This functionality is coming soon.
To configure token encryption using the application manifest
1. From the Azure portal, go to Azure Active Directory > App registrations.
2. Select All apps from the dropdown to show all apps, and then select the enterprise application that you
want to configure.
3. In the application's page, select Manifest to edit the application manifest.
4. Set the value for the tokenEncryptionKeyId attribute.
The following example shows an application manifest configured with two encryption certificates, and with
the second selected as the active one using the tokenEnryptionKeyId.
{
"id": "3cca40e2-367e-45a5-8440-ed94edd6cc35",
"accessTokenAcceptedVersion": null,
"allowPublicClient": false,
"appId": "cb2df8fb-63c4-4c35-bba5-3d659dd81bf1",
"appRoles": [],
"oauth2AllowUrlPathMatching": false,
"createdDateTime": "2017-12-15T02:10:56Z",
"groupMembershipClaims": "SecurityGroup",
"informationalUrls": {
"termsOfService": null,
"support": null,
"privacy": null,
"marketing": null
},
"identifierUris": [
"https://testapp"
],
"keyCredentials": [
{
"customKeyIdentifier": "Tog/O1Hv1LtdsbPU5nPphbMduD=",
"endDate": "2039-12-31T23:59:59Z",
"keyId": "8be4cb65-59d9-404a-a6f5-3d3fb4030351",
"startDate": "2018-10-25T21:42:18Z",
"type": "AsymmetricX509Cert",
"usage": "Encrypt",
"value": <Base64EncodedKeyFile>
"displayName": "CN=SAMLEncryptTest"
},
{
"customKeyIdentifier": "U5nPphbMduDmr3c9Q3p0msqp6eEI=",
"endDate": "2039-12-31T23:59:59Z",
"keyId": "6b9c6e80-d251-43f3-9910-9f1f0be2e851",
"startDate": "2018-10-25T21:42:18Z",
"type": "AsymmetricX509Cert",
"usage": "Encrypt",
"value": <Base64EncodedKeyFile>
"displayName": "CN=SAMLEncryptTest2"
}
],
"knownClientApplications": [],
"logoUrl": null,
"logoutUrl": null,
"name": "Test SAML Application",
"oauth2AllowIdTokenImplicitFlow": true,
"oauth2AllowImplicitFlow": false,
"oauth2Permissions": [],
"oauth2RequirePostResponse": false,
"orgRestrictions": [],
"parentalControlSettings": {
"countriesBlockedForMinors": [],
"legalAgeGroupRule": "Allow"
},
"passwordCredentials": [],
"preAuthorizedApplications": [],
"publisherDomain": null,
"replyUrlsWithType": [],
"requiredResourceAccess": [],
"samlMetadataUrl": null,
"signInUrl": "https://127.0.0.1:444/applications/default.aspx?metadata=customappsso|ISV9.1|primary|z"
"signInAudience": "AzureADMyOrg",
"tags": [],
"tokenEncryptionKeyId": "6b9c6e80-d251-43f3-9910-9f1f0be2e851"
}
Next steps
Find out How Azure AD uses the SAML protocol
Learn the format, security characteristics, and contents of SAML tokens in Azure AD
Single sign-on to applications in Azure Active
Directory
Single sign-on (SSO ) adds security and convenience when users sign-on to applications in Azure Active
Directory (Azure AD ). This article describes the single sign-on methods, and helps you choose the most
appropriate SSO method when configuring your applications.
With single sign-on, users sign in once with one account to access domain-joined devices, company
resources, software as a service (SaaS ) applications, and web applications. After signing in, the user can
launch applications from the Office 365 portal or the Azure AD MyApps access panel. Administrators can
centralize user account management, and automatically add or remove user access to applications based
on group membership.
Without single sign-on, users must remember application-specific passwords and sign in to each
application. IT staff needs to create and update user accounts for each application such as Office 365, Box,
and Salesforce. Users need to remember their passwords, plus spend the time to sign in to each
application.
Choosing a single sign-on method

There are several ways to configure an application for single sign-on. Choosing a single sign-on method
depends on how the application is configured for authentication.
Cloud applications can use OpenID Connect, OAuth, SAML, password-based, linked, or disabled methods for
single sign-on.
On-premises applications can use password-based, Integrated Windows Authentication, header-based,
linked, or disabled methods for single sign-on. The on-premises choices work when applications are
configured for Application Proxy.
This flowchart helps you decide which single sign-on method is best for your situation.
The following table summarizes the single sign-on methods, and links to more details.
SINGLE SIGN-ON METHOD APPLICATION TYPES WHEN TO USE
OpenID Connect and OAuth cloud only Use OpenID Connect and OAuth when
developing a new application. This
protocol simplifies application
configuration, has easy-to-use SDKs,
and enables your application to use MS
Graph.
SAML cloud only Choose SAML whenever possible for

existing applications that do not use
OpenID Connect or OAuth. SAML
works for applications that
authenticate using one of the SAML
protocols.
Password-based cloud and on-premises Choose password-based when the

application authenticates with
username and password. Password-
based single sign-on enables secure
application password storage and
replay using a web browser extension
or mobile app. This method uses the
existing sign-in process provided by
the application, but enables an
administrator to manage the
passwords.
Linked cloud and on-premises Choose linked single sign-on when the
application is configured for single
sign-on in another identity provider
service. This option doesn't add single
sign-on to the application. However,
the application might already have
single sign-on implemented using
another service such as Active
Directory Federation Services.
Disabled cloud and on-premises Choose disabled single sign-on when

the app isn't ready to be configured for
single sign-on. Users need to enter
their username and password every
time they launch this application.
Integrated Windows Authentication on-premises only Choose IWA single sign-on for
(IWA) applications that use Integrated
Windows Authentication (IWA), or
claims-aware applications. For IWA, the
Application Proxy connectors use
Kerberos Constrained Delegation (KCD)
to authenticate users to the
application.
SINGLE SIGN-ON METHOD APPLICATION TYPES WHEN TO USE
Header-based on-premises only Use header-based single sign-on when

the application uses headers for
authentication. Header-based single
sign-on requires PingAccess for Azure
AD. Application Proxy uses Azure AD
to authenticate the user and then
passes traffic through the connector
service.
OpenID Connect and OAuth

When developing new applications, use modern protocols like OpenID Connect and OAuth to achieve the best
single sign-on experience for your app across multiple device platforms. OAuth enables users or admins to grant
consent for protected resources like MS Graph. We provide easy to adopt SDKs for your app, and additionally,
your app will be ready to use MS Graph.
For more information, see:
OAuth 2.0
OpenID Connect 1.0
Azure Active Directory developer’s guide.
SAML SSO
With SAML single sign-on, Azure AD authenticates to the application by using the user's Azure AD account.
Azure AD communicates the sign-on information to the application through a connection protocol. With SAML -
based single sign-on, you can map users to specific application roles based on rules you define in your SAML
claims.
Choose SAML -based single sign-on when the application supports it.
SAML -based single sign-on is supported for applications that use any of these protocols:
SAML 2.0
WS -Federation
To configure an application for SAML -based single sign-on, see Configure SAML -based single sign-on. Also,
many Software as a Service (SaaS ) applications have an application-specific tutorial that step you through the
configuration for SAML -based single sign-on.
To configure an application for WS -Federation, follow the same guidance to configure application for SAML -
based single sign-on, see Configure SAML -based single sign-on. In the step to configure the application to use
Azure AD, you will need to replace the Azure AD login URL for the WS -Federation end-point
https://login.microsoftonline.com/<tenant-ID>/wsfed .
For more information about the SAML protocol, see Single sign-on SAML protocol.
Password-based SSO
With password-based sign-on, users sign on to the application with a username and password the first time they
access it. After the first sign-on, Azure AD supplies the username and password to the application.
Password-based single sign-on uses the existing authentication process provided by the application. When you
enable password single sign-on for an application, Azure AD collects and securely stores user names and
passwords for the application. User credentials are stored in an encrypted state in the directory.
Choose password-based single sign-on when:
An application doesn't support SAML single sign-on protocol.
An application authenticates with a username and password instead of access tokens and headers.
Password-based single sign-on is supported for any cloud-based application that has an HTML -based sign-in
page. The user can use any of the following browsers:
Internet Explorer 11 on Windows 7 or later
Microsoft Edge on Windows 10 Anniversary Edition or later
Chrome on Windows 7 or later, and on MacOS X or later
Firefox 26.0 or later on Windows XP SP2 or later, and on Mac OS X 10.6 or later
To configure a cloud application for password-based single sign-on, see Configure the application for password
single sign-on.
To configure an on-premises application for single sign-on through Application Proxy, see Password vaulting for
single sign-on with Application Proxy
How authentication works for password-based SSO
To authenticate a user to an application, Azure AD retrieves the user's credentials from the directory and enters
them into the application's sign-on page. Azure AD securely passes the user credentials via a web browser
extension or mobile app. This process enables an administrator to manage user credentials, and doesn't require
users to remember their password.
IMPORTANT
The credentials are obfuscated from the user during the automated sign-on process. However, the credentials are
discoverable by using web-debugging tools. Users and administrators need to follow the same security policies as if
credentials were entered directly by the user.
Managing credentials for password-based SSO

Passwords for each application can either be managed by the Azure AD administrator or by the users.
When the Azure AD administrator manages the credentials:
The user doesn't need to reset or remember the user name and password. The user can access the application
by clicking on it in their access panel or via a provided link.
The administrator can do management tasks on the credentials. For example, the administrator can update
application access according to user group memberships and employee status.
The administrator can use administrative credentials to provide access to applications shared among many
users. For example, the administrator can allow everyone who can access an application to have access to a
social media or document sharing application.
When the end user manages the credentials:
Users can manage their passwords by updating or deleting them as needed.
Administrators are still able to set new credentials for the application.
Linked SSO
Linked sign-on enables Azure AD to provide single sign-on to an application that is already configured for single
sign-on in another service. The linked application can appear to end users in the Office 365 portal or Azure AD
MyApps portal. For example, a user can launch an application that is configured for single sign-on in Active
Directory Federation Services 2.0 (AD FS ) from the Office 365 portal. Additional reporting is also available for
linked applications that are launched from the Office 365 portal or the Azure AD MyApps portal.
Linked SSO for application migration
Linked SSO can provide a consistent user experience while you migrate applications over a period of time. If
you're migrating applications to Azure Active Directory, you can use linked single sign-on to quickly publish links
to all the applications you intend to migrate. Users can find all the links in the MyApps portal or the Office 365
application launcher. Users won't know they're accessing a linked application or a migrated application.
Once a user has authenticated with a linked application, an account record needs to be created before the end
user is provided single sign-on access. Provisioning this account record can either occur automatically, or it can
occur manually by an administrator.
Disabled SSO
Disabled mode means single sign-on isn't used for the application. When single sign-on is disabled, users might
need to authenticate twice. First, users authenticate to Azure AD, and then they sign in to the application.
Use disabled single sign-on mode:
If you're not ready to integrate this application with Azure AD single sign-on, or
If you're testing other aspects of the application, or
As a layer of security to an on-premises application that doesn't require users to authenticate. With disabled,
the user needs to authenticate.
Integrated Windows Authentication (IWA) SSO

Application Proxy provides single sign-on (SSO ) to applications that use Integrated Windows Authentication
(IWA), or claims-aware applications. If your application uses IWA, Application Proxy authenticates to the
application by using Kerberos Constrained Delegation (KCD ). For a claims-aware application that trusts Azure
Active Directory, single sign-on works because the user was already authenticated by using Azure AD.
Choose Integrated Windows Authentication single sign-on mode:
To provide single sign-on to an on-premises app that authenticates with IWA.
To configure an on-premises app for IWA, see Kerberos Constrained Delegation for single sign-on to your
applications with Application Proxy.
How single sign-on with KCD works
This diagram explains the flow when a user accesses an on-premises application that uses IWA.
1. The user enters the URL to access the on premises application through Application Proxy.
2. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this point,
Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication.
If the user is validated, Azure AD creates a token and sends it to the user.
3. The user passes the token to Application Proxy.
4. Application Proxy validates the token and retrieves the User Principal Name (UPN ) from the token. It then
sends the request, the UPN, and the Service Principal Name (SPN ) to the Connector through a dually
authenticated secure channel.
5. The connector uses Kerberos Constrained Delegation (KCD ) negotiation with the on premises AD,
impersonating the user to get a Kerberos token to the application.
6. Active Directory sends the Kerberos token for the application to the connector.
7. The connector sends the original request to the application server, using the Kerberos token it received from
AD.
8. The application sends the response to the connector, which is then returned to the Application Proxy service
and finally to the user.
Header-based SSO
Header-based single sign-on works for applications that use HTTP headers for authentication. This sign-on
method uses a third-party authentication service called PingAccess. A user only needs to authenticate to Azure
AD.
Choose header-based single sign-on when:
Application Proxy and PingAccess are configured for the application
To configure header-based authentication, see Header-based authentication for single sign-on with Application
Proxy.
What is PingAccess for Azure AD?
Using PingAccess for Azure AD, users can access and single sign-on to applications that use headers for
authentication. Application Proxy treats these applications like any other, using Azure AD to authenticate access
and then passing traffic through the connector service. After authentication occurs, the PingAccess service
translates the Azure AD access token into a header format that is sent to the application.
Your users won’t notice anything different when they sign in to use your corporate applications. They can still
work from anywhere on any device. The Application Proxy connectors direct remote traffic to all applications,
and they’ll continue to load balance automatically.
How do I get a license for PingAccess?
Since this scenario is offered through a partnership between Azure AD and PingAccess, you need licenses for
both services. However, Azure AD Premium subscriptions include a basic PingAccess license that covers up to
20 applications. If you need to publish more than 20 header-based applications, you can acquire an additional
license from PingAccess.
For more information, see Azure Active Directory editions.
Related articles
Tutorials for integrating SaaS applications with Azure Active Directory
Tutorial for configuring single sign-on
Introduction to Managing Access to applications
Download link: Single sign-on deployment plan.
End-user experiences for applications in Azure Active
Directory
Azure Active Directory (Azure AD ) provides several customizable ways to deploy applications to end users in your
organization:
Azure AD access panel
Office 365 application launcher
Direct sign-on to federated apps
Deep links to federated, password-based, or existing apps
Which method(s) you choose to deploy in your organization is your discretion.
Azure AD access panel

The Access Panel at https://myapps.microsoft.com is a web-based portal that allows an end user with an
organizational account in Azure Active Directory to view and launch cloud-based applications to which they have
been granted access by the Azure AD administrator. If you are an end user with Azure Active Directory Premium,
you can also utilize self-service group management capabilities through the Access Panel.
The Access Panel is separate from the Azure portal and does not require users to have an Azure subscription or
Office 365 subscription.
For more information on the Azure AD access panel, see the introduction to the access panel.
Office 365 application launcher

For organizations that have deployed Office 365, applications assigned to users through Azure AD will also appear
in the Office 365 portal at https://portal.office.com/myapps. This makes it easy and convenient for users in an
organization to launch their apps without having to use a second portal, and is the recommended app launching
solution for organizations using Office 365.
For more information about the Office 365 application launcher, see Have your app appear in the Office 365 app
launcher.
Direct sign-on to federated apps

Most federated applications that support SAML 2.0, WS -Federation, or OpenID connect also support the ability
for users to start at the application, and then get signed in through Azure AD either by automatic redirection or by
clicking on a link to sign in. This is known as service provider -initiated sign-on, and most federated applications in
the Azure AD application gallery support this (see the documentation linked from the app’s single sign-on
configuration wizard in the Azure portal for details).
Direct sign-on links
Azure AD also supports direct single sign-on links to individual applications that support password-based single
sign-on, linked single sign-on, and any form of federated single sign-on.
These links are specifically crafted URLs that send a user through the Azure AD sign-in process for a specific
application without requiring the user launch them from the Azure AD access panel or Office 365. These Single
Sign-On URLs can be found under the Dashboard tab of any pre-integrated application in the Active Directory
section of the Azure portal, as shown in the screenshot below.
These links can be copied and pasted anywhere you want to provide a sign-in link to the selected application. This
could be in an email, or in any custom web-based portal that you have set up for user application access. Here's an
example of an Azure AD direct single sign-on URL for Twitter:
https://myapps.microsoft.com/signin/Twitter/230848d52c8745d4b05a60d29a40fced
Similar to organization-specific URLs for the access panel, you can further customize this URL by adding one of
the active or verified domains for your directory after the myapps.microsoft.com domain. This ensures any
organizational branding is loaded immediately on the sign-in page without the user needing to enter their user ID
first:
https://myapps.microsoft.com/contosobuild.com/signin/Twitter/230848d52c8745d4b05a60d29a40fced
When an authorized user clicks on one of these application-specific links, they first see their organizational sign-in
page (assuming they are not already signed in), and after sign-in are redirected to their app without stopping at the
access panel first. If the user is missing pre-requisites to access the application, such as the password-based single
sign browser extension, then the link will prompt the user to install the missing extension. The link URL also
remains constant if the single sign-on configuration for the application changes.
These links use the same access control mechanisms as the access panel and Office 365, and only those users or
groups who have been assigned to the application in the Azure portal will be able to successfully authenticate.
However, any user who is unauthorized will see a message explaining that they have not been granted access, and
are given a link to load the access panel to view available applications for which they do have access.
Next steps
For deployment plans, see Azure Active Directory deployment plans
Choosing the application type when adding an
application in Azure Active Directory
Learn about the four types of applications you can add to Azure Active Directory (Azure AD ). When you are adding
an application in Azure Active Directory, you'll be prompted to choose one of the four application type.
What are the types of applications?

Azure AD supports four main application types that you can add using the Add feature found under Enterprise
Applications. These include:
Azure AD Gallery Applications – An application that has been pre-integrated for single sign-on with
Azure AD.
Application Proxy Applications – An application running in your on-premises environment that you
want to provide secure single-sign on to externally.
Custom -developed Applications – An application that your organization wishes to develop on the Azure
AD Application Development Platform, but that may not exist yet.
Non-Gallery Applications – Bring your own applications! Any web link you want, or any application that
renders a username and password field, supports SAML or OpenID Connect protocols, or supports SCIM
that you wish to integrate for single sign-on with Azure AD.
Features and capabilities supported by the application types

The following features are supported by any of the preceding four application types in Azure AD:
Quick start – get going with an application quickly by following simple deployment steps
General properties management – get a direct deeplink to an application, customize the branding of an
application, or disable the application for all users.
User and group management – assign or remove users and groups to an application, and optionally
assign the specific application roles these users and groups have access to
Self-service application access – enable your users to request self-service application access to an
application from their Application Access Panels either by adding an application directly or joining a self-
service enabled group, optionally requiring business approval along the way
Sign-in logs – see all the sign-ins to an application, or all your applications
Audit logs – see detailed audit logs about modifications to an application, or to all your applications
Conditional and risk-based access – set powerful condition-based access rules that are enforced when
users attempt to sign in to a specific application
Permissions view – view any of the OAuth2 permissions an application has access to in your directory
from a single place
Single sign-on and provisioning modes supported by specific

application types
The following table describes the different single sign-on and provisioning modes supported by each of the
preceding application types. You can use this table to help you to understand which application you need to add to
support a specific goal.
How to choose a single sign-on mode

Following are the supported single sign-on modes for Azure AD applications.
Azure AD single sign-on disabled – choose Azure AD single sign-on disabled single sign-on mode if
you are not yet ready to integrate this application with single sign-on with Azure AD, or are simply testing it
out
Linked Sign-on – choose the Linked Sign-on single sign-on mode if you have an application that is
already connected with an existing single sign-on solution, or if you just want to publish a simple link for
your users in their Application Access Panel or Office 365 application launcher
Password-based Sign-on – choose the Password-based Sign-on single sign-on mode if your application
renders an HTML username and password field and you want to store that username and password
securely to be replayed to the application later
SAML -based Sign-on – choose the SAML -based Sign-on single-sign on mode if your application
supports the SAML or OpenID Connect protocols, or you want to be able to map users to specific
application roles based on rules you define in your SAML claims *
NOTE
This option is not available when the application proxy is configured for an application.
Header-based Sign-on – choose this Header-based Sign-on single sign-on mode if you have an
application using PingAccess that supports HTTP -header-based authentication that you wish to perform
single-sign on to
NOTE
This option is only available when the application proxy and PingAccess is configured for an application.
Integrated Windows Authentication – choose the Integrated Windows Authentication single-sign on

mode when exposing an on-premises WIA application that you wish to perform single-sign on to
NOTE
This option is only available when the application proxy is configured for an application.
Single sign-on modes for custom-developed applications
Applications you have custom developed through the Custom-developed application experience also support
additional single sign-on modes not previously listed, which include:
OAuth 2.0 based sign-on
OpenID Connect 1.0 based sign-on
WS -Federation 1.2 based sign-on
SAML 2.0 based sign-on
Read the Azure Active Directory developer’s guide to learn more about how to create a custom-developed
application that supports these single sign-on modes.
How to set an application’s single sign-on mode

To set an application’s single sign-on mode, follow these instructions:
1. Open the Azure portal and sign in as a Global Administrator or Co-admin.
2. Open the Azure Active Directory Extension by clicking All services at the top of the main left-hand
navigation menu.
3. Type in “Azure Active Directory” in the filter search box and select the Azure Active Directory item.
4. click Enterprise Applications from the Azure Active Directory left-hand navigation menu.
5. click All Applications to view a list of all your applications.
If you do not see the application you want show up here, use the Filter control at the top of the All
Applications List and set the Show option to All Applications.
6. Select the application for which you want to configure single sign-on.
7. Once the application loads, click Single sign-on from the application’s left-hand navigation menu.
How to choose a provisioning mode

Manual Provisioning – choose the Manual provisioning mode if you have existing accounts, or wish to
manage accounts for this application outside of Azure AD.
Automatic Provisioning – choose the Automatic provisioning mode if you want to enable automatic
API-based provisioning and/or de-provisioning of user accounts to this application
NOTE
This option is available only for applications within the featured category of the Azure AD Application Gallery.
SCIM -based Automatic Provisioning – use SCIM -based Automatic Provisioning if your application
supports the SCIM protocol for detecting changes to users and groups, which are automatically emitted for
changes to any application integrated with Azure AD
NOTE
This option is not listed as a specific provisioning mode, but is enabled by default for all applications that are
integrated with Azure AD.
How to set an application’s provisioning mode
To set an application’s provisioning mode, follow these instructions:
To set an application’s single sign-on mode, follow these instructions:
navigation menu.
6. Select the application for which you want to configure provisioning.
7. Once the application loads, click Provisioning from the application’s left-hand navigation menu.
Next steps
Managing Applications with Azure Active Directory
Problem adding an Azure AD Gallery application
This article helps you understand the common problems people face when adding Azure AD Gallery applications
and what you can do to resolve them.
I clicked the “add” button and my application took a long time to

appear
Under some circumstances, it can take 1-2 minutes (and sometimes longer) for an application to appear after
adding it to your directory. While this is not the normal expected performance, you can see the application addition
is in progress by clicking on the Notifications icon (the bell) in the upper right of the Azure portal and looking for
an In Progress or Completed notification labeled Adding application.
If your application is never added, or you encounter an error when clicking the Add button, you’ll see a
Notification in an Error state. If you want more details about the error to learn more to or share with a support
engineer, you can see more information about the error by following the steps in the How to see the details of a
portal notification section.
I clicked the “add” button and my application didn’t appear

Sometimes, due to transient issues, networking problems, or a bug, adding an application fails. You can tell this
happens when you click the Notifications icon (the bell) in the upper right of the Azure portal and you see a red
(!) icon next to your Adding application notification. This indicates there was an error when creating the
application.
If you encounter an error when clicking the Add button, you’ll see a Notification in an Error state. If you want
more details about the error to learn more to or share with a support engineer, you can see more information
about the error by following the steps in the How to see the details of a portal notification section.
I don’t know how to set up my application once I’ve added it

If you need help learning about applications, the List of Tutorials on How to Integrate SaaS Apps with Azure Active
Directory article is a good place to start.
In addition to this, the Azure AD Applications Document Library helps you to learn more about single sign-on with
Azure AD and how it works.
How to see the details of a portal notification

You can see the details of any portal notification by following the steps below:
1. Select the Notifications icon (the bell) in the upper right of the Azure Portal
2. Select any notification in an Error state (those with a red (!) next to them).
NOTE
You cannot click notifications in a Successful or In Progress state.
3. Use the information under Notification Details to understand more details about the problem.
4. If you still need help, you can also share this information with a support engineer or the product group to
get help with your problem.
5. Click the copy icon to the right of the Copy error textbox to copy all the notification details to share with a
support or product group engineer.
How to get help by sending notification details to a support engineer

It is very important that you share all the details listed below with a support engineer if you need help, so that
they can help you quickly. You can do this easily by taking a screenshot, or by clicking the Copy error icon,
found to the right of the Copy error textbox.
Notification Details Explained

See the following descriptions for more details about the notifications.
Essential Notification Items
Title – the descriptive title of the notification
Example – Application proxy settings
Description – the description of what occurred as a result of the operation
Example – Internal url entered is already being used by another application
Notification ID – the unique ID of the notification
Example – clientNotification-2adbfc06-2073-4678-a69f-7eb78d96b068
Client Request ID – the specific request ID made by your browser
Example – 302fd775-3329-4670-a9f3-bea37004f0bc
Time Stamp UTC – the timestamp during which the notification occurred, in UTC
Example – 2017-03-23T19:50:43.7583681Z
Internal Transaction ID – the internal ID we can use to look the error up in our systems
Example – 71a2f329-ca29-402f-aa72-bc00a7aca603
UPN – the user who performed the operation
Example – tperkins@f128.info
Tenant ID – the unique ID of the tenant that the user who performed the operation was a member of
Example – 7918d4b5-0442-4a97-be2d-36f9f9962ece
User object ID – the unique ID of the user who performed the operation
Example – 17f84be4-51f8-483a-b533-383791227a99
Detailed Notification Items
Display Name – (can be empty) a more detailed display name for the error
Status – the specific status of the notification
Example – Failed
Object ID – (can be empty) the object ID against which the operation was performed
Example – 8e08161d-f2fd-40ad-a34a-a9632d6bb599
Details – the detailed description of what occurred as a result of the operation
Example – Internal url 'https://bing.com/' is invalid since it is already in use
Copy error – Click the copy icon to the right of the Copy error textbox to copy all the notification details to
share with a support or product group
engineer
Example
{"errorCode":"InternalUrl\_Duplicate","localizedErrorDetails":{"errorDetail":"Internal url
'https://google.com/' is invalid since it is already in use"},"operationResults":\
[{"objectId":null,"displayName":null,"status":0,"details":"Internal url 'https://bing.com/' is invalid
since it is already in use"}\],"timeStampUtc":"2017-03-
23T19:50:26.465743Z","clientRequestId":"302fd775-3329-4670-a9f3-
bea37004f0bb","internalTransactionId":"ea5b5475-03b9-4f08-8e95-
bbb11289ab65","upn":"tperkins@f128.info","tenantId":"7918d4b5-0442-4a97-be2d-
36f9f9962ece","userObjectId":"17f84be4-51f8-483a-b533-383791227a99"}
Problem adding a non-gallery application
This article helps you understand the common problems people face when adding custom non-gallery
applications and what you can do to resolve them.
I clicked the “add” button and my application took a long time to

appear
Under some circumstances, it can take 1-2 minutes (and sometimes longer) for an application to appear after
adding it to your directory. While this is not the normal expected performance, you can see the application addition
is in progress by clicking on the Notifications icon (the bell) in the upper right of the Azure portal and looking for
an In Progress or Completed notification labeled Create application.
If your application is never added, or you encounter an error when clicking the Add button, you’ll see a
Notification in an Error state. If you want more details about the error to learn more to or share with a support
engineer, you can see more information about the error by following the steps in the How to see the details of a
portal notification section.
I clicked the “add” button and my application didn’t appear

Sometimes, due to transient issues, networking problems, or a bug, adding an application fail. You can tell this
happens when you click the Notifications icon (the bell) in the upper right of the Azure portal and you see a red
(!) icon next to your Create application notification. This indicates there was an error when creating the
application.
If you encounter an error when clicking the Add button, you’ll see a Notification in an Error state. If you want
more details about the error to learn more to or share with a support engineer, you can see more information
about the error by following the steps in the How to see the details of a portal notification section.
I don’t know how to set up my application once I’ve added it

If you need help learning about custom applications, the Azure AD Applications Document Library help you to
learn more about single sign-on with Azure AD and how it works.

1. click the Notifications icon (the bell) in the upper right of the Azure portal
NOTE
You cannot click notifications in a Successful or In Progress state.
3. Use the information under Notification Details to understand more details about the problem.
4. If you still need help, you can also share this information with a support engineer or the product group to
get help with your problem.

they can help you quickly. You can do this easily by taking a screenshot, or by clicking the Copy error icon,
found to the right of the Copy error textbox.

See the following descriptions for more details about the notifications.
Notification ID – the unique ID of the notification
Client Request ID – the specific request ID made by your browser
Example – 2017-03-23T19:50:43.7583681Z
Internal Transaction ID – the internal ID we can use to look the error up in our systems
Example – 17f84be4-51f8-483a-b533-383791227a99
Example – Failed
share with a support or product group
engineer
Example
Change the name or logo of an enterprise app in
It's easy to change the name or logo for a custom enterprise application in Azure Active Directory (Azure AD ). You
must have the appropriate permissions to make these changes, and you must be the creator of the custom app.
How do I change an enterprise app's name or logo?

1. Sign in to the Azure portal with an account that's a global admin for the directory.
2. Select All services, enter Azure Active Directory in the text box, and then select Enter.
3. On the Azure Active Directory - *directoryname* pane (that is, the Azure AD pane for the directory you
are managing), select Enterprise applications.
4. On the Enterprise applications pane, select All applications. You see a list of the apps you can manage.
5. On the Enterprise applications - All applications pane, select an app.
6. On the appname pane (that is, the pane with the name of the selected app in the title), select Properties.
7. On the appname - Properties pane, browse for a file to use as a new logo, or edit the app name, or both.
8. Select the Save command.
Next steps
See all of my groups
Assign a user or group to an enterprise app
Remove a user or group assignment from an enterprise app
Disable user sign-ins for an enterprise app
This article explains how to configure Azure Active Directory (Azure AD ) Application Proxy connectors to work
with outbound proxy servers. It is intended for customers with network environments that have existing proxies.
We start by looking at these main deployment scenarios:
Configure connectors to bypass your on-premises outbound proxies.
Configure connectors to use an outbound proxy to access Azure AD Application Proxy.
For more information about how connectors work, see Understand Azure AD Application Proxy connectors.
Bypass outbound proxies

Connectors have underlying OS components that make outbound requests. These components automatically
attempt to locate a proxy server on the network using Web Proxy Auto-Discovery (WPAD ).
The OS components attempt to locate a proxy server by carrying out a DNS lookup for wpad.domainsuffix. If the
lookup resolves in DNS, an HTTP request is then made to the IP address for wpad.dat. This request becomes the
proxy configuration script in your environment. The connector uses this script to select an outbound proxy server.
However, connector traffic might still not go through, because of additional configuration settings needed on the
proxy.
You can configure the connector to bypass your on-premises proxy to ensure that it uses direct connectivity to the
Azure services. We recommend this approach, as long as your network policy allows for it, because it means that
you have one less configuration to maintain.
To disable outbound proxy usage for the connector, edit the C:\Program Files\Microsoft AAD App Proxy
Connector\ApplicationProxyConnectorService.exe.config file and add the system.net section shown in this code
sample:
<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<system.net>
<defaultProxy enabled="false"></defaultProxy>
</system.net>
<runtime>
<gcServer enabled="true"/>
</runtime>
<appSettings>
<add key="TraceFilename" value="AadAppProxyConnector.log" />
</appSettings>
</configuration>
To ensure that the Connector Updater service also bypasses the proxy, make a similar change to the
ApplicationProxyConnectorUpdaterService.exe.config file. This file is located at C:\Program Files\Microsoft AAD
App Proxy Connector Updater.
Be sure to make copies of the original files, in case you need to revert to the default .config files.
Use the outbound proxy server

Some environments require all outbound traffic to go through an outbound proxy, without exception. As a result,
bypassing the proxy is not an option.
You can configure the connector traffic to go through the outbound proxy, as shown in the following diagram:
As a result of having only outbound traffic, there's no need to configure inbound access through your firewalls.
NOTE
Application Proxy does not support authentication to other proxies. The connector/updater network service accounts should
be able to connect to the proxy without being challenged for authentication.
Step 1: Configure the connector and related services to go through the outbound proxy
If WPAD is enabled in the environment and configured appropriately, the connector automatically discovers the
outbound proxy server and attempt to use it. However, you can explicitly configure the connector to go through
an outbound proxy.
To do so, edit the C:\Program Files\Microsoft AAD App Proxy
Connector\ApplicationProxyConnectorService.exe.config file, and add the system.net section shown in this code
sample. Change proxyserver:8080 to reflect your local proxy server name or IP address, and the port that it's
listening on. The value must have the prefix http:// even if you are using an IP address.
<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<system.net>
<defaultProxy>
<proxy proxyaddress="http://proxyserver:8080" bypassonlocal="True" usesystemdefault="True"/>
</defaultProxy>
</system.net>
<runtime>
<gcServer enabled="true"/>
</runtime>
<appSettings>
<add key="TraceFilename" value="AadAppProxyConnector.log" />
</appSettings>
</configuration>
Next, configure the Connector Updater service to use the proxy by making a similar change to the C:\Program
Files\Microsoft AAD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config file.
Step 2: Configure the proxy to allow traffic from the connector and related services to flow through
There are four aspects to consider at the outbound proxy:
Proxy outbound rules
Proxy authentication
Proxy ports
SSL inspection
Proxy outbound rules
Allow access to the following URLs:
URL HOW IT'S USED
*.msappproxy.net Communication between the connector and the Application

*.servicebus.windows.net Proxy cloud service
mscrl.microsoft.com:80 Azure uses these URLs to verify certificates

crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
login.windows.net The connector uses these URLs during the registration

login.microsoftonline.com process.
If your firewall or proxy allows DNS whitelisting, you can whitelist connections to *.msappproxy.net and
*.servicebus.windows.net. If not, you need to allow access to the Azure DataCenter IP ranges. The IP ranges are
updated each week.
If you can't allow connectivity by FQDN and need to specify IP ranges instead, use these options:
Allow the connector outbound access to all destinations.
Allow the connector outbound access to all of the Azure datacenter IP ranges. The challenge with using the list
of Azure datacenter IP ranges is that it's updated weekly. You need to put a process in place to ensure that your
access rules are updated accordingly. Only using a subset of the IP addresses may cause your configuration to
break.
Proxy authentication
Proxy authentication is not currently supported. Our current recommendation is to allow the connector
anonymous access to the Internet destinations.
Proxy ports
The connector makes outbound SSL -based connections by using the CONNECT method. This method essentially
sets up a tunnel through the outbound proxy. Configure the proxy server to allow tunneling to ports 443 and 80.
NOTE
When Service Bus runs over HTTPS, it uses port 443. However, by default, Service Bus attempts direct TCP connections and
falls back to HTTPS only if direct connectivity fails.
SSL inspection
Do not use SSL inspection for the connector traffic, because it causes problems for the connector traffic. The
connector uses a certificate to authenticate to the Application Proxy service, and that certificate can be lost during
SSL inspection.
Troubleshoot connector proxy problems and service connectivity

issues
Now you should see all traffic flowing through the proxy. If you have problems, the following troubleshooting
information should help.
The best way to identify and troubleshoot connector connectivity issues is to take a network capture while starting
the connector service. Here are some quick tips on capturing and filtering network traces.
You can use the monitoring tool of your choice. For the purposes of this article, we used Microsoft Message
Analyzer. You can download it from Microsoft.
The following examples are specific to Message Analyzer, but the principles can be applied to any analysis tool.
Take a capture of connector traffic
For initial troubleshooting, perform the following steps:
1. From services.msc, stop the Azure AD Application Proxy Connector service.
2. Run Message Analyzer as an administrator.

3. Select Start local trace.
4. Start the Azure AD Application Proxy Connector service.

5. Stop the network capture.
Check if the connector traffic bypasses outbound proxies

If you configured your Application Proxy connector to bypass the proxy servers and connect directly to the
Application Proxy service, you want to look in the network capture for failed TCP connection attempts.
Use the Message Analyzer filter to identify these attempts. Enter property.TCPSynRetransmit in the filter box and
select Apply.
A SYN packet is the first packet sent to establish a TCP connection. If this packet doesn’t return a response, the
SYN is reattempted. You can use the preceding filter to see any retransmitted SYNs. Then, you can check whether
these SYNs correspond to any connector-related traffic.
If you expect the connector to make direct connections to the Azure services, SynRetransmit responses on port
443 are an indication that you have a network or firewall problem.
Check if the connector traffic uses outbound proxies
If you configured your Application Proxy connector traffic to go through the proxy servers, you want to look for
failed https connections to your proxy.
To filter the network capture for these connection attempts, enter
(https.Request or https.Response) and tcp.port==8080 in the Message Analyzer filter, replacing 8080 with your
proxy service port. Select Apply to see the filter results.
The preceding filter shows just the HTTPs requests and responses to/from the proxy port. You're looking for the
CONNECT requests that show communication with the proxy server. Upon success, you get an HTTP OK (200)
response.
If you see other response codes, such as 407 or 502, that means that the proxy is requiring authentication or not
allowing the traffic for some other reason. At this point, you engage your proxy server support team.
Next steps
If you have problems with connector connectivity issues, ask your question in the Azure Active Directory
forum or create a ticket with our support team.
Working with claims-aware apps in Application Proxy
Claims-aware apps perform a redirection to the Security Token Service (STS ). The STS requests credentials from
the user in exchange for a token and then redirects the user to the application. There are a few ways to enable
Application Proxy to work with these redirects. Use this article to configure your deployment for claims-aware
apps.
Prerequisites
Make sure that the STS that the claims-aware app redirects to is available outside of your on-premises network.
You can make the STS available by exposing it through a proxy or by allowing outside connections.
Publish your application

1. Publish your application according to the instructions described in Publish applications with Application Proxy.
2. Navigate to the application page in the portal and select Single sign-on.
3. If you chose Azure Active Directory as your Preauthentication Method, select Azure AD single sign-on
disabled as your Internal Authentication Method. If you chose Passthrough as your Preauthentication
Method, you don't need to change anything.
Configure ADFS
You can configure ADFS for claims-aware apps in one of two ways. The first is by using custom domains. The
second is with WS -Federation.
Option 1: Custom domains
If all the internal URLs for your applications are fully qualified domain names (FQDNs), then you can configure
custom domains for your applications. Use the custom domains to create external URLs that are the same as the
internal URLs. When your external URLs match your internal URLs, then the STS redirections work whether your
users are on-premises or remote.
Option 2: WS -Federation
1. Open ADFS Management.
2. Go to Relying Party Trusts, right-click on the app you are publishing with Application Proxy, and choose
Properties.
3. On the Endpoints tab, under Endpoint type, select WS -Federation.

4. Under Trusted URL, enter the URL you entered in the Application Proxy under External URL and click OK.
Next steps
Enable single-sign on for applications that aren't claims-aware
Enable native client apps to interact with proxy applications
Create an unattended installation script for the Azure
AD Application Proxy connector
This topic helps you create a Windows PowerShell script that enables unattended installation and registration for
your Azure AD Application Proxy connector.
This capability is useful when you want to:
Install the connector on Windows servers that don't have user interface enabled, or that you can't access with
Remote Desktop.
Install and register many connectors at once.
Integrate the connector installation and registration as part of another procedure.
Create a standard server image that contains the connector bits but is not registered.
For the Application Proxy connector to work, it has to be registered with your Azure AD directory using a global
administrator and password. Ordinarily this information is entered during Connector installation in a pop-up
dialog box, but you can use PowerShell to automate this process instead.
There are two steps for an unattended installation. First, install the connector. Second, register the connector with
Azure AD.
Install the connector

Use the following steps to install the connector without registering it:
1. Open a command prompt.
2. Run the following command, in which the /q means quiet installation. A quiet installation doesn't prompt
you to accept the End-User License Agreement.
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
Register the connector with Azure AD

There are two methods you can use to register the connector:
Register the connector using a Windows PowerShell credential object
Register the connector using a token created offline
Register the connector using a Windows PowerShell credential object
1. Create a Windows PowerShell Credentials object $cred that contains an administrative username and
password for your directory. Run the following command, replacing <username> and <password>:
$User = "<username>"
$PlainPassword = '<password>'
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User,
$SecurePassword
2. Go to C:\Program Files\Microsoft AAD App Proxy Connector and run the following script using the
$cred object that you created:
.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -

moduleName "AppProxyPSModule" -Authenticationmode Credentials -Usercredentials $cred -Feature
ApplicationProxy
Register the connector using a token created offline

1. Create an offline token using the AuthenticationContext class using the values in this code snippet or
PowerShell cmdlets below:
Using C#:
using System;
using System.Diagnostics;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
class Program
{
#region constants
/// <summary>
/// The AAD authentication endpoint uri
/// </summary>
static readonly Uri AadAuthenticationEndpoint = new
Uri("https://login.microsoftonline.com/common/oauth2/token?api-version=1.0");
/// <summary>
/// The application ID of the connector in AAD
/// </summary>
static readonly string ConnectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489";
/// <summary>
/// The reply address of the connector application in AAD
/// </summary>
static readonly Uri ConnectorRedirectAddress = new Uri("urn:ietf:wg:oauth:2.0:oob");
/// <summary>
/// The AppIdUri of the registration service in AAD
/// </summary>
static readonly Uri RegistrationServiceAppIdUri = new
Uri("https://proxy.cloudwebappproxy.net/registerapp");
#endregion
#region private members

private string token;
private string tenantID;
#endregion
public void GetAuthenticationToken()

{
AuthenticationContext authContext = new
AuthenticationContext(AadAuthenticationEndpoint.AbsoluteUri);
AuthenticationResult authResult = authContext.AcquireToken(RegistrationServiceAppIdUri.AbsoluteUri,

ConnectorAppId,
ConnectorRedirectAddress,
PromptBehavior.Always);
if (authResult == null || string.IsNullOrEmpty(authResult.AccessToken) ||

string.IsNullOrEmpty(authResult.TenantId))
{
Trace.TraceError("Authentication result, token or tenant id returned are null");
throw new InvalidOperationException("Authentication result, token or tenant id returned are
null");
}
token = authResult.AccessToken;
tenantID = authResult.TenantId;
}
Using PowerShell:
# Locate AzureAD PowerShell Module
# Change Name of Module to AzureAD after what you have installed
$AADPoshPath = (Get-InstalledModule -Name AzureAD).InstalledLocation
# Set Location for ADAL Helper Library
$ADALPath = $(Get-ChildItem -Path $($AADPoshPath) -Filter
Microsoft.IdentityModel.Clients.ActiveDirectory.dll -Recurse ).FullName | Select-Object -Last 1
# Add ADAL Helper Library

Add-Type -Path $ADALPath
#region constants
# The AAD authentication endpoint uri

[uri]$AadAuthenticationEndpoint = "https://login.microsoftonline.com/common/oauth2/token?api-
version=1.0/"
# The application ID of the connector in AAD

[string]$ConnectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489"
# The reply address of the connector application in AAD

[uri]$ConnectorRedirectAddress = "urn:ietf:wg:oauth:2.0:oob"
# The AppIdUri of the registration service in AAD

[uri]$RegistrationServiceAppIdUri = "https://proxy.cloudwebappproxy.net/registerapp"
#endregion
#region GetAuthenticationToken
# Set AuthN context

$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -
ArgumentList $AadAuthenticationEndpoint
# Build platform parameters

$promptBehavior = [Microsoft.IdentityModel.Clients.ActiveDirectory.PromptBehavior]::Always
$platformParam = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -
ArgumentList $promptBehavior
# Do AuthN and get token

$authResult = $authContext.AcquireTokenAsync($RegistrationServiceAppIdUri.AbsoluteUri, $ConnectorAppId,
$ConnectorRedirectAddress, $platformParam).Result
# Check AuthN result

If (($authResult) -and ($authResult.AccessToken) -and ($authResult.TenantId) ) {
$token = $authResult.AccessToken
$tenantId = $authResult.TenantId
}
Else {
Write-Output "Authentication result, token or tenant id returned are null"
}
#endregion
2. Once you have the token, create a SecureString using the token:
$SecureToken = $Token | ConvertTo-SecureString -AsPlainText -Force
3. Run the following Windows PowerShell command, replacing <tenant GUID> with your directory ID:
.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -
moduleName "AppProxyPSModule" -Authenticationmode Token -Token $SecureToken -TenantId <tenant GUID> -
Feature ApplicationProxy
Next steps
Publish applications using your own domain name
How to enable native client apps to interact with
proxy applications
In addition to web applications, Azure Active Directory Application Proxy can also be used to publish native client
apps that are configured with the Azure AD Authentication Library (ADAL ). Native client apps differ from web
apps because they are installed on a device, while web apps are accessed through a browser.
Application Proxy supports native client apps by accepting Azure AD issued tokens sent in the header. The
Application Proxy service performs authentication on behalf of the users. This solution does not use application
tokens for authentication.
Use the Azure AD Authentication Library, which takes care of authentication and supports many client
environments, to publish native applications. Application Proxy fits into the Native Application to Web API
scenario.
This article walks you through the four steps to publish a native application with Application Proxy and the Azure
AD Authentication Library.
Step 1: Publish your application

Publish your proxy application as you would any other application and assign users to access your application. For
more information, see Publish applications with Application Proxy.
Step 2: Configure your application

Configure your native application as follows:
2. Navigate to Azure Active Directory > App registrations.
3. Select New application registration.
4. Specify a name for your application, select Native as the application type, and provide the Redirect URI for
your application.
5. Select Create.
For more detailed information about creating a new app registration, see Integrating applications with Azure
Active Directory.
Step 3: Grant access to other applications

Enable the native application to be exposed to other applications in your directory:
1. Still in App registrations, select the new native application that you just created.
2. Select API permissions.
3. Select Add a permission.
4. Open the first step, Select an API.
5. Use the search bar to find the Application Proxy app that you published in the first section. Choose that app,
then click Select.
6. Open the second step, Select permissions.

7. Use the checkbox to grant your native application access to your proxy application, then click Select.
8. Select Done.
Step 4: Edit the Active Directory Authentication Library
Edit the native application code in the authentication context of the Active Directory Authentication Library (ADAL )
to include the following text:
// Acquire Access Token from AAD for Proxy Application

AuthenticationContext authContext = new AuthenticationContext("https://login.microsoftonline.com/<Tenant
ID>");
AuthenticationResult result = await authContext.AcquireTokenAsync("< External Url of Proxy App >",
"<App ID of the Native app>",
new Uri("<Redirect Uri of the Native App>"),
PromptBehavior.Never);
//Use the Access Token to access the Proxy Application

HttpClient httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
HttpResponseMessage response = await httpClient.GetAsync("< Proxy App API Url >");
The variables in the sample code should be replaced as follows:

Tenant ID can be found in the Azure portal. Navigate to Azure Active Directory > Properties and copy the
Directory ID.
External URL is the front-end URL you entered in the Proxy Application. To find this value, navigate to the
Application proxy section of the proxy app.
App ID of the native app can be found on the Properties page of the native application.
Redirect URI of the native app can be found on the Redirect URIs page of the native application.
Once the ADAL is edited with these parameters, your users should be able to authenticate to native client apps
even when they're outside of the corporate network.
Next steps
For more information about the native application flow, see Native application to web API
Learn about setting up [Single sign-on for Application Proxy](what-is-single-sign-on.md#single- sign-on-
methods)
Set a custom home page for published apps by using
Azure AD Application Proxy
This article discusses how to configure apps to direct users to a custom home page. When you publish an
application with Application Proxy, you set an internal URL but sometimes that's not the page your users should
see first. Set a custom home page so that your users go to the right page when they access the apps. Your users
will see the custom home page that you set, whether they access the app from the Azure Active Directory Access
Panel or the Office 365 app launcher.
When users launch the app, they're directed by default to the root domain URL for the published app. The landing
page is typically set as the home page URL. Use the Azure AD PowerShell module to define custom home page
URLs when you want app users to land on a specific page within the app.
Here's one example of why a company would set a custom home page:
Inside your corporate network, users go to https://ExpenseApp/login/login.aspx to sign in and access your app.
Because you have other assets like images that Application Proxy needs to access at the top level of the folder
structure, you publish the app with https://ExpenseApp as the internal URL.
The default external URL is https://ExpenseApp -contoso.msappproxy.net, which doesn't take your users to the
sign-in page.
Set https://ExpenseApp -contoso.msappproxy.net/login/login.aspx as the home page URL.
NOTE
When you give users access to published apps, the apps are displayed in the Azure AD Access Panel and the Office 365 app
launcher.
Before you start

Before you set the home page URL, keep in mind the following requirements:
Ensure that the path you specify is a subdomain path of the root domain URL.
If the root-domain URL is, for example, https://apps.contoso.com/app1/, the home page URL that you
configure must start with https://apps.contoso.com/app1/.
If you make a change to the published app, the change might reset the value of the home page URL. When
you update the app in the future, you should recheck and, if necessary, update the home page URL.
Change the home page in the Azure portal

1. Sign in to the Azure portal as an administrator.
2. Navigate to Azure Active Directory > App registrations and choose your application from the list.
3. Select Properties from the settings.
4. Update the Home page URL field with your new path.
5. Select Save
Change the home page with PowerShell

Install the Azure AD PowerShell module
Before you define a custom home page URL by using PowerShell, install the Azure AD PowerShell module. You
can download the package from the PowerShell Gallery, which uses the Graph API endpoint.
To install the package, follow these steps:
1. Open a standard PowerShell window, and then run the following command:
Install-Module -Name AzureAD
If you're running the command as a non-admin, use the -scope currentuser option.
2. During the installation, select Y to install two packages from Nuget.org. Both packages are required.
Find the ObjectID of the app
Obtain the ObjectID of the app, and then search for the app by its home page.
1. In the same PowerShell window, import the Azure AD module.
Import-Module AzureAD
2. Sign in to the Azure AD module as the tenant administrator.
Connect-AzureAD
3. Find the app based on its home page URL. You can find the URL in the portal by going to Azure Active
Directory > Enterprise applications > All applications. This example uses sharepoint-iddemo.
Get-AzureADApplication | where { $_.Homepage -like "sharepoint-iddemo" } | fl DisplayName, Homepage,

ObjectID
4. You should get a result that's similar to the one shown here. Copy the ObjectID GUID to use in the next
section.
DisplayName : SharePoint
Homepage : https://sharepoint-iddemo.msappproxy.net/
ObjectId : 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
Update the home page URL

Create the home page URL, and update your application with that value. Continue using the same PowerShell
window to run these commands. Or, if you're using a new PowerShell window, sign in to the Azure AD module
again using Connect-AzureAD .
1. Confirm that you have the correct app, and replace 8af89bfa -eac6 -40b0 -8a13 -c2c4e3ee22a4 with the
ObjectID that you copied in the preceding section.
Get-AzureADApplication -ObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4.
Now that you've confirmed the app, you're ready to update the home page, as follows.
2. Create a blank application object to hold the changes that you want to make. This variable holds the values
that you want to update. Nothing is created in this step.
$appnew = New-Object "Microsoft.Open.AzureAD.Model.Application"
3. Set the home page URL to the value that you want. The value must be a subdomain path of the published
app. For example, if you change the home page URL from https://sharepoint-iddemo.msappproxy.net/ to
https://sharepoint-iddemo.msappproxy.net/hybrid/ , app users go directly to the custom home page.
$homepage = "https://sharepoint-iddemo.msappproxy.net/hybrid/"
4. Make the update by using the GUID (ObjectID ) that you copied in "Step 1: Find the ObjectID of the app."
Set-AzureADApplication -ObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4 -Homepage $homepage
5. To confirm that the change was successful, restart the app.
Get-AzureADApplication -ObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
NOTE
Any changes that you make to the app might reset the home page URL. If your home page URL resets, repeat the steps in
this section to set it back.
Next steps
Enable remote access to SharePoint with Azure AD Application Proxy
Enable Application Proxy in the Azure portal
Redirect hardcoded links for apps published with
Azure AD Application Proxy
Azure AD Application Proxy makes your on-premises apps available to users who are remote or on their own
devices. Some apps, however, were developed with local links embedded in the HTML. These links don't work
correctly when the app is used remotely. When you have several on-premises applications point to each other, your
users expect the links to keep working when they're not at the office.
The best way to make sure that links work the same both inside and outside of your corporate network is to
configure the external URLs of your apps to be the same as their internal URLs. Use custom domains to configure
your external URLs to have your corporate domain name instead of the default application proxy domain.
If you can't use custom domains in your tenant, there are several other options for providing this functionality. All
of these are also compatible with custom domains and each other, so you can configure custom domains and other
solutions if needed.
Option 1: Use the Managed Browser – This solution is only applicable if you plan to recommend or require that
users access the application through the Intune Managed Browser. It will handle all published URLs.
Option 2: Use the MyApps Extension – This solution requires users to install a client-side browser extension,
but it will handle all published URLs and works with most popular browsers.
Option 3: Use the link translation setting – This is an admin side setting that is invisible to users. However, it
will only handle URLs in HTML and CSS. Hard-coded internal URLs generated through Javascript (for example)
will not work.
These three features keep your links working no matter where your users are. When you have apps that point
directly to internal endpoints or ports, you can map these internal URLs to the published external Application
Proxy URLs.
NOTE
The last option is only for tenants that, for whatever reason, can't use custom domains to have the same internal and
external URLs for their apps. Before you enable this feature, see if custom domains in Azure AD Application Proxy can work
for you.
Or, if the application you need to configure with link translation is SharePoint, see Configure alternate access mappings for
SharePoint 2013 for another approach to mapping links.
Option 1: Intune Managed Browser Integration

You can use the Intune Managed Browser to further protect your application and content. To use this solution, you
need to require/recommend users access the application through the Intune Managed Browser. All internal URLs
published with Application Proxy will be recognized by the Managed Browser and redirected to the corresponding
external URL. This ensures that all the hard-coded internal URLs work, and if a user goes to the browser and
directly types the internal URL, it works even if the user is remote.
To learn more, including how to configure this option, please see the Managed Browser documentation.
Option 2: MyApps Browser Extension
With the MyApps Browser Extension, all internal URLs published with Application Proxy are recognized by the
extension and redirected to the corresponding external URL. This ensures that all the hard-coded internal URLs
work, and if a user goes to the browser's address bar and directly types the internal URL, it works even if the user
is remote.
To use this feature, the user needs to download the extension and be logged in. There is no other configuration
needed for admins or the users.
Option 3: Link Translation Setting
When link translation is enabled, the Application Proxy service searches through HTML and CSS for published
internal links and translates them so that your users get an uninterrupted experience.
How link translation works

After authentication, when the proxy server passes the application data to the user, Application Proxy scans the
application for hardcoded links and replaces them with their respective, published external URLs.
Application Proxy assumes that applications are encoded in UTF -8. If that's not the case, specify the encoding type
in an http response header, like Content-Type:text/html;charset=utf-8 .
Which links are affected?
The link translation feature only looks for links that are in code tags in the body of an app. Application Proxy has a
separate feature for translating cookies or URLs in headers.
There are two common types of internal links in on-premises applications:
Relative internal links that point to a shared resource in a local file structure like /claims/claims.html . These
links automatically work in apps that are published through Application Proxy, and continue to work with or
without link translation.
Hardcoded internal links to other on-premises apps like http://expenses or published files like
http://expenses/logo.jpg . The link translation feature works on hardcoded internal links, and changes them to
point to the external URLs that remote users need to go through.
How do apps link to each other?
Link translation is enabled for each application, so that you have control over the user experience at the per-app
level. Turn on link translation for an app when you want the links from that app to be translated, not links to that
app.
For example, suppose that you have three applications published through Application Proxy that all link to each
other: Benefits, Expenses, and Travel. There's a fourth app, Feedback, that isn't published through Application
Proxy.
When you enable link translation for the Benefits app, the links to Expenses and Travel are redirected to the
external URLs for those apps, but the link to Feedback is not redirected because there is no external URL. Links
from Expenses and Travel back to Benefits don't work, because link translation has not been enabled for those two
apps.
Which links aren't translated?
To improve performance and security, some links aren't translated:
Links not inside of code tags.
Links not in HTML or CSS.
Links in URL -encoded format.
Internal links opened from other programs. Links sent through email or instant message, or included in other
documents, won't be translated. The users need to know to go to the external URL.
If you need to support one of these two scenarios, use the same internal and external URLs instead of link
translation.
Enable link translation

Getting started with link translation is as easy as clicking a button:
2. Go to Azure Active Directory > Enterprise applications > All applications > select the app you want to
manage > Application proxy.
3. Turn Translate URLs in application body to Yes.
4. Select Save to apply your changes.

Now, when your users access this application, the proxy will automatically scan for internal URLs that have been
published through Application Proxy on your tenant.
Send feedback
We want your help to make this feature work for all your apps. We search over 30 tags in HTML and CSS. If you
have an example of generated links that aren't being translated, send a code snippet to Application Proxy
Feedback.
Next steps
Use custom domains with Azure AD Application Proxy to have the same internal and external URL
Configure alternate access mappings for SharePoint 2013
Cookie settings for accessing on-premises
applications in Azure Active Directory
Azure Active Directory (Azure AD ) has access and session cookies for accessing on-premises applications through
Application Proxy. Find out how to use the Application Proxy cookie settings.
What are the cookie settings?

Application Proxy uses the following access and session cookie settings.
COOKIE SETTING DEFAULT DESCRIPTION RECOMMENDATIONS
Use HTTP-Only Cookie No Yes allows Application Proxy Use Yes because of the
to include the HTTPOnly flag additional security benefits.
in HTTP response headers.
This flag provides additional Use No for clients or user
security benefits, for agents that do require
example, it prevents client- access to the session cookie.
side scripting (CSS) from For example, use No for an
copying or modifying the RDP or MTSC client that
cookies. connects to a Remote
Desktop Gateway server
Before we supported the through Application Proxy.
HTTP-Only setting,
Application Proxy encrypted
and transmitted cookies over
a secured SSL channel to
protect against modification.
Use Secure Cookie No Yes allows Application Proxy Use Yes because of the
to include the Secure flag in additional security benefits.
HTTP response headers.
Secure Cookies enhances
security by transmitting
cookies over a TLS secured
channel such as HTTPS. This
prevents cookies from being
observed by unauthorized
parties due to the
transmission of the cookie in
clear text.
COOKIE SETTING DEFAULT DESCRIPTION RECOMMENDATIONS
Use Persistent Cookie No Yes allows Application Proxy Use No because of the
to set its access cookies to security risk associated with
not expire when the web keeping users authenticated.
browser is closed. The
persistence lasts until the We suggest only using Yes
access token expires, or until for older applications that
the user manually deletes can't share cookies between
the persistent cookies. processes. It's better to
update your application to
handle sharing cookies
between processes instead
of using persistent cookies.
For example, you might need
persistent cookies to allow a
user to open Office
documents in explorer view
from a SharePoint site.
Without persistent cookies,
this operation might fail if
the access cookies aren't
shared between the browser,
the explorer process, and the
Office process.
Set the cookie settings - Azure portal

To set the cookie settings using the Azure portal:
2. Navigate to Azure Active Directory>Enterprise applications>All applications.
3. Select the application for which you want to enable a cookie setting.
4. Click Application Proxy.
5. Under Additional Settings, set the cookie setting to Yes or No.
6. Click Save to apply your changes.
View current cookie settings - PowerShell

To see the current cookie settings for the application, use this PowerShell command:
Get-AzureADApplicationProxyApplication -ObjectId <ObjectId> | fl *
Set cookie settings - PowerShell

In the following PowerShell commands, <ObjectId> is the ObjectId of the application.
Http-Only Cookie
Set-AzureADApplicationProxyApplication -ObjectId <ObjectId> -IsHttpOnlyCookieEnabled $true

Set-AzureADApplicationProxyApplication -ObjectId <ObjectId> -IsHttpOnlyCookieEnabled $false
Secure Cookie
Set-AzureADApplicationProxyApplication -ObjectId <ObjectId> -IsSecureCookieEnabled $true
Set-AzureADApplicationProxyApplication -ObjectId <ObjectId> -IsSecureCookieEnabled $false
Persistent Cookies
Set-AzureADApplicationProxyApplication -ObjectId <ObjectId> -IsPersistentCookieEnabled $true

Set-AzureADApplicationProxyApplication -ObjectId <ObjectId> -IsPersistentCookieEnabled $false
Wildcard applications in the Azure Active Directory
application proxy
In Azure Active Directory (Azure AD ), configuring a large number of on-premises applications can quickly become
unmanageable and introduces unnecessary risks for configuration errors if many of them require the same
settings. With Azure AD Application Proxy, you can address this issue by using wildcard application publishing to
publish and manage many applications at once. This is a solution that allows you to:
Simplify your administrative overhead
Reduce the number of potential configuration errors
Enable your users to securely access more resources
This article provides you with the information you need to configure wildcard application publishing in your
environment.
Create a wildcard application

You can create a wildcard (*) application if you have a group of applications with the same configuration. Potential
candidates for a wildcard application are applications sharing the following settings:
The group of users having access to them
The SSO method
The access protocol (http, https)
You can publish applications with wildcards if both, the internal and external URLs are in the following format:
http(s)://*.<domain>
For example: http(s)://*.adventure-works.com . While the internal and external URLs can use different domains, as
a best practice, they should be same. When publishing the application, you see an error if one of the URLs doesn't
have a wildcard.
If you have additional applications with different configuration settings, you must publish these exceptions as
separate applications to overwrite the defaults set for the wildcard. Applications without a wildcard do always take
precedence over wildcard applications. From the configuration perspective, these are "just" regular applications.
Creating a wildcard application is based on the same application publishing flow that is available for all other
applications. The only difference is that you include a wildcard in the URLs and potentially the SSO configuration.
Prerequisites
Custom domains
While custom domains are optional for all other applications, they are a prerequisite for wildcard applications.
Creating custom domains requires you to:
1. Create a verified domain within Azure
2. Upload an SSL certificate in the PFX format to your application proxy.
You should consider using a wildcard certificate to match the application you plan to create. Alternatively, you can
also use a certificate that only lists specific applications. In this case, only the applications listed in the certificate will
be accessible through this wildcard application.
For security reasons, this is a hard requirement and we will not support wildcards for applications that cannot use a
custom domain for the external URL.
DNS updates
When using custom domains, you need to create a DNS entry with a CNAME record for the external URL (for
example, *.adventure-works.com ) pointing to the external URL of the application proxy endpoint.For wildcard
applications, the CNAME record needs to point to the relevant external URLs:
<yourAADTenantId>.tenant.runtime.msappproxy.net
To confirm that you have configured your CNAME correctly, you can use nslookup on one of the target endpoints,
for example, expenses.adventure-works.com . Your response should include the already mentioned alias (
<yourAADTenantId>.tenant.runtime.msappproxy.net ).
Considerations
Accepted formats
For wildcard applications, the Internal URL must be formatted as http(s)://*.<domain> .
When you configure an External URL, you must use the following format: https://*.<custom domain>
Other positions of the wildcard, multiple wildcards, or other regex strings are not supported and are causing errors.
Excluding applications from the wildcard
You can exclude an application from the wildcard application by
Publishing the exception application as regular application
Enabling the wildcard only for specific applications through your DNS settings
Publishing an application as regular application is the preferred method to exclude an application from a wildcard.
You should publish the excluded applications before the wildcard applications to ensure that your exceptions are
enforced from the beginning. The most specific application will always take precedence – an application published
as budgets.finance.adventure-works.com takes precedence over the application *.finance.adventure-works.com ,
which in turn takes precedence over the application *.adventure-works.com .
You can also limit the wildcard to only work for specific applications through your DNS management. As a best
practice, you should create a CNAME entry that includes a wildcard and matches the format of the external URL
you have configured. However, you can instead point specific application URLs to the wildcards. For example,
instead of *.adventure-works.com , point hr.adventure-works.com , expenses.adventure-works.com and
travel.adventure-works.com individually to 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net .
If you use this option, you also need another CNAME entry for the value AppId.domain , for example,
00000000-1a11-22b2-c333-444d4d4dd444.adventure-works.com , also pointing to the same location. You can find the
AppId on the application properties page of the wildcard application:
Setting the homepage URL for the MyApps panel
The wildcard application is represented with just one tile in the MyApps panel. By default this tile is hidden. To
show the tile and have users land on a specific page:
1. Follow the guidelines for setting a homepage URL.
2. Set Show Application to true on the application properties page.
Kerberos constrained delegation
For applications using kerberos constrained delegation (KCD ) as the SSO method, the SPN listed for the SSO
method may also need a wildcard. For example, the SPN could be: HTTP/*.adventure-works.com . You still need to
have the individual SPNs configured on your backend servers (for example,
http://expenses.adventure-works.com and HTTP/travel.adventure-works.com ).
Scenario 1: General wildcard application

In this scenario, you have three different applications you want to publish:
expenses.adventure-works.com
hr.adventure-works.com
travel.adventure-works.com
All three applications:

Are used by all your users
Use Integrated Windows Authentication
Have the same properties
You can publish the wildcard application using the steps outlined in Publish applications using Azure AD
Application Proxy. This scenario assumes:
A tenant with the following ID: 000aa000-11b1-2ccc-d333-4444eee4444e
A verified domain called adventure-works.com has been configured.

A CNAME entry that points *.adventure-works.com to
000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net has been created.
Following the documented steps, you create a new application proxy application in your tenant. In this example, the
wildcard is in the following fields:
Internal URL:
External URL:
Internal Application SPN:
By publishing the wildcard application, you can now access your three applications by navigating to the URLs you
are used to (for example, travel.adventure-works.com ).
The configuration implements the following structure:
COLOR DESCRIPTION
Blue Applications explicitly published and visible in the Azure Portal.
Gray Applications you can accessible through the parent

application.
Scenario 2: General wildcard application with exception

In this scenario, you have in addition to the three general applications another application,
finance.adventure-works.com , which should only be accessible by Finance division. With the current application
structure, your finance application would be accessible through the wildcard application and by all employees. To
change this, you exclude your application from your wildcard by configuring Finance as a separate application with
more restrictive permissions.
You need to make sure that a CNAME records exist that points finance.adventure-works.com to the application
specific endpoint, specified on the Application Proxy page for the application. For this scenario,
finance.adventure-works.com points to https://finance-awcycles.msappproxy.net/ .
Following the documented steps, this scenario requires the following settings:
In the Internal URL, you set finance instead of a wildcard.
In the External URL, you set finance instead of a wildcard.
Internal Application SPN you set finance instead of a wildcard.
This configuration implements the following scenario:
Because finance.adventure-works.com is a more specific URL than *.adventure-works.com , it takes precedence.

Users navigating to finance.adventure-works.com have the experience specified in the Finance Resources
application. In this case, only finance employees are able to access finance.adventure-works.com .
If you have multiple applications published for finance and you have finance.adventure-works.com as a verified
domain, you could publish another wildcard application *.finance.adventure-works.com . Because this is more
specific than the generic *.adventure-works.com , it takes precedence if a user accesses an application in the finance
domain.
Next steps
For more information about:
Custom domains, see Working with custom domains in Azure AD Application Proxy.
Publishing applications, see Publish applications using Azure AD Application Proxy
Remove personal data for Azure Active Directory
Application Proxy
Azure Active Directory Application Proxy requires that you install connectors on your devices, which means that
there might be personal data on your devices. This article provides steps for how to delete that personal data to
improve privacy.
Where is the personal data?

It is possible for Application Proxy to write personal data to the following log types:
Connector event logs
Windows event logs
Remove personal data from Windows event logs

For information on how to configure data retention for the Windows event logs, see Settings for event logs. To
learn about Windows event logs, see Using Windows Event Log.
NOTE
If you’re interested in viewing or deleting personal data, please review Microsoft's guidance in the Windows Data Subject
Requests for the GDPR site. If you’re looking for general information about GDPR, see the GDPR section of the Service Trust
portal.
Remove personal data from Connector event logs

To ensure the Application Proxy logs do not have personal data, you can either:
Delete or view data when needed, or
Turn off logging
Use the following sections to remove personal data from connector event logs. You must complete the removal
process for all devices on which the connector is installed.
NOTE
This article provides steps for how to delete personal data from the device or service and can be used to support your
obligations under the GDPR. If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.
View or export specific data

To view or export specific data, search for related entries in each of the connector event logs. The logs are located at
C:\ProgramData\Microsoft\Microsoft AAD Application Proxy Connector\Trace .
Since the logs are text files, you can use findstr to search for text entries related to a user.
To find personal data, search log files for UserID.
To find personal data logged by an application that uses Kerberos Constrained Delegation, search for these
components of the username type:
On-premises user principal name
Username part of user principal name
Username part of on-premises user principal name
On-premises security accounts manager (SAM ) account name
Delete specific data
To delete specific data:
1. Restart the Microsoft Azure AD Application Proxy Connector service to generate a new log file. The new log file
enables you to delete or modify the old log files.
2. Follow the View or export specific data process described previously to find information that needs to be
deleted. Search all of the connector logs.
3. Either delete the relevant log files or selectively delete the fields that contain personal data. You can also delete
all old log files if you don’t need them anymore.
Turn off connector logs
One option to ensure the connector logs do not contain personal data is to turn off the log generation. To stop
generating connector logs, remove the following highlighted line from
C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe.config .
Next steps
For an overview of Application Proxy, see How to provide secure remote access to on-premises applications.
Working with custom domains in Azure AD
Application Proxy
When you publish an application through Azure Active Directory Application Proxy, you create an external URL
for your users to go to when they're working remotely. This URL gets the default domain
yourtenant.msappproxy.net. For example, if you published an app named Expenses and your tenant is named
Contoso, then the external URL would be https://expenses-contoso.msappproxy.net. If you want to use your
own domain name, configure a custom domain for your application.
We recommend that you set up custom domains for your applications whenever possible. Some of the benefits
of custom domains include:
Your users can get to the application with the same URL, whether they are working inside or outside of your
network.
If all of your applications have the same internal and external URLs, then links in one application that point to
another continue to work even outside the corporate network.
You control your branding, and create the URLs you want.
Configure a custom domain

Prerequisites
Before you configure a custom domain, make sure that you have the following requirements prepared:
A verified domain added to Azure Active Directory.
A custom certificate for the domain, in the form of a PFX file.
An on-premises app published through Application Proxy.
Configure your custom domain
When you have those three requirements ready, follow these steps to set up your custom domain:
2. Navigate to Azure Active Directory > Enterprise applications > All applications and choose the app
you want to manage.
3. Select Application Proxy.
4. In the External URL field, use the dropdown list to select your custom domain. If you don't see your domain
in the list, then it hasn't been verified yet.
5. Select Save
6. The Certificate field that was disabled becomes enabled. Select this field.
If you already uploaded a certificate for this domain, the Certificate field displays the certificate
information.
7. Upload the PFX certificate and enter the password for the certificate.
8. Select Save to save your changes.
9. Add a DNS record that redirects the new external URL to the msappproxy.net domain.
TIP
You only need to upload one certificate per custom domain. Once you upload a certificate, you can choose the custom
domain when you publish a new app and not have to do additional configuration except for the DNS record.
Manage certificates
Certificate format
There is no restriction on the certificate signature methods. Elliptic Curve Cryptography (ECC ), Subject
Alternative Name (SAN ), and other common certificate types are all supported.
You can use a wildcard certificate as long as the wildcard matches the desired external URL.
Changing the domain
All verified domains appear in the External URL dropdown list for your application. To change the domain, just
update that field for the application. If the domain you want isn't in the list, add it as a verified domain. If you
select a domain that doesn't have an associated certificate yet, follow steps 5-7 to add the certificate. Then, make
sure you update the DNS record to redirect from the new external URL.
Certificate management
You can use the same certificate for multiple applications unless the applications share an external host.
You get a warning when a certificate expires, telling you to upload another certificate through the portal. If the
certificate is revoked, your users may see a security warning when accessing the application. We don’t perform
revocation checks for certificates. To update the certificate for a given application, navigate to the application and
follow steps 5-7 for configuring custom domains on published applications to upload a new certificate. If the old
certificate is not being used by other applications, it is deleted automatically.
Currently all certificate management is through individual application pages so you need to manage certificates
in the context of the relevant applications.
Next steps
Enable single sign-on to your published apps with Azure AD authentication.
Enable conditional access to your published apps.
Add your custom domain name to Azure AD
Troubleshoot Application Proxy problems and error
messages
If errors occur in accessing a published application or in publishing applications, check the following options to
see if Microsoft Azure AD Application Proxy is working correctly:
Open the Windows Services console and verify that the Microsoft AAD Application Proxy Connector
service is enabled and running. You may also want to look at the Application Proxy service properties page, as
shown in the following image:
Open Event Viewer and look for Application Proxy connector events in Applications and Services Logs >
Microsoft > AadApplicationProxy > Connector > Admin.
If needed, more detailed logs are available by turning on the Application Proxy connector session logs.
For more information about the Azure AD Troubleshooting tool, see Troubleshooting tool to validate connector
networking prerequisites.
The page is not rendered correctly

You may have problems with your application rendering or functioning incorrectly without receiving specific error
messages. This can occur if you published the article path, but the application requires content that exists outside
that path.
For example, if you publish the path https://yourapp/app but the application calls images in
https://yourapp/media, they won't be rendered. Make sure that you publish the application using the highest level
path you need to include all relevant content. In this example, it would be http://yourapp/.
If you change your path to include referenced content, but still need users to land on a deeper link in the path, see
the blog post Setting the right link for Application Proxy applications in the Azure AD access panel and Office 365
app launcher.
Connector errors
If registration fails during the Connector wizard installation, there are two ways to view the reason for the failure.
Either look in the event log under Applications and Services
Logs\Microsoft\AadApplicationProxy\Connector\Admin, or run the following Windows PowerShell
command:
Get-EventLog application –source "Microsoft AAD Application Proxy Connector" –EntryType "Error" –Newest 1
Once you find the Connector error from the event log, use this table of common errors to resolve the problem:
ERROR RECOMMENDED STEPS
Connector registration failed: Make sure you enabled If you closed the registration window without signing in to
Application Proxy in the Azure Management Portal and that Azure AD, run the Connector wizard again and register the
you entered your Active Directory user name and password Connector.
correctly. Error: 'One or more errors occurred.'
If the registration window opens and then immediately closes
without allowing you to log in, you will probably get this
error. This error occurs when there is a networking error on
your system. Make sure that it is possible to connect from a
browser to a public website and that the ports are open as
specified in Application Proxy prerequisites.
Clear error is presented in the registration window. Cannot If you see this error and then the window closes, you entered
proceed the wrong username or password. Try again.
Connector registration failed: Make sure you enabled You are trying to sign in using a Microsoft Account and not a
Application Proxy in the Azure Management Portal and that domain that is part of the organization ID of the directory
you entered your Active Directory user name and password you are trying to access. Make sure that the admin is part of
correctly. Error: 'AADSTS50059: No tenant-identifying the same domain name as the tenant domain, for example, if
information found in either the request or implied by any the Azure AD domain is contoso.com, the admin should be
provided credentials and search by service principal URI has admin@contoso.com.
failed.
Failed to retrieve the current execution policy for running If the Connector installation fails, check to make sure that
PowerShell scripts. PowerShell execution policy is not disabled.
1. Open the Group Policy Editor.

2. Go to Computer Configuration > Administrative
Templates > Windows Components > Windows
PowerShell and double-click Turn on Script Execution.
3. The execution policy can be set to either Not Configured
or Enabled. If set to Enabled, make sure that under Options,
the Execution Policy is set to either Allow local scripts and
remote signed scripts or to Allow all scripts.
Connector failed to download the configuration. The Connector’s client certificate, which is used for
authentication, expired. This may also occur if you have the
Connector installed behind a proxy. In this case, the
Connector cannot access the Internet and will not be able to
provide applications to remote users. Renew trust manually
using the Register-AppProxyConnector cmdlet in Windows
PowerShell. If your Connector is behind a proxy, it is
necessary to grant Internet access to the Connector accounts
“network services” and “local system.” This can be
accomplished either by granting them access to the Proxy or
by setting them to bypass the proxy.
Connector registration failed: Make sure you are an The alias you're trying to log in with isn't an admin on this
Application Administrator of your Active Directory to register domain. Your Connector is always installed for the directory
the Connector. Error: 'The registration request was denied.' that owns the user’s domain. Make sure that the admin
account you are trying to sign in with has atleast application
administrator permissions to the Azure AD tenant.
Kerberos errors
This table covers the more common errors that come from Kerberos setup and configuration, and includes
suggestions for resolution.
Failed to retrieve the current execution policy for running If the Connector installation fails, check to make sure that
PowerShell scripts. PowerShell execution policy is not disabled.
1. Open the Group Policy Editor.

2. Go to Computer Configuration > Administrative
Templates > Windows Components > Windows
PowerShell and double-click Turn on Script Execution.
3. The execution policy can be set to either Not Configured
or Enabled. If set to Enabled, make sure that under Options,
the Execution Policy is set to either Allow local scripts and
remote signed scripts or to Allow all scripts.
12008 - Azure AD exceeded the maximum number of This error may indicate incorrect configuration between Azure
permitted Kerberos authentication attempts to the backend AD and the backend application server, or a problem in time
server. and date configuration on both machines. The backend
server declined the Kerberos ticket created by Azure AD.
Verify that Azure AD and the backend application server are
configured correctly. Make sure that the time and date
configuration on the Azure AD and the backend application
server are synchronized.
13016 - Azure AD cannot retrieve a Kerberos ticket on behalf There is a problem with the STS configuration. Fix the UPN
of the user because there is no UPN in the edge token or in claim configuration in the STS.
the access cookie.
13019 - Azure AD cannot retrieve a Kerberos ticket on behalf This event may indicate incorrect configuration between
of the user because of the following general API error. Azure AD and the domain controller server, or a problem in
time and date configuration on both machines. The domain
controller declined the Kerberos ticket created by Azure AD.
configured correctly, especially the SPN configuration. Make
sure the Azure AD is domain joined to the same domain as
the domain controller to ensure that the domain controller
establishes trust with Azure AD. Make sure that the time and
date configuration on the Azure AD and the domain
controller are synchronized.
13020 - Azure AD cannot retrieve a Kerberos ticket on behalf This event may indicate incorrect configuration between
of the user because the backend server SPN is not defined. Azure AD and the domain controller server, or a problem in
time and date configuration on both machines. The domain
controller declined the Kerberos ticket created by Azure AD.
configured correctly, especially the SPN configuration. Make
sure the Azure AD is domain joined to the same domain as
the domain controller to ensure that the domain controller
establishes trust with Azure AD. Make sure that the time and
date configuration on the Azure AD and the domain
controller are synchronized.
13022 - Azure AD cannot authenticate the user because the This event may indicate incorrect configuration between
backend server responds to Kerberos authentication Azure AD and the backend application server, or a problem in
attempts with an HTTP 401 error. time and date configuration on both machines. The backend
server declined the Kerberos ticket created by Azure AD.
configured correctly. Make sure that the time and date
configuration on the Azure AD and the backend application
server are synchronized. For more information, see
Troubleshoot Kerberos Constrained Delegation
Configurations for Application Proxy.
End-user errors
This list covers errors that your end users might encounter when they try to access the app and fail.
The website cannot display the page. Your user may get this error when trying to access the app
you published if the application is an IWA application. The
defined SPN for this application may be incorrect. For IWA
apps, make sure that the SPN configured for this application
is correct.
The website cannot display the page. Your user may get this error when trying to access the app
you published if the application is an OWA application. This
could be caused by one of the following:
The defined SPN for this application is incorrect. Make sure
that the SPN configured for this application is correct.
The user who tried to access the application is using a
Microsoft account rather than the proper corporate account
to sign in, or the user is a guest user. Make sure the user
signs in using their corporate account that matches the
domain of the published application. Microsoft Account users
and guest cannot access IWA applications.
The user who tried to access the application is not properly
defined for this application on the on premises side. Make
sure that this user has the proper permissions as defined for
this backend application on the on premises machine.
This corporate app can’t be accessed. You are not authorized Your users may get this error when trying to access the app
to access this application. Authorization failed. Make sure to you published if they use Microsoft accounts instead of their
assign the user with access to this application. corporate account to sign in. Guest users may also get this
error. Microsoft Account users and guests cannot access IWA
applications. Make sure the user signs in using their
corporate account that matches the domain of the published
application.
You may not have assigned the user for this application. Go
to the Application tab, and under Users and Groups, assign
this user or user group to this application.
This corporate app can’t be accessed right now. Please try Your users may get this error when trying to access the app
again later…The connector timed out. you published if they are not properly defined for this
application on the on premises side. Make sure that your
users have the proper permissions as defined for this backend
application on the on premises machine.
This corporate app can’t be accessed. You are not authorized Your users may get this error when trying to access the app
to access this application. Authorization failed. Make sure that you published if they weren't explicitly assigned with a
the user has a license for Azure Active Directory Premium or Premium/Basic license by the subscriber’s administrator. Go to
Basic. the subscriber’s Active Directory Licenses tab and make sure
that this user or user group is assigned a Premium or Basic
license.
My error wasn't listed here

If you encounter an error or problem with Azure AD Application Proxy that isn't listed in this troubleshooting
guide, we'd like to hear about it. Send an email to our feedback team with the details of the error you
encountered.
See also
Enable Application Proxy for Azure Active Directory
Publish applications with Application Proxy
Enable single sign-on
Enable conditional access
Configure real-time application access monitoring
with Microsoft Cloud App Security and Azure Active
Directory
Configure an on-premises application in Azure Active Directory (Azure AD ) to use Microsoft Cloud App Security
(MCAS ) for real-time monitoring. MCAS uses Conditional Access App Control to monitor and control sessions in
real-time based on conditional access policies. You can apply these policies to on-premises applications that use
Application Proxy in Azure Active Directory (Azure AD ).
Here are some examples of the types of policies you can create with MCAS:
Block or protect the download of sensitive documents on unmanaged devices.
Monitor when high-risk users sign on to applications, and then log their actions from within the session. With
this information, you can analyze user behavior to determine how to apply session policies.
Use client certificates or device compliance to block access to specific applications from unmanaged devices.
Restrict user sessions from non-corporate networks. You can give restricted access to users accessing an
application from outside your corporate network. For example, this restricted access can block the user from
downloading sensitive documents.
For more information, see Protect apps with Microsoft Cloud App Security Conditional Access App Control.
Requirements
License:
EMS E5 license, or
Azure Active Directory Premium P1 and MCAS Standalone.
On-premises application:
The on-premises application must use Kerberos Constrained Delegation (KCD )
Configure Application Proxy:
Configure Azure AD to use Application Proxy, including preparing your environment and installing the
Application Proxy connector. For a tutorial, see Add an on-premises applications for remote access through
Application Proxy in Azure AD.
Add on-premises application to Azure AD

Add an on-premises application to Azure AD. For a quickstart, see Add an on-premises app to Azure AD. When
adding the application, be sure to set the following two settings in the Add your on-premises application blade:
Pre Authentication: Enter Azure Active Directory.
Translate URLs in Application Body: Choose Yes.
Those two settings are required for the application to work with MCAS.
Test the on-premises application

After adding your application to Azure AD, use the steps in Test the application to add a user for testing, and test
the sign-on.
Deploy Conditional Access App Control

To configure your application with the Conditional Access Application Control, follow the instructions in Deploy
Conditional Access Application Control for Azure AD apps.
Test Conditional Access App Control

To test the deployment of Azure AD applications with Conditional Access Application Control, follow the
instructions in Test the deployment for Azure AD apps.
Publish Remote Desktop with Azure AD Application
Proxy
Remote Desktop Service and Azure AD Application Proxy work together to improve the productivity of workers
who are away from the corporate network.
The intended audience for this article is:
Current Application Proxy customers who want to offer more applications to their end users by publishing on-
premises applications through Remote Desktop Services.
Current Remote Desktop Services customers who want to reduce the attack surface of their deployment by
using Azure AD Application Proxy. This scenario gives a limited set of two-step verification and conditional
access controls to RDS.
How Application Proxy fits in the standard RDS deployment

A standard RDS deployment includes various Remote Desktop role services running on Windows Server. Looking
at the Remote Desktop Services architecture, there are multiple deployment options. Unlike other RDS
deployment options, the RDS deployment with Azure AD Application Proxy (shown in the following diagram) has
a permanent outbound connection from the server running the connector service. Other deployments leave open
inbound connections through a load balancer.
In an RDS deployment, the RD Web role and the RD Gateway role run on Internet-facing machines. These
endpoints are exposed for the following reasons:
RD Web provides the user a public endpoint to sign in and view the various on-premises applications and
desktops they can access. Upon selecting a resource, an RDP connection is created using the native app on the
OS.
RD Gateway comes into the picture once a user launches the RDP connection. The RD Gateway handles
encrypted RDP traffic coming over the internet and translates it to the on-premises server that the user is
connecting to. In this scenario, the traffic the RD Gateway is receiving comes from the Azure AD Application
Proxy.
TIP
If you haven't deployed RDS before, or want more information before you begin, learn how to seamlessly deploy RDS with
Azure Resource Manager and Azure Marketplace.
Requirements
Use a client other than the Remote Desktop web client, since the web client does not support Application
Proxy.
Both the RD Web and RD Gateway endpoints must be located on the same machine, and with a common
root. RD Web and RD Gateway are published as a single application with Application Proxy so that you can
have a single sign-on experience between the two applications.
You should already have deployed RDS, and enabled Application Proxy.
This scenario assumes that your end users go through Internet Explorer on Windows 7 or Windows 10
desktops that connect through the RD Web page. If you need to support other operating systems, see
Support for other client configurations.
When publishing RD Web, it is recommended to use the same internal and external FQDN. If the internal
and external FQDNs are different then you should disable Request Header Translation to avoid the client
receiving invalid links.
On Internet Explorer, enable the RDS ActiveX add-on.
Deploy the joint RDS and Application Proxy scenario

After setting up RDS and Azure AD Application Proxy for your environment, follow the steps to combine the two
solutions. These steps walk through publishing the two web-facing RDS endpoints (RD Web and RD Gateway) as
applications, and then directing traffic on your RDS to go through Application Proxy.
Publish the RD host endpoint
1. Publish a new Application Proxy application with the following values:
Internal URL: https://\<rdhost\>.com/ , where \<rdhost\> is the common root that RD Web and RD
Gateway share.
External URL: This field is automatically populated based on the name of the application, but you can
modify it. Your users will go to this URL when they access RDS.
Preauthentication method: Azure Active Directory
Translate URL headers: No
2. Assign users to the published RD application. Make sure they all have access to RDS, too.
3. Leave the single sign-on method for the application as Azure AD single sign-on disabled. Your users are
asked to authenticate once to Azure AD and once to RD Web, but have single sign-on to RD Gateway.
4. Go to Azure Active Directory > App Registrations > Your application > Settings.
5. Select Properties and update the Home-page URL field to point to your RD Web endpoint (like
https://\<rdhost\>.com/RDWeb ).
Direct RDS traffic to Application Proxy

Connect to the RDS deployment as an administrator and change the RD Gateway server name for the
deployment. This configuration ensures that connections go through the Azure AD Application Proxy service.
1. Connect to the RDS server running the RD Connection Broker role.
2. Launch Server Manager.
3. Select Remote Desktop Services from the pane on the left.
4. Select Overview.
5. In the Deployment Overview section, select the drop-down menu and choose Edit deployment properties.
6. In the RD Gateway tab, change the Server name field to the External URL that you set for the RD host
endpoint in Application Proxy.
7. Change the Logon method field to Password Authentication.
8. Run this command for each collection. Replace <yourcollectionname> and <proxyfrontendurl> with your
own information. This command enables single sign-on between RD Web and RD Gateway, and optimizes
performance:
Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-

authentication server address:s:<proxyfrontendurl>`nrequire pre-authentication:i:1"
For example:
Set-RDSessionCollectionConfiguration -CollectionName "QuickSessionCollection" -CustomRdpProperty "pre-
authentication server address:s:https://remotedesktoptest-aadapdemo.msappproxy.net/`nrequire pre-
authentication:i:1"
NOTE
The above command uses a backtick in "`nrequire".
9. To verify the modification of the custom RDP properties as well as view the RDP file contents that will be
downloaded from RDWeb for this collection, run the following command:
(get-wmiobject -Namespace root\cimv2\terminalservices -Class

Win32_RDCentralPublishedRemoteDesktop).RDPFileContents
Now that you've configured Remote Desktop, Azure AD Application Proxy has taken over as the internet-facing
component of RDS. You can remove the other public internet-facing endpoints on your RD Web and RD Gateway
machines.
Test the scenario

Test the scenario with Internet Explorer on a Windows 7 or 10 computer.
1. Go to the external URL you set up, or find your application in the MyApps panel.
2. You are asked to authenticate to Azure Active Directory. Use an account that you assigned to the application.
3. You are asked to authenticate to RD Web.
4. Once your RDS authentication succeeds, you can select the desktop or application you want, and start working.
Support for other client configurations

The configuration outlined in this article is for users on Windows 7 or 10, with Internet Explorer plus the RDS
ActiveX add-on. If you need to, however, you can support other operating systems or browsers. The difference is in
the authentication method that you use.
AUTHENTICATION METHOD SUPPORTED CLIENT CONFIGURATION
Pre-authentication Windows 7/10 using Internet Explorer + RDS ActiveX add-on
Passthrough Any other operating system that supports the Microsoft

Remote Desktop application
The pre-authentication flow offers more security benefits than the passthrough flow. With pre-authentication you
can use Azure AD authentication features like single sign-on, conditional access, and two-step verification for your
on-premises resources. You also ensure that only authenticated traffic reaches your network.
To use passthrough authentication, there are just two modifications to the steps listed in this article:
1. In Publish the RD host endpoint step 1, set the Preauthentication method to Passthrough.
2. In Direct RDS traffic to Application Proxy, skip step 8 entirely.
Next steps
Enable remote access to SharePoint with Azure AD Application Proxy
Security considerations for accessing apps remotely by using Azure AD Application Proxy
Enable remote access to SharePoint with Azure AD
Application Proxy
This article discusses how to integrate an on-premises SharePoint server with Azure Active Directory (Azure AD )
Application Proxy.
To enable remote access to SharePoint with Azure AD Application Proxy, follow the sections in this article step by
step.
Prerequisites
This article assumes that you already have SharePoint 2013 or newer in your environment. In addition, consider
the following prerequisites:
SharePoint includes native Kerberos support. Therefore, users who are accessing internal sites remotely
through Azure AD Application Proxy can assume to have a single sign-on (SSO ) experience.
This scenario includes configuration changes to your SharePoint server. We recommend using a staging
environment. This way, you can make updates to your staging server first, and then facilitate a testing cycle
before going into production.
We require SSL on the published URL. SSL is also required on the internal URL to ensure that links are
sent/mapped correctly.
Step 1: Configure Kerberos Constrained Delegation (KCD)

For on-premises applications that use Windows authentication, you can achieve single sign-on (SSO ) with the
Kerberos authentication protocol and a feature called Kerberos constrained delegation (KCD ). KCD, when
configured, allows the Application Proxy connector to obtain a Windows token for a user, even if the user hasn’t
signed in to Windows directly. To learn more about KCD, see Kerberos Constrained Delegation Overview.
To set up KCD for a SharePoint server, use the procedures in the following sequential sections:
Ensure that SharePoint web application is running under a domain account
First, make sure that SharePoint web application is running under a domain account--not local system, local
service, or network service. Do this so that you can attach service principal names (SPNs) to this account. SPNs
are how the Kerberos protocol identifies different services. And you will need the account later to configure the
KCD.
NOTE
You need to have a previously created Azure AD account for the service. We suggest that you allow for an automatic
password change. For more information about the full set of steps and troubleshooting issues, see Configure automatic
password change in SharePoint.
To ensure that your sites are running under a defined service account, perform the following steps:
1. Open the SharePoint Central Administration site.
2. Go to Security and select Configure service accounts.
3. Select Web Application Pool - SharePoint - 80. The options may be slightly different based on the
name of your web pool, or if the web pool uses SSL by default.
4. If Select an account for this component field is set to Local Service or Network Service, you need to
create an account. If not, you're finished and can move to the next section.
5. Select Register new managed account. After your account is created, you must set Web Application Pool
before you can use the account.
Set a service principal name for the SharePoint service account
Before you configure KCD, you need to:
Identify the domain account running the SharePoint web application that Azure AD Proxy will expose.
Choose an Internal URL that will be configured in both Azure AD Proxy and SharePoint. This Internal URL
must not already be used in the web application, and will never appear in the web browser.
Assuming the internal URL chosen is https://sharepoint, then the SPN is:
HTTP/SharePoint
NOTE
Please respect the following recommendations for the internal URL:
Use HTTPS
Do not use custom ports
In the DNS, create a Host (A) to point to SharePoint WFE (or load balancer), and not an Alias (CName)
To register this SPN, run the following command from the command prompt as an administrator of the domain:
setspn -S HTTP/SharePoint demo\spAppPoolAccount
This command sets the SPN HTTP/SharePoint for the SharePoint application pool account
demo\spAppPoolAccount.
Replace HTTP/SharePoint with the SPN for your internal URL and demo\spAppPoolAccount with the application
pool account in your environment. The Setspn command searches for the SPN before it adds it. In it already
exists, you will see a Duplicate SPN Value error. In this case, consider to remove the existing SPN if it's not set
under the correct application pool account.
You can verify that the SPN was added by running the Setspn command with the -L option. To learn more about
this command, see Setspn.
Ensure that the connector is trusted for delegation to the SPN added to the SharePoint application pool
account
Configure the KCD so that the Azure AD Application Proxy service can delegate user identities to the SharePoint
application pool account. Configure KCD by enabling the Application Proxy connector to retrieve Kerberos tickets
for your users who have been authenticated in Azure AD. Then that server passes the context to the target
application, or SharePoint in this case.
To configure the KCD, repeat the following steps for each connector machine:
1. Log in as a domain administrator to a DC, and then open Active Directory Users and Computers.
2. Find the computer that the connector is running on. In this example, it's the same SharePoint server.
3. Double-click the computer, and then click the Delegation tab.
4. Ensure that the delegation settings are set to Trust this computer for delegation to the specified services
only. Then, select Use any authentication protocol.
5. Click the Add button, click Users or Computers, and locate the SharePoint application pool account, for
example demo\spAppPoolAccount.
6. In the list of SPNs, select the one that you created earlier for the service account.
7. Click OK. Click OK again to save the changes.
Step 2: Configure Azure AD Proxy

Now that you’ve configured KCD, you're ready to configure Azure AD Application Proxy.
1. Publish your SharePoint site with the following settings. For step-by-step instructions, see Publishing
applications using Azure AD Application Proxy.
Internal URL: SharePoint Internal URL that was chosen earlier, such as https://SharePoint/.
Pre-authentication Method: Azure Active Directory
Translate URL in Headers: NO
TIP
SharePoint uses the Host Header value to look up the site. It also generates links based on this value. The net effect
is that any link that SharePoint generates is a published URL that is correctly set to use the external URL. Setting the
value to YES also enables the connector to forward the request to the back-end application. However, setting the
value to NO means that the connector will not send the internal host name. Instead, the connector sends the host
header as the published URL to the back-end application.
2. Once your app is published, configure the single sign-on settings with the following steps:
a. On the application page in the portal, select Single sign-on.
b. For Single Sign-on Mode, select Integrated Windows Authentication.
c. Set Internal Application SPN to the value that you set earlier. For this example, that would be
HTTP/SharePoint.
d. In "Delegated Login Identity", select On-premises SAM account name.
3. To finish setting up your application, go to the Users and groups section and assign users to access this
application.
Step 3: Configure SharePoint to use Kerberos and Azure AD Proxy
URLs
Next step is to extend SharePoint web application to a new zone, configured with Kerberos and the appropriate
alternate access mapping to allow SharePoint to handle incoming requests sent to the Internal URL, and respond
with links built for the External URL.
1. Start the SharePoint Management Shell.
2. Run the following script to extend the web application to Extranet zone and enable Kerberos
authentication:
# Replace "http://spsites/" with the URL of your web application

# Replace "https://sharepoint-f128.msappproxy.net/" with the External URL in your Azure AD proxy
application
$winAp = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos:$false
Get-SPWebApplication "http://spsites/" | New-SPWebApplicationExtension -Name "SharePoint - AAD Proxy" -
SecureSocketsLayer -Zone "Extranet" -Url "https://sharepoint-f128.msappproxy.net/" -
AuthenticationProvider $winAp
3. Open the SharePoint Central Administration site.

4. Under System Settings, select Configure Alternate Access Mappings. The Alternate Access Mappings box
opens.
5. Select your site, for example SharePoint - 80. For the moment, Extranet zone doesn't have the Internal
URL properly set yet:
6. Click Add Internal URLs.

7. In URL protocol, host and port textbox, type the Internal URL configured in Azure AD proxy, for example
https://SharePoint/.
8. Select Zone Extranet in the drop-down list.
9. Click Save.
10. The Alternate Access Mappings should now look like this:
Step 4: Ensure that an HTTPS certificate is configured for the IIS site of
the Extranet zone
SharePoint configuration is now finished, but since the Internal URL of the Extranet zone is https://SharePoint/, a
certificate must be set for this site.
1. Open Windows PowerShell console.
2. Run the following script to generate a self-signed certificate and add it to the computer MY store:
# Replace "SharePoint" with the actual hostname of the Internal URL of your Azure AD proxy application
New-SelfSignedCertificate -DnsName "SharePoint" -CertStoreLocation "cert:\LocalMachine\My"
NOTE
Self-signed certificates are suitable only for test purposes. In production environments, it is strongly recommended
to use certificates issued by a certificate authority instead.
3. Open "Internet Information Services Manager" console.

4. Expand the server in the tree view, expand "Sites", select the site "SharePoint - AAD Proxy" and click on
Bindings.
5. Select https binding and click Edit....
6. In SSL certificate field, choose SharePoint certificate and click OK.
You can now access the SharePoint site externally via Azure AD Application Proxy.
Next steps
Working with custom domains in Azure AD Application Proxy
Access your on-premises applications through
Microsoft Teams
Azure Active Directory Application Proxy gives you single sign-on to on-premises applications no matter where
you are. Microsoft Teams streamlines your collaborative efforts in one place. Integrating the two together means
that your users can be productive with their teammates in any situation.
Your users can add cloud apps to their Teams channels using tabs, but what about the SharePoint sites or planning
tool that are hosted on-premises? Application Proxy is the solution. They can add apps published through
Application Proxy to their channels using the same external URLs they always use to access their apps remotely.
And because Application Proxy authenticates through Azure Active Directory, your users get a single sign-on
experience.
Install the Application Proxy connector and publish your app

If you haven't already, configure Application Proxy for your tenant and install the connector. Then, publish your on-
premises application for remote access. When you're publishing the app, make note of the external URL because
it's used to add the app to Teams.
If you already have your apps published but don't remember their external URLs, look them up in the Azure portal.
Sign in, then navigate to Azure Active Directory > Enterprise applications > All applications > select your
app > Application proxy.
Add your app to Teams

Once you publish the app through Application Proxy, let your users know that they can add it as a tab directly in
their Teams channels, and then the app is available for everyone in the team to use. Have them follow these three
steps:
1. Navigate to the Teams channel where you want to add this app and select + to add a tab.
2. Select Website from the tab options.

3. Give the tab a name and set the URL to the Application Proxy external URL.
Once one member of a team adds the tab, it shows up for everyone in the channel. Any users who have access to
the app get single sign-on access with the credentials they use for Microsoft Teams. Any users who don't have
access to the app can see the tab in Teams, but are blocked until you give them permissions to the on-premises app
and the Azure portal published version of the app.
Next steps
Learn how to publish on-premises SharePoint sites with Application Proxy.
Configure your apps to use custom domains for their external URL.
Azure Active Directory Application Proxy and Tableau
Azure Active Directory Application Proxy and Tableau have partnered to ensure you are easily able to use
Application Proxy to provide remote access for your Tableau deployment. This article explains how to configure
this scenario.
Prerequisites
The scenario in this article assumes that you have:
Tableau configured.
An Application Proxy connector installed.
Enabling Application Proxy for Tableau

Application Proxy supports the OAuth 2.0 Grant Flow, which is required for Tableau to work properly. This means
that there are no longer any special steps required to enable this application, other than configuring it by following
the publishing steps below.
Publish your applications in Azure

To publish Tableau, you need to publish an application in the Azure Portal.
For:
Detailed instructions of steps 1-8, see Publish applications using Azure AD Application Proxy.
Information about how to find Tableau values for the App Proxy fields, please see the Tableau documentation.
To publish your app:
1. Sign in to the Azure portal as a global administrator.
2. Select Azure Active Directory > Enterprise applications.
3. Select Add at the top of the blade.
4. Select On-premises application.
5. Fill out the required fields with information about your new app. Use the following guidance for the settings:
Internal URL: This application should have an internal URL that is the Tableau URL itself. For
example, https://adventure-works.tableau.com .
Pre-authentication method: Azure Active Directory (recommended but not required).
6. Select Add at the top of the blade. Your application is added, and the quick start menu opens.
7. In the quick start menu, select Assign a user for testing, and add at least one user to the application. Make
sure this test account has access to the on-premises application.
8. Select Assign to save the test user assignment.
9. (Optional) On the app management page, select Single sign-on. Choose Integrated Windows
Authentication from the drop-down menu, and fill out the required fields based on your Tableau
configuration. Select Save.
Testing
Your application is now ready to test. Access the external URL you used to publish Tableau, and login as a user
assigned to both applications.
Next steps
For more information about Azure AD Application Proxy, see How to provide secure remote access to on-premises
applications.
Application Proxy and Qlik Sense
Azure Active Directory Application Proxy and Qlik Sense have partnered together to ensure you are easily able to
use Application Proxy to provide remote access for your Qlik Sense deployment.
Prerequisites
The remainder of this scenario assumes you done the following:
Configured Qlik Sense.
Installed an Application Proxy connector
Publish your applications in Azure

To publish QlikSense, you will need to publish two applications in Azure.
Application #1:
Follow these steps to publish your app. For a more detailed walkthrough of steps 1-8, see Publish applications
using Azure AD Application Proxy.
5. Fill out the required fields with information about your new app. Use the following guidance for the settings:
Internal URL: This application should have an internal URL that is the QlikSense URL itself. For
example, https://demo.qlikemm.com:4244
Pre-authentication method: Azure Active Directory (Recommended but not required)
6. Select Add at the bottom of the blade. Your application is added, and the quick start menu opens.
9. (Optional) On the app management blade, select Single sign-on. Choose Kerberos Constrained Delegation
from the drop-down menu, and fill out the required fields based on your Qlik configuration. Select Save.
Application #2:
Follow the same steps as for Application #1, with the following exceptions:
Step #5: The Internal URL should now be the QlikSense URL with the authentication port used by the application.
The default is 4244 for HTTPS, and 4248 for HTTP. Ex: https://demo.qlik.com:4244
Step #10: Don’t set up SSO, and leave the Single sign-on disabled
Testing
Your application is now ready to test. Access the external URL you used to publish QlikSense in Application #1, and
login as a user assigned to both applications.
Additional references
For more information about publishing Qlik Sense with Application Proxy, refer to the Qlik Community Article:
Azure AD with Integrated Windows Authentication using a Kerberos Constrained Delegation with Qlik Sense.
Next steps
Publish applications with Application Proxy
Working with Application Proxy connectors
Application page does not display correctly for an
Application Proxy application
This article helps you troubleshoot issues with Azure Active Directory Application Proxy applications when you
navigate to the page, but something on the page doesn't look correct.
Overview
When you publish an Application Proxy app, only pages under your root are accessible when accessing the
application. If the page isn’t displaying correctly, the root internal URL used for the application may be missing
some page resources. To resolve, make sure you have published all the resources for the page as part of your
application.
You can verify if missing resources is the issue by opening your network tracker (such as Fiddler, or F12 tools in
Internet Explorer/Microsoft Edge), loading the page, and looking for 404 errors. That indicates the pages currently
cannot be found and that you need to publish them.
As an example of this case, assume you have published an expenses application using the internal URL
http://myapps/expenses, but the app uses the stylesheet http://myapps/style.css. In this case, the stylesheet is not
published in your application, so loading the expenses app throw a 404 error while trying to load style.css. In this
example, the problem is resolved by publishing the application with an internal URL http://myapp/.
Problems with publishing as one application

If it is not possible to publish all resources within the same application, you need to publish multiple applications
and enable links between them.
To do so, we recommend using the custom domains solution. However, this solution requires that you own the
certificate for your domain and your applications use fully qualified domain names (FQDNs). For other options,
see the troubleshoot broken links documentation.
Next steps
Publish applications using Azure AD Application Proxy
An Application Proxy application takes too long to
load
This article helps you to understand why an Azure AD Application Proxy application may take a long time to load.
It also explains what you can do to resolve this issue.
Overview
Although your applications are working, they can experience a long latency. There might be network topology
tweaks that you can make to improve speed. For an evaluation of different topologies, see the network
considerations document.
Besides network topology, there are currently no further recommendations for performance tuning. As the
Application Proxy service expands it might come to a data center that is physically closer. The closer proximity
might help with latency. For a list of Azure data centers, see the latency test page.
The data centers with the Application Proxy service can be found with the Connector Ports Test Tool.
Feedback on Application Proxy data center locations

There may be Azure data centers that don’t yet include Application Proxy, but would lead to a great latency
improvement for you. Send the data center location to aadapfeedback@microsoft.com. Microsoft uses your
feedback for expansion plans.
Microsoft is working on additional capabilities to improve latency. As soon as these improvements are available,
the documentation will be updated.
Next steps
Links on the page don't work for an Application Proxy
application
This article helps you troubleshoot why links on your Azure Active Directory Application Proxy application don't
work correctly.
Overview
After publishing an Application Proxy app, the only links that work by default in the application are links to
destinations contained within the published root URL. The links within the applications aren’t working, the internal
URL for the application probably does not include all the destinations of links within the application.
Why does this happen? When clicking a link in an application, Application Proxy tries to resolve the URL as
either an internal URL within the same application, or as an externally available URL. If the link points to an
internal URL that is not within the same application, it does not belong to either of these buckets and result in a
not found error.
Ways you can resolve broken links

There are three ways to resolve this issue. The choices below are in listed in increasing complexity.
1. Make sure the internal URL is a root that contains all the relevant links for the application. This allows all
links to be resolved as content published within the same application.
If you change the internal URL but don’t want to change the landing page for users, change the Home page
URL to the previously published internal URL. This can be done by going to “Azure Active Directory” ->
App Registrations -> select the application -> Properties. In this properties tab, you see the field “Home
Page URL”, which you can adjust to be the desired landing page.
2. If your applications use fully qualified domain names (FQDNs), use custom domains to publish your
applications. This feature allows the same URL to be used both internally and externally.
This option ensures that the links in your application are externally accessible through Application Proxy
since the links within the application to internal URLs are also recognized externally. All links still need to
belong to a published application. However, with this option the links do not need to belong to the same
application and can belong to multiple applications.
3. If neither of these options are feasible, there are multiple options for enabling inline link translation. These
options include using the Intune Managed Browser, My Apps extension, or using the link translation setting
on your application. To learn more about each of these options and how to enable them, see Redirect
hardcoded links for apps published with Azure AD Application Proxy.
Next steps
How to open the firewall ports required for an
To see a full list of the required ports and the function of each port, see the prerequisites section of the Application
Proxy documentation. note that Application Proxy only uses outbound ports.
You can also check whether you have all the required ports open by opening the Connector Ports Test Tool from
your on premises network. More green checkmarks means greater resiliency.
App Proxy regions

We are working on a way to let you know which of these regions needs to be green for you. For now, make sure
they all are. Central US is also required regardless of which region you are in.
To make sure the tool gives you the right results, be sure to:
Open the tool on a browser from the server where you have installed the Connector.
Ensure that any proxies or firewalls applicable to your Connector are also applied to this page. This can be
done in Internet Explorer by going to Settings -> Internet Options -> Connections -> LAN Settings.
On this page, you see the field “Use a Proxy Server for your LAN”. Select this box, and put the proxy address
into the “Address” field.
Next steps
No working connector group found for an
This article helps to resolve the common issues faced when there is not a connector detected for an Application
Proxy application integrated with Azure Active Directory.
Overview of steps
If there is no working Connector in a Connector Group for your application, there are a few ways to resolve the
problem:
If you have no connectors in the group, you can:
Download a new Connector on the right on premises server, and assign it to this group
Move an active Connector into the group
If you have no active connectors in the group, you can:
Identify the reason your Connector is inactive and resolve
Move an active Connector into the group
To figure out the issue, open the “Application Proxy” menu in your Application, and look at the Connector Group
warning message. If there are no connectors in the group, the warning message specifies the group needs at least
one Connector. If you have no active Connectors, the warning message explains that. It is common to have inactive
Connectors.
For details on each of these options, see the corresponding section below. The instructions assume that you are
starting from the Connector management page. If you are looking at the error message above, you can go to this
page by clicking on the warning message. You can also get to the page by going to Azure Active Directory,
clicking on Enterprise Applications, then Application Proxy.
Download a new Connector
To download a new Connector, use the “Download Connector” button at the top of the page.
Install the connector on a machine with direct line of sight to the backend application. Typically, the connector is
installed on the same server as the application. After downloading, the Connector should appear in this menu. click
the Connector, and use the “Connector Group” drop-down to make sure it belongs to the right group. Save the
change.
Move an Active Connector
If you have an active Connector that should belong to the group and has line of sight to the target backend
application, you can move the Connector into the assigned group. To do so, click the Connector. In the “Connector
Group” field, use the drop-down to select the correct group, and click Save.
Resolve an inactive Connector

If the only Connectors in the group are inactive, they are likely on a machine that does not have all the necessary
ports unblocked.
see the ports Troubleshoot document for details on investigating this problem.
Next steps
How to configure an Application Proxy application
This article help you to understand how to configure an Application Proxy application within Azure AD to expose
your on-premises applications to the cloud.
Recommended documents
To learn about the initial configurations and creation of an Application Proxy application through the Admin Portal,
follow the Publish applications using Azure AD Application Proxy.
For details on configuring Connectors, see Enable Application Proxy in the Azure portal.
For information on uploading certificates and using custom domains, see Working with custom domains in Azure
AD Application Proxy.
Create the Application/Setting the URLs

If you are following the steps in the Publish applications using Azure AD Application Proxy documentation and are
getting an error creating the application, see the error details for information and suggestions for how to fix the
application. Most error messages include a suggested fix. To avoid common errors, verify:
You are an administrator with permission to create an Application Proxy application
The internal URL is unique
The external URL is unique
The URLs start with http or https, and end with a “/”
The URL should be a domain name, not an IP address
The error message should display in the top right corner when you create the application. You can also select the
notification icon to see the error messages.
Configure connectors/connector groups

If you are having difficulty configuring your application because of warning about the connectors and connector
groups, see instructions on enabling Application Proxy for details on how to download connectors. If you want to
learn more about connectors, see the connectors documentation.
If your connectors are inactive, this means that they are unable to reach the service. This is often because all the
required ports are not open. To see a list of required ports, see the pre-requisites section of the enabling
Application Proxy documentation.
Upload certificates for custom domains

Custom Domains allow you to specify the domain of your external URLs. To use custom domains, you need to
upload the certificate for that domain. For information on using custom domains and certificates, see Working with
custom domains in Azure AD Application Proxy.
If you are encountering issues uploading your certificate, look for the error messages in the portal for additional
information on the problem with the certificate. Common certificate problems include:
Expired certificate
Certificate is self-signed
Certificate is missing the private key
The error message display in the top right corner as you try to upload the certificate. You can also select the
Next steps
Publish applications using Azure AD Application Proxy
How to configure single sign-on to an Application
Proxy application
Single sign-on (SSO ) allows your users to access an application without authenticating multiple times. It allows the
single authentication to occur in the cloud, against Azure Active Directory, and allows the service or Connector to
impersonate the user to complete any additional authentication challenges from the application.
How to configure single-sign on

To configure SSO, first make sure that your application is configured for Pre-Authentication through Azure Active
Directory. To do this configuration, go to Azure Active Directory -> Enterprise Applications -> All
Applications -> Your application -> Application Proxy. On this page, you see the “Pre Authentication” field, and
make sure that is set to “Azure Active Directory.
For more information on the Pre-Authentication methods, see step 4 of the app publishing document.
Configuring single sign-on modes for Application Proxy Applications

Configure the specific type of single sign-on. The sign-on methods are classified based on what type of
authentication the backend application uses. App Proxy applications support three types of sign-on:
Password-based Sign-On: Password-based sign-on can be used for any application that uses username
and password fields to sign on. Configuration steps are in Configure password Single sign-on for an Azure
AD gallery application.
Integrated Windows Authentication: For applications using Integrated Windows Authentication (IWA),
single sign-on is enabled through Kerberos Constrained Delegation (KCD ). This method gives Application
Proxy Connectors permission in Active Directory to impersonate users, and to send and receive tokens on
their behalf. Details on configuring KCD can be found in the Single Sign-On with KCD documentation.
Header-based Sign-On: Header-based sign-on is enabled through a partnership and does require some
additional configuration. For details on the partnership and step-by-step instructions for configuring single
sign-on to an application that uses headers for authentication, see the PingAccess for Azure AD
documentation.
Each of these options can be found by going to your application in “Enterprise Applications”, and opening the
Single Sign-On page on the left menu. note that if your application was created in the old portal, you may not see
all these options.
On this page, you also see one additional Sign-On option: Linked Sign-On. This option is also supported by
Application Proxy. However, this option does not add single sign-on to the application. That said the application
may already have single sign-on implemented using another service such as Active Directory Federation Services.
This option allows an admin to create a link to an application that users first land on when accessing the
application. For example, if there is an application that is configured to authenticate users using Active Directory
Federation Services 2.0, an administrator can use the “Linked Sign-On” option to create a link to it on the access
panel.
Next steps
Provide single sign-on to your apps with Application Proxy
Problem creating an Application Proxy application
Below are some of the common issues people face when creating a new application proxy application.
Recommended documents
To learn more about creating an Application Proxy application through the Admin Portal, see Publish applications
If you are following the steps in that document and are getting an error creating the application, see the error
details for information and suggestions for how to fix the application. Most error messages include a suggested fix.
Specific things to check

To avoid common errors, verify:
You are an administrator with permission to create an Application Proxy application
The internal URL is unique
The external URL is unique
The URLs start with http or https, and end with a “/”
The URL should be a domain name and not an IP address
The error message should display in the top right corner when you create the application. You can also select the
Next steps
Enable Application Proxy in the Azure portal
Troubleshoot Kerberos constrained delegation
configurations for Application Proxy
The methods available for achieving SSO to published applications can vary from one application to another. One
option that Azure Active Directory (Azure AD ) Application Proxy offers by default is Kerberos constrained
delegation (KCD ). You can configure a connector, for your users, to run constrained Kerberos authentication to
back-end applications.
The procedure for enabling KCD is straightforward. It requires no more than a general understanding of the
various components and authentication flow that support SSO. But sometimes, KCD SSO doesn’t function as
expected. You need good sources of information to troubleshoot these scenarios.
This article provides a single point of reference that helps troubleshoot and self-remediate some of the most
common issues. It also covers diagnosis of more complex implementation problems.
This article makes the following assumptions:
Deployment of Azure AD Application Proxy per Get started with Application Proxy and general access to
non-KCD applications work as expected.
The published target application is based on Internet Information Services (IIS ) and the Microsoft
implementation of Kerberos.
The server and application hosts reside in a single Azure Active Directory domain. For detailed information
on cross-domain and forest scenarios, see the KCD white paper.
The subject application is published in an Azure tenant with pre-authentication enabled. Users are expected
to authenticate to Azure via forms-based authentication. Rich client authentication scenarios aren't covered
by this article. They might be added at some point in the future.
Prerequisites
Azure AD Application Proxy can be deployed into many types of infrastructures or environments. The
architectures vary from organization to organization. The most common causes of KCD -related issues aren't the
environments. Simple misconfigurations or general mistakes cause most issues.
For this reason, it's best to make sure you've met all the prerequisites in Using KCD SSO with the Application
Proxy before you start troubleshooting. Note the section on configuring Kerberos constrained delegation on
2012R2. This process employs a different approach to configuring KCD on previous versions of Windows. Also, be
mindful of these considerations:
It's not uncommon for a domain member server to open a secure channel dialog with a specific domain
controller (DC ). Then the server might move to another dialog at any given time. So connector hosts aren't
restricted to communication with only specific local site DCs.
Cross-domain scenarios rely on referrals that direct a connector host to DCs that might be outside of the
local network perimeter. In these cases, it's equally important to also send traffic onward to DCs that
represent other respective domains. If not, delegation fails.
Where possible, avoid placing any active IPS or IDS devices between connector hosts and DCs. These
devices are sometimes overintrusive and interfere with core RPC traffic.
Test delegation in simple scenarios. The more variables you introduce, the more you might have to contend with.
To save time, limit your testing to a single connector. Add additional connectors after the issue has been resolved.
Some environmental factors might also contribute to an issue. To avoid these factors, minimize architecture as
much as possible during testing. For example, misconfigured internal firewall ACLs are common. If possible, send
all traffic from a connector straight through to the DCs and back-end application.
The best place to position connectors is as close as possible to their targets. A firewall that sits inline when testing
adds unnecessary complexity and can prolong your investigations.
What shows a KCD problem? There are several common indications that KCD SSO is failing. The first signs of an
issue appear in the browser.
Both of these images show the same symptom: SSO failure. User access to the application is denied.
Troubleshooting
How you troubleshoot depends on the issue and the symptoms you observe. Before you go any farther, explore
the following articles. They provide useful troubleshooting information:
Troubleshoot Application Proxy problems and error messages
Kerberos errors and symptoms
Working with SSO when on-premises and cloud identities aren't identical
If you got to this point, then your main issue exists. To start, separate the flow into the following three stages that
you can troubleshoot.
Client pre -authentication
The external user authenticating to Azure via a browser. The ability to pre-authenticate to Azure is necessary for
KCD SSO to function. Test and address this ability if there are any issues. The pre-authentication stage isn't related
to KCD or the published application. It's easy to correct any discrepancies by sanity checking that the subject
account exists in Azure. Also check that it's not disabled or blocked. The error response in the browser is
descriptive enough to explain the cause. If you're uncertain, check other Microsoft troubleshooting articles to
verify.
Delegation service
The Azure Proxy connector that gets a Kerberos service ticket for users from a Kerberos Key Distribution Center
(KCD ).
The external communications between the client and the Azure front end have no bearing on KCD. These
communications only make sure that KCD works. The Azure Proxy service is provided a valid user ID that is used
to get a Kerberos ticket. Without this ID, KCD isn't possible and fails.
As mentioned previously, the browser error messages provides some good clues about why things fail. Make sure
to note down the activity ID and timestamp in the response. This information helps you correlate the behavior to
actual events in the Azure Proxy event log.
The corresponding entries seen in the event log show as events 13019 or 12027. Find the connector event logs in
Applications and Services Logs > Microsoft > AadApplicationProxy > Connector > Admin.
1. Use an A record in your internal DNS for the application’s address, not a CName.
2. Reconfirm that the connector host has been granted the right to delegate to the designated target account’s
SPN. Reconfirm that Use any authentication protocol is selected. For more information, see the SSO
configuration article.
3. Verify that there's only one instance of the SPN in existence in Azure AD. Issue setspn -x from a
command prompt on any domain member host.
4. Check that a domain policy is enforced that limits the maximum size of issued Kerberos tokens. This policy
stops the connector from getting a token if it's found to be excessive.
A network trace that captures the exchanges between the connector host and a domain KDC is the next best step
to get more low -level detail on the issues. For more information, see the deep dive Troubleshoot paper.
If ticketing looks good, you see an event in the logs stating that authentication failed because the application
returned a 401. This event indicates that the target application rejected your ticket. Go to the next stage.
Target application
The consumer of the Kerberos ticket provided by the connector. At this stage, expect the connector to have sent a
Kerberos service ticket to the back end. This ticket is a header in the first application request.
1. By using the application’s internal URL defined in the portal, validate that the application is accessible
directly from the browser on the connector host. Then you can sign in successfully. Details can be found on
the connector Troubleshoot page.
2. Still on the connector host, confirm that the authentication between the browser and the application uses
Kerberos. Take one of the following actions:
3. Run DevTools (F12) in Internet Explorer, or use Fiddler from the connector host. Go to the application by
using the internal URL. Inspect the offered WWW authorization headers returned in the response from the
application to make sure that either negotiate or Kerberos is present.
The next Kerberos blob that is returned in the response from the browser to the application starts
with YII. These letters tell you that Kerberos is running. Microsoft NT LAN Manager (NTLM ), on the
other hand, always starts with TlRMTVNTUAAB, which reads NTLM Security Support Provider
(NTLMSSP ) when decoded from Base64. If you see TlRMTVNTUAAB at the start of the blob,
Kerberos is not available. If you don’t see TlRMTVNTUAAB, Kerberos is likely available.
NOTE
If you use Fiddler, this method requires that you temporarily disable extended protection on the application’s
configuration in IIS.
The blob in this figure doesn't start with TIRMTVNTUAAB. So in this example, Kerberos is
available, and the Kerberos blob doesn’t start with YII.
4. Temporarily remove NTLM from the providers list on the IIS site. Access the app directly from Internet
Explorer on the connector host. NTLM is no longer in the providers list. You can access the application by
using Kerberos only. If access fails, there might be a problem with the application’s configuration. Kerberos
authentication isn't functioning.
If Kerberos isn't available, check the application’s authentication settings in IIS. Make sure
Negotiate is listed at the top, with NTLM just beneath it. If you see Not Negotiate, Kerberos or
Negotiate, or PKU2U, continue only if Kerberos is functional.
With Kerberos and NTLM in place, temporarily disable pre-authentication for the application in the
portal. Try to access it from the internet by using the external URL. You're prompted to authenticate.
You're able to do so with the same account used in the previous step. If not, there's a problem with
the back-end application, not KCD.
Re-enable pre-authentication in the portal. Authenticate through Azure by attempting to connect to
the application via its external URL. If SSO fails, you see a forbidden error message in the browser
and event 13022 in the log:
Microsoft AAD Application Proxy Connector cannot authenticate the user because the backend
server responds to Kerberos authentication attempts with an HTTP 401 error.
Check the IIS application. Make sure that the configured application pool and the SPN are
configured to use the same account in Azure AD. Navigate in IIS as shown in the following
illustration:
After you know the identity, make sure this account is configured with the SPN in question. An
example is setspn –q http/spn.wacketywack.com . Enter the following text in a command prompt:
Check the SPN defined against the application’s settings in the portal. Make sure that the same SPN
configured against the target Azure AD account is used by the application’s app pool.
Go into IIS and select the Configuration Editor option for the application. Navigate to
system.webServer/security/authentication/windowsAuthentication. Make sure the value
UseAppPoolCredentials is True.
Change this value to True. Remove all cached Kerberos tickets from the back-end server by running
the following command:
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-
Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
For more information, see Purge the Kerberos client ticket cache for all sessions.
If you leave Kernel mode enabled, it improves the performance of Kerberos operations. But it also causes the ticket
for the requested service to be decrypted by using the machine account. This account is also called the Local
system. Set this value to True to break KCD when the application is hosted across more than one server in a farm.
As an additional check, disable Extended protection too. In some scenarios, Extended protection broke
KCD when it was enabled in specific configurations. In those cases, an application was published as a
subfolder of the default website. This application is configured for anonymous authentication only. All the
dialogs are grayed out, which suggests child objects wouldn't inherit any active settings. We recommend
that you test, but don’t forget to restore this value to enabled, where possible.
This additional check puts you on track to use your published application. You can spin up additional
connectors that are also configured to delegate. For more information, read the more in-depth technical
walk-through, Troubleshooting the Azure AD Application Proxy.
If you still can't make progress, Microsoft support can assist you. Create a support ticket directly within the portal.
An engineer will contact you.
Other scenarios
Azure Application Proxy requests a Kerberos ticket before sending its request to an application. Some third-
party applications like Tableau Server don't like this method of authenticating. These applications expect the
more conventional negotiations to take place. The first request is anonymous, which allows the application
to respond with the authentication types that it supports through a 401.
Multi-hop authentication is commonly used in scenarios where an application is tiered, with a back end and
front end, where both require authentication, such as SQL Server Reporting Services. To configure the
multihop scenario, see the support article Kerberos Constrained Delegation May Require Protocol
Transition in Multi-hop Scenarios.
Next steps
Configure KCD on a managed domain.
How to configure an Application Proxy application to
use PingAccess
Our collaboration with PingAccess now allows you to extend the benefits of Application Proxy to applications
using header-based authentication. If your applications do not use headers, see our Single Sign-On documentation
for details on other options.
Overview of steps and recommended documents

To configure an application with PingAccess, there are four steps:
1. Configure Application Proxy Connectors
2. Create an Azure AD Application Proxy Application
3. Download & Configure PingAccess
4. Configure Applications in PingAccess
For details on each of these steps, see our Single Sign-On with Headers documentation.
"Can't Access this Corporate Application" error when
using an Application Proxy application
This article helps you troubleshoot common issues for the "This corporate app can't be accessed" error on an
Azure AD Application Proxy application.
Overview
When you see this error, find the status code on the error page. That code is likely one of the following status
codes:
Gateway Timeout: The Application Proxy service is unable to reach the connector. This error typically
indicates a problem with the connector assignment, connector itself, or the networking rules around the
connector.
Bad Gateway: The connector is unable to reach the backend application. This error could indicate a
misconfiguration of the application.
Forbidden: The user is not authorized to access the application. This error can happen either when the user
is not assigned to the application in Azure Active Directory, or if on the backend the user does not have
permission to access the application.
To find the code, look at the text at the bottom left of the error message for the “Status Code” field. Also look for
any additional tips at the bottom of the page.
For details on how to troubleshoot the root cause of these errors and more details on suggested fixes, see the
corresponding section below.
Gateway Timeout errors

A gateway timeout occurs when the service tries to reach the connector and is unable to within the timeout
window. This error is typically caused by an application assigned to a Connector Group with no working
connectors, or some ports required by the Connector are not open.
Bad Gateway errors
A bad gateway error indicates that the connector is unable to reach the backend application. make sure that you
have published the correct application. Common mistakes that cause this error are:
A typo or mistake in the internal URL
Not publishing the root of the application. For example, publishing http://expenses/reimbursement but
trying to access http://expenses
Problems with the Kerberos Constrained Delegation (KCD ) configuration
Problems with the backend application
Forbidden errors
If you see a forbidden error, the user has not been assigned to the application. This error could be either in Azure
Active Directory or on the backend application.
To learn how to assign users to the application in Azure, see the configuration documentation.
If you confirm the user is assigned to the application in Azure, check the user configuration in the backend
application. If you are using Kerberos Constrained Delegation/Integrated Windows Authentication, see the KCD
Troubleshoot page for guidelines.
Check the application's internal URL

As a first quick step, double check and fix the internal URL by opening the application through Enterprise
Applications, then selecting the Application Proxy menu. Verify the internal URL is the one used from your on
premises network to access the application.
Check the application is assigned to a working Connector Group

To verify the application is assigned to a working Connector Group:
1. Open the application in the portal by going to Azure Active Directory, clicking on Enterprise
Applications, then All Applications. Open the application, then select Application Proxy from the left
menu.
2. Look at the Connector Group field. If there are no active connectors in the group, you see a warning. If you
don’t see any warnings, move on to “verify all required ports are whitelisted”.
3. If the wrong Connector Group is showing, use the drop-down to select the correct group, and confirm you
no longer see any warnings. If the intended Connector Group is showing, click the warning message to open
the page with Connector management.
4. From here, there are a few ways to drill in further:
Move an active Connector into the group: If you have an active Connector that should belong to this
group and has line of sight to the target backend application, you can move the Connector into the
assigned group. To do so, click the Connector. In the “Connector Group” field, use the drop-down to
select the correct group, and click save.
Download a new Connector for that group: From this page, you can get the link to download a new
Connector. Install the Connector on a machine with direct line of sight to the backend application.
Typically, the Connector is installed on the same server as the application. Use the download
Connector link to download a connector onto the target machine. Next, click the Connector, and use
the “Connector Group” drop-down to make sure it belongs to the right group.
Investigate an inactive Connector: If a connector shows as inactive, it is unable to reach the service.
This error is typically due to some required ports being blocked. To solve this issue, move on to
“verify all required ports are whitelisted.”
After using these steps to ensure the application is assigned to a group with working Connectors, test the
application again. If it is still not working, continue to the next section.
Check all required ports are whitelisted

To verify that all required ports are open, see the documentation on opening ports. If all the required ports are
open, move to the next section.
Check for other Connector Errors

If none of the above resolve the issue, the next step is to look for issues or errors with the Connector itself. You can
see some common errors in the Troubleshoot document.
You can also look directly at the Connector logs to identify any errors. Many of the error messages share specific
recommendations for fixes. To view the logs, see the connectors documentation.
Additional Resolutions
If the above didn’t fix the problem, there are a few different possible causes. To identify the issue:
If your application is configured to use Integrated Windows Authentication (IWA), test the application without
single sign-on. If not, move to the next paragraph. To check the application without single sign-on, open your
application through Enterprise Applications, and go to the Single Sign-On menu. Change the drop-down from
“Integrated Windows Authentication” to “Azure AD single sign-on disabled”.
Now open a browser and try to access the application again. You should be prompted for authentication and get
into the application. If you are able to authenticate, the problem is with the Kerberos Constrained Delegation (KCD )
configuration that enables the single sign-on. For more information, see the KCD Troubleshoot page.
If you continue to see the error, go to the machine where the Connector is installed, open a browser and attempt to
reach the internal URL used for the application. The Connector acts like another client from the same machine. If
you can’t reach the application, investigate why that machine is unable to reach the application, or use a connector
on a server that is able to access the application.
If you can reach the application from that machine, to look for issues or errors with the Connector itself. You can
see some common errors in the Troubleshoot document. You can also look directly at the Connector logs to
identify any errors. Many of our error messages be able to share more specific recommendations for fixes. To learn
how to view the logs, see our connectors documentation.
Next steps
Problem installing the Application Proxy Agent
Connector
Microsoft AAD Application Proxy Connector is an internal domain component that uses outbound connections to
establish the connectivity from the cloud available endpoint to the internal domain.
General Problem Areas with Connector installation

When the installation of a connector fails, the root cause is usually one of the following areas:
1. Connectivity – to complete a successful installation, the new connector needs to register and establish
future trust properties. This is done by connecting to the AAD Application Proxy cloud service.
2. Trust Establishment – the new connector creates a self-signed cert and registers to the cloud service.
3. Authentication of the admin – during installation, the user must provide admin credentials to complete
the Connector installation.
Verify connectivity to the Cloud Application Proxy service and

Microsoft Login page
Objective: Verify that the connector machine can connect to the AAD Application Proxy registration endpoint as
well as Microsoft login page.
1. Open a browser and go to the following web page: https://aadap-
portcheck.connectorporttest.msappproxy.net , and verify that the connectivity to Central US and East US
datacenters with ports 80 and 443 is working.
2. If any of those ports is not successful (doesn’t have a green checkmark), verify that the Firewall or backend
proxy has *.msappproxy.net with ports 80 and 443 defined correctly.
3. Open a browser (separate tab) and go to the following web page: https://login.microsoftonline.com, make
sure that you can login to that page.
Verify Machine and backend components support for Application Proxy

trust cert
Objective: Verify that the connector machine, backend proxy and firewall can support the certificate created by
the connector for future trust.
NOTE
The connector tries to create a SHA512 cert that is supported by TLS1.2. If the machine or the backend firewall and proxy
does not support TLS1.2, the installation fail.
To resolve the issue:

1. Verify the machine supports TLS1.2 – All Windows versions after 2012 R2 should support TLS 1.2. If your
connector machine is from a version of 2012 R2 or prior, make sure that the following KBs are installed on
the machine: https://support.microsoft.com/help/2973337/sha512-is-disabled-in-windows-when-you-use-
tls-1.2
2. Contact your network admin and ask to verify that the backend proxy and firewall do not block SHA512 for
outgoing traffic.
Verify admin is used to install the connector

Objective: Verify that the user who tries to install the connector is an administrator with correct credentials.
Currently, the user must be either an application administrator or global administrator for the installation to
succeed.
To verify the credentials are correct:
Connect to https://login.microsoftonline.com and use the same credentials. Make sure the login is successful. You
can check the user role by going to Azure Active Directory -> Users and Groups -> All Users.
Select your user account, then “Directory Role” in the resulting menu. Verify that the selected role is "Application
Administrator" or “Global administrator”. If you are unable to access any of the pages along these steps, you do
not have the required role.
Next steps
Problems signing in to an on-premises application
using the Azure AD application proxy
If you are having problems signing in an on-premises application, you can try following the steps below to
resolving your problem.
I can load my application, but something on the page looks broken

The following documents can help you to resolve some of the most common issues in this category.
I can get to my application, but the application page isn't displaying correctly
I can get to my application, but the application takes too long to load
I can get to my application, but the links on the application page do not work
I'm having a connectivity problem my application

I don't know what ports to open for my application
I encountered a problem because there was no working connector in a connector group for my application
I'm having a problem configuring the Azure AD Application Proxy in

the admin portal
I am having difficulty configuring an application Proxy application
I don't know how to configure single sign-on to my application Proxy application
I encountered a problem when creating my application in admin portal
I'm having a problem setting up back-end authentication to my

application
I don't know how to configure Kerberos Constrained Delegation
I don't know how to configure my application with PingAccess
I'm having a problem when signing in to my application

I get a "Can't Access this Corporate Application" error
I'm having a problem with the Application Proxy Agent Connector

I am having issues installing the Application Proxy Agent Connector
Next steps
How to provide secure remote access to on-premises applications
Find out when a specific user will be able to access an
application
When using automatic user provisioning with an application, Azure AD automatically provision and update user
accounts in an app based on things like user and group assignment at a regularly scheduled time interval, typically
every 10 minutes.
How long does it take?

The time it takes for a given user to be provisioned depends mainly on whether or not an initial “full” sync has
already occurred.
The first sync between Azure AD and an app can take anywhere from 20 minutes to several hours, depending on
the size of the Azure AD directory and the number of users in scope for provisioning.
Subsequent syncs after the initial sync be faster (e.g. within 10 minutes), as the provisioning service stores
watermarks that represent the state of both systems after the initial sync, improving performance of subsequent
syncs.
How to check the status of a user

To see the provisioning status for a selected user, consult the Audit logs in Azure AD.
The provisioning audit logs can be accessed in the Azure portal, in the Azure Active Directory > Enterprise
Apps > [Application Name] > Audit Logs tab. Filter the logs on the Account Provisioning category to only
see the provisioning events for that app. You can search for users based on the “matching ID” that was configured
for them in the attribute mappings.
For example, if you configured the “user principal name” or “email address” as the matching attribute on the Azure
AD side, and the user not being provisioning has a value of “audrey@contoso.com”, then search the audit logs for
“audrey@contoso.com” and review then entries returned.
The provisioning audit logs record all the operations performed by the provisioning service, including:
Querying Azure AD for assigned users that are in scope for provisioning
Querying the target app for the existence of those users
Comparing the user objects between the system
Adding, updating, or disabling the user account in the target system based on the comparison
Next steps
Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active Directory''
User provisioning to an Azure AD Gallery application
is taking hours or more
When first enabling automatic provisioning for an application, the initial sync can take anywhere from 20 minutes
to several hours, depending on the size of the Azure AD directory and the number of users in scope for
provisioning.
Subsequent syncs after the initial sync be faster, as the provisioning service stores watermarks that represent the
state of both systems after the initial sync, improving performance of subsequent syncs.
How to improve provisioning performance

If the initial sync is taking more than a few hours, there is one thing you can do to improve performance:
User scoping filters. Scoping filters allow you to fine tune the data that the provisioning service extracts from
Azure AD by filtering out users based on specific attribute values. For more information on scoping filters, see
Attribute-based application provisioning with scoping filters.
Next steps
How to configure user provisioning to an Azure AD
Gallery application
User account provisioning is the act of creating, updating, and/or disabling user account records in an application’s
local user profile store. Most cloud and SaaS applications store the users role and permissions in their own local
user profile store, and presence of such a user record in their local store is required for single sign-on and access to
work.
In the Azure portal, the Provisioning tab in the left navigation pane for an Enterprise App displays what
provisioning modes are supported for that app. This can be one of two values:
Configuring an application for Manual Provisioning

Manual provisioning means that user accounts must be created manually using the methods provided by that app.
This could mean logging into an administrative portal for that app and adding users using a web-based user
interface. Or it could be uploading a spreadsheet with user account detail, using a mechanism provided by that
application. Consult the documentation provided by the app, or contact the app developer to determine wat
mechanisms are available.
If Manual is the only mode shown for a given application, it means that no automatic Azure AD provisioning
connector has been created for the app yet. Or it means the app does not support the pre-requisite user
management API upon which to build an automated provisioning connector.
If you would like to request support for automatic provisioning for a given app, you can fill out a request using the
Azure Active Directory Application Requests.
Configuring an application for Automatic Provisioning

Automatic means that an Azure AD provisioning connector has been developed for this application. For more
information on the Azure AD provisioning service and how it works, see Automate User Provisioning and
Deprovisioning to SaaS Applications with Azure Active Directory.
For more information on how to provision specific users and groups to an application, see Managing user account
provisioning for enterprise apps.
The actual steps required to enable and configure automatic provisioning vary depending on the application.
NOTE
You should start by finding the setup tutorial specific to setting up provisioning for your application, and following those
steps to configure both the app and Azure AD to create the provisioning connection.
App tutorials can be found at List of Tutorials on How to Integrate SaaS Apps with Azure Active Directory.
An important thing to consider when setting up provisioning be to review and configure the attribute mappings
and workflows that define which user (or group) properties flow from Azure AD to the application. This includes
setting the “matching property” that be used to uniquely identify and match users/groups between the two
systems. For more information on this important process.
Next steps
Customizing User Provisioning Attribute Mappings for SaaS Applications in Azure Active Directory
Problem configuring user provisioning to an Azure
Configuring automatic user provisioning for an app (where supported), requires that specific instructions be
followed to prepare the application for automatic provisioning. Then you can use the Azure portal to configure the
provisioning service to synchronize user accounts to the application.
You should always start by finding the setup tutorial specific to setting up provisioning for your application. Then
follow those steps to configure both the app and Azure AD to create the provisioning connection. A list of app
tutorials can be found at List of Tutorials on How to Integrate SaaS Apps with Azure Active Directory.
How to see if provisioning is working

Once the service is configured, most insights into the operation of the service can be drawn from two places:
Audit logs – The provisioning audit logs record all the operations performed by the provisioning service,
including querying Azure AD for assigned users that are in scope for provisioning. Query the target app for
the existence of those users, comparing the user objects between the system. Then add, update, or disable
the user account in the target system based on the comparison. The provisioning audit logs can be accessed
in the Azure portal, in the Azure Active Directory > Enterprise Apps > [Application Name] > Audit
Logs tab. Filter the logs on the Account Provisioning category to only see the provisioning events for
that app.
Provisioning status – A summary of the last provisioning run for a given app can be seen in the Azure
Active Directory > Enterprise Apps > [Application Name] >Provisioning section, at the bottom of
the screen under the service settings. This section summarizes how many users (and/or groups) are
currently being synchronized between the two systems, and if there are any errors. Error details be in the
audit logs. Note that the provisioning status not be populated until one full initial synchronization has been
completed between Azure AD and the app.
General problem areas with provisioning to consider

Audit logs say users are “skipped” and not provisioned, even though they are assigned

subsequent reloads. It is likely that the service is running but has not completed an initial synchronization yet.
Check the Audit logs described above to determine what operations the service is performing, and if there are
any errors.
NOTE
An initial sync can take anywhere from 20 minutes to several hours, depending on the size of the Azure AD directory and
the number of users in scope for provisioning. Subsequent syncs after the initial sync be faster, as the provisioning service
stores watermarks that represent the state of both systems after the initial sync, improving performance of subsequent
syncs.

In order for provisioning to work, Azure AD requires valid credentials that allow it to connect to a user
management API provided by that app. If these credentials don’t work, or you don’t know what they are, review
the tutorial for setting up this app, described previously.
are assigned
When a user shows up as “skipped” in the audit logs, it is very important to read the extended details in the log
message to determine the reason. Below are common reasons and resolutions:
A scoping filter has been configured that is filtering the user out based on an attribute value. For
more information on scoping filters, see https://docs.microsoft.com/azure/active-directory/active-directory-
saas-scoping-filters.
The user is “not effectively entitled”. If you see this specific error message, it is because there is a
problem with the user assignment record stored in Azure AD. To fix this issue, un-assign the user (or group)
from the app, and re-assign it again. For more information on assignment, see
https://docs.microsoft.com/azure/active-directory/active-directory-coreapps-assign-user-azure-portal.
A required attribute is missing or not populated for a user. An important thing to consider when
setting up provisioning be to review and configure the attribute mappings and workflows that define which
user (or group) properties flow from Azure AD to the application. This includes setting the “matching
property” that be used to uniquely identify and match users/groups between the two systems. For more
information on this important process, see https://docs.microsoft.com/azure/active-directory/active-
directory-saas-customizing-attribute-mappings.
disabling the Mapping for group objects shown in the Provisioning tab. If provisioning groups is
enabled, be sure to review the attribute mappings to ensure an appropriate field is being used for the
“matching ID”. This can be the display name or email alias), as the group and its members not be
provisioned if the matching property is empty or not populated for a group in Azure AD.
Next steps
Problem saving administrator credentials while
configuring user provisioning to an Azure Active
Directory Gallery application
When using the Azure portal to configure automatic user provisioning for an enterprise application, you may
encounter a situation where:
The Admin Credentials entered for the application are valid, and the Test Connection button works.
However, the credentials cannot be saved, and the Azure portal returns a generic error message.
If SAML -based single sign-on is also configured for the same application, the most likely cause of the error is that
Azure AD's internal, per-application storage limit for certificates and credentials has been exceeded.
Azure AD currently has a maximum storage capacity of 1024 bytes for all certificates, secret tokens, credentials,
and related configuration data associated with a single instance of an application (also known as a service principal
record in Azure AD ).
When SAML -based single sign-on is configured, the certificate used to sign the SAML tokens is stored here, and
often consumes over 50% percent of the space.
Any secret tokens, URIs, notification email addresses, user names, and passwords that get entered during setup of
user provisioning can cause the storage limit to be exceeded.
How to work around this issue

There are two possible ways to work around this issue today:
1. Use two gallery application instances, one for single sign-on and one for user provisioning - Taking
the gallery application LinkedIn Elevate as an example, you can add LinkedIn Elevate from the gallery and
configure it for single sign-on. For provisioning, add another instance of LinkedIn Elevate from the Azure
AD app gallery, and name it "LinkedIn Elevate (Provisioning)." For this second instance, configure
provisioning, but not single sign-on. When using this workaround, the same users and groups need to be
assigned to both applications.
2. Reduce the amount of configuration data stored - All data entered in the Admin credentials section of
the provisioning tab is stored in the same place as the SAML certificate. While it may not be possible to
reduce the length of all of this data, some optional configuration fields like the Notification Email can be
removed.
Next steps
Configure user provisioning and de-provisioning to SaaS applications
No users are being provisioned to an Azure AD
Gallery application
After automatic provisioning has been configured for an application (including verifying that the app credentials
provided to Azure AD to connect to the app are valid), then users and/or groups are provisioned to the app.
Provisioning is determined by the following things:
Which users and groups have been assigned to the application. For more information on assignment, see
Assign a user or group to an enterprise app in Azure Active Directory.
Whether or not attribute mappings are enabled, and configured to sync valid attributes from Azure AD to the
app. For more information on attribute mappings, see Customizing User Provisioning Attribute Mappings for
SaaS Applications in Azure Active Directory.
Whether or not there is a scoping filter present that is filtering users based on specific attribute values. For
more information on scoping filters, see Attribute-based application provisioning with scoping filters.
If you observe that users are not being provisioned, consult the Audit logs in Azure AD. Search for log entries for a
specific user.
The provisioning audit logs can be accessed in the Azure portal, in the Azure Active Directory > Enterprise
Apps > [Application Name] > Audit Logs tab. Filter the logs on the Account Provisioning category to only
see the provisioning events for that app. You can search for users based on the “matching ID” that was configured
for them in the attribute mappings. For example, if you configured the “user principal name” or “email address” as
the matching attribute on the Azure AD side, and the user not being provisioning has a value of
“audrey@contoso.com”, then search the audit logs for “audrey@contoso.com” and review the entries returned.
The provisioning audit logs record all the operations performed by the provisioning service, including querying
Azure AD for assigned users that are in scope for provisioning, querying the target app for the existence of those
users, comparing the user objects between the system. Then add, update, or disable the user account in the target
system based on the comparison.
General Problem Areas with Provisioning to consider

Audit logs say users are skipped and not provisioned, even though they are assigned

subsequent reloads, it is likely that the service is running but has not completed an initial synchronization yet.
Check the Audit logs described above to determine what operations the service is performing, and if there are any
errors.
NOTE
An initial sync can take anywhere from 20 minutes to several hours, depending on the size of the Azure AD directory and the
number of users in scope for provisioning. Subsequent syncs after the initial sync are faster, as the provisioning service stores
watermarks that represent the state of both systems after the initial sync. The initial sync improves performance of
subsequent syncs.
are assigned
When a user shows up as “skipped” in the audit logs, it is important to read the extended details in the log message
to determine the reason. Below are common reasons and resolutions:
A scoping filter has been configured that is filtering the user out based on an attribute value. For more
information on scoping filters, see scoping filters.
The user is “not effectively entitled”. If you see this specific error message, it is because there is a problem
with the user assignment record stored in Azure AD. To fix this issue, unassign the user (or group) from the app,
and reassign it again. For more information on assignment, see Assign user or group access.
A required attribute is missing or not populated for a user. An important thing to consider when setting
up provisioning is to review and configure the attribute mappings and workflows that define which user (or
group) properties flow from Azure AD to the application. This configuration includes setting the “matching
property” that is used to uniquely identify and match users/groups between the two systems. For more
information on this important process, see Customizing User Provisioning Attribute Mappings for SaaS
Applications in Azure Active Directory.
disabling the Mapping for group objects shown in the Provisioning tab. If provisioning groups is enabled, be
sure to review the attribute mappings to ensure an appropriate field is being used for the “matching ID”. The
matching ID can be the display name or email alias. The group and its members are not provisioned if the
matching property is empty or not populated for a group in Azure AD.
Next steps
Azure AD Connect sync: Understanding Declarative Provisioning
Wrong set of users are being provisioned to an Azure
Which users are provisioned to the app is primarily driven by which users and groups have been assigned to the
application.
Use the following resources to learn how to check which users and groups have been assigned to an application
within Azure Active Directory.
Assign a user directly as an administrator

To assign one or more users to an application directly, follow these steps:
1. Open the Azure portal and sign in as a Global Administrator.
navigation menu.
6. Select the application you want to assign a user to from the list.
7. Once the application loads, click Users and Groups from the application’s left-hand navigation menu.
8. To open the Add Assignment pane, click the Add button on top of the Users and Groups list.
9. click the Users and groups selector from the Add Assignment pane.
10. Type in the full name or email address of the user you are interested in assigning into the Search by
name or email address search box.
11. Hover over the user in the list to reveal a checkbox. Click the checkbox next to the user’s profile photo or
logo to add your user to the Selected list.
12. Optional: If you would like to add more than one user, type in another full name or email address into
the Search by name or email address search box, and click the checkbox to add this user to the Selected
list.
13. When you are finished selecting users, click the Select button to add them to the list of users and groups to
be assigned to the application.
14. Optional: click the Select Role selector in the Add Assignment pane to select a role to assign to the users
you have selected.
15. Click the Assign button to assign the application to the selected users.
If provisioning is configured and already running for an app, new users should be provisioned to an application in
approximately 10 minutes. Check the Audit Logs for details.
Assign a group directly to an application as an administrator
To assign one or more groups to an application directly, follow these steps:
navigation menu.
10. Type in the full group name of the group you are interested in assigning into the Search by name or
email address search box.
11. Hover over the group in the list to reveal a checkbox. Click the checkbox next to the group’s profile photo
or logo to add your user to the Selected list.
12. Optional: If you would like to add more than one group, type in another full group name into the
Search by name or email address search box, and click the checkbox to add this group to the Selected
list.
13. When you are finished selecting groups, click the Select button to add them to the list of users and groups
to be assigned to the application.
14. Optional: click the Select Role selector in the Add Assignment pane to select a role to assign to the
groups you have selected.
15. Click the Assign button to assign the application to the selected groups.
If provisioning is configured and already running for an app, new users contained within the group should be
provisioned to an application in approximately 10 minutes. Check the Audit Logs for details.
IMPORTANT
Provisioning of the group name and group details, in addition to the members, if supported for some applications. You can
enable or disable this functionality by enabling or disabling the Mapping for group objects shown in the Provisioning tab.
If provisioning groups is enabled, be sure to review the attribute mappings to ensure an appropriate field is being
used for the “matching ID”. This matching ID can be the display name or email alias. The group and its members
are not provisioned if the matching property is empty or not populated for a group in Azure AD.
Next steps
Unexpected application in my applications list
This article help you to understand how applications appear in your All Applications list under Enterprise
Applications.
How to see all applications in your tenant

To see all the applications in your tenant, you need to use the Filter control to show All Applications under the
All Applications list. Follow these steps:
navigation menu.
6. click the use the Filter control at the top of the All Applications List.
7. On the Filter pane, set the Show option to All Applications.
Why does a specific application appear in my all applications list?

When filtered to All Applications, the All Applications List shows every Service Principal object in your tenant.
Service Principal objects can appear in this list in a various ways:
1. When you add any application from the application gallery, including:
a. Azure AD Gallery Applications – An application that has been pre-integrated for single sign-on
with Azure AD
b. Application Proxy Applications – An application running in your on-premises environment that
you want to provide secure single-sign on to externally
c. Custom -developed Applications – An application that your organization wishes to develop on the
Azure AD Application Development Platform, but that may not exist yet
d. Non-Gallery Applications – Bring your own applications! Any web link you want, or any
application that renders a username and password field, supports SAML or OpenID Connect
protocols, or supports SCIM that you wish to integrate for single sign-on with Azure AD.
2. When signing up for, or signing in to, a 3rd party application integrated with Azure Active Directory. One
example is Smartsheet or DocuSign.
3. When signing up for, or adding a license to a user or a group to a first party application, like Microsoft Office
365
4. When you add a new application registration by creating a custom-developed application using the
Application Registry
5. When you add a new application registration by creating a custom-developed application using the V2.0
Application Registration portal
6. When you add an application you’re developing using Visual Studio’s ASP.net Authentication Methods or
Connected Services
7. When you create a service principal object using the Azure AD PowerShell Module
8. When you consent to an application as an administrator to use data in your tenant
9. When a user consents to an application to use data in your tenant
10. When you enable certain services that store data in your tenant. One example is Password Reset, which is
modeled as a service principal to store your password reset policy securely.
To get more details on how apps are added to your directory, read How and why applications are added to Azure
AD.
I want to remove a specific user’s or group’s assignment to an

application
To remove a user or group assignment to an application, follow the steps listed in the Remove a user or group
assignment from an enterprise app in Azure Active Directory article.
I want to disable all access to an application for every user

To disable all user sign-ins to an application, follow the steps listed in the Disable user sign-ins for an enterprise
app in Azure Active Directory article.
I want to delete an application entirely

To delete an application, follow these steps:
navigation menu.
6. Select the application you want to delete.
7. Once the application loads, click Delete icon from the top application’s Overview pane.
I want to disable all future user consent operations to any application

Disabling user consent for your entire directory prevent end users from consenting to any application.
Administrators can still consent on user’s behalf. To learn more about application consent, and why you may or
may not want to consent, read Understanding user and admin consent.
To disable all future user consent operations in your entire directory, follow these steps:
navigation menu.
4. click Users and groups in the navigation menu.
5. click User settings.
6. Disable all future user consent operations by setting the Users can allow apps to access their data toggle
to No and click the Save button.
Next steps
Configure the way end-users consent to an
application in Azure Active Directory
Learn how to configure the way users consent to application permissions. You can simplify the user experience by
granting admin consent. This article gives the different ways you can configure user consent. The methods apply to
all end users in your Azure Active Directory (Azure AD ) tenant.
For more information on consenting to applications, see Azure Active Directory consent framework.
Prerequisites
Granting admin consent requires you to sign in as global administrator, an application administrator, or a cloud
application administrator.
To restrict access to applications, you need to require user assignment and then assign users or groups to the
application. For more information, see Methods for assigning users and groups.
Grant admin consent to enterprise apps in the Azure portal

To grant admin consent to an enterprise app:
1. Sign in to the Azure portal as a global administrator, an application administrator, or a cloud application
administrator.
2. Click All services at the top of the left-hand navigation menu. The Azure Active Directory Extension opens.
3. In the filter search box, type "Azure Active Directory" and select the Azure Active Directory item.
4. From the navigation menu, click Enterprise applications.
5. Click Grant Admin Consent. You'll be prompted to sign in to administrate the application.
6. Sign in with an account that has permissions to grant admin consent for the application.
7. Consent to the application permissions.
This option only works if the application is:
Registered in your tenant, or
Registered in another Azure AD tenant, and consented by at least one end user. Once an end user has consented
to an application, Azure AD lists the application under Enterprise apps in the Azure portal.
Grant admin consent when registering an app in the Azure portal

To grant admin consent when registering an app:
2. Navigate to the App Registrations blade.
3. Select the application for the consent.
4. Select Required Permissions.
5. Click Grant Permissions at the top of the blade.
Grant admin consent through a URL request

To grant admin consent through a URL request:
1. Construct a request to login.microsoftonline.com with your app configurations and append on
&prompt=admin_consent .
2. After signing in with admin credentials, the app has been granted consent for all users.
Force user consent through a URL request

To require end users to consent to an application each time they authenticate, append &prompt=consent to the
authentication request URL.
Next steps
Consent and Integrating Apps to AzureAD
Consent and Permissioning for AzureAD v2.0 converged Apps
AzureAD StackOverflow
Assign users and groups to an application in Azure
Active Directory
This article shows you how to assign users or groups to an application in Azure Active Directory (Azure AD ). Users
must first be assigned to an application before an administrator can grant them access to do the following:
Access an application by navigating to the application’s URL directly (also known as SP -initiated sign-
on).
Access an application by using the User Access URL on an application’s Properties page (also known as
IDP -initiated sign on).
See an application appear on their Application Access Panel or mobile application.
See an application appear on their Office 365 Application Launcher.
Prerequisites
Before you can assign users and groups to an application, you must require user assignment. To require user
assignment:
1. Log in to the Azure portal with an administrator account.
2. Click on the All services item in the main menu.
3. Choose the directory you are using for the application.
4. Click on the Enterprise applications tab.
5. Select the application from the list of applications associated with this directory.
6. Click the Properties tab.
7. Change the User assignment required? toggle to Yes.
8. Click the Save button at the top of the screen.
Assign users
To assign one or more users to an application directly, follow the steps below:
2. Open the Azure Active Directory Extension by clicking All services at the top of the main left hand
navigation menu.
4. click Enterprise Applications from the Azure Active Directory left hand navigation menu.
7. Once the application loads, click Users and Groups from the application’s left hand navigation menu.
8. Click the Add button on top of the Users and Groups list to open the Add Assignment pane.
list.
you have selected.
After a short period of time, the users you have selected be able to launch these applications using the methods
described in the solution description section.
Assign groups
To assign one or more groups to an application directly, follow the steps below:
navigation menu.
7. Once the application loads, click Users and Groups from the application’s left hand navigation menu.
list.
After a short period of time, the users within the groups you have selected be able to launch these applications
using the methods described in the solution description section. If these are dynamic groups, there may be some
additional processing delay in these assignments appearing for users within these assigned groups.
Enable self-service application access

Self-service application access is a great way to allow users to self-discover applications, optionally allow the
business group to approve access to those applications. You can allow the business group to manage the
credentials assigned to those users for Password Single-Sign On Applications right from their access panels.
To enable self-service application access to an application, follow the steps below:
navigation menu.
6. Select the application you want to enable Self-service access to from the list.
7. Once the application loads, click Self-service from the application’s left hand navigation menu.
8. To enable Self-service application access for this application, turn the Allow users to request access to
this application? toggle to Yes.
9. Next, to select the group to which users who request access to this application should be added, click the
selector next to the label To which group should assigned users be added? and select a group.
10. Optional: If you wish to require a business approval before users are allowed access, set the Require
approval before granting access to this application? toggle to Yes.
11. Optional: For applications using password single-sign on only, if you wish to allow those business
approvers to specify the passwords that are sent to this application for approved users, set the Allow
approvers to set user’s passwords for this application? toggle to Yes.
12. Optional: To specify the business approvers who are allowed to approve access to this application, click the
selector next to the label Who is allowed to approve access to this application? to select up to 10
individual business approvers.
NOTE
Groups are not supported.
13. Optional: For applications which expose roles, if you wish to assign self-service approved users to a
role, click the selector next to the To which role should users be assigned in this application? to select
the role to which these users should be assigned.
14. Click the Save button at the top of the pane to finish.
Once you complete Self-service application configuration, users can navigate to their Application Access Panel and
click the +Add button to find the apps to which you have enabled Self-service access. Business approvers also see
a notification in their Application Access Panel. You can enable an email notifying them when a user has requested
access to an application that requires their approval.
These approvals support single approval workflows only, meaning that if you specify multiple approvers, any
single approver may approver access to the application.
Next steps
Assign a user or group to an enterprise app in
To assign a user or group to an enterprise app, you must have the appropriate permissions to manage the
enterprise app, and you must be global admin for the directory.
NOTE
For licensing requirements for the features discussed in this article, see the Azure Active Directory pricing page.
NOTE
For Microsoft Applications (such as Office 365 apps), use PowerShell to assign users to an enterprise app.
Assign a user to an app - portal

3. Select Enterprise applications.
4. On the Enterprise applications blade, select All applications. This lists the apps you can manage.
5. On the Enterprise applications - All applications blade, select an app.
6. On the appname blade (that is, the blade with the name of the selected app in the title), select Users &
Groups.
7. On the appname - User & Group Assignment blade, select the Add command.
8. On the Add Assignment blade, select Users and groups.
9. On the Users and groups blade, select one or more users or groups from the list and then select the Select
button at the bottom of the blade.
10. On the Add Assignment blade, select Role. Then, on the Select Role blade, select a role to apply to the
selected users or groups, and then select the OK button at the bottom of the blade.
11. On the Add Assignment blade, select the Assign button at the bottom of the blade. The assigned users or
groups have the permissions defined by the selected role for this enterprise app.
Allow all users to access an app - portal
To allow all users to access an application:
3. Select Enterprise applications.
4. On the Enterprise applications blade, select All applications. This lists the apps you can manage.
5. On the Enterprise applications - All applications blade, select an app.
6. On the appname blade, select Properties.
7. On the appname - Properties blade, set the User assignment required? setting to No.
The User assignment required? option:
Does not affect whether or not an application appears on the application access panel. To show the
application on the access panel, you need to assign an appropriate user or group to the application.
Only functions with the cloud applications that are configured for SAML single sign-on, and on-premises
applications configured with Application Proxy. See Single sign-on for applications.
Requires that users consent to an application. An admin can grant consent for all users. See Configure the
way end-users consent to an application.
Assign a user to an app - PowerShell

1. Open an elevated Windows PowerShell command prompt.
NOTE
You need to install the AzureAD module (use the command Install-Module -Name AzureAD ). If prompted to
install a NuGet module or the new Azure Active Directory V2 PowerShell module, type Y and press ENTER.
2. Run Connect-AzureAD and sign in with a Global Admin user account.

3. Use the following script to assign a user and role to an application:
# Assign the values to the variables

$username = "<You user's UPN>"
$app_name = "<Your App's display name>"
$app_role_name = "<App role display name>"
# Get the user to assign, and the service principal for the app to assign to
$user = Get-AzureADUser -ObjectId "$username"
$sp = Get-AzureADServicePrincipal -Filter "displayName eq '$app_name'"
$appRole = $sp.AppRoles | Where-Object { $_.DisplayName -eq $app_role_name }
# Assign the user to the app role

New-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId
$sp.ObjectId -Id $appRole.Id
For more information about how to assign a user to an application role visit the documentation for New -
AzureADUserAppRoleAssignment
To assign a group to an enterprise app, you need to replace Get-AzureADUser with Get-AzureADGroup .
Example
This example assigns the user Britta Simon to the Microsoft Workplace Analytics application using PowerShell.
1. In PowerShell, assign the corresponding values to the variables $username, $app_name and
$app_role_name.

$username = "britta.simon@contoso.com"
$app_name = "Workplace Analytics"
2. In this example, we don't know what is the exact name of the application role we want to assign to Britta
Simon. Run the following commands to get the user ($user) and the service principal ($sp) using the user
UPN and the service principal display names.
# Get the user to assign, and the service principal for the app to assign to
$user = Get-AzureADUser -ObjectId "$username"
$sp = Get-AzureADServicePrincipal -Filter "displayName eq '$app_name'"
3. Run the command $sp.AppRoles to display the roles available for the Workplace Analytics application. In
this example, we want to assign Britta Simon the Analyst (Limited access) Role.
4. Assign the role name to the $app_role_name variable.

$app_role_name = "Analyst (Limited access)"
$appRole = $sp.AppRoles | Where-Object { $_.DisplayName -eq $app_role_name }
5. Run the following command to assign the user to the app role:
# Assign the user to the app role

New-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId
$sp.ObjectId -Id $appRole.Id
Next steps
Change the name or logo of an enterprise app
How to remove a user's access to an application
This article helps you to understand how to remove a user's access to an application.
I want to remove a specific user’s or group’s assignment to an

application
To remove a user or group assignment to an application, follow the steps listed in the Remove a user or group
assignment from an enterprise app in Azure Active Directory article.
I want to disable all access to an application for every user

To disable all user sign-ins to an application, follow the steps listed in the Disable user sign-ins for an enterprise
app in Azure Active Directory article.
I want to delete an application entirely

To delete an application, follow these instructions:
navigation menu.
4. Click Enterprise Applications from the Azure Active Directory left-hand navigation menu.
5. Click All Applications to view a list of all your applications.
6. Select the application you want to delete.
7. Once the application loads, click Delete icon from the top application’s Overview pane.
I want to disable all future user consent operations to any application

Disabling user consent for your entire directory prevent end users from consenting to any application.
Administrators can still consent on user’s behalf. For more information about application consent, and why you
may or may not wish to do this, read Understanding user and admin consent. See also, Permissions and consent.
To disable all future user consent operations in your entire directory, follow these instructions:
2. Open the Azure Active Directory Extension
3. Click Enterprise applications in the navigation menu.
4. Click User settings.
5. Set the Users can allow apps to access company data on their behalf toggle to No and click the Save
button.
Next steps
Managing access to apps
How to assign users to applications
This article help you to understand how users get assigned to an application in your tenant.
How do users get assigned to an application in Azure AD?

For a user to access an application, they must first be assigned to it in some way. Assignment can be performed by
an administrator, a business delegate, or sometimes, the user themselves. Below describes the ways users can get
assigned to applications:
1. An administrator assigns a user to the application directly
2. An administrator assigns a group that the user is a member of to the application, including:
A group that was synchronized from on-premises
A static security group created in the cloud
A dynamic security group created in the cloud
An Office 365 group created in the cloud
The All Users group
3. An administrator enables Self-service Application Access to allow a user to add an application using the
Application Access Panel Add App feature without business approval
4. An administrator enables Self-service Application Access to allow a user to add an application using the
Application Access Panel Add App feature, but only with prior approval from a selected set of business
approvers
5. An administrator enables Self-service Group Management to allow a user to join a group that an application
is assigned to without business approval
6. An administrator enables Self-service Group Management to allow a user to join a group that an application
is assigned to, but only with prior approval from a selected set of business approvers
7. An administrator assigns a license to a user directly for a first party application, like Microsoft Office 365
8. An administrator assigns a license to a group that the user is a member of to a first party application, like
Microsoft Office 365
9. An administrator consents to an application to be used by all users and then a user signs in to the
application
10. A user consents to an application themselves by signing in to the application
Next steps
Remove a user or group assignment from an
enterprise app in Azure Active Directory
It's easy to remove a user or a group from being assigned access to one of your enterprise applications in Azure
Active Directory (Azure AD ). You must have the appropriate permissions to manage the enterprise app, and you
must be global admin for the directory.
NOTE
For Microsoft Applications (such as Office 365 apps), use PowerShell to remove users to an enterprise app.
How do I remove a user or group assignment to an enterprise app in

the Azure portal?
2. Select More services, enter Azure Active Directory in the text box, and then select Enter.
3. On the Azure Active Directory - *directoryname* page (that is, the Azure AD page for the directory you
4. On the Enterprise applications page, select All applications. You'll see a list of the apps you can manage.
5. On the Enterprise applications - All applications page, select an app.
6. On the appname page (that is, the page with the name of the selected app in the title), select Users &
Groups.
7. On the appname - User & Group Assignment page, select one of more users or groups and then select
the Remove command. Confirm your decision at the prompt.
How do I remove a user or group assignment to an enterprise app

using PowerShell?
1. Open an elevated Windows PowerShell command prompt.
NOTE
You need to install the AzureAD module (use the command Install-Module -Name AzureAD ). If prompted to
install a NuGet module or the new Azure Active Directory V2 PowerShell module, type Y and press ENTER.
2. Run Connect-AzureAD and sign in with a Global Admin user account.

3. Use the following script to remove a user and role from an application:
# Store the proper parameters

$user = get-azureaduser -ObjectId <objectId>
$spo = Get-AzureADServicePrincipal -ObjectId <objectId>
#Get the ID of role assignment

$assignments = Get-AzureADServiceAppRoleAssignment -ObjectId $spo.ObjectId | Where
{$_.PrincipalDisplayName -eq $user.DisplayName}
#if you run the following, it will show you what is assigned what
$assignments | Select *
#To remove the App role assignment run the following command.
Remove-AzureADServiceAppRoleAssignment -ObjectId $spo.ObjectId -AppRoleAssignmentId
$assignments[assignment #].ObjectId
Next steps
Hide applications from end-users in Azure Active
Directory
Instructions for how to hide applications from end-users' MyApps panel or Office 365 launcher. When an
application is hidden, users still have permissions to the application.
Prerequisites
Application administrator privileges are required to hide an application from the MyApps panel and Office 365
launcher.
Global administrator privileges are required to hide all Office 365 applications.
Hide an application from the end user

Use the following steps to hide an application from MyApps panel and Office 365 application launcher.
1. Sign in to the Azure portal as the global administrator for your directory.
2. Select Azure Active Directory.
3. Select Enterprise applications. The Enterprise applications - All applications blade opens.
4. Under Application Type, select Enterprise Applications, if it isn't already selected.
5. Search for the application you want to hide, and click the application. The application's overview opens.
6. Click Properties.
7. For the Visible to users? question, click No.
8. Click Save.
Hide Office 365 applications from the MyApps panel

Use the following steps to hide all Office 365 applications from the MyApps panel. The applications are still visible
in the Office 365 portal.
1. Sign in to the Azure portal as a global administrator for your directory.
2. Select Azure Active Directory.
3. Select User settings.
4. Under Enterprise applications, click Manage how end users launch and view their applications.
5. For Users can only see Office 365 apps in the Office 365 portal, click Yes.
6. Click Save.
Next steps
See all my groups
Disable user sign-ins for an enterprise app in Azure
Active Directory
It's easy to disable an enterprise application so that no users may sign in to it in Azure Active Directory (Azure
AD ). You must have the appropriate permissions to manage the enterprise app, and you must be global admin for
the directory.
How do I disable user sign-ins?

3. On the Azure Active Directory - directoryname pane (that is, the Azure AD pane for the directory you
4. On the Enterprise applications pane, select All applications. You see a list of the apps you can manage.
5. On the Enterprise applications - All applications pane, select an app.
6. On the appname pane (that is, the pane with the name of the selected app in the title), select Properties.
7. On the appname - Properties pane, select No for Enabled for users to sign-in?.
8. Select the Save command.
Next steps
See all my groups
How to configure self-service application assignment
Before your users can self-discover applications from their access panel, you need to enable Self-service
application access to any applications that you wish to allow users to self-discover and request access to.
This feature is a great way for you to save time and money as an IT group, and is highly recommended as part of a
modern applications deployment with Azure Active Directory.
Using this feature, you can:
Let users self-discover applications from the Application Access Panel without bothering the IT group.
Add those users to a pre-configured group so you can see who has requested access, remove access, and
manage the roles assigned to them.
Optionally allow a business approver to approve application access requests so the IT group doesn’t have to.
Optionally configure up to 10 individuals who may approve access to this application.
Optionally allow a business approver to set the passwords those users can use to sign in to the application,
right from the business approver’s Application Access Panel.
Optionally automatically assign self-service assigned users to an application role directly.
Enable self-service application access to allow users to find their own

applications
1. Open the Azure Portal and sign in as a Global Administrator.
navigation menu.
NOTE
Groups synchronized from on-premises are not supported to be used for the group to which users who request
access to this application should be added.
NOTE
14. Click the Save button at the top of the blade to finish.
These approvals support single approval workflows only, meaning that if you specify multiple approvers, any single
approver may approver access to the application.
Next steps
Setting up Azure Active Directory for self-service group management
Configure Azure Active Directory sign in behavior for
an application by using a Home Realm Discovery
policy
The following document provides an introduction to configuring Azure Active Directory authentication behavior
for federated users. It covers configuration of auto-acceleration and authentication restrictions for users in
federated domains.
Home Realm Discovery

Home Realm Discovery (HRD ) is the process that allows Azure Active Directory (Azure AD ) to determine where a
user needs to authenticate at sign-in time. When a user signs in to an Azure AD tenant to access a resource, or to
the Azure AD common sign-in page, they type a user name (UPN ). Azure AD uses that to discover where the user
needs to sign in.
The user might need to be taken to one of the following locations to be authenticated:
The home tenant of the user (might be the same tenant as the resource that the user is attempting to
access).
Microsoft account. The user is a guest in the resource tenant.
An on-premises identity provider such as Active Directory Federation Services (AD FS ).
Another identity provider that's federated with the Azure AD tenant.
Auto-acceleration
Some organizations configure domains in their Azure Active Directory tenant to federate with another IdP, such as
AD FS for user authentication.
When a user signs into an application, they are first presented with an Azure AD sign-in page. After they have
typed their UPN, if they are in a federated domain they are then taken to the sign-in page of the IdP serving that
domain. Under certain circumstances, administrators might want to direct users to the sign-in page when they're
signing in to specific applications.
As a result users can skip the initial Azure Active Directory page. This process is referred to as “sign-in auto-
acceleration.”
In cases where the tenant is federated to another IdP for sign-in, auto-acceleration makes user sign-in more
streamlined. You can configure auto-acceleration for individual applications.
NOTE
If you configure an application for auto-acceleration, guest users cannot sign in. If you take a user straight to a federated IdP
for authentication, there is no way to for them to get back to the Azure Active Directory sign-in page. Guest users, who
might need to be directed to other tenants or an external IdP such as a Microsoft account, can't sign in to that application
because they're skipping the Home Realm Discovery step.
There are two ways to control auto-acceleration to a federated IdP:

Use a domain hint on authentication requests for an application.
Configure a Home Realm Discovery policy to enable auto-acceleration.
Domain hints
Domain hints are directives that are included in the authentication request from an application. They can be used to
accelerate the user to their federated IdP sign-in page. Or they can be used by a multi-tenant application to
accelerate the user straight to the branded Azure AD sign-in page for their tenant.
For example, the application "largeapp.com" might enable their customers to access the application at a custom
URL "contoso.largeapp.com." The app might also include a domain hint to contoso.com in the authentication
request.
Domain hint syntax varies depending on the protocol that's used, and it's typically configured in the application.
WS -Federation: whr=contoso.com in the query string.
SAML: Either a SAML authentication request that contains a domain hint or a query string whr=contoso.com.
Open ID Connect: A query string domain_hint=contoso.com.
If a domain hint is included in the authentication request from the application, and the tenant is federated with that
domain, Azure AD attempts to redirect sign-in to the IdP that's configured for that domain.
If the domain hint doesn’t refer to a verified federated domain, it is ignored and normal Home Realm Discovery is
invoked.
For more information about auto-acceleration using the domain hints that are supported by Azure Active
Directory, see the Enterprise Mobility + Security blog.
NOTE
If a domain hint is included in an authentication request, its presence overrides auto-acceleration that is set for the
application in HRD policy.
Home Realm Discovery policy for auto -acceleration

Some applications do not provide a way to configure the authentication request they emit. In these cases, it’s not
possible to use domain hints to control auto-acceleration. Auto-acceleration can be configured via policy to achieve
the same behavior.
Enable direct authentication for legacy applications

Best practice is for applications to use AAD libraries and interactive sign-in to authenticate users. The libraries take
care of the federated user flows. Sometimes legacy applications aren't written to understand federation. They don't
perform home realm discovery and do not interact with the correct federated endpoint to authenticate a user. If you
choose to, you can use HRD Policy to enable specific legacy applications that submit username/password
credentials to authenticate directly with Azure Active Directory. Password Hash Sync must be enabled.
IMPORTANT
Only enable direct authentication if you have Password Hash Sync turned on and you know it's okay to authenticate this
application without any policies implemented by your on-premises IdP. If you turn off Password Hash Sync, or turn off
Directory Synchronization with AD Connect for any reason, you should remove this policy to prevent the possibility of direct
authentication using a stale password hash.
Set HRD policy

There are three steps to setting HRD policy on an application for federated sign-in auto-acceleration or direct
cloud-based applications:
1. Create an HRD policy.
2. Locate the service principal to which to attach the policy.
3. Attach the policy to the service principal.
Policies only take effect for a specific application when they are attached to a service principal.
Only one HRD policy can be active on a service principal at any one time.
You can use either the Microsoft Azure Active Directory Graph API directly, or the Azure Active Directory
PowerShell cmdlets to create and manage HRD policy.
The Graph API that manipulates policy is described in the Operations on policy article on MSDN.
Following is an example HRD policy definition:
{
"HomeRealmDiscoveryPolicy":
{
"AccelerateToFederatedDomain":true,
"PreferredDomain":"federated.example.edu",
"AllowCloudPasswordValidation":true
}
}
The policy type is "HomeRealmDiscoveryPolicy."

AccelerateToFederatedDomain is optional. If AccelerateToFederatedDomain is false, the policy has no effect
on auto-acceleration. If AccelerateToFederatedDomain is true and there is only one verified and federated
domain in the tenant, then users will be taken straight to the federated IdP for sign in. If it is true and there is more
than one verified domain in the tenant, PreferredDomain must be specified.
PreferredDomain is optional. PreferredDomain should indicate a domain to which to accelerate. It can be
omitted if the tenant has only one federated domain. If it is omitted, and there is more than one verified federated
domain, the policy has no effect.
If PreferredDomain is specified, it must match a verified, federated domain for the tenant. All users of the
application must be able to sign in to that domain.
AllowCloudPasswordValidation is optional. If AllowCloudPasswordValidation is true then the application is
allowed to authenticate a federated user by presenting username/password credentials directly to the Azure Active
Directory token endpoint. This only works if Password Hash Sync is enabled.
Priority and evaluation of HRD policies
HRD policies can be created and then assigned to specific organizations and service principals. This means that it is
possible for multiple policies to apply to a specific application. The HRD policy that takes effect follows these rules:
If a domain hint is present in the authentication request, then any HRD policy is ignored for auto-
acceleration. The behavior that's specified by the domain hint is used.
Otherwise, if a policy is explicitly assigned to the service principal, it is enforced.
If there is no domain hint, and no policy is explicitly assigned to the service principal, a policy that's explicitly
assigned to the parent organization of the service principal is enforced.
If there is no domain hint, and no policy has been assigned to the service principal or the organization, the
default HRD behavior is used.
Tutorial for setting HRD policy on an application

We'll use Azure AD PowerShell cmdlets to walk through a few scenarios, including:
Setting up HRD policy to do auto-acceleration for an application in a tenant with a single federated domain.
Setting up HRD policy to do auto-acceleration for an application to one of several domains that are verified
for your tenant.
Setting up HRD policy to enable a legacy application to do direct username/password authentication to
Azure Active Directory for a federated user.
Listing the applications for which a policy is configured.
Prerequisites
In the following examples, you create, update, link, and delete policies on application service principals in Azure
AD.
1. To begin, download the latest Azure AD PowerShell cmdlet preview.
2. After you have downloaded the Azure AD PowerShell cmdlets, run the Connect command to sign in to
Azure AD with your admin account:
Connect-AzureAD -Confirm
3. Run the following command to see all the policies in your organization:
Get-AzureADPolicy
If nothing is returned, it means you have no policies created in your tenant.

Example: Set HRD policy for an application
In this example, you create a policy that when it is assigned to an application either:
Auto-accelerates users to an AD FS sign-in screen when they are signing in to an application when there is a
single domain in your tenant.
Auto-accelerates users to an AD FS sign-in screen there is more than one federated domain in your tenant.
Enables non-interactive username/password sign in directly to Azure Active Directory for federated users for
the applications the policy is assigned to.
Step 1: Create an HRD policy
The following policy auto-accelerates users to an AD FS sign-in screen when they are signing in to an application
when there is a single domain in your tenant.
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AccelerateToFederatedDomain`":true}}") -

DisplayName BasicAutoAccelerationPolicy -Type HomeRealmDiscoveryPolicy
The following policy auto-accelerates users to an AD FS sign-in screen there is more than one federated domain in
your tenant. If you have more than one federated domain that authenticates users for applications, you need
specify the domain to auto-accelerate.
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AccelerateToFederatedDomain`":true,
`"PreferredDomain`":`"federated.example.edu`"}}") -DisplayName MultiDomainAutoAccelerationPolicy -Type
HomeRealmDiscoveryPolicy
To create a policy to enable username/password authentication for federated users directly with Azure Active
Directory for specific applications, run the following command:
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AllowCloudPasswordValidation`":true}}") -

DisplayName EnableDirectAuthPolicy -Type HomeRealmDiscoveryPolicy
To see your new policy and get its ObjectID, run the following command:
Get-AzureADPolicy
To apply the HRD policy after you have created it, you can assign it to multiple application service principals.
Step 2: Locate the service principal to which to assign the policy
You need the ObjectID of the service principals to which you want to assign the policy. There are several ways to
find the ObjectID of service principals.
You can use the portal, or you can query Microsoft Graph. You can also go to the Graph Explorer Tool and sign in
to your Azure AD account to see all your organization's service principals. Because you are using PowerShell, you
can use the get-AzureADServicePrincipal cmdlet to list the service principals and their IDs.
Step 3: Assign the policy to your service principal
After you have the ObjectID of the service principal of the application for which you want to configure auto-
acceleration, run the following command. This command associates the HRD policy that you created in step 1 with
the service principal that you located in step 2.
Add-AzureADServicePrincipalPolicy -Id <ObjectID of the Service Principal> -RefObjectId <ObjectId of the Policy>
You can repeat this command for each service principal to which you want to add the policy.
In the case where an application already has a HomeRealmDiscovery policy assigned, you won’t be able to add a
second one. In that case, change the definition of the Home Realm Discovery policy that is assigned to the
application to add additional parameters.
Step 4: Check which application service principals your HRD policy is assigned to
To check which applications have HRD policy configured, use the Get-AzureADPolicyAppliedObject cmdlet.
Pass it the ObjectID of the policy that you want to check on.
Get-AzureADPolicyAppliedObject -ObjectId <ObjectId of the Policy>
Step 5: You're done!

Try the application to check that the new policy is working.
Example: List the applications for which HRD policy is configured
Step 1: List all policies that were created in your organization
Get-AzureADPolicy
Note the ObjectID of the policy that you want to list assignments for.
Step 2: List the service principals to which the policy is assigned
Example: Remove an HRD policy for an application

Step 1: Get the ObjectID
Use the previous example to get the ObjectID of the policy, and that of the application service principal from
which you want to remove it.
Step 2: Remove the policy assignment from the application service principal
Remove-AzureADApplicationPolicy -ObjectId <ObjectId of the Service Principal> -PolicyId <ObjectId of the

policy>
Step 3: Check removal by listing the service principals to which the policy is assigned
Next steps
For more information about how authentication works in Azure AD, see Authentication scenarios for Azure AD.
For more information about user single sign-on, see Application access and single sign-on with Azure Active
Directory.
Visit the Active Directory developer's guide for an overview of all developer-related content.
Configure single sign-on to non-gallery applications
in Azure Active Directory
This article is about a feature that enables administrators to configure single sign-on to applications not present in
the Azure Active Directory app gallery without writing code. If you are instead looking for developer guidance on
how to integrate custom apps with Azure AD through code, see Authentication Scenarios for Azure AD.
The Azure Active Directory application gallery provides a listing of applications that are known to support a form
of single sign-on with Azure Active Directory, as described in this article. Once you (as an IT specialist or system
integrator in your organization) have found the application you want to connect, you can get started by following
the step-by-step instructions presented in the Azure portal to enable single sign-on.
These capabilities are also available, according to your license agreement. For more information, see the pricing
page.
Self-service integration of any application that supports SAML 2.0 identity providers (SP -initiated or IdP -
initiated)
Self-service integration of any web application that has an HTML -based sign-in page using password-based
SSO
Self-service connection of applications that use the SCIM protocol for user provisioning ( described here)
Ability to add links to any application in the Office 365 app launcher or the Azure AD access panel
This can include not only SaaS applications that you use but have not yet been on-boarded to the Azure AD
application gallery, but third-party web applications that your organization has deployed to servers you control,
either in the cloud or on-premises.
These capabilities, also known as app integration templates, provide standards-based connection points for apps
that support SAML, SCIM, or forms-based authentication, and include flexible options and settings for
compatibility with a broad number of applications.
Adding an unlisted application

To connect an application using an app integration template, sign in to the Azure portal using your Azure Active
Directory administrator account. Browse to the Active Directory > Enterprise Applications > New
application > Non-gallery application section, select Add, and then Add an application from the gallery.
In the app gallery, you can add an unlisted app by selecting the Non-gallery application tile that is shown in the
search results if your desired app wasn't found. After entering a Name for your application, you can configure the
single sign-on options and behavior.
Quick tip: As a best practice, use the search function to check to see if the application already exists in the
application gallery. If the app is found and its description mentions single sign-on, then the application is already
supported for federated single sign-on.
Adding an application this way provides a similar experience to the one available for pre-integrated applications. To
start, select Configure Single Sign-On or click on Single sign-on from the application’s left-hand navigation
menu. The next screen presents the options for configuring single sign-on. The options are described in the next
sections of this article.
SAML-based single sign-on
Select this option to configure SAML -based authentication for the application. This requires that the application
support SAML 2.0. You should collect information on how to use the SAML capabilities of the application before
continuing. Complete the following sections to configure single sign-on between the application and Azure AD.
Enter basic SAML configuration
To set up Azure AD, enter the basic SAML configuration. You can manually enter the values or upload a metadata
file to extract the value of the fields.
Sign On URL (SP -initiated only) – Where the user goes to sign-in to this application. If the application is
configured to perform service provider-initiated single sign-on, then when a user navigates to this URL, the
service provider will do the necessary redirection to Azure AD to authenticate and log on the user in. If this field
is populated, then Azure AD will use this URL to launch the application from Office 365 and the Azure AD
Access Panel. If this field is omitted, then Azure AD will instead perform identity provider -initiated sign-on
when the app is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on
URL (can be copied from the Dashboard tab).
Identifier - should uniquely identify the application for which single sign-on is being configured. You can
find this value as the Issuer element in the AuthRequest (SAML request) sent by the application. This value
also appears as the Entity ID in any SAML metadata provided by the application. Check the application’s
SAML documentation for details on what its Entity ID or Audience value is.
The following is an example of how the Identifier or Issuer appears in the SAML request sent by the
application to Azure AD:
<samlp:AuthnRequest
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="id6c1c178c166d486687be4aaf5e482730"
Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.contoso.com</Issuer>
</samlp:AuthnRequest>
Reply URL - The reply URL is where the application expects to receive the SAML token. This is also referred
to as the Assertion Consumer Service (ACS ) URL. Check the application’s SAML documentation for details
on what its SAML token reply URL or ACS URL is.
To configure multiple replyURLs you can use the following PowerShell script.
$sp = Get-AzureADServicePrincipal -SearchString "<Exact App name>"
$app = Get-AzureADApplication -SearchString "<Exact app name>"
Set-AzureADApplication -ObjectId $app.ObjectId -ReplyUrls "<ReplyURLs>"
Set-AzureADServicePrincipal -ObjectId $sp.ObjectId -ReplyUrls "<ReplyURLs>"
For more information, see SAML 2.0 authentication requests and responses that Azure Active Directory (Azure
AD ) supports
Review or customize the claims issued in the SAML token
When a user authenticates to the application, Azure AD will issue a SAML token to the app that contains
information (or claims) about the user that uniquely identifies them. By default this includes the user's username,
email address, first name, and last name.
You can view or edit the claims sent in the SAML token to the application under the Attributes tab.
There are two reasons why you might need to edit the claims issued in the SAML token:
The application has been written to require a different set of claim URIs or claim values.
Your application has been deployed in a way that requires the NameIdentifier claim to be something other than
the username (AKA user principal name) stored in Azure Active Directory.
For more information, see Customizing claims issued in the SAML token for enterprise applications.
Review certificate expiration data, status, and email notification
When you create a Gallery or a Non-Gallery application, Azure AD will create an application-specific certificate
with an expiration date of 3 years from the date of creation. You need this certificate to set up the trust between
Azure AD and the application. For details on the certificate format, see the application’s SAML documentation.
From Azure AD, you can download the certificate in Base64 or Raw format. In addition, you can get the certificate
by downloading the application metadata XML file or by using the App federation metadata URL.
Verify the certificate has:
The desired expiration date. You can configure the expiration date for at most 3 years.
A status of active. If the status is inactive, change the status to active. To change the status, check Active and
then save the configuration.
The correct notification email. When the active certificate is near the expiration date, Azure AD will send a
notification to the email address configured in this field.
For more information, see Manage certificates for federated single sign-on in Azure Active Directory.
Set up target application
To configure the application for single sign-on, locate the application's documentation. To find the documentation,
scroll to the end of the SAML -based sign-on configuration page, and then click on Configure .
The required values vary according to the application. For details, see the application's SAML documentation. The
Sign-On and Sign-Out service URL both resolve to the same endpoint, which is the SAML request-handling
endpoint for your instance of Azure AD. The SAML Entity ID is the value that appears as the Issuer in the SAML
token that is issued to the application.
Assign users and groups to your SAML application
Once your application has been configured to use Azure AD as a SAML -based identity provider, then it is almost
ready to test. As a security control, Azure AD will not issue a token allowing a user to sign into the application
unless Azure AD has granted access to the user. Users may be granted access directly, or through a group
membership.
To assign a user or group to your application, click the Assign Users button. Select the user or group you wish to
assign, and then select the Assign button.
Assigning a user will allow Azure AD to issue a token for the user. It also causes a tile for this application to appear
in the user's Access Panel. An application tile will also appear in the Office 365 application launcher if the user is
using Office 365.
NOTE
You can upload a tile logo for the application using the Upload Logo button on the Configure tab for the application.
Test the SAML application

Before testing the SAML application, you must have set up the application with Azure AD, and assigned users or
groups to the application. To test the SAML application, see How to debug SAML -based single sign-on to
applications in Azure Active Directory.
Password single sign-on

Select this option to configure password-based single sign-on for a web application that has an HTML sign-in
page. Password-based SSO, also referred to as password vaulting, enables you to manage user access and
passwords to web applications that don't support identity federation. It is also useful for scenarios where several
users need to share a single account, such as to your organization's social media app accounts.
After selecting Next, you will be prompted to enter the URL of the application's web-based sign-in page. Note that
this must be the page that includes the username and password input fields. Once entered, Azure AD starts a
process to parse the sign-in page for a username input and a password input. If the process is not successful, then
it guides you through an alternate process of installing a browser extension (requires Internet Explorer, Chrome, or
Firefox) that will allow you to manually capture the fields.
Once the sign-in page is captured, users and groups may be assigned and credential policies can be set just like
regular password SSO apps.
NOTE
Existing single sign-on

Select this option to add a link to an application to your organization's Azure AD Access Panel or Office 365 portal.
You can use this to add links to custom web apps that currently use Active Directory Federation Services (or other
federation service) instead of Azure AD for authentication. Or, you can add deep links to specific SharePoint pages
or other web pages that you just want to appear on your user's Access Panels.
After selecting Next, you will be prompted to enter the URL of the application to link to. Once completed, users
and groups may be assigned to the application, which causes the application to appear in the Office 365 app
launcher or the Azure AD access panel for those users.
NOTE
Related Articles
How to Customize Claims Issued in the SAML Token for Pre-Integrated Apps
Troubleshooting SAML -Based Single Sign-On
How to configure federated single sign-on for an
Azure AD Gallery application
All applications in the Azure AD gallery enabled with Enterprise single sign-on capability has a step-by-step
tutorial available. You can access the List of tutorials on how to integrate SaaS apps with Azure Active Directory for
detailed step-by-step guidance.
Overview of steps required

To configure an application from the Azure AD gallery you need to:
Add an application from the Azure AD gallery
Configure the application’s metadata values in Azure AD (Sign on URL, Identifier, Reply URL )
Select User Identifier and add user attributes to be sent to the application
Retrieve Azure AD metadata and certificate
Configure Azure AD metadata values in the application (Sign on URL, Issuer, Logout URL and certificate)

To add an application from the Azure AD Gallery, follow the steps below:
1. Open the Azure portal and sign in as a Global Administrator or Co-admin
navigation menu.
5. click the Add button at the top-right corner on the Enterprise Applications pane.
6. In the Enter a name textbox from the Add from the gallery section, type the name of the application.
7. Select the application you want to configure for single sign-on.
8. Before adding the application, you can change its name from the Name textbox.
9. Click Add button, to add the application.
After a short period of time, you be able to see the application’s configuration pane.
Configure single sign-on for an application from the Azure AD gallery

To configure single sign-on for an application, follow the steps below:
navigation menu.
6. Select the application you want to configure single sign-on.
7. Once the application loads, click the Single sign-on from the application’s left-hand navigation menu.
8. Select SAML -based Sign-on from the Mode dropdown.
9. Enter the required values in Domain and URLs. You should get these values from the application vendor.
a. To configure the application as SP -initiated SSO, the Sign-on URL it’s a required value. For some
applications, the Identifier is also a required value.
b. To configure the application as IdP -initiated SSO, the Reply URL it’s a required value. For some
10. Optional: click Show advanced URL settings if you want to see the non-required values.
11. In the User attributes, select the unique identifier for your users in the User Identifier dropdown.
12. Optional: click View and edit all other user attributes to edit the attributes to be sent to the application
in the SAML token when users sign in.
To add an attribute:
a. click Add attribute. Enter the Name and the select the Value from the dropdown.
b. Click Save. You see the new attribute in the table.
13. click Configure <application name> to access documentation on how to configure single sign-on in the
application. Also, you have the metadata URLs and certificate required to setup SSO with the application.
14. Click Save to save the configuration.
15. Assign users to the application.
Select User Identifier and add user attributes to be sent to the

application
To select the User Identifier or add user attributes, follow the steps below:
navigation menu.
6. Select the application you have configured single sign-on.
8. Under the User attributes section, select the unique identifier for your users in the User Identifier
dropdown. The selected option needs to match the expected value in the application to authenticate the user.
NOTE
Azure AD select the format for the NameID attribute (User Identifier) based on the value selected or the format
requested by the application in the SAML AuthRequest. For more information visit the article Single Sign-On SAML
protocol under the section NameIDPolicy.
9. To add user attributes, click View and edit all other user attributes to edit the attributes to be sent to the
application in the SAML token when users sign in.
Download the Azure AD metadata or certificate

To download the application metadata or certificate from Azure AD, follow the steps below:
navigation menu.
8. Go to SAML Signing Certificate section, then click Download column value. Depending on what the
application requires configuring single sign-on, you see either the option to download the Metadata XML or
the Certificate.
Azure AD also provides a URL to get the metadata. Follow this pattern to get the metadata URL specific to the
application:
https://login.microsoftonline.com/<Directory ID>/federationmetadata/2007-06/federationmetadata.xml?appid=
<Application ID>

navigation menu.
list.
you have selected.
Customizing the SAML claims sent to an application

To learn how to customize the SAML attribute claims sent to your application, see Claims mapping in Azure Active
Directory for more information.
Next steps
Problem configuring federated single sign-on for an
If you encounter a problem when configuring an application. Verify you have followed all the steps in the tutorial
for the application. In the application’s configuration, you have inline documentation on how to configure the
application. Also, you can access the List of tutorials on how to integrate SaaS apps with Azure Active Directory for
a detail step-by-step guidance.
Can’t add another instance of the application

To add a second instance of an application, you need to be able to:
Configure a unique identifier for the second instance. You won’t be able to configure the same identifier
used for the first instance.
Configure a different certificate than the one used for the first instance.
If the application doesn’t support any of the above. Then, you won’t be able to configure a second instance.
Can’t add the Identifier or the Reply URL

If you’re not able to configure the Identifier or the Reply URL, confirm the Identifier and Reply URL values match
the patterns pre-configured for the application.
To know the patterns pre-configured for the application:
1. Open the Azure portal and sign in as a Global Administrator or Co-admin. Go to step 7. If you are
already in the application configuration blade on Azure AD.
navigation menu.
9. Go to the Identifier or Reply URL textbox, under the Domain and URLs section.
10. There are three ways to know the supported patterns for the application:
In the textbox, you see the supported pattern(s) as a placeholder Example: https://contoso.com.
if the pattern is not supported, you see a red exclamation mark when you try to enter the value in the
textbox. If you hover your mouse over the red exclamation mark, you see the supported patterns.
In the tutorial for the application, you can also get information about the supported patterns. Under
the Configure Azure AD single sign-on section. Go to the step for configured the values under the
Domain and URLs section.
If the values don’t match with the patterns pre-configured on Azure AD. You can:
Work with the application vendor to get values that match the pattern pre-configured on Azure AD
Or, you can contact Azure AD team at aadapprequest@microsoft.com or leave a comment in the tutorial to
request the update of the supported patterns for the application
Where do I set the EntityID (User Identifier) format

You won’t be able to select the EntityID (User Identifier) format that Azure AD sends to the application in the
response after user authentication.
requested by the application in the SAML AuthRequest. For more information visit the article Single Sign-On
SAML protocol under the section NameIDPolicy,
Can’t find the Azure AD metadata to complete the configuration with

the application
To download the application metadata or certificate from Azure AD, follow these steps:
navigation menu.
the Certificate.
Azure AD doesn’t provide a URL to get the metadata. The metadata can only be retrieved as a XML file.
Don't know how to customize SAML claims sent to an application

Next steps
How to configure federated single sign-on for a non-
gallery application
To configure single sign-on for a non-gallery application without writing code, you need to have a subscription or
Azure AD Premium and the application must support SAML 2.0. For more information about Azure AD versions,
visit Azure AD pricing.

Below is a high-level overview of the steps required to configure federated single sign-on with SAML 2.0 for a
non-gallery (e.g. custom) application.
Configuring single sign-on to non-gallery applications

To configure single sign-on for an application that is not in the Azure AD gallery, follow the steps below:
navigation menu.
6. click Non-gallery application in the Add your own app section
7. Enter the name of the application in the Name textbox.
10. Select SAML -based Sign-on in the Mode dropdown.
a. To configure the application as IdP -initiated SSO, enter the Reply URL and the Identifier.
b. Optional: To configure the application as SP -initiated SSO, the Sign-on URL it’s a required value.
application. Also, you has Azure AD URLs and certificate required for the application.
Select User Identifier and add user attributes to be sent to the

application
navigation menu.
NOTE

navigation menu.
the Certificate.
Azure AD also provides a URL to get the metadata. Follow this pattern to get the metadata URL specific to the
application: https://login.microsoftonline.com//federationmetadata/2007-06/federationmetadata.xml?appid=.

navigation menu.
list.
you have selected.
Customizing the SAML claims sent to an application

Next steps
Problem configuring federated single sign-on for a
non-gallery application
If you encounter a problem when configuring an application. Verify you have followed all the steps in the article
Configuring single sign-on to applications that are not in the Azure Active Directory application gallery.
Can’t add another instance of the application

To add a second instance of an application, you need to be able to:
Configure a unique identifier for the second instance. You cannot configure the same identifier used for the
first instance.
Configure a different certificate than the one used for the first instance.
If the application doesn’t support any of the preceding, you cannot configure a second instance.
Where do I set the EntityID (User Identifier) format

You cannot select the EntityID (User Identifier) format that Azure AD sends to the application in the response after
user authentication.
Azure AD selects the format for the NameID attribute (User Identifier) based on the value selected or the format
SAML protocol under the section NameIDPolicy,
Where do I get the application metadata or certificate from Azure AD

To download the application metadata or certificate from Azure AD, follow these steps:
navigation menu.
the Certificate.
Azure AD doesn’t provide a URL to get the metadata. The metadata can only be retrieved as an XML file.
Don't know how to customize SAML claims sent to an application
Next steps
How to configure password single sign-on for an
When you add an application from the Azure AD Application Gallery, you have the choice of how you want your
users to sign in to that application. You can configure this choice at any time by selecting the Single Sign-on
navigation item on an Enterprise Application in the Azure portal.
One of the single sign-on methods available to you is the Password-Based Single Sign-on option. This is a great
way to get started integrating applications into Azure AD quickly, and allows you to:
Enable Single Sign-on for your users by securely storing and replaying usernames and passwords for the
application you’ve integrated with Azure AD
Support applications that require multiple sign-in fields for applications that require more than just
username and password fields to sign in
Customize the labels of the username and password input fields your users see on the Application Access
Panel when they enter their credentials
Allow your users to provide their own usernames and passwords for any existing application accounts they
are typing in manually on the Application Access Panel
Allow a member of the business group to specify the usernames and passwords assigned to a user by
using the Self-Service Application Access feature
Allow an administrator to specify the usernames and passwords assigned to a user by using the Update
Credentials feature when assigning a user to an application
Allow an administrator to specify the shared username or password used by a group of people by using
the Update Credentials feature when assigning a group to an application
The following section describes how you can enable Password-Based Single Sign-on to an application that is
already in the Azure AD Application Gallery.

Configure the application for password single sign-on
Assign the application to a user or a group
Assign a user to an application directly
Assign an application to a group directly

To add an application from the Azure AD Gallery, follow these steps:
navigation menu.
After a short period, you can see the application’s configuration pane.

To configure single sign-on for an application, follow these steps:
navigation menu.
6. Select the application you want to configure single sign-on
8. Select the mode Password-based Sign-on.
10. Additionally, you can also provide credentials on behalf of the user by selecting the rows of the users and
clicking on Update Credentials and entering the username and password on behalf of the users.
Otherwise, users be prompted to enter the credentials themselves upon launch.

navigation menu.
list.
you have selected.

navigation menu.
list.
After a short period, the users you have selected be able to launch these applications in the Access Panel.
Next steps
Problem configuring password single sign-on for an
This article helps you understand the common problems people face when configuring Password Single Sign-on
with an Azure AD Gallery application.
Credentials are filled in, but the extension does not submit them
This problem typically happens if the application vendor has changed their sign-in page recently to add a field,
changed an identifier used for detecting the username and password fields, or modified how the sign-in experience
works for their application. Fortunately, in many instances, Microsoft can work with application vendors to rapidly
resolve these issues.
While Microsoft has technologies to automatically detect when integrations break, it might not be possible to find
the issues right away, or the issues take some time to fix. In the case when one of these integrations does not work
correctly, open a support case so it can be fixed as quickly as possible.
If you are in contact with this application’s vendor, send them our way so Microsoft can work with them to
natively integrate their application with Azure Active Directory. You can send the vendor to the Listing your
application in the Azure Active Directory application gallery to get them started.
Credentials are filled in and submitted, but the page indicates the
credentials are incorrect
To resolve this issue, first try these things:
Have the user first try to sign in to the application website directly with the credentials stored for them.
If sign-in works, then have the user click the Update credentials button on the Application Tile in
the Apps section of the Application Access Panel to update them to the latest known working
username and password.
If you, or another administrator assigned the credentials for this user, find the user or group’s
application assignment by navigating to the Users & Groups tab of the application, selecting the
assignment and clicking the Update Credentials button.
If the user assigned their own credentials, have the user check to be sure that their password has not
expired in the application and if so, update their expired password by signing in to the application
directly.
After the password has been updated in the application, request the user to click the Update
credentials button on the Application Tile in the Apps section of the Application Access Panel to
update them to the latest known working username and password.
If you, or another administrator assigned the credentials for this user, find the user or group’s
application assignment by navigating to the Users & Groups tab of the application, selecting the
assignment and clicking the Update Credentials button.
Have the user update the access panel browser extension by following the steps below in the How to install
the Access Panel Browser extension section.
Ensure that the access panel browser extension is running and enabled in your user’s browser.
Ensure that your users are not trying to sign in to the application from the access panel while in incognito,
inPrivate, or Private mode. The access panel extension is not supported in these modes.
In case the previous suggestions do not work, it could be the case that a change has occurred on the application
side that has temporarily broken the application’s integration with Azure AD. For example, this can occur when the
application vendor introduces a script on their page which behaves differently for manual vs automated input,
which causes automated integration, like our own, to break. Fortunately, in many instances, Microsoft can work
with application vendors to rapidly resolve these issues.
While Microsoft has technologies to automatically detect when application integrations break, it might not be
possible to find the issues right away, or the issues might take some time to fix. When an integration does not work
correctly, you can open a support case to get it fixed as quickly as possible.
In addition to this, if you are in contact with this application’s vendor, send them our way so we can work
with them to natively integrate their application with Azure Active Directory. You can send the vendor to the Listing
your application in the Azure Active Directory application gallery to get them started.
The extension works in Chrome and Firefox, but not in Internet

Explorer
There are two main causes to this issue:
Depending on the security settings enabled in Internet Explorer, if the website is not part of a Trusted Zone,
sometimes our script be blocked from executing for the application.
To resolve this, instruct the user to Add the application’s website to the Trusted Sites list within their
Internet Explorer security settings. You can send your users to the How to add a site to my trusted
sites list article for detailed instructions.
In rare circumstances, Internet Explorer’s security validation can sometimes cause the page to load more
slowly than the execution of our script.
Unfortunately, this situation can vary depending on the browser version, computer speed, or site visited.
In this case, we suggest that you contact support so we can fix the integration for this specific application.
Check if the application’s login page has changed recently or requires

an additional field
If the application’s login page has changed drastically, sometimes this causes our integrations to break. An example
of this is when an application vendor adds a sign-in field, a captcha, or multi-factor authentication to their
experiences. Fortunately, in many instances, Microsoft can work with application vendors to rapidly resolve these
issues.
While Microsoft has technologies to automatically detect when application integrations break, it might not be
possible to find the issues right away, or the issues might take some time to fix. When an integration does not work
correctly, you can open a support case to get it fixed as quickly as possible.
How to install the Access Panel Browser extension
To install the Access Panel Browser extension, follow the steps below:
1. Open the Access Panel in one of the supported browsers and sign in as a user in your Azure AD.
2. click a password-SSO application in the Access Panel.
3. In the prompt asking to install the software, select Install Now.
4. Based on your browser, you are directed to the download link. Add the extension to your browser.
5. If your browser asks, select to either Enable or Allow the extension.
6. Once installed, restart your browser session.
7. Sign in into the Access Panel and see if you can launch your password-SSO applications
You may also download the extension for Chrome and Firefox from the direct links below:
Chrome Access Panel Extension
Firefox Access Panel Extension
Next steps
How to configure password single sign-on for a non-
gallery application
In addition to the choices found within the Azure AD Application Gallery, you also have the option to add a non-
gallery application when the application you want is not listed there. Using this capability, you can add any
application that already exists in your organization, or any third-party application that you might use from a vendor
who is not already part of the Azure AD Application Gallery.
Once you add a non-gallery application, you can then configure the Single sign-on method this application uses by
selecting the Single Sign-on navigation item on an Enterprise Application in the Azure portal.
One of the Single Sign-on methods available to you is the Password-Based Single Sign-on option. With the add a
non-gallery application experience, you can integrate any application that renders an HTML -based username
and password input field, even if it is not in our set of pre-integrated applications.
The way this works is by a page scraping technology that is part of the Access Panel extension that allows us to
auto-detect username and password input fields, store them securely for your specific application instance. Then
securely replay usernames and passwords to those fields when a user navigates to that application on the
application access panel.
This is a great way to get started integrating any kind of application into Azure AD quickly, and allows you to:
Integrate any application in the world with your Azure AD tenant, so long as it renders an HTML
username and password input field
Enable Single Sign-on for your users by securely storing and replaying usernames and passwords for the
application you’ve integrated with Azure AD
Auto-detect input fields for any application and allow you to manually detect those fields using the Access
Panel Browser Extension, in case auto-detection does not find them
Support applications that require multiple sign-in fields for applications that require more than just
username and password fields to sign in
Customize the labels of the username and password input fields your users see on the Application Access
Panel when they enter their credentials
Allow your users to provide their own usernames and passwords for any existing application accounts they
are typing in manually on the Application Access Panel
Allow a member of the business group to specify the usernames and passwords assigned to a user by
using the Self-Service Application Access feature
Allow an administrator to specify the usernames and passwords assigned to a user by using the Update
Credentials feature when assigning a user to an application
Allow an administrator to specify the shared username or password used by a group of people by using
the Update Credentials feature when assigning a group to an application
The following section describes how you can enable Password-Based Single Sign-on to any application that you
add using the add a non-gallery application experience.
Add a non-gallery application
Assign the application to a user or a group

navigation menu.
6. click Non-gallery application.
7. Enter the name of your application in the Name textbox. Select Add.
After a short period, you be able to see the application’s configuration pane.

navigation menu.
9. Enter the Sign-on URL. This is the URL where users enter their username and password to sign in to.
Ensure the sign-in fields are visible at the URL.

navigation menu.
list.
you have selected.

navigation menu.
list.
Next steps
Problem configuring password single sign-on for a
non-gallery application
This article help you to understand the common problems people face when configuring Password single sign-
on with a non-gallery application.
How to capture sign-in fields for an application

Sign-in field capture is only supported for HTML -enabled sign-in pages and is not supported for non-standard
sign-in pages, like those that use Flash, or other non-HTML -enabled technologies.
There are two ways you can capture sign-in fields for your custom applications:
Automatic sign-in field capture
Manual sign-in field capture
Automatic sign-in field capture works well with most HTML -enabled sign-in pages, if they use well-known
DIV IDs for the username and password input field. The way this works is by scraping the HTML on the page
to find DIV IDs that match certain criteria and by then saving that metadata for this application to replay
passwords to it later.
Manual sign-in field capture can be used in the case that the application vendor does not label the input fields
used for sign-in. Manual sign-in field capture can also be used in the case when the vendor renders multiple
fields that cannot be auto-detected. Azure AD can store data for as many fields as are on the sign-in page, so long
as you tell us where those fields are on the page.
In general, if automatic sign-in field capture does not work, try the manual option.
How to automatically capture sign-in fields for an application
To configure Password-based Single Sign-on for an application using automatic sign-in field capture, follow
the steps below:
navigation menu.
9. Enter the Sign-on URL, the URL where users enter their username and password to sign in. Ensure the
sign-in fields are visible at the URL you provide.
10. Click the Save button.
11. Once you do that, that URL is automatically scraped for a username and password input box and allow you
to use Azure AD to securely transmit passwords to that application using the access panel browser
extension.
How to manually capture sign-in fields for an application

To manually capture sign-in fields, you must first have the Access Panel Browser extension installed and not be
running in inPrivate, incognito, or private mode. To install the browser extension, follow the steps in the How
to install the Access Panel Browser extension section.
To configure Password-based Single Sign-on for an application using manual sign-in field capture, follow the
steps below:
navigation menu.
sign-in fields are visible at the URL you provide.
10. Click the Save button.
11. Once you do that, that URL is automatically scraped for a username and password input box and allow you
to use Azure AD to securely transmit passwords to that application using the access panel browser
extension. In the case of failure, you can change the sign-in mode to use manual sign-in field capture
by continuing to step 12.
12. click Configure <appname> Password Single Sign-on Settings.
13. Select the Manually detect sign-in fields configuration option.
14. Click Ok.
15. Click Save.
16. Follow the on screen instructions to use the Access Panel.
I see a “We couldn’t find any sign-in fields at that URL” error
You see this error when automatic detection of sign-in fields fails. To resolve the issue, try manual sign-in field
detection by following the steps in the How to manually capture sign-in fields for an application section.
I see an “Unable to save Single Sign-on configuration” error
In certain rare cases, updating the single sign-on configuration can fail. To resolve, try saving the single sign-on
configuration again.
If it continues to fail consistently, open a support case and provide the information gathered in the How to see the
details of a portal notification and How to get help by sending notification details to a support engineer sections.
I cannot manually detect sign-in fields for my application

Some of the behaviors you might see when manual detection is not working include:
The manual capture process appeared to work, but the fields captured were not correct
The right fields don’t get highlighted when performing the capture process
The capture process takes me to the application’s login page as expected, but nothing happens
Manual capture appears to work, but SSO doesn’t happen when my users navigate to the application from
the Access Panel.
check the following if you encounter any of these issues:
Ensure that you have the latest version of the access panel browser extension installed and enabled by
following the steps in the How to install the Access Panel Browser extension section.
Ensure that you are not attempting the capture process while your browser in incognito, inPrivate, or
Private mode. The access panel extension is not supported in these modes.
Ensure that your users are not trying to sign in to the application from the access panel while in incognito,
inPrivate, or Private mode. The access panel extension is not supported in these modes.
Try the manual capture process again, ensuring the red markers are over the correct fields.
If the manual capture process seems to hang, or the sign-in page doesn’t do anything (case 3 above), try the
manual capture process again. But, this time after completing the process, press the F12 button to open your
browser’s developer console. Once there, open the console and type window.location="<enter the sign-
in url you specified when configuring the app>" and then press Enter. This forces a page redirect that
ends the capture process and stores the fields that have been captured.
If none of these approaches work for you, support can help. Open a support case with the details of what you tried,
as well as the information gathered in the How to see the details of a portal notification and How to get help by
sending notification details to a support engineer sections (if applicable).

4. Based on your browser you be directed to the download link. Add the extension to your browser.
7. Sign in into the Access Panel and see if you can launch your password-SSO applications.

1. click the Notifications icon (the bell) in the upper right of the Azure portal
!NOTE ] You cannot click notifications in a Successful or In Progress state.
3. The Notification Details pane opens.

4. Use the information yourself to understand more details about the problem.
5. If you still need help, you can also share the information with a support engineer or the product group to get
help with your problem.

they can help you quickly. You can take a screenshot, or click the Copy error icon, found to the right of the Copy
error textbox.

The below explains more what each of the notification items means, and gives examples of each of them.
Notification ID – the unique id of the notification
Client Request ID – the specific request id made by your browser
Example – 2017-03-23T19:50:43.7583681Z
Internal Transaction ID – the internal ID used to look the error up in our systems
Example – 17f84be4-51f8-483a-b533-383791227a99
Example – **Application proxy settings*
Example – **Failed*
share with a support or product group engineer
Example –
Next steps
Kerberos Constrained Delegation for single sign-
on to your apps with Application Proxy
You can provide single sign-on for on-premises applications published through Application Proxy that are
secured with Integrated Windows Authentication. These applications require a Kerberos ticket for access.
Application Proxy uses Kerberos Constrained Delegation (KCD ) to support these applications.
You can enable single sign-on to your applications using Integrated Windows Authentication (IWA) by giving
Application Proxy connectors permission in Active Directory to impersonate users. The connectors use this
permission to send and receive tokens on their behalf.
How single sign-on with KCD works

This diagram explains the flow when a user attempts to access an on premises application that uses IWA.
1. The user enters the URL to access the on premises application through Application Proxy.
2. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this
point, Azure AD applies any applicable authentication and authorization policies, such as multifactor
authentication. If the user is validated, Azure AD creates a token and sends it to the user.
3. The user passes the token to Application Proxy.
4. Application Proxy validates the token and retrieves the User Principal Name (UPN ) from it, and then
sends the request, the UPN, and the Service Principal Name (SPN ) to the Connector through a dually
authenticated secure channel.
5. The Connector performs Kerberos Constrained Delegation (KCD ) negotiation with the on premises AD,
impersonating the user to get a Kerberos token to the application.
6. Active Directory sends the Kerberos token for the application to the Connector.
7. The Connector sends the original request to the application server, using the Kerberos token it received
from AD.
8. The application sends the response to the Connector, which is then returned to the Application Proxy
service and finally to the user.
Prerequisites
Before you get started with single sign-on for IWA applications, make sure your environment is ready with
the following settings and configurations:
Your apps, like SharePoint Web apps, are set to use Integrated Windows Authentication. For more
information, see Enable Support for Kerberos Authentication, or for SharePoint see Plan for Kerberos
authentication in SharePoint 2013.
All your apps have Service Principal Names.
The server running the Connector and the server running the app are domain joined and part of the same
domain or trusting domains. For more information on domain join, see Join a Computer to a Domain.
The server running the Connector has access to read the TokenGroupsGlobalAndUniversal attribute for
users. This default setting might have been impacted by security hardening the environment.
Configure Active Directory
The Active Directory configuration varies, depending on whether your Application Proxy connector and the
application server are in the same domain or not.
Connector and application server in the same domain
1. In Active Directory, go to Tools > Users and Computers.
2. Select the server running the connector.
3. Right-click and select Properties > Delegation.
4. Select Trust this computer for delegation to specified services only.
5. Under Services to which this account can present delegated credentials add the value for the
SPN identity of the application server. This enables the Application Proxy Connector to impersonate
users in AD against the applications defined in the list.
Connector and application server in different domains

1. For a list of prerequisites for working with KCD across domains, see Kerberos Constrained Delegation
across domains.
2. Use the principalsallowedtodelegateto property on the Connector server to enable the Application Proxy
to delegate for the Connector server. The application server is sharepointserviceaccount and the
delegating server is connectormachineaccount . For Windows 2012 R2, use this code as an example:
$connector= Get-ADComputer -Identity connectormachineaccount -server dc.connectordomain.com
Set-ADComputer -Identity sharepointserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
Get-ADComputer sharepointserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
sharepointserviceaccount can be the SPS machine account or a service account under which the SPS app
pool is running.

1. Publish your application according to the instructions described in Publish applications with Application
Proxy. Make sure to select Azure Active Directory as the Preauthentication Method.
2. After your application appears in the list of enterprise applications, select it and click Single sign-on.
3. Set the single sign-on mode to Integrated Windows Authentication.
4. Enter the Internal Application SPN of the application server. In this example, the SPN for our published
application is http/www.contoso.com. This SPN needs to be in the list of services to which the connector
can present delegated credentials.
5. Choose the Delegated Login Identity for the connector to use on behalf of your users. For more
information, see Working with different on-premises and cloud identities
SSO for non-Windows apps

The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in
the cloud. Once the request arrives on-premises, the Azure AD Application Proxy connector issues a
Kerberos ticket on behalf of the user by interacting with the local Active Directory. This process is referred to
as Kerberos Constrained Delegation (KCD ). In the next phase, a request is sent to the backend application
with this Kerberos ticket.
There are several protocols that define how to send such requests. Most non-Windows servers expect to
negotiate with SPNEGO. This protocol is supported on Azure AD Application Proxy, but is disabled by
default. A server can be configured for SPNEGO or standard KCD, but not both.
If you configure a connector machine for SPNEGO, make sure that all other connectors in that Connector
group are also configured with SPNEGO. Applications expecting standard KCD should be routed through
other connectors that are not configured for SPNEGO.
To enable SPNEGO:
1. Open an command prompt that runs as administrator.
2. From the command prompt, run the following commands on the connector servers that need
SPNEGO.
REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft AAD App Proxy Connector" /v UseSpnegoAuthentication /t

REG_DWORD /d 1
net stop WAPCSvc & net start WAPCSvc
For more information about Kerberos, see All you want to know about Kerberos Constrained Delegation
(KCD ).
Non-Windows apps typically user usernames or SAM account names instead of domain email addresses. If
that situation applies to your applications, you need to configure the delegated login identity field to connect
your cloud identities to your application identities.
Working with different on-premises and cloud identities

Application Proxy assumes that users have exactly the same identity in the cloud and on-premises. If that's
not the case, you can still use KCD for single sign-on. Configure a Delegated login identity for each
application to specify which identity should be used when performing single sign-on.
This capability allows many organizations that have different on-premises and cloud identities to have SSO
from the cloud to on-premises apps without requiring the users to enter different usernames and passwords.
This includes organizations that:
Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the
cloud (joe@contoso.com).
Have non-routable domain name internally (joe@contoso.usa) and a legal one in the cloud.
Do not use domain names internally (joe)
Use different aliases on premises and in the cloud. For example, joe-johns@contoso.com vs.
joej@contoso.com
With Application Proxy, you can select which identity to use to obtain the Kerberos ticket. This setting is per
application. Some of these options are suitable for systems that do not accept email address format, others
are designed for alternative login.
If delegated login identity is used, the value might not be unique across all the domains or forests in your
organization. You can avoid this issue by publishing these applications twice using two different Connector
groups. Since each application has a different user audience, you can join its Connectors to a different
domain.
Configure SSO for different identities
1. Configure Azure AD Connect settings so the main identity is the email address (mail). This is done as part
of the customize process, by changing the User Principal Name field in the sync settings. These settings
also determine how users log in to Office365, Windows10 devices, and other applications that use Azure
AD as their identity store.
2. In the Application Configuration settings for the application you would like to modify, select the
Delegated Login Identity to be used:
User Principal Name (for example, joe@contoso.com)
Alternate User Principal Name (for example, joed@contoso.local)
Username part of User Principal Name (for example, joe)
Username part of Alternate User Principal Name (for example, joed)
On-premises SAM account name (depends on the domain controller configuration)
Troubleshooting SSO for different identities
If there is an error in the SSO process, it appears in the connector machine event log as explained in
Troubleshooting. But, in some cases, the request is successfully sent to the backend application while this
application replies in various other HTTP responses. Troubleshooting these cases should start by examining
event number 24029 on the connector machine in the Application Proxy session event log. The user identity
that was used for delegation appears in the “user” field within the event details. To turn on session log, select
Show analytic and debug logs in the event viewer view menu.
Next steps
How to configure an Application Proxy application to use Kerberos Constrained Delegation
For the latest news and updates, check out the Application Proxy blog
Password vaulting for single sign-on with Application
Proxy
Azure Active Directory Application Proxy helps you improve productivity by publishing on-premises applications
so that remote employees can securely access them, too. In the Azure portal, you can also set up single sign-on
(SSO ) to these apps. Your users only need to authenticate with Azure AD, and they can access your enterprise
application without having to sign in again.
Application Proxy supports several single sign-on modes. Password-based sign-on is intended for applications that
use a username/password combination for authentication. When you configure password-based sign-on for your
application, your users have to sign in to the on-premises application once. After that, Azure Active Directory
stores the sign-in information and automatically provides it to the application when your users access it remotely.
You should already have published and tested your app with Application Proxy. If not, follow the steps in Publish
applications using Azure AD Application Proxy then come back here.
Set up password vaulting for your application

2. Select Azure Active Directory > Enterprise applications > All applications.
3. From the list, select the app that you want to set up with SSO.
4. Select Single sign-on.
5. For the SSO mode, choose Password-based Sign-on.

6. For the Sign-on URL, enter the URL for the page where users enter their username and password to sign in
to your app outside of the corporate network. This may be the External URL that you created when you
published the app through Application Proxy.
7. Select Save.
Test your app

Go to external URL that you configured for remote access to your application. Sign in with your credentials for that
app (or the credentials for a test account that you set up with access). Once you sign in successfully, you should be
able to leave the app and come back without entering your credentials again.
Next steps
Read about other ways to implement Single sign-on
Learn about Security considerations for accessing apps remotely with Azure AD Application Proxy
Header-based authentication for single sign-on with
Application Proxy and PingAccess
Azure Active Directory Application Proxy and PingAccess have partnered together to provide Azure Active
Directory customers with access to even more applications. PingAccess expands the existing Application Proxy
offerings to include single sign-on access to applications that use headers for authentication.
What is PingAccess for Azure AD?

PingAccess for Azure Active Directory is an offering of PingAccess that enables you to give users access and
single sign-on to applications that use headers for authentication. Application Proxy treats these apps like any
other, using Azure AD to authenticate access and then passing traffic through the connector service. PingAccess
sits in front of the apps and translates the access token from Azure AD into a header so that the application
receives the authentication in the format it can read.
Your users won’t notice anything different when they sign in to use your corporate apps. They can still work from
anywhere on any device.
Since the Application Proxy connectors direct remote traffic to all apps regardless of their authentication type,
they’ll continue to load balance automatically, as well.
How do I get access?

Since this scenario is offered through a partnership between Azure Active Directory and PingAccess, you need
licenses for both services. However, Azure Active Directory Premium subscriptions include a basic PingAccess
license that covers up to 20 applications. If you need to publish more than 20 header-based applications, you can
purchase an additional license from PingAccess.
For more information, see Azure Active Directory editions.
Publish your application in Azure

This article is intended for people who are publishing an app with this scenario for the first time. It walks through
how to get started with both Application and PingAccess, in addition to the publishing steps. If you’ve already
configured both services but want a refresher on the publishing steps, you can skip the connector installation and
move on to Add your app to Azure AD with Application Proxy.
NOTE
Since this scenario is a partnership between Azure AD and PingAccess, some of the instructions exist on the Ping Identity
site.
Install an Application Proxy connector

If you already have Application Proxy enabled, and have a connector installed, you can skip this section and move
on to Add your app to Azure AD with Application Proxy.
The Application Proxy connector is a Windows Server service that directs the traffic from your remote employees
to your published apps. For more detailed installation instructions, see Enable Application Proxy in the Azure
portal.
2. Select Azure Active Directory > Application proxy.
3. Select Download Connector to start the Application Proxy connector download. Follow the installation
instructions.
4. Downloading the connector should automatically enable Application Proxy for your directory, but if not
you can select Enable Application Proxy.
Add your app to Azure AD with Application Proxy
There are two actions you need to take in the Azure portal. First, you need to publish your application with
Application Proxy. Then, you need to collect some information about the app that you can use during the
PingAccess steps.
Follow these steps to publish your app. For a more detailed walkthrough of steps 1-8, see Publish applications
1. If you didn't in the last section, sign in to the Azure portal as a global administrator.
5. Fill out the required fields with information about your new app. Use the following guidance for the
settings:
Internal URL: Normally you provide the URL that takes you to the app’s sign in page when you’re
on the corporate network. For this scenario the connector needs to treat the PingAccess proxy as the
front page of the app. Use this format: https://<host name of your PA server>:<port> . The port is
3000 by default, but you can configure it in PingAccess.
WARNING
For this type of SSO, the internal URL must use https and cannot use http.
Pre-authentication method: Azure Active Directory

Translate URL in Headers: No
NOTE
If this is your first application, use port 3000 to start and come back to update this setting if you change your
PingAccess configuration. If this is your second or later app, this will need to match the Listener you’ve configured in
PingAccess. Learn more about listeners in PingAccess.
6. Select Add at the bottom of the blade. Your application is added, and the quick start menu opens.
9. On the app management blade, select Single sign-on.
10. Choose Header-based sign-on from the drop-down menu. Select Save.
TIP
If this is your first time using header-based single sign-on, you need to install PingAccess. To make sure your Azure
subscription is automatically associated with your PingAccess installation, use the link on this single sign-on page to
download PingAccess. You can open the download site now, or come back to this page later.
11. Close the Enterprise applications blade or scroll all the way to the left to return to the Azure Active
Directory menu.
12. Select App registrations.
13. Select the app you just added, then Reply URLs.
14. Check to see if the external URL that you assigned to your app in step 5 is in the Reply URLs list. If it’s not,
add it now.
15. On the app settings blade, select Required permissions.
16. Select Add. For the API, choose Windows Azure Active Directory, then Select. For the permissions,
choose Read and write all applications and Sign in and read user profile, then Select and Done.
17. Grant permissions before you close the permissions screen.
Collect information for the PingAccess steps

1. On your app settings blade, select Properties.
2. Save the Application Id value. This is used for the client ID when you configure PingAccess.
3. On the app settings blade, select Keys.
4. Create a key by entering a key description and choosing an expiration date from the drop-down menu.
5. Select Save. A GUID appears in the Value field.
Save this value now, as you won’t be able to see it again after you close this window.
6. Close the App registrations blade or scroll all the way to the left to return to the Azure Active Directory
menu.
7. Select Properties.
8. Save the Directory ID GUID.
Optional - Update GraphAPI to send custom fields
For a list of security tokens that Azure AD sends for authentication, see Azure AD token reference. If you need a
custom claim that sends other tokens, use Graph Explorer or the manifest for the application in the Azure Portal to
set the app field acceptMappedClaims to True.
This example uses Graph Explorer:
PATCH https://graph.windows.net/myorganization/applications/<object_id_GUID_of_your_application>
{
"acceptMappedClaims":true
}
This example uses the Azure portal to update the acceptedMappedClaims field:
2. Select Azure Active Directory > App registrations.
3. Select your application > Manifest.
4. Select Edit, search for the acceptedMappedClaims field and change the value to true.
5. Select Save.
NOTE
To use a custom claim, you must also have a custom policy defined and assigned to the application. This policy should
include all required custom attributes.
Policy definition and assignment can be done through PowerShell, Azure AD Graph Explorer, or MS Graph. If you are doing
this in PowerShell, you may need to first use New-AzureADPolicy and then assign it to the application with
Set-AzureADServicePrincipalPolicy . For more information see the Azure AD Policy documentation.
Optional - Use a custom claim

To make your application use a custom claim and include additional fields, be sure that you have also created a
custom claims mapping policy and assigned it to the application.
Download PingAccess and configure your app

Now that you've completed all the Azure Active Directory setup steps, you can move on to configuring
PingAccess.
The detailed steps for the PingAccess part of this scenario continue in the Ping Identity documentation, Configure
PingAccess for Azure AD.
Those steps walk you through the process of getting a PingAccess account if you don't already have one, installing
the PingAccess Server, and creating an Azure AD OIDC Provider connection with the Directory ID that you
copied from the Azure portal. Then, you use the Application ID and Key values to create a Web Session on
PingAccess. After that, you can set up identity mapping and create a virtual host, site, and application.
Test your app
When you've completed all these steps, your app should be up and running. To test it, open a browser and
navigate to the external URL that you created when you published the app in Azure. Sign in with the test account
that you assigned to the app.
Next steps
Configure PingAccess for Azure AD
How does Azure AD Application Proxy provide single sign-on?
Troubleshoot Application Proxy
Troubleshooting the Access Panel Extension for
Internet Explorer
This article helps you troubleshoot the following problems:

You're unable to access your apps through the My Apps portal while using Internet Explorer.
You see the "Install Software" message even though you've already installed the software.
If you are an admin, see also: How to Deploy the Access Panel Extension for Internet Explorer using Group Policy
Run the Diagnostic Tool

You can diagnose installation problems with the Access Panel Extension by downloading and running the Access
Panel diagnostic tool:
1. Click here to download the diagnostic tool.
2. Open the file, and press Extract all button.
3. Then press the Extract button to continue.

4. To run the tool, right-click the file named AccessPanelExtensionDiagnosticTool, then select Open with >
Microsoft Windows Based Script Host.
5. You will then see the following diagnostic window, which describes what might be wrong with your
installation.
6. Click "YES" to let the program fix the issues that have been found.
7. To save these changes, close every Internet Explorer window, and then open Internet Explorer again.
If you still can't access your apps, try the steps below.
Check that the Access Panel Extension is enabled

To verify that the Access Panel Extension is enabled in Internet Explorer:
1. In Internet Explorer, click the Gear icon on the top right corner of the window. Then select Internet
options.
(In older versions of Internet Explorer you can find this under Tools > Internet options.
2. Click the Programs tab, then click the Manage add-ons button.
3. In this dialog, select Access Panel Extension and then click the Enable button.
4. To save these changes, close every Internet Explorer window and then open Internet Explorer again.
Enable Extensions for InPrivate Browsing

If you are using the InPrivate Browsing mode:
1. In Internet Explorer, click the Gear icon on the top right corner of the window. Then select Internet
options.
(In older versions of Internet Explorer you can find this under Tools > Internet options.
2. Go to the Privacy tab, then uncheck the checkbox labeled Disable toolbars and extensions when
InPrivate Browsing starts
3. To save these changes, close every Internet Explorer window and then open Internet Explorer again.
Uninstall the Access Panel Extension

To uninstall the Access Panel extension from your computer:
1. On your keyboard, press the Windows key to open the Start menu. When the menu is open, you can type
anything to do a search. Type "Control Panel" and then open the Control Panel when it appears in the
search results.
2. In the top right corner of the Control Panel, change the View by option to Large icons. Then find and click
the Programs and Features button.
3. From the list, select Access Panel Extension, and the click the Uninstall button.
4. You can then try to install the extension again to see if the problem has been resolved.
If you encounter issues uninstalling the extension, you can also remove it using the Microsoft Fix It tool.
Related Articles
Application access and single sign-on with Azure Active Directory
How to Deploy the Access Panel Extension for Internet Explorer using Group Policy
An assigned application is not appearing on the
access panel
The Access Panel is a web-based portal, which enables a user with a work or school account in Azure Active
Directory (Azure AD ) to view and start cloud-based applications that the Azure AD administrator has granted them
access to. These applications are configured on behalf of the user in the Azure AD portal. The application must be
configured properly and assigned to the user or a group the user is a member of to see the application in the
Access Panel.
The type of apps a user may be seeing fall in the following categories:
Office 365 Applications
Microsoft and third-party applications configured with federation-based SSO
Password-based SSO applications
Applications with existing SSO solutions
General issues to check first

If an application was just added to a user, try to sign in and out again into the user’s Access Panel after a few
minutes to see if the application is added.
If a license was just removed from a user or group the user is a member of this may take a long time,
depending on the size and complexity of the group for changes to be made. Allow for extra time before
signing into the Access Panel.
Problems related to application configuration

An application may not be appearing in a user’s Access Panel because it is not configured properly. Below are some
ways you can troubleshoot issues related to application configuration:
How to configure federated single sign-on for an Azure AD gallery application
How to configure federated single sign-on for a non-gallery application
How to configure a password single sign-on application for an Azure AD gallery application
How to configure a password single sign-on application for a non-gallery application
How to configure federated single sign-on for an Azure AD gallery application
All applications in the Azure AD gallery enabled with Enterprise Single Sign-On capability has a step-by-step
navigation menu.
navigation menu.
a. To configure the application as SP -initiated SSO, the Sign on URL it’s a required value. For some
b. To configure the application as IdP -initiated SSO, the Reply URL it’s a required value. For some
b. click Save. You see the new attribute in the table.
application. Also, you have the metadata URLs and certificate required to set up SSO with the application.
14. click Save to save the configuration.
navigation menu.
If you do not see the application you want to show up here, use the Filter control at the top of the All
NOTE
b. click Save. You will see the new attribute in the table.
navigation menu.
the Certificate.
To configure a non-gallery application, you need to have Azure AD premium and the application supports SAML
2.0. For more information about Azure AD versions, visit Azure AD pricing.
Configure the application’s metadata values in Azure AD (Sign on URL, Identifier, Reply URL)
navigation menu.
6. click Non-gallery application in the Add your own app section.
10. Select SAML -based Sign-on in the Mode dropdown.
b. Optional: To configure the application as SP -initiated SSO, the Sign on URL it’s a required value.
application. Also, you have Azure AD URLs and certificates required for the application.
navigation menu.
NOTE
navigation menu.
the Certificate.
How to configure password single sign-on for an Azure AD gallery application
navigation menu.
navigation menu.
How to configure password single sign-on for a non-gallery application
navigation menu.
navigation menu.
a. If you do not see the application you want show up here, use the Filter control at the top of the All
Ensure the sign-in fields are visible at the URL.
Problems related to assigning applications to users
A user may not be seeing an application on their Access Panel because they are not assigned to the application.
Below are some ways to check:
Check if a user is assigned to the application
How to assign a user to an application directly
Check if a user is assigned to a license related to the application
How to assign a license to a user
To check if a user is assigned to the application, follow the steps below:
navigation menu.
6. Search for the name of the application in question.
7. click Users and groups.
8. Check to see if your user is assigned to the application.
If not follow the steps in “How to assign a user to an application directly” to do so.
navigation menu.
list.
you have selected.
Check if a user is under a license related to the application
To check a user’s assigned licenses, follow the steps below:
navigation menu.
5. click All users.
6. Search for the user you are interested in and click the row to select.
7. click Licenses to see which licenses the user currently has assigned.
If the user is assigned to an Office license this enables First Party Office applications to appear on the
user’s Access Panel.
How to assign a user a license
To assign a license to a user, follow the steps below:
navigation menu.
5. click All users.
8. click the Assign button.
9. Select one or more products from the list of available products.
10. Optional click the assignment options item to granularly assign products. Click Ok when this is
completed.
11. Click the Assign button to assign these licenses to this user.
Problems related to assigning applications to groups
A user may be seeing an application on their Access Panel because they are part of a group that has been assigned
the application. Below are some ways to check:
Check a user’s group memberships
How to assign an application to a group directly
Check if a user is part of group assigned to a license
How to assign a license to a group
To check a group’s membership, follow the steps below:
navigation menu.
5. click All users.
7. click Groups.
8. Check to see if your user is part of a Group assigned to the application.
If you want to remove the user from the group, click the row of the group and select delete.
How to assign an application to a group directly
To assign one or more groups to an application directly, follow the steps below:
navigation menu.
list.
Check if a user is part of group assigned to a license
navigation menu.
5. click All users.
7. click Groups.
8. click the row of a specific group.
9. click Licenses to see which licenses the group has assigned to it.
If the group is assigned to an Office license this may enable certain First Party Office applications to
appear on the user’s Access Panel.
How to assign a license to a group
To assign a license to a group, follow the steps below:
navigation menu.
5. click All groups.
6. Search for the group you are interested in and click the row to select.
7. click Licenses to see which licenses the group currently has assigned.
completed.
11. Click the Assign button to assign these licenses to this group. This may take a long time, depending on the
size and complexity of the group.
NOTE
To do this faster, consider temporarily assigning a license to the user directly.
Next steps
Add new users to Azure Active Directory
How applications appear on the access panel
The Access Panel is a web-based portal, which enables a user with a work or school account in Azure Active
access to. These applications are configured on behalf of the user in the Azure AD portal. The admin can provision
the application to the user directly or to a group a user is part of resulting in the application appearing on the user’s
Access Panel.

If an application was removed from a user or group the user is a member of, try to sign in and out again into
the user’s Access Panel after a few minutes to see if the application is removed.
If a license was removed from a user or group the user is a member of this may take a long time, depending
on the size and complexity of the group for changes to be made. Allow for extra time before signing into the
Access Panel.
Problems related to assigning applications to users

A user may be seeing an application on their Access Panel because they had been previously assigned to it.
Following are some ways to check:
To check if a user is assigned to the application, follow these steps:
navigation menu.
6. Search for the name of the application in question.
7. click Users and groups.
8. Check to see if your user is assigned to the application.
If you want to remove the user from the application, click the row of the user and select delete.
To check a user’s assigned licenses, follow these steps:
navigation menu.
5. click All users.
If the user is assigned to an Office license, this enables First Party Office applications to appear on the
user’s Access Panel.
Problems related to assigning applications to groups

A user may be seeing an application on their Access Panel because they are part of a group that has been assigned
the application. Following are some ways to check:
Check if a user is a member of a group assigned to a license
To check a group’s membership, follow these steps:
navigation menu.
5. click All users.
7. click Groups.
8. Check to see if your user is part of a Group assigned to the application.
If you want to remove the user from the group, click the row of the group and select delete.
Check if a user is a member of a group assigned to a license
navigation menu.
5. click All users.
7. click Groups.
8. click the row of a specific group.
9. click Licenses to see which licenses the group has assigned to it.
If the group is assigned to an Office license, this may enable certain First Party Office applications to
appear on the user’s Access Panel.
If these troubleshooting steps do not the resolve the issue

open a support ticket with the following information if available:
Correlation error ID
UPN (user email address)
Tenant ID
Browser type
Time zone and time/timeframe during error occurs
Fiddler traces
Next steps
Problem signing in to the access panel website
The Access Panel is a web-based portal that enables a user who has a work or school account in Azure Active
Directory (Azure AD ) to view and launch cloud-based applications that the Azure AD administrator has granted
them access to. A user who has Azure AD editions can also use self-service group and app management
capabilities through the Access Panel. The Access Panel is separate from the Azure portal and does not require
users to have an Azure subscription.
Users can sign in to the Access Panel if they have a work or school account in Azure AD.
Users can be authenticated by Azure AD directly.
Users can be authenticated by using Active Directory Federation Services (AD FS ).
Users can be authenticated by Windows Server Active Directory.
If a user has a subscription for Azure or Office 365 and has been using the Azure portal or an Office 365
application, they'll be able to use the Access Panel seamlessly without needing to sign in again. Users who are not
authenticated are prompted to sign in by using the username and password for their account in Azure AD. If the
organization has configured federation, typing the username is sufficient.

Make sure the user is signing in to the correct URL: https://myapps.microsoft.com
Make sure the user’s browser has added the URL to its trusted sites
Make sure the user’s account is enabled for sign-ins.
Make sure the user’s account is not locked out.
Make sure the user’s password is not expired or forgotten.
Make sure Multi-Factor Authentication is not blocking user access.
Make sure a Conditional Access policy or Identity Protection policy is not blocking user access.
Make sure that a user’s authentication contact info is up-to-date to allow Multi-Factor Authentication or
Conditional Access policies to be enforced.
Make sure to also try clearing your browser’s cookies and trying to sign in again.
Meeting browser requirements for the Access Panel

The Access Panel requires a browser that supports JavaScript and has CSS enabled. To use password-based single
sign-on (SSO ) in the Access Panel, the Access Panel extension must be installed in the user’s browser. This
extension is downloaded automatically when a user selects an application that is configured for password-based
SSO.
For password-based SSO, the end user’s browsers can be:
Internet Explorer 8, 9, 10, 11 -- on Windows 7 or later
Chrome -- on Windows 7 or later, and on MacOS X or later
Firefox 26.0 or later -- on Windows XP SP2 or later, and on Mac OS X 10.6 or later
Problems with the user’s account

Access to the Access Panel can be blocked due to a problem with the user’s account. Following are some ways you
can troubleshoot and solve problems with users and their account settings:
Check if a user account exists in Azure Active Directory
Check a user’s account status
Reset a user’s password
Enable self-service password reset
Check a user’s multi-factor authentication status
Check a user’s authentication contact info
Check a user’s assigned licenses
Assign a user a license
To check if a user’s account is present, follow these steps:
navigation menu.
5. click All users.
7. Check the properties of the user object to be sure that they look as you expect and no data is missing.
To check a user’s account status, follow these steps:
navigation menu.
5. click All users.
7. click Profile.
8. Under Settings ensure that Block sign in is set to No.
To reset a user’s password, follow these steps:
navigation menu.
5. click All users.
7. click the Reset password button at the top of the user pane.
8. click the Reset password button on the Reset password pane that appears.
9. Copy the temporary password or enter a new password for the user.
10. Communicate this new password to the user, they be required to change this password during their next
sign-in to Azure Active Directory.
To enable self-service password reset, follow these deployment steps:
Enable users to reset their Azure Active Directory passwords
Enable users to reset or change their Active Directory on-premises passwords
To check a user’s multi-factor authentication status, follow these steps:
navigation menu.
5. click All users.
6. click the Multi-Factor Authentication button at the top of the pane.
7. Once the Multi-Factor Authentication Administration Portal loads, ensure you are on the Users tab.
8. Find the user in the list of users by searching, filtering, or sorting.
9. Select the user from the list of users and Enable, Disable, or Enforce multi-factor authentication as
desired.
NOTE
If a user is in an Enforced state, you may set them to Disabled temporarily to let them back into their account. Once
they are back in, you can then change their state to Enabled again to require them to re-register their contact
information during their next sign-in. Alternatively, you can follow the steps in the Check a user’s authentication
contact info to verify or set this data for them.
To check a user’s authentication contact info used for Multi-factor authentication, Conditional Access, Identity
Protection, and Password Reset, follow these steps:
navigation menu.
5. click All users.
7. click Profile.
8. Scroll down to Authentication contact info.
9. Review the data registered for the user and update as needed.
To check a user’s group memberships, follow these steps:
navigation menu.
5. click All users.
7. click Groups to see which groups the user is a member of.
navigation menu.
5. click All users.
To assign a license to a user, follow these steps:
navigation menu.
5. click All users.
completed.
If these troubleshooting steps do not resolve the issue

Tenant ID
Browser type
Fiddler traces
Next steps
Install the access panel browser extension
The access panel is a web-based portal. If you have a work or school account in Azure Active Directory (Azure AD ),
you can use the access panel to view and start cloud-based applications that an Azure AD administrator has
granted you access to.
If you're using Azure AD editions, you can also use self-service group and app management capabilities through
the access panel.
The access panel is separate from the Azure portal. It does not require you to have an Azure subscription.
Web browser requirements

At minimum, the access panel requires a browser that supports JavaScript and has CSS enabled. To be signed in to
applications through password-based SSO in the access panel, you must have the access panel extension installed
in your browser. The extension is downloaded automatically when you select an application that's configured for
password-based SSO.
For password-based SSO, you can use any of the following browsers:
Microsoft Edge: on Windows 10 Anniversary Edition or later.
Chrome: on Windows 7 or later, and on MacOS X or later.
Firefox 26.0 or later: on Windows XP SP2 or later, and on Mac OS X 10.6 or later.
Install the access panel browser extension

To install the access panel browser extension, do the following:
1. In one of the supported browsers, open the access panel, and then sign in as a user in your Azure AD
account.
2. Select a password-based SSO application.
3. When you are prompted, select Install Now.
You are directed to the download link for your selected browser.
4. Select Add.
5. If you are prompted, either Enable or Allow the extension.
6. After installation is complete, restart your browser.
7. Sign in to the access panel, and check to see whether you can start your password-based SSO applications.
You can also download the extension for Chrome and Microsoft Edge directly from following sites:
Chrome extension
Microsoft Edge extension
Use the My Apps Secure Sign-in Extension

If you are using a My Apps URL other than https://myapps.microsoft.com , configure your default URL by
doing the following:
1. While you are not signed in to the extension, right-click the extension icon.
2. On the menu, select My Apps URL.
3. Select your default URL.
4. Select the extension icon.
5. To sign in to the extension, select Sign in to get started.
To sign in directly to an app from the browser, do the following:
1. After you install the extension, sign in to it by selecting Sign in to get started.
2. Sign in to the app with the sign-on URL.
The sign-on URL is usually the URL of the app that displays the sign-in form. The extension should
change state and let you know that a password is available.
3. To sign in, select the extension icon.
To start an app from the extension, do the following:
1. After you install the extension, sign in to it by selecting Sign in to get started.
2. Select the extension icon to open its menu.
3. Search for an app that's available in the My Apps portal.
4. In the search results list, select the app.
The last three apps you've used are displayed in the Recently Used shortcut list.
To use internal company URLs while remote, do the following:
1. Configure Application Proxy on your tenant
2. Publish the application and URL through Application Proxy
3. Install the extension, and sign in to it by selecting Sign in to get started
4. You can now browse to the internal company URL even while remote
NOTE
The preceding options are available only for Microsoft Edge, Chrome, and Firefox.
Set up a group policy for Internet Explorer

You can set up a group policy that allows you to remotely install the access panel extension for Internet Explorer on
your users' machines.
Before you set up a group policy, ensure that:
You have set up Active Directory Domain Services, and you have joined your users' machines to your
domain.
To edit the Group Policy Object (GPO ), you must have Edit settings permissions. By default, this permission
is granted to members of the following security groups: domain administrators, enterprise administrators,
and group policy creator owners.
For step by step instructions about configuring the group policy and deploying it to users, see Deploy the access
panel extension for Internet Explorer by using group policy.
Troubleshoot the access panel extension in Internet Explorer

For access to a diagnostics tool and information about configuring the extension for Internet Explorer, see
Troubleshoot the access panel extension for Internet Explorer.
NOTE
Internet Explorer is on limited support and no longer receives new software updates. Microsoft Edge is the recommended
browser.
If the preceding steps do not resolve the issue

Open a support ticket with the following information, if it is available:
TenantID
Browser type
Time zone and the time or timeframe when the error occurred
Fiddler traces
Next steps
What is application access and single sign-on with Azure Active Directory?
How to use self-service application access
This feature is a great way for you to save time and money as an IT group, and is highly recommended as part of a
modern applications deployment with Azure Active Directory.
Using this feature, you can:
Let users self-discover applications from the Application Access Panel without bothering the IT group.
Add those users to a pre-configured group so you can see who has requested access, remove access, and
manage the roles assigned to them.
Optionally allow a business approver to approve application access requests so the IT group doesn’t have to.
Optionally configure up to 10 individuals who may approve access to this application.
Optionally allow a business approver to set the passwords those users can use to sign in to the application,
right from the business approver’s Application Access Panel.
Optionally automatically assign self-service assigned users to an application role directly.
Enable self-service application access to allow users to find their own

applications
navigation menu.
approver may approve access to the application.
Next steps
Problem using self-service application access

Make sure self-service application access is configured correctly. See “How to configure self-service
application access”.
Make sure the user or group has been enabled to request self-service application access.
Make sure the user is visiting the correct place for self-service application access. users can navigate to their
Application Access Panel and click the +Add button to find the apps to which you have enabled self-service
access.
If self-service application access was just recently configured, try to sign in and out again into the user’s
Access Panel after a few minutes to see if the self-service access changes have appeared.
How to configure self-service application access

navigation menu.
NOTE
approver may approve access to the application.
If these troubleshooting steps do not resolve the issue

TenantID
Browser type
Fiddler traces
Next steps
Resources for migrating applications to Azure Active
Directory
Resources to help you migrate application access and authentication to Azure Active Directory (Azure AD ). Take
this short survey (https://aka.ms/AppsMigrationFeedback) to provide feedback on your experience migrating apps
to Azure AD (including blockers to migration, need for tooling / guidance, or reasons for retaining your on-
premises IDP ).
RESOURCE DESCRIPTION
Migrating your apps to Azure AD This white paper presents the benefits of migration, and
describes how to plan for migration in four clearly-outlined
phases: discovery, classification, migration, and ongoing
management. You’ll be guided through how to think about
the process and break down your project into easy-to-
consume pieces. Throughout the document are links to
important resources that will help you along the way.
Solution guide: Migrating apps from Active Directory This solution guide walks you through the same four phases
Federation Services (AD FS) to Azure AD of planning and executing an application migration project
described at a higher level in the migration whitepaper. In this
guide, you’ll learn how to apply those phases to the specific
goal of moving an application from Azure Directory Federated
Services (AD FS) to Azure AD.
Tool: Active Directory Federation Services Migration Readiness This is a script you can run on your on-premises Active
Script Directory Federation Services (AD FS) server to determine the
readiness of apps for migration to Azure AD.
Deployment plan: Migrating from AD FS to password hash With password hash synchronization, hashes of user
sync passwords are synchronized from on-premises Active
Directory to Azure AD. This allows Azure AD to authenticate
users without interacting with the on-premises Active
Directory.
Deployment plan: Migrating from AD FS to pass-through Azure AD pass-through authentication helps users sign in to
authentication both on-premises and cloud-based applications by using the
same password. This feature provides your users with a better
experience since they have one less password to remember. It
also reduces IT helpdesk costs because users are less likely to
forget how to sign in when they only need to remember one
password. When people sign in using Azure AD, this feature
validates users' passwords directly against your on-premises
Active Directory.
Deployment plan: Enabling Single Sign-on to a SaaS app with Single sign-on (SSO) helps you access all the apps and
Azure AD resources you need to do business, while signing in only once,
using a single user account. For example, after a user has
signed in, the user can move from Microsoft Office, to
SalesForce, to Box without authenticating (for example, typing
a password) a second time.
RESOURCE DESCRIPTION
Deployment plan: Extending apps to Azure AD with Providing access from employee laptops and other devices to
Application Proxy on-premises applications has traditionally involved virtual
private networks (VPNs) or demilitarized zones (DMZs). Not
only are these solutions complex and hard to make secure, but
they are costly to set up and manage. Azure AD Application
Proxy makes it easier to access on-premises applications.
Deployment plans Find more deployment plans for deploying features such as
multi-Factor authentication, conditional access, user
provisioning, seamless SSO, self-service password reset, and
more!
Move applications from AD FS to Azure AD
This article helps you understand how to move applications from AD FS to Azure Active Directory (Azure AD ). It
focuses on federated SaaS applications.
This article does not provide step-by-step guidance. It provides conceptual guidance to help you achieve the
migration by understanding how on-premises configurations translate to Azure AD. It also covers common
scenarios.
Introduction
If you have an on-premises directory that contains user accounts, chances are you have at least one or two apps.
And these apps are configured for users to access by signing on with those identities.
And if you’re like most organizations, you’re probably somewhere along the road to adopting cloud applications
and identities. Perhaps you’re up and running with Office 365 and Azure AD Connect. Maybe you’ve set up cloud-
based SaaS applications for some key workloads but not all.
Many organizations have SaaS or custom line-of-business (LOB ) apps federated directly to an on-premises sign-
on service such as Active Directory Federation Services (AD FS ), alongside Office 365 and Azure AD -based apps.
This guide describes why and how to move your applications to Azure AD.
NOTE
This guide provides detailed information on SaaS app configuration and migration, with high-level information about custom
LOB apps. More detailed guidance for custom LOB apps is planned for the future.
Reasons for moving apps to Azure AD
For an organization that already uses AD FS, Ping, or another on-premises authentication provider, moving apps to
Azure AD enables the following benefits:
More secure access
Configure granular per-application access controls, including Azure Multi-Factor Authentication, by using Azure
AD conditional access. The policies can be applied to SaaS and custom apps in the same way that you might be
doing today for Office 365.
To detect threats and help protect sign-on based on machine learning and heuristics that identify risky traffic,
take advantage of Azure AD Identity Protection.
Azure AD B2B collaboration
After sign-on to SaaS apps is based on Azure AD, you can give partners access to cloud resources with Azure
AD B2B collaboration.
Easier admin experience and additional capabilities of Azure AD
Azure AD, as an identity provider for SaaS apps, supports additional capabilities such as:
Token signing certificates per application.
Configurable certificate expiration dates.
Automated provisioning of user accounts (in key Azure Marketplace apps) based on Azure AD identities.
Keeping the benefits of an on-premises identity provider
While you're gaining the Azure AD benefits, you can keep using your on-premises solution for authentication.
That way, benefits like on-premises Multi-Factor Authentication solutions, logging, and auditing stay in place.
Helping with retirement of the on-premises identity provider
For organizations that want to retire the on-premises authentication product, moving apps to Azure AD enables
an easier transition by getting some of the work out of the way.
Mapping types of apps on-premises to types of apps in Azure AD

Most apps fit in one of a few categories based on the type of sign-on that they use. These categories determine
how the app is represented in Azure AD.
In short, SAML 2.0 applications can be integrated with Azure AD either via the Azure AD application gallery in the
Marketplace or as non-Marketplace applications. Apps that use OAuth 2.0 or OpenID Connect can be integrated
with Azure AD similarly as app registrations. Read on for more details.
Federated SaaS apps vs. custom LOB apps
Federated apps include apps that fall into these categories:
SaaS apps
If your users sign on to SaaS apps such as Salesforce, ServiceNow, or Workday, and you're integrating
with an on-premises identity provider such as AD FS or Ping, you're using federated sign-on for SaaS
apps.
Apps generally use the SAML 2.0 protocol for federated sign-on.
Apps that fall into this category can be integrated with Azure AD as enterprise applications, either from
the Marketplace or as non-Marketplace applications.
Custom LOB apps
This refers to non-SaaS apps, developed internally by your organization or available as a standard
packaged product that's installed in your datacenter. This includes SharePoint apps and apps built on
Windows Identity Foundation.
Apps can use SAML 2.0, WS -Federation, OAuth, or OpenID Connect for federated sign-on.
Custom apps that use OAuth 2.0, OpenID Connect, or WS -Federation can be integrated with Azure AD
as app registrations. Custom apps that use SAML 2.0 or WS -Federation can be integrated as non-
Marketplace applications within enterprise applications.
Non-federated apps
You can integrate non-federated apps with Azure AD by using Azure AD Application Proxy and related capabilities.
Non-federated apps include:
Apps that use Windows Integrated Authentication directly with Active Directory. You can integrate these apps
with Azure AD via Azure AD Application Proxy.
Apps that integrate with your single sign-on provider via an agent and that use headers for authorization. On-
premises apps that use an installed agent for sign-on and header-based authorization can be configured for
Azure AD -based sign-on via Azure AD Application Proxy with Ping Access for Azure AD.
Translating on-premises federated apps to Azure AD

AD FS and Azure AD work similarly, so the concepts of configuring trust, sign-on and sign-out URLs, and
identifiers apply in both cases. However, you need to understand some small differences as you make the
transition.
The following tables map key ideas shared by AD FS, Azure AD, and SaaS apps to help you translate.
Representing the app in Azure AD or AD FS
Migration starts with assessing how the application is configured on-premises and mapping that configuration to
Azure AD. The following table is a mapping of AD FS relying party configuration elements to the corresponding
elements in Azure AD.
AD FS term: Relying party or relying party trust.
Azure AD term: Enterprise application or app registration (depending on the type of app).
CORRESPONDING
APP CONFIGURATION LOCATION IN AD FS LOCATION IN AZURE AD
ELEMENT DESCRIPTION CONFIGURATION CONFIGURATION SAML TOKEN ELEMENT
CORRESPONDING
App sign-on URL URL of the sign-in N/A In Azure AD, the sign- N/A
page of this on URL is configured
application. This is within the Azure
where the user goes portal in the
to sign in to the app application’s Single
in an SP-initiated sign-on properties as
SAML flow. the sign-on URL.
(You might have to
select Show
advanced URL
settings to see the
sign-on URL.)
App reply URL URL of the app from Find it in the AD FS In Azure AD, the reply Maps to the
the identity provider's relying party trust for URL is configured Destination element
(IdP’s) perspective. the app. Right-click within the Azure in the SAML token.
This is where the user the relying party, portal in the Example value:
and token are sent select Properties, application’s Single https://contoso.my.sal
after the user has and then select the sign-on properties as esforce.com
signed on at the IdP. Endpoints tab. the reply URL.
This is sometimes (You might have to
called the “SAML select Show
assertion consumer advanced URL
endpoint.” settings to see the
reply URL.)
App sign-out URL URL to which “sign- Find it in AD FS N/A. Azure AD does N/A
out cleanup” requests Management under not support “single
are sent when a user Relying Party Trusts. logout,” meaning
signs out from an Right-click the relying sign-out of all apps. It
app, to sign out all party, select simply signs out the
other apps to which Properties, and then user from Azure AD
the IdP has signed on select the Endpoints itself.
the user. tab.
App identifier Identifier of the app In AD FS, this is the In Azure AD, the Corresponds to the
from the IdP’s relying party ID. identifier is configured Audience element in
perspective. The sign- Right-click the relying within the Azure the SAML token.
on URL value is often party trust, select portal in the
used for the identifier Properties, and then application’s Single
(but not always). select the Identifiers sign-on properties as
Sometimes the app tab. the identifier under
calls this the “entity Domain and URLs.
ID." (You might need to
select the Show
advanced URL
settings check box.)
App federation Location of the app’s Find the app’s N/A. Azure AD does N/A
metadata federation metadata. federation metadata not support
The IdP uses it to URL in the AD FS consuming application
automatically update relying party trust for federation metadata
specific configuration the app. Right-click directly.
settings, such as the trust, select
endpoints or Properties, and then
encryption select the
certificates. Monitoring tab.
CORRESPONDING
User Attribute that is used In AD FS, you can find In Azure AD, you can Communicated from
identifier/NameID to uniquely indicate this as a claim rule on find the user identifier the IdP to the app as
the user identity from the relying party. In within the Azure the NameID element
Azure AD or AD FS to most cases, the claim portal in the in the SAML token.
your app. rule issues a claim application’s Single
This attribute is with a type that ends sign-on properties
typically either the with “nameidentifier.” under the header
UPN or the email User Attributes.
address of the user. By default, the UPN is
used.
Other claims to be In addition to the In AD FS, you can find In Azure AD, you can N/A
sent to the app user this as other claim find it within the
identifier/NameID, rules on the relying Azure portal in the
other claim party. application’s Single
information is sign-on properties
commonly sent from under the header
the IdP to the app. User Attributes.
Examples include first Select View and edit
name, last name, all other user
email address, and attributes.
groups that the user
is a member of.
Representing Azure AD as an identity provider in an SaaS app

As part of migration, you need to configure the app to point to Azure AD (versus the on-premises identity
provider). This section focuses on SaaS apps that use SAML protocol and not on custom LOB apps. However, the
concepts would extend to custom LOB apps.
At a high level, a few key things point an SaaS app to Azure AD:
Identity provider issuer: https://sts.windows.net/{tenant-id}/
Identity provider login URL: https://login.microsoftonline.com/{tenant-id}/saml2
Identity provider logout URL: https://login.microsoftonline.com/{tenant-id}/saml2
Federation metadata location: https://login.windows.net/{tenant-id}/federationmetadata/2007-
06/federationmetadata.xml?appid={application-id}
Replace {tenant-id} with your tenant ID, found in the Azure portal under Azure Active Directory > Properties as
Directory ID. Replace {application-id} with your application ID, found under the application’s properties as
Application ID.
The following table describes the key IdP configuration elements to configure SSO settings in the app, and their
values or locations within AD FS and Azure AD. The table's frame of reference is the SaaS app, which needs to
know where to send authentication requests and how to validate the received tokens.
CONFIGURATION ELEMENT DESCRIPTION AD FS AZURE AD

IdP Sign-on URL of the IdP from The AD FS sign-on URL is The corresponding value for
sign-on the app’s perspective (where the AD FS federation service Azure AD follows the pattern
URL the user is redirected for name followed by “/adfs/ls/.” where {tenant-id} is replaced
login). For example: with your tenant ID. Find it
https://fs.contoso.com/adfs/l in the Azure portal under
s/ Azure Active Directory >
Properties as Directory ID.
For apps that use the SAML-
P protocol:
https://login.microsoftonline.
com/{tenant-id}/saml2
For apps that use the WS-

Federation protocol:
com/{tenant-id}/wsfed
IdP Sign-out URL of the IdP For AD FS, the sign-out URL The corresponding value for
sign-out from the app’s perspective is either the same as the Azure AD depends on
URL (where the user is redirected sign-on URL, or the same whether the app supports
when they choose to sign URL with “wa=wsignout1.0” SAML 2.0 sign-out.
out of the app). appended. For example: If the app supports SAML
https://fs.contoso.com/adfs/l sign-out, the value follows
s/?wa=wsignout1.0 the pattern where the value
for {tenant-id} is replaced
with the tenant ID. Find it in
the Azure portal under
Azure Active Directory >
Properties as Directory ID:
com/{tenant-id}/saml2
If the app does not support

SAML sign-out:
com/common/wsfederation?
wa=wsignout1.0
Token Certificate whose private key Find the AD FS token signing In Azure AD, you can find
signing the IdP uses to sign issued certificate in AD FS the token signing certificate
certificate tokens. It verifies that the Management under within the Azure portal in
token came from the same Certificates. the application’s Single
IdP that the app is sign-on properties under
configured to trust. the header SAML Signing
Certificate. There, you can
download the certificate for
upload to the app.
If the application has more
than one certificate, you can
find all certificates in the
federation metadata XML
file.
Identifier/ Identifier of the IdP from the The identifier for AD FS is The corresponding value for
“issuer” app’s perspective (sometimes usually the federation service Azure AD follows the pattern
called the “issuer ID”). identifier in AD FS where the value for {tenant-
In the SAML token, the Management under Service id} is replaced with the
value appears as the Issuer > Edit Federation Service tenant ID. Find it in the
element. Properties. For example: Azure portal under Azure
http://fs.contoso.com/adfs/se Active Directory >
rvices/trust Properties as Directory ID:
https://sts.windows.net/{tena
nt-id}/
IdP Location of the IdP’s publicly Find the AD FS federation The corresponding value for
federation available federation metadata URL in AD FS Azure AD follows the pattern
metadata metadata. (Some apps use Management under Service https://login.microsoftonline.
federation metadata as an > Endpoints > Metadata > com/{TenantDomainName}/F
alternative to the Type: Federation ederationMetadata/2007-
administrator configuring Metadata. For example: 06/FederationMetadata.xml.
URLs, identifier, and token https://fs.contoso.com/Feder The value for
signing certificate ationMetadata/2007- {TenantDomainName} is
individually.) 06/FederationMetadata.xml replaced with your tenant’s
name in the format
“contoso.onmicrosoft.com.”
For more information, see
Federation metadata.
Moving SaaS apps

Moving SaaS apps from AD FS or another identity provider to Azure AD is a manual process today. For app-
specific guidance, see the list of tutorials on integrating SaaS apps found in the Marketplace.
The integration tutorials assume that you're doing a green field integration. As you plan, assess, configure, and cut
over your apps, you should know about a few key concepts that are specific to migration:
Some apps can be migrated easily. Apps with more complex requirements, such as custom claims, might
require additional configuration in Azure AD and/or Azure AD Connect.
In the most common scenarios, only the NameID claim and other common user identifier claims are required
for an app. To determine if any additional claims are required, examine what claims you’re issuing from AD FS
or your third-party identity provider.
After you determine that additional claims are required, ensure that they're available in Azure AD. Check Azure
AD Connect sync configuration to ensure that a required attribute--for example, samAccountName--is being
synced to Azure AD.
After the attributes are available in Azure AD, you can add claim issuance rules in Azure AD to include those
attributes as claims in issued tokens. You add these rules in the Single sign-on properties of the app in Azure
AD.
Assess what can be moved
SAML 2.0 applications can be integrated with Azure AD either via the Azure AD application gallery in the
Marketplace or as non-Marketplace applications.
Some configurations require additional steps to configure in Azure AD, and some configurations are not supported
today. To determine what you can move, look at the current configuration of each of your apps. Specifically, look
for:
Claim rules configured (issuance transform rules).
SAML NameID format and attribute.
SAML token versions issued.
Other configurations, such as issuance authorization rules or access control policies and Multi-Factor
Authentication (additional authentication) rules.
What can be moved today
Apps that you can move easily today include SAML 2.0 apps that use the standard set of configuration elements
and claims. These apps can consist of:
User principal name.
Email address.
Given name.
Surname.
Alternate attribute as SAML NameID, including the Azure AD mail attribute, mail prefix, employee ID,
extension attributes 1-15, or on-premises SamAccountName attribute. For more information, see Editing the
NameIdentifier claim.
Custom claims. For information about supported claims mappings, see Claims mapping in Azure Active
Directory and Customizing claims issued in the SAML token for enterprise applications in Azure Active
Directory.
In addition to custom claims and NameID elements, configurations that require additional configuration steps in
Azure AD as part of the migration are:
Custom authorization or Multi-Factor Authentication rules in AD FS. You configure them by using the Azure AD
conditional access feature.
Apps with multiple SAML endpoints. You configure them in Azure AD by using PowerShell. (This capability is
not available in the portal.)
WS -Federation apps such as SharePoint apps that require SAML version 1.1 tokens. You must configure them
manually by using PowerShell.
Apps and configurations not supported in Azure AD today
Apps that require the following capabilities cannot be migrated today. If you have apps that require these features,
provide feedback in the comments section.
Protocol capabilities:
Support for SAML Single Logout (SLO ) of all signed-in apps.
Support for the WS -Trust ActAs pattern.
SAML artifact resolution.
Signature verification of signed SAML requests. Note that signed requests are accepted, but the
signature is not verified.
Token capabilities:
SAML token encryption.
SAML version 1.1 tokens within SAML protocol responses.
Claims in token capabilities:
Issuance of on-premises group names as claims.
Claims from stores other than Azure AD.
Complex claims issuance transform rules. For information about supported claims mappings, see Claims
mapping in Azure Active Directory and Customizing claims issued in the SAML token for enterprise
applications in Azure Active Directory.
Issuance of directory extensions as claims.
Custom specification of the NameID format.
Issuance of multiple-value attributes.
NOTE
Azure AD is constantly evolving to add capabilities in this area. We update this article on a regular basis.
Configure Azure AD
Configure single sign-on (SSO) settings for the SaaS app
In Azure AD, you configure SAML sign-on (as required by your app) in the Single sign-on properties of the app,
under User Attributes.
Select View and edit all other user attributes to see the attributes to send as claims in the security token.
Select a specific attribute row to edit, or select Add attribute to add a new attribute.
Assign users to the app

For your users in Azure AD to be able to sign in to an SaaS app, you need to give them access.
To assign users in the Azure AD portal, browse to the SaaS app’s page, and then select Users and groups in the
sidebar. To add either a user or a group, select Add user at the top of the pane.
To verify access, users should see the SaaS app in their access panel when they sign in. They can find the access
panel at https://myapps.microsoft.com. In this example, a user has been successfully assigned access to both
Salesforce and ServiceNow.
Configure the SaaS app
The cutover process from on-premises federation to Azure AD depends on whether the SaaS app that you're
working with supports multiple identity providers. Here are some common questions about support for multiple
IdPs:
Q: What does it mean for an app to support multiple IdPs?
A: SaaS apps that support multiple IdPs enable you to enter all of the information about the new IdP (in our case,
Azure AD ) before you commit to changing the sign-on experience. After the configuration is done, you can switch
the app’s authentication configuration to point at Azure AD.
Q: Why does it matter if the SaaS app supports multiple IdPs?
A: If multiple IdPs are not supported, the admin has to set aside a short window of time as a service or
maintenance outage during which they configure Azure AD as an app’s new IdP. During this outage, users should
be notified that they won't be able to sign in to their accounts.
If an app does support multiple IdPs, the additional IdP can be configured in advance. The admin can then switch
the IdP at Azure cutover.
If the app supports multiple IdPs and you choose multiple IdPs to simultaneously handle authentication for sign-in,
the user is given a choice of IdP to authenticate on their sign-in page.
Example: Support for multiple IdPs
For example, in Salesforce, you can find the IDP configuration under Settings > Company Settings > My
Domain > Authentication Configuration.
Because of the configuration created earlier under Identity > Single sign-on settings, you should be able to
change your IdP for authentication configuration. For example, you can change it from AD FS to Azure AD.
Optional: Configure user provisioning in Azure AD

If you want Azure AD to directly handle user provisioning for an SaaS app, see Automate user provisioning and
deprovisioning to SaaS applications with Azure Active Directory.
Next steps
Managing applications with Azure Active Directory
Manage access to apps
Azure AD Connect federation
Unexpected consent prompt when signing in to an
application
Many applications that integrate with Azure Active Directory require permissions to various resources in order to
run. When these resources are also integrated with Azure Active Directory, permissions to access them is
requested using the Azure AD consent framework.
This results in a consent prompt being shown the first time an application is used, which is often a one-time
operation.
Scenarios in which users see consent prompts

Additional prompts can be expected in various scenarios:
The set of permissions required by the application have changed.
The user who originally consented to the application was not an administrator, and now a different (non-
admin) User is using the application for the first time.
The user who originally consented to the application was an administrator, but they did not consent on-
behalf of the entire organization.
The application is using incremental and dynamic consent to request additional permissions after consent
was initially granted. This is often used when optional features of an application additional require
permissions beyond those required for baseline functionality.
Consent was revoked after being granted initially.
The developer has configured the application to require a consent prompt every time it is used (note: this is
not best practice).
Next steps
Apps, permissions, and consent in Azure Active Directory (v1.0 endpoint)
Scopes, permissions, and consent in the Azure Active Directory (v2.0 endpoint)
Unexpected error when performing consent to an
application
This article discusses errors that can occur during the process of consenting to an application. If you are
troubleshooting unexpected consent prompts that do not contain any error messages, see Authentication
Scenarios for Azure AD.
Many applications that integrate with Azure Active Directory require permissions to access other resources in
order to function. When these resources are also integrated with Azure Active Directory, permissions to access
them is often requested using the common consent framework. A consent prompt is displayed, which generally
occurs the first time an application is used but can also occur on a subsequent use of the application.
Certain conditions must be true for a user to consent to the permissions an application requires. If these conditions
are not met, the following errors can occur.
Requesting not authorized permissions error

AADSTS90093: <clientAppDisplayName> is requesting one or more permissions that you are not authorized
to grant. Contact an administrator, who can consent to this application on your behalf.
This error occurs when a user who is not a company administrator attempts to use an application that is requesting
permissions that only an administrator can grant. This error can be resolved by an administrator granting access to
the application on behalf of their organization.
Policy prevents granting permissions error

AADSTS90093: An administrator of <tenantDisplayName> has set a policy that prevents you from granting
<name of app> the permissions it is requesting. Contact an administrator of <tenantDisplayName>, who can
grant permissions to this app on your behalf.
This error occurs when a company administrator turns off the ability for users to consent to applications, then a
non-administrator user attempts to use an application that requires consent. This error can be resolved by an
administrator granting access to the application on behalf of their organization.
Intermittent problem error

AADSTS90090: It looks like the sign-in process encountered an intermittent problem recording the
permissions you attempted to grant to <clientAppDisplayName>. try again later.
This error indicates that an intermittent service side issue has occurred. It can be resolved by attempting to consent
to the application again.
Resource not available error

AADSTS65005: The app <clientAppDisplayName> requested permissions to access a resource
<resourceAppDisplayName> that is not available.
Contact the application developer.
Resource not available in tenant error
AADSTS65005: <clientAppDisplayName> is requesting access to a resource <resourceAppDisplayName>
that is not available in your organization <tenantDisplayName>.
Ensure that this resource is available or contact an administrator of <tenantDisplayName>.
Permissions mismatch error

AADSTS65005: The app requested consent to access resource <resourceAppDisplayName>. This request
failed because it does not match how the app was pre-configured during app registration. Contact the app
vendor.**
These errors all occur when the application a user is trying to consent to is requesting permissions to access a
resource application that cannot be found in the organization’s directory (tenant). This situation can occur for
several reasons:
The client application developer has configured their application incorrectly, causing it to request access to
an invalid resource. In this case, the application developer must update the configuration of the client
application to resolve this issue.
A Service Principal representing the target resource application does not exist in the organization, or existed
in the past but has been removed. To resolve this issue, a Service Principal for the resource application must
be provisioned in the organization so the client application can request permissions to it. The Service
Principal can be provisioned in a number of ways, depending on the type of application, including:
Acquiring a subscription for the resource application (Microsoft published applications)
Consenting to the resource application
Granting the application permissions via the Azure portal
Adding the application from the Azure AD Application Gallery
Next steps
Apps, permissions, and consent in Azure Active Directory (v1 endpoint)
Scopes, permissions, and consent in the Azure Active Directory (v2.0 endpoint)
Problems signing in to an application using a deeplink
The Access Panel is a web-based portal which enables a user with a work or school account in Azure Active
access to.
These applications are configured on behalf of the user in the Azure AD portal. The application must be configured
properly and assigned to the user or a group the user is a member of to see the application in the Access Panel.
Deep links or User access URLs are links your users may use to access their password-SSO applications directly
from their browsers URL bars. By navigating to this link, users be automatically signed into the application without
having to go to the Access Panel first. This is the same link that users use to access these applications from the
Office 365 application launcher.

Make sure your using a browser that meets the minimum requirements for the Access Panel.
Make sure the user’s browser has added the URL of the application to its trusted sites.
Make sure to check the application is configured correctly.
Make sure that a user’s authentication contact info is up to date to allow Multi-Factor Authentication or
Checking the deeplink

To check if you have the correct deeplink, follow these steps:
navigation menu.
navigation menu.
11. Select the application you want the check the deeplink for.
12. Find the label User Access URL. Your deeplink should match this URL.

To install the Access Panel Browser extension, follow these steps:
4. Based on your browser you are directed to the download link. Add the extension to your browser.
You may also download the extension for Chrome and Firefox from these direct links:
How to configure password single sign-on for an Azure AD gallery

application
To configure an application from the Azure AD gallery, you must:
navigation menu.
9. To add the application, click Add.
After a short period, you are able to see the application’s configuration pane.
navigation menu.

To configure an application from the Azure AD gallery, you must:
navigation menu.
After a short period, you are able to see the application’s configuration pane.
navigation menu.
a. If you do not see the application you want show up here, use the Filter control at the top of the All
sign-in fields are visible at the URL.

navigation menu.
11. Hover over the user in the list to reveal a checkbox. To add your user to the Selected list, click the
checkbox next to the user’s profile photo or logo.
list.
you have selected.
If these troubleshooting steps do not the resolve the issue.

TenantID
Browser type
Fiddler traces
Next steps
Problems signing in to an application from the access
panel
The Access Panel is a web-based portal which enables a user with a work or school account in Azure Active
access to.
These applications are configured on behalf of the user in the Azure AD portal. The application must be configured
properly and assigned to the user or a group the user is a member of to see the application in the Access Panel.
The type of apps a user may be seeing fall in the following categories:
Office 365 Applications
Microsoft and third-party applications configured with federation-based SSO
Password-based SSO applications
Applications with existing SSO solutions

Make sure your using a browser that meets the minimum requirements for the Access Panel.
Make sure the user’s browser has added the URL of the application to its trusted sites.
Make sure to check the application is configured correctly.
Make sure that a user’s authentication contact info is up to date to allow Multi-Factor Authentication or

SSO.

2. Click a password-SSO application in the Access Panel.
4. Based on your browser you are directed to the download link. Add the extension to your browser.
You may also download the extension for Chrome and Microsoft Edge from the direct links below:
Microsoft Edge Access Panel Extension
How to configure federated single sign-on for an Azure AD gallery

application
All application in the Azure AD gallery enabled with Enterprise Single Sign-On capability has a step-by-step
navigation menu.
navigation menu.
a. To configure the application as SP -initiated SSO, the Sign-on URL is a required value. For some
b. To configure the application as IdP -initiated SSO, the Reply URL is a required value. For some
application. Also, you have the metadata URLs and certificate required to setup SSO with the application.
14. Click Save to save the configuration.
navigation menu.
If you do not see the application you want to show up here, use the Filter control at the top of the All
NOTE
navigation menu.
the Certificate.
To configure a non-gallery application, you need to have Azure AD premium and the application supports SAML
2.0. For more information about Azure AD versions, visit Azure AD pricing.
navigation menu.
6. click Non-gallery application in the Add your own app section.
10. Select SAML -based Sign-on in the Mode dropdown
b. Optional: To configure the application as SP -initiated SSO, the Sign-on URL is a required value.
application. Also, you have Azure AD URLs and certificate required for the application.
navigation menu.
NOTE
1.click Add attribute. Enter the Name and the select the Value from the dropdown.
2 Click Save. You see the new attribute in the table.
navigation menu.
the Certificate.

application
navigation menu.
6. In the Enter a name textbox from the Add from the gallery section, type the name of the application
7. Select the application you want to configure for single sign-on
navigation menu.

navigation menu.
navigation menu.
9. Enter the Sign-on URL. This is the URL where users enter their username and password to sign in. Ensure
the sign-in fields are visible at the URL.

navigation menu.
list.
you have selected.

TenantID
Browser type
Fiddler traces
Next steps
Error on an application's page after signing in
In this scenario, Azure AD has signed the user in, but the application is displaying an error not allowing the user to
successfully finish the sign-in flow. In this scenario, the application is not accepting the response issue by Azure AD.
There are some possible reasons why the application didn’t accept the response from Azure AD. If the error in the
application is not clear enough to know what is missing in the response, then:
If the application is the Azure AD Gallery, verify you have followed all the steps in the article How to debug
SAML -based single sign-on to applications in Azure Active Directory.
Use a tool like Fiddler to capture SAML request, SAML response and SAML token.
Share the SAML response with the application vendor to know what is missing.
Missing attributes in the SAML response

To add an attribute in the Azure AD configuration to be sent in the Azure AD response, follow these steps:
navigation menu.
8. click View and edit all other user attributes under the User Attributes section to edit the attributes to
be sent to the application in the SAML token when users sign in.
click Add attribute. Enter the Name and the select the Value from the dropdown.
Click Save. You see the new attribute in the table.
9. Save the configuration.
Next time the user signs in to the application, Azure AD send the new attribute in the SAML response.
The application expects a different User Identifier value or format

The sign-in to the application is failing because the SAML response is missing attributes such as roles or because
the application is expecting a different format for the EntityID attribute.
Add an attribute in the Azure AD application configuration:

To change the User Identifier value, follow these steps:
navigation menu.
8. Under the User attributes, select the unique identifier for your users in the User Identifier dropdown.
Change EntityID (User Identifier) format

If the application expects another format for the EntityID attribute. Then, you won’t be able to select the EntityID
(User Identifier) format that Azure AD sends to the application in the response after user authentication.
SAML protocol under the section NameIDPolicy.
The application expects a different signature method for the SAML

response
To change what parts of the SAML token are digitally signed by Azure Active Directory. Follow these steps:
navigation menu.
8. click Show advanced certificate signing settings under the SAML Signing Certificate section.
9. Select the appropriate Signing Option expected by the application:
Sign SAML response
Sign SAML response and assertion
Sign SAML assertion
Next time the user signs in to the application, Azure AD sign the part of the SAML response selected.
The application expects the signing algorithm to be SHA-1

By default, Azure AD signs the SAML token using the most security algorithm. Changing the sign algorithm to
SHA-1 is not recommended unless required by the application.
To change the signing algorithm, follow these steps:
navigation menu.
8. click Show advanced certificate signing settings under the SAML Signing Certificate section.
9. Select SHA-1, in the Signing Algorithm.
Next time the user signs in to the application, Azure AD sign the SAML token using SHA-1 algorithm.
Next steps
How to debug SAML -based single sign-on to applications in Azure Active Directory
Problems signing in to an Azure AD Gallery
application configured for password single sign-on
The Access Panel is a web-based portal which enables a user who has a work or school account in Azure Active
To use password-based single sign-on (SSO ) in the Access Panel, the Access Panel extension must be installed in
the user’s browser. This extension is downloaded automatically when a user selects an application that is
configured for password-based SSO.

SSO.
NOTE
The password-based SSO extension become available for Microsoft Edge in Windows 10 when browser extensions become
supported for Microsoft Edge.

Setting up a group policy for Internet Explorer

You can setup a group policy that allow you to remotely install the Access Panel extension for Internet Explorer on
The prerequisites include:
domain.
You must have the "Edit settings" permission to edit the Group Policy Object (GPO ). By default, members of
the following security groups have this permission: Domain Administrators, Enterprise Administrators, and
Group Policy Creator Owners. Learn more.
Follow the tutorial How to Deploy the Access Panel Extension for Internet Explorer using Group Policy for step by
step instructions on how to configure the group policy and deploy it to users.
Troubleshoot the Access Panel in Internet Explorer

Follow the Troubleshoot the Access Panel Extension for Internet Explorer guide for access a diagnostics tool and
step by step instructions on configuring the extension for IE.

navigation menu.
navigation menu.
Ensure the sign in fields are visible at the URL.
navigation menu.
list.
you have selected.

TenantID
Browser type
Fiddler traces
Next steps
Problems signing in to an Azure AD Gallery
application configured for password single sign-on
The Access Panel is a web-based portal which enables a user who has a work or school account in Azure Active
To use password-based single sign-on (SSO ) in the Access Panel, the Access Panel extension must be installed in
the user’s browser. This extension is downloaded automatically when a user selects an application that is
configured for password-based SSO.

SSO.
Internet Explorer 8, 9, 10, 11 - on Windows 7 or later
Chrome - on Windows 7 or later, and on MacOS X or later
Firefox 26.0 or later - on Windows XP SP2 or later, and on Mac OS X 10.6 or later
NOTE
The password-based SSO extension become available for Microsoft Edge in Windows 10 when browser extensions become
supported for Microsoft Edge.

To install the Access Panel Browser extension, follow these steps:
Setting up a group policy for Internet Explorer

You can setup a group policy that allow you to remotely install the Access Panel extension for Internet Explorer on
The prerequisites include:
domain.
You must have the "Edit settings" permission to edit the Group Policy Object (GPO ). By default, members of
the following security groups have this permission: Domain Administrators, Enterprise Administrators, and
Group Policy Creator Owners. Learn more.
Follow the tutorial How to Deploy the Access Panel Extension for Internet Explorer using Group Policy for step by
step instructions on how to configure the group policy and deploy it to users.
Troubleshoot the Access Panel in Internet Explorer

Follow the Troubleshoot the Access Panel Extension for Internet Explorer guide for access a diagnostics tool and
step by step instructions on configuring the extension for IE.

application
navigation menu.
navigation menu.
navigation menu.
list.
you have selected.
If these troubleshoot steps don't resolve the issue

TenantID
Browser type
Fiddler traces
Next steps
Problems signing in to a Microsoft application
Microsoft Applications (like Office 365 Exchange, SharePoint, Yammer, etc.) are assigned and managed a bit
differently than 3rd party SaaS applications or other applications you integrate with Azure AD for single sign on.
There are three main ways that a user can get access to a Microsoft-published application.
For applications in the Office 365 or other paid suites, users are granted access through license
assignment either directly to their user account, or through a group using our group-based license
assignment capability.
For applications that Microsoft or a Third Party publishes freely for anyone to use, users may be granted
access through user consent. This0 means that they sign in to the application with their Azure AD Work or
School account and allow it to have access to some limited set of data on their account.
For applications that Microsoft or a 3rd party publishes freely for anyone to use, users may also be granted
access through administrator consent. This means that an administrator has determined the application
may be used by everyone in the organization, so they sign in to the application with a Global Administrator
account and grant access to everyone in the organization.
To troubleshoot your issue, start with the General Problem Areas with Application Access to consider and then
read the Walkthrough: Steps to troubleshoot Microsoft Application access to get into the details.
General Problem Areas with Application Access to consider

Following is a list of the general problem areas that you can drill into if you have an idea of where to start, but we
recommend you read the walkthrough to get going quickly: Walkthrough: Steps to troubleshoot Microsoft
Application access.
Problems with groups
Problems with conditional access policies
Problems with application consent
Steps to troubleshoot Microsoft Application access

Following are some common issues folks run into when their users cannot sign in to a Microsoft application.
Make sure the user is signing in to the correct URL and not a local application URL.
Make sure the user’s account exists in Azure Active Directory. Check if a user account exists in
Make sure the user’s account is enabled for sign ins. Check a user’s account status
Make sure the user’s password is not expired or forgotten. Reset a user’s password or Enable self-
service password reset
Make sure Multi-Factor Authentication is not blocking user access. Check a user’s multi-factor
authentication status or Check a user’s authentication contact info
Check a specific conditional access policy or Check a specific application’s conditional access policy or
Disable a specific conditional access policy
Make sure that a user’s authentication contact info is up to date to allow Multi-Factor
Authentication or Conditional Access policies to be enforced. Check a user’s multi-factor
authentication status or Check a user’s authentication contact info
For Microsoft applications that require a license (like Office365), here are some specific issues to check
once you have ruled out the general issues above:
Ensure the user or has a license assigned. Check a user’s assigned licenses or Check a group’s
assigned licenses
If the license is assigned to a static group, ensure that the user is a member of that group. Check a
user’s group memberships
If the license is assigned to a dynamic group, ensure that the dynamic group rule is set
correctly. Check a dynamic group’s membership criteria
If the license is assigned to a dynamic group, ensure that the dynamic group has finished
processing its membership and that the user is a member (this can take some time). Check a user’s
group memberships
Once you make sure the license is assigned, make sure the license is not expired.
Make sure the license is for the application they are accessing.
For Microsoft applications that don’t require a license, here are some other things to check:
If the application is requesting user-level permissions (for example “Access this user’s mailbox”),
make sure that the user has signed in to the application and has performed a user-level consent
operation to let the application access her data.
If the application is requesting administrator-level permissions (for example “Access all user’s
mailboxes”), make sure that a Global Administrator has performed an administrator-level consent
operation on behalf of all users in the organization.

Application access can be blocked due to a problem with a user that is assigned to the application. Following are
some ways you can troubleshoot and solve problems with users and their account settings:
To check if a user’s account is present, follow these steps:
navigation menu.
5. click All users.
7. Check the properties of the user object to be sure that they look as you expect and no data is missing.
To check a user’s account status, follow these steps:
navigation menu.
5. click All users.
7. click Profile.
8. Under Settings ensure that Block sign in is set to No.
To reset a user’s password, follow these steps:
navigation menu.
5. click All users.
7. click the Reset password button at the top of the user pane.
8. click the Reset password button on the Reset password pane that appears.
9. Copy the temporary password or enter a new password for the user.
10. Communicate this new password to the user, they be required to change this password during their next
sign in to Azure Active Directory.
To enable self-service password reset, follow the deployment steps below:
Enable users to reset their Azure Active Directory passwords
Enable users to reset or change their Active Directory on-premises passwords
To check a user’s multi-factor authentication status, follow these steps:
navigation menu.
5. click All users.
6. click the Multi-Factor Authentication button at the top of the pane.
7. Once the Multi-Factor Authentication Administration portal loads, ensure you are on the Users tab.
8. Find the user in the list of users by searching, filtering, or sorting.
9. Select the user from the list of users and Enable, Disable, or Enforce multi-factor authentication as
desired.
Note: If a user is in an Enforced state, you may set them to Disabled temporarily to let them back into
their account. Once they are back in, you can then change their state to Enabled again to require them to
re-register their contact information during their next sign in. Alternatively, you can follow the steps in
the Check a user’s authentication contact info to verify or set this data for them.
To check a user’s authentication contact info used for Multi-factor authentication, Conditional Access, Identity
Protection, and Password Reset, follow these steps:
navigation menu.
5. click All users.
7. click Profile.
8. Scroll down to Authentication contact info.
9. Review the data registered for the user and update as needed.
To check a user’s group memberships, follow these steps:
navigation menu.
5. click All users.
7. click Groups to see which groups the user is a member of.
navigation menu.
5. click All users.
To assign a license to a user, follow these steps:
navigation menu.
5. click All users.
completed.
Problems with groups

Application access can be blocked due to a problem with a group that is assigned to the application. Following are
some ways you can troubleshoot and solve problems with groups and group memberships:
Check a group’s membership
Check a dynamic group’s membership criteria
Check a group’s assigned licenses
Reprocess a group’s licenses
Assign a group a license
Check a group’s membership
To check a group’s membership, follow these steps:
navigation menu.
7. click Members to review the list of users assigned to this group.
Check a dynamic group’s membership criteria
To check a dynamic group’s membership criteria, follow these steps:
navigation menu.
7. click Dynamic membership rules.
8. Review the simple or advanced rule defined for this group and ensure that the user you want to be a
member of this group meets these criteria.
Check a group’s assigned licenses
To check a group’s assigned licenses, follow these steps:
navigation menu.
Reprocess a group’s licenses
To reprocess a group’s assigned licenses, follow these steps:
navigation menu.
8. click the Reprocess button to ensure that the licenses assigned to this group’s members are up-to-date. This
may take a long time, depending on the size and complexity of the group.
NOTE
To do this faster, consider temporarily assigning a license to the user directly. Assign a user a license.
Assign a group a license

To assign a license to a group, follow these steps:
navigation menu.
completed.
11. Click the Assign button to assign these licenses to this group. This may take a long time, depending on the
size and complexity of the group.
NOTE
To do this faster, consider temporarily assigning a license to the user directly. Assign a user a license.
Problems with conditional access policies
Check a specific conditional access policy
To check or validate a single conditional access policy:
navigation menu.
4. click Enterprise applications in the navigation menu.
5. click the Conditional access navigation item.
6. click the policy you are interested in inspecting.
7. Review that there are no specific conditions, assignments, or other settings which may be blocking user
access.
NOTE
You may wish to temporarily disable this policy to ensure it is not affecting sign ins. To do this, set the Enable policy
toggle to No and click the Save button.
Check a specific application’s conditional access policy

To check or validate a single application’s currently configured conditional access policy:
navigation menu.
5. click All applications.
6. Search for the application you are interested in, or the user is attempting to sign in to by application display
name or application id.
NOTE
If you don’t see the application you are looking for, click the Filter button and expand the scope of the list to All
applications. If you want to see more columns, click the Columns button to add additional details for your
applications.

9. Review that there are no specific conditions, assignments, or other settings which may be blocking user
access.
NOTE
You may wish to temporarily disable this policy to ensure it is not affecting sign ins. To do this, set the Enable policy
toggle to No and click the Save button.
Disable a specific conditional access policy

To check or validate a single conditional access policy:
navigation menu.
7. Disable the policy by setting the Enable policy toggle to No and click the Save button.
Problems with application consent

Application access can be blocked because the proper permissions consent operation has not occurred. Following
are some ways you can troubleshoot and solve application consent issues:
Perform a user-level consent operation
Perform administrator-level consent operation for any application
Perform administrator-level consent for a single-tenant application
Perform administrator-level consent for a multi-tenant application
Perform a user-level consent operation
For any Open ID Connect-enabled application that requests permissions, navigating to the application’s sign
in screen performs a user level consent to the application for the signed-in user.
If you wish to do this programmatically, see Requesting individual user consent.
Perform administrator-level consent operation for any application
For only applications developed using the V1 application model, you can force this administrator
level consent to occur by adding “?prompt=admin_consent” to the end of an application’s sign in URL.
For any application developed using the V2 application model, you can enforce this administrator-
level consent to occur by following the instructions under the Request the permissions from a directory
admin section of Using the admin consent endpoint.
Perform administrator-level consent for a single -tenant application
For single-tenant applications that request permissions (like those you are developing or own in your
organization), you can perform an administrative-level consent operation on behalf of all users by
signing in as a Global Administrator and clicking on the Grant permissions button at the top of the
Application Registry -> All Applications -> Select an App -> Required Permissions pane.
For any application developed using the V1 or V2 application model, you can enforce this
administrator-level consent to occur by following the instructions under the Request the permissions
from a directory admin section of Using the admin consent endpoint.
Perform administrator-level consent for a multi-tenant application
For multi-tenant applications that request permissions (like an application a third party, or Microsoft,
develops), you can perform an administrative-level consent operation. Sign in as a Global Administrator
and clicking on the Grant permissions button under the Enterprise Applications -> All Applications ->
Select an App -> Permissions pane (available soon).
You can also enforce this administrator-level consent to occur by following the instructions under the
Request the permissions from a directory admin section of Using the admin consent endpoint.
Next steps
Using the admin consent endpoint
Problems signing in to a non-gallery application
configured for federated single sign-on
To troubleshoot the sign-in issues below, we recommend you follow these suggestion to get better diagnosis and
automate the resolution steps:
Install the My Apps Secure Browser Extension to help Azure Active Directory (Azure AD ) to provide better
diagnosis and resolutions when using the testing experience in the Azure portal.
Reproduce the error using the testing experience in the app configuration page in the Azure portal. Learn more
on Debug SAML -based single sign-on applications
Application not found in directory

Error AADSTS70001: Application with Identifier ‘https://contoso.com’ was not found in the directory.
Possible cause
The Issuer attribute sends from the application to Azure AD in the SAML request doesn’t match the Identifier value
configured in the application Azure AD.
Resolution
Ensure that the Issuer attribute in the SAML request matches the Identifier value configured in Azure AD. If you
use the testing experience in the Azure portal with the My Apps Secure Browser Extension, you don't need to
manually follow these steps.
navigation menu.
8. Once the application loads, open Basic SAML configuration. Verify that the value in the Identifier textbox
matches the value for the identifier value displayed in the error.
The reply address does not match the reply addresses configured for
the application.
Error AADSTS50011: The reply address ‘https://contoso.com’ does not match the reply addresses configured for the
application
Possible cause
The AssertionConsumerServiceURL value in the SAML request doesn't match the Reply URL value or pattern
configured in Azure AD. The AssertionConsumerServiceURL value in the SAML request is the URL you see in the
error.
Resolution
navigation menu.
8. Once the application loads, open Basic SAML configuration. Verify or update the value in the Reply URL
textbox to match the AssertionConsumerServiceURL value in the SAML request.
After you've updated the Reply URL value in Azure AD, and it matches the value sent by the application in the
SAML request, you should be able to sign in to the application.
User not assigned a role

Error AADSTS50105: The signed in user 'brian@contoso.com' is not assigned to a role for the application
Possible cause
The user has not been granted access to the application in Azure AD.
Resolution
To assign one or more users to an application directly, follow the steps below. If you use the testing experience in
the Azure portal with the My Apps Secure Browser Extension, you don't need to manually follow these steps.
navigation menu.
list.
you have selected.
Not a valid SAML Request

Error AADSTS75005: The request is not a valid Saml2 protocol message.
Possible cause
Azure AD doesn’t support the SAML Request sent by the application for Single Sign-on. Some common issues
are:
Missing required fields in the SAML request
SAML request encoded method
Resolution
1. Capture SAML request. follow the tutorial on how to debug SAML -based single sign-on to applications in
Azure AD to learn how to capture the SAML request.
2. Contact the application vendor and share:
SAML request
Azure AD Single Sign-on SAML protocol requirements
The application vendor should validate that they support the Azure AD SAML implementation for single sign-on.
Misconfigured application
Error AADSTS650056: Misconfigured application. This could be due to one of the following: The client has not
listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration. Or, The
admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the
configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of
the tenant..
Possible cause
The Issuer attribute sent from the application to Azure AD in the SAML request doesn’t match the Identifier
value configured for the application in Azure AD.
Resolution
manually follow these steps:
2. Open the Azure Active Directory Extension by selecting All services at the top of the main left-hand
navigation menu.
3. Type “Azure Active Directory" in the filter search box and select the Azure Active Directory item.
4. Select Enterprise Applications from the Azure Active Directory left-hand navigation menu.
5. Select All Applications to view a list of all your applications.
Certificate or key not configured

Error AADSTS50003: No signing key configured.
Possible cause
The application object is corrupted and Azure AD doesn’t recognize the certificate configured for the application.
Resolution
To delete and create a new certificate, follow the steps below:
navigation menu.
8. click Create new certificate under the SAML signing Certificate section.
9. Select Expiration date. Then, click Save.
10. Check Make new certificate active to override the active certificate. Then, click Save at the top of the
pane and accept to activate the rollover certificate.
11. Under the SAML Signing Certificate section, click remove to remove the Unused certificate.
SAML Request not present in the request

Error AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters in HTTP
request for SAML Redirect binding.
Possible cause
Azure AD wasn’t able to identify the SAML request within the URL parameters in the HTTP request. This can
happen if the application is not using HTTP redirect binding when sending the SAML request to Azure AD.
Resolution
The application needs to send the SAML request encoded into the location header using HTTP redirect binding.
For more information about how to implement it, read the section HTTP Redirect Binding in the SAML protocol
specification document.
Azure AD is sending the token to an incorrect endpoint

Possible cause
During single sign-on, if the sign-in request does not contain an explicit reply URL (Assertion Consumer Service
URL ) then Azure AD will select any of the configured rely URLs for that application. Even if the application has an
explicit reply URL configured, the user may be to redirected https://127.0.0.1:444.
When the application was added as a non-gallery app, Azure Active Directory created this reply URL as a default
value. This behavior has changed and Azure Active Directory no longer adds this URL by default.
Resolution
Delete the unused reply URLs configured for the application.
navigation menu.
7. Once the application loads, open Basic SAML configuration. In the Reply URL (Assertion Consumer
Service URL ), delete unused or default Reply URLs created by the system. For example,
https://127.0.0.1:444/applications/default.aspx .
Problem when customizing the SAML claims sent to an application

Next steps
Problems signing in to a gallery application
configured for federated single sign-on
To troubleshoot the sign-in issues below, we recommend you follow these suggestion to get better diagnosis and
automate the resolution steps:
Install the My Apps Secure Browser Extension to help Azure Active Directory (Azure AD ) to provide better
diagnosis and resolutions when using the testing experience in the Azure portal.
Reproduce the error using the testing experience in the app configuration page in the Azure portal. Learn more
on Debug SAML -based single sign-on applications
Application not found in directory

Error AADSTS70001: Application with Identifier ‘https://contoso.com’ was not found in the directory.
Possible cause
value that's configured for the application in Azure AD.
Resolution
navigation menu.
The reply address does not match the reply addresses configured for
the application
Error AADSTS50011: The reply address ‘https://contoso.com’ does not match the reply addresses configured for the
application
Possible cause
The AssertionConsumerServiceURL value in the SAML request doesn't match the Reply URL value or pattern
configured in Azure AD. The AssertionConsumerServiceURL value in the SAML request is the URL you see in the
error.
Resolution
Ensure that the AssertionConsumerServiceURL value in the SAML request matches the Reply URL value configured
in Azure AD. If you use the testing experience in the Azure portal with the My Apps Secure Browser Extension, you
don't need to manually follow these steps.
navigation menu.
7. Once the application loads, open Basic SAML configuration. Verify or update the value in the Reply URL
textbox to match the AssertionConsumerServiceURL value in the SAML request.
After you've updated the Reply URL value in Azure AD, and it matches the value sent by the application in the
SAML request, you should be able to sign in to the application.
User not assigned a role

Error AADSTS50105: The signed in user 'brian@contoso.com' is not assigned to a role for the application.
Possible cause
The user has not been granted access to the application in Azure AD.
Resolution
To assign one or more users to an application directly, follow the steps below. If you use the testing experience in
the Azure portal with the My Apps Secure Browser Extension, you don't need to manually follow these steps.
navigation menu.
3. Type “Azure Active Directory” in the filter search box and select the Azure Active Directory item.
6. From the list of applications, select the one that you want to assign a user to.
7. Once the application loads, select Users and Groups from the application’s left-hand navigation menu.
9. Select the Users and groups selector from the Add Assignment pane.
10. In the Search by name or email address search box, type the full name or email address of the user that
you want to add.
logo to add the user to the Selected list.
12. Optional: If you would like to add more than one user, type another full name or email address into the
Search by name or email address search box, and click the checkbox to add the user to the Selected list.
13. When you're finished selecting users, click the Select button to add them to the list of users and groups to
14. Optional: Click the Select Role selector in the Add Assignment pane to select a role to assign to the users
you have selected.
After a short period of time, the users you have selected will be able to launch these applications using the
methods described in the solution description section.
Not a valid SAML request

Error AADSTS75005: The request is not a valid Saml2 protocol message.
Possible cause
Azure AD doesn’t support the SAML request sent by the application for single sign-on. Some common issues are:
Missing required fields in the SAML request
SAML request encoded method
Resolution
1. Capture the SAML request. Follow the tutorial How to debug SAML -based single sign-on to applications in
Azure AD to learn how to capture the SAML request.
2. Contact the application vendor and share the following info:
SAML request
The application vendor should validate that they support the Azure AD SAML implementation for single sign-on.
Misconfigured application
Error AADSTS650056: Misconfigured application. This could be due to one of the following: The client has not
listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration. Or, The
admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the
configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of
the tenant..
Possible cause
value configured for the application in Azure AD.
Resolution
manually follow these steps:
navigation menu.
Certificate or key not configured

Error AADSTS50003: No signing key configured.
Possible cause
The application object is corrupted and Azure AD doesn’t recognize the certificate configured for the application.
Resolution
To delete and create a new certificate, follow the steps below:
navigation menu.
8. Select Create new certificate under the SAML signing Certificate section.
9. Select Expiration date and then click Save.
10. Check Make new certificate active to override the active certificate. Then, click Save at the top of the
pane and accept to activate the rollover certificate.
11. Under the SAML Signing Certificate section, click remove to remove the Unused certificate.
SAML Request not present in the request
Error AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters in HTTP
request for SAML Redirect binding.
Possible cause
Azure AD wasn’t able to identify the SAML request within the URL parameters in the HTTP request. This can
happen if the application is not using HTTP redirect binding when sending the SAML request to Azure AD.
Resolution
The application needs to send the SAML request encoded into the location header using HTTP redirect binding.
For more information about how to implement it, read the section HTTP Redirect Binding in the SAML protocol
specification document.
Azure AD is sending the token to an incorrect endpoint

Possible cause
During single sign-on, if the sign-in request does not contain an explicit reply URL (Assertion Consumer Service
URL ) then Azure AD will select any of the configured rely URLs for that application. Even if the application has an
explicit reply URL configured, the user may be to redirected https://127.0.0.1:444.
When the application was added as a non-gallery app, Azure Active Directory created this reply URL as a default
value. This behavior has changed and Azure Active Directory no longer adds this URL by default.
Resolution
Delete the unused reply URLs configured for the application.
navigation menu.
7. Once the application loads, open Basic SAML configuration. In the Reply URL (Assertion Consumer
Service URL ), delete unused or default Reply URLs created by the system. For example,
https://127.0.0.1:444/applications/default.aspx .
Problem when customizing the SAML claims sent to an application

Directory.
Next steps
How to debug SAML -based single sign-on to applications in Azure AD
Problems signing in to an custom-developed
application
There are several errors that could be causing you to not be able to sign into an app. The biggest reason people
encounter this problem is misconfigured apps.
Errors related to misconfigured apps

Verify both the configurations in the portal match what you have in your app. Specifically, compare
Client/Application ID, Reply URLs, Client Secrets/Keys, and App ID URI.
Compare the resource you’re requesting access to in code with the configured permissions in the Required
Resources tab to make sure you only request resources you’ve configured.
See Azure AD StackOverflow for any similar errors or problems.
Next steps
Azure AD Developer Guide
Consent and Integrating Apps to Azure AD
Consent and Permissioning for Azure AD v2.0 converged Apps
Azure AD StackOverflow

Microsoft Azure1 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Microsoft Azure1 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Contents

Application Management Documentation

Why manage applications with a cloud solution?

Manage risk with conditional access policies

Improve productivity with single sign-on

Address governance and compliance

Before you begin

Add an application to your Azure AD tenant

4. Click New application at the top of the All applications blade.

Find your Azure AD tenant application

yes yes yes yes yes

yes yes no yes no

yes no yes yes yes

Behavior for unassigned users:

yes yes yes no no

yes no yes yes no

Use a custom logo

Before you begin

Find the list of tenant applications

Select viewing options

2. Under Application Type, choose one of these options:

Search for a tenant application

Before you begin

Select a single sign-on mode

Configure domain and URLs

CONFIGURATION SETTING SP-INITIATED IDP-INITIATED DESCRIPTION

Sign-on URL Required Don't specify When a user opens this

Reply URL Optional Required Specifies where the

Relay State Optional Optional Specifies to the application

3. At the top of the blade, click Save.

Configure user attributes

2. Enter User Identifier.

Create a SAML signing certificate

Assign users to the application

Configure the application to use Azure AD

2. Click Configure application in the portal, and follow the instructions.

Test single sign-on

Before you begin

2. Restart the server

Prepare your on-premises environment

PORT NUMBER HOW IT'S USED

80 Downloading certificate revocation lists (CRLs) while validating

443 All outbound communication with the Application Proxy

URL HOW IT'S USED

*.msappproxy.net Communication between the connector and the Application

mscrl.microsoft.com:80 Azure uses these URLs to verify certificates

login.windows.net The connector uses these URLs during the registration

Verify the connector installed and registered correctly

Add an on-premises app to Azure AD

If you publish a path, make sure that it includes all the

Azure Active Directory - Application Proxy redirects

Passthrough - Users don't have to authenticate against

Connector Group Connectors process the remote access to your application,

If your application uses WebSockets to connect, all

Set this value to Yes if you plan to monitor this application

Test the application

2. On the Users and groups blade, select Add user.

Integrating applications with Azure AD

Managing access to applications

Configure access rules

Configure the app to require user assignment and assign users

Suppress user consent

What is Application Proxy?