APPs Management Azure

Contents
Application management documentation

Overview
What is cloud app management and single sign-on?
What is automatic user provisioning?
What is Application Proxy for on-premises apps?
Quickstarts
Add a cloud app from the gallery
View your enterprise applications
Tutorials
SaaS apps tutorials
Add an on-premises app with Application Proxy
Concepts
Cloud apps and single sign-on
Planning a cloud app integration
Get started with app integration
Plan an access panel deployment
Guidance for developers
Single sign-on
What is single sign-on
Enable SSO for your multi-tenant application
Create an Azure tenant for multi-tenant application
Choose multi-tenant federation
Create documentation for multi-tenant application
Plan a single sign-on deployment
One Click SSO
What is One Click SSO
Application security
App access options
Certificate signing options
Manage certificates
Tenant restrictions
Configure SAML token encryption (Preview)
End-user portals
Automatic user provisioning
Automatic provisioning for SCIM-enabled apps
Application Proxy for on-premises apps
Application Proxy
Planning an Application Proxy deployment
Connectors
Connector groups
Security
Network topology
High availability and load balancing
Comparison of remote access solutions
How-to guides
Cloud apps and single sign-on
Add a cloud app
Add a gallery app
Add a non-gallery app
Change the app name or logo
Configure single sign-on
Configure SAML-based single sign-on
Configure SAML-based single sign-on
Customize user attributes and claims
Configure group claims
Configure role claims
Customize claims in the portal
Customize claims with PowerShell
Configure optional claims
Configure token lifetimes
Configure password-based sign-on
Configure linked sign-on
Assign users and manage access to apps
Configure user consent
Methods for assigning users and groups to an app
Assign a user to an app
Use self-service app access
Methods for removing a user's access to an app
Remove user or group access
Hide app from a user
Disable user sign-on
Configure self-service app assignment
Home Realm Discovery
Migrate apps to Azure AD
Migration resources
Migrate an ADFS app to Azure
Troubleshoot
Troubleshoot adding apps
Common problems - gallery apps
Common problems - non-gallery apps
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
Troubleshoot single sign-on
Configuring federated common problems - gallery apps
Configure federated common problems - non-gallery apps
Configure password common problems - gallery apps
Configure password common problems - non-gallery apps
Troubleshoot app list and assignment
Manage the applications list for your tenant
Unexpected user assigned
Troubleshoot the access panel
Manage browser extension
App not appearing
Unexpected app appearing
Can't sign in
Error installing browser extension
Error using self-service app access
Configure user provisioning
User provisioning for gallery apps
Enable automatic user provisioning for multi-tenant apps
Configure automatic user provisioning
Customize application attributes
Scoping filters
Skip deletion for out-of-scope users
Check provisioning status
Report on automatic user provisioning
Exporting and importing your configuration
Troubleshoot user provisioning
Troubleshoot user provisioning
Sync an attribute for mapping - gallery app
Taking hours - gallery app
Problem saving administrator credentials while configuring user provisioning
gallery app
Users are not provisioned - gallery app
Wrong users provisioned - gallery app
Configure connectors
Configure with proxy servers
Register connector - silent install
Configure application access
Configure claims-aware apps
Give mobile and desktop apps access to on-premises APIs
Configure mobile and desktop client apps
Configure custom home page
Translate inline links
Configure cookie settings
Publish using wildcards
Remove personal data
Configure custom domain
Single sign-on with Application Proxy
Kerberos constrained Delegation (KCD)
Password vaulting
Headers
SAML SSO
Publishing walkthroughs
Integrate with Power BI
Integrate with Cloud App Security
Integrate with Remote Desktop
Integrate with SharePoint
Integrate with Teams
Integrate with Tableau
Integrate with Qlik
Troubleshoot Application Proxy
Application Proxy troubleshooting
Connector troubleshooting flowchart
Application troubleshooting flowchart
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
CORS issues in Application Proxy
Reference
Write expressions for attribute mappings
Azure AD Connect Provisioning Agent
Provisioning Agent version history
Application Proxy version history
Resources
Azure feedback forum
MSDN forum
Pricing
Service updates
Stack Overflow
Videos
Application management with Azure Active Directory
7/23/2019 • 3 minutes to read • Edit Online
Azure Active Directory (Azure AD ) simplifies the way you manage your applications by providing a single identity
system for your cloud and on-premises apps. You can add your software as a service (SaaS ) applications, on-
premises applications, and line of business (LOB ) apps to Azure AD. Then users sign in once to securely and
seamlessly access these applications, along with Office 365 and other business applications from Microsoft. You
can reduce administrative costs by automating user provisioning. You can also 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's more critical than ever to use a cloud-based solution to manage
user access to all applications.
What types of applications can I integrate with Azure AD?

There are four main types of applications that you can add to your Enterprise applications and manage with
Azure AD:
Azure AD Gallery applications – Azure AD has a gallery that contains thousands of applications that
have been pre-integrated for single sign-on with Azure AD. Some of the applications your organization
uses are probably in the gallery. Learn about planning your app integration, or get detailed integration
steps for individual apps in the SaaS application tutorials.
On-premises applications with Application Proxy – With Azure AD Application Proxy, you can
integrate your on-premises web apps with Azure AD to support single sign-on. Then end users can access
your on-premises web apps in the same way they access Office 365 and other SaaS apps. Learn why to use
Application Proxy and how it works.
Custom -developed applications – When building your own line-of-business applications, you can
integrate them with Azure AD to support single sign-on. By registering your application with Azure AD,
you have control over the authentication policy for the application. For more information, see guidance for
developers.
Non-Gallery applications – Bring your own applications! Support single sign-on for other apps by
adding them to Azure AD. You can integrate any web link you want, or any application that renders a
username and password field, supports SAML or OpenID Connect protocols, or supports SCIM. For more
information, see Configure single sign-on for non-gallery apps.
Manage risk with Conditional Access policies

Coupling Azure AD single sign-on (SSO ) with Conditional Access 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. Read more about single sign-on.
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.
Next steps
What is Application Proxy?
Quickstart: Add a gallery application to your Azure AD tenant
Automate user provisioning and deprovisioning to
SaaS applications with Azure Active Directory
Azure Active Directory (Azure AD ) lets you automate the creation, maintenance, and removal of user identities in
cloud (SaaS ) applications such as Dropbox, Salesforce, ServiceNow, and more. This is known as automated user
provisioning for SaaS apps.
This feature lets you:

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 this functionality:
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.
Securing your organization by instantly removing users' identities from key SaaS apps when they leave the
organization.
Easily importing a large number of users into a particular SaaS application or system.
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 many popular SaaS apps and human resources systems, and
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
can then 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?

Use the Azure Active Directory portal to configure the Azure AD provisioning service for a selected application.
1. Open the Azure Active Directory portal.
2. Select Enterprise applications from the left pane. A list of all configured apps is show.
3. Choose + New application to add an application. Add either of the following depending on your
scenario:
The Add your own app option supports custom-developed SCIM integrations.
All applications in the Add from the gallery > Featured applications section support automatic
provisioning. See the list of application tutorials for user provisioning for additional ones.
4. Provide any details and select Add. The new app is added to the list of enterprise applications and opens
to its application management screen.
5. Select Provisioning to manage user account provisioning settings for the app.
6. Select the Automatic option for the Provisioning Mode to specify settings for admin credentials,
mappings, starting and stopping, and synchronization.
Expand Admin credentials to enter the credentials required for Azure AD to connect to the
application's user management API. This section also lets you enable email notifications if the
credentials fail, or the provisioning job goes into quarantine.
Expand Mappings to view and edit the user attributes that flow between Azure AD and the target
application when user accounts are provisioned or updated. If the target application supports it,
this section lets you optionally configure provisioning of groups and user accounts. Select a
mapping in the table to open the mapping editor to the right, where you can view and customize
user attributes.
Scoping filters tell the provisioning service which users and groups in the source system should
be provisioned or deprovisioned to the target system. In the Attribute mapping pane, select
Source Object Scope to filter 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.
For more information, see Customizing Attribute Mappings.
Settings control the operation of the provisioning service for an application, including whether it's
currently running. The Scope menu lets you 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.
In the app management screen, select Audit logs to view records of every operation run by the Azure AD
provisioning service. For more information, 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 run 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 assigned or in scope for provisioning, the service queries the target system for a matching
user using the specified 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 isn't found in the target system, it's 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 run all future operations on that user.
5. If a matching user is found, it's 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 run all future operations on that user.
6. If the attribute mappings contain "reference" attributes, the service does 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 later incremental
syncs.
Some applications such as ServiceNow, G Suite, 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 later synchronizes the group
memberships.
Incremental syncs
After the initial sync, all other 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 assigned or in scope for provisioning, the service queries the target system for a matching
user using the specified matching attributes.
4. If a matching user isn't found in the target system, it's 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 run all future operations on that user.
5. If a matching user is found, it's updated using the attributes provided by the source system. If it's 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 run all future operations on that user.
6. If the attribute mappings contain "reference" attributes, the service does 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're soft-deleted.
10. Persist a new watermark at the end of the incremental sync, which provides the starting point for the later
incremental syncs.
NOTE
You can optionally disable the Create, Update, or Delete operations by using the Target object actions check boxes in
the 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 continues running 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 action clears any stored watermark and causes all source objects to be
evaluated again.
A new initial sync is triggered because of a change in attribute mappings or scoping filters. This action also
clears any stored watermark and causes all source objects to be evaluated again.
The provisioning process goes into quarantine (see below ) because of 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 because of an error in the target
system, then the operation is 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 must 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's 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 because of an error (such as for invalid
admin credentials), then the provisioning job goes into a "quarantine" state. This state 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 are 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 running an initial provisioning cycle or an
incremental cycle. For details about how long provisioning takes and how to monitor the status of the
provisioning service, see Check the status of user provisioning.
How can I tell if users are being provisioned properly?

All operations run 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, and the user data that was read or written
during each operation.
For information on how to 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.
Frequently asked questions

Does automatic user provisioning to SaaS apps work with B2B users in Azure AD?
Yes, it's 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 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 they're 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, 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 results 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 isn't
able to read or provision users that are in nested groups. It's 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.
Is provisioning between Azure AD and a target application using an encrypted channel?
Yes. We use HTTPS SSL encryption for the server target.
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 AD to applications
Azure AD synchronization API overview
Using Azure AD Application Proxy to publish on-
premises apps for remote users
Azure Active Directory (Azure AD ) offers many capabilities for protecting users, apps, and data in the cloud and
on-premises. In particular, the Azure AD Application Proxy feature can be implemented by IT professionals who
want to publish on-premises web applications externally. Remote users who need access to internal apps can then
access them in a secure manner.
The ability to securely access internal apps from outside your network becomes even more critical in the modern
workplace. With scenarios such as BYOD (Bring Your Own Device) and mobile devices, IT professionals are
challenged to meet two goals:
Empower end users to be productive anytime and anywhere
Protect corporate assets at all times
Many organizations believe they are in control and protected when resources exist within the boundaries of their
corporate networks. But in today's digital workplace, that boundary has expanded with managed mobile devices
and resources and services in the cloud. Now you need to manage the complexity of protecting your users'
identities and data stored on their devices and apps.
Perhaps you're already using Azure AD to manage users in the cloud who need to access Office 365 and other
SaaS applications, as well as web apps hosted on-premises. If you already have Azure AD, you can leverage it as
one control plane to allow seamless and secure access to your on-premises applications. Or, maybe you're still
contemplating a move to the cloud. If so, you can begin your journey to the cloud by implementing Application
Proxy and taking the first step towards building a strong identity foundation.
While not comprehensive, the list below illustrates some of the things you can enable by implementing App Proxy
in a hybrid coexistence scenario:
Publish on-premises web apps externally in a simplified way without a DMZ
Support single sign-on (SSO ) across devices, resources, and apps in the cloud and on-premises
Support multi-factor authentication for apps in the cloud and on-premises
Quickly leverage cloud features with the security of the Microsoft Cloud
Centralize user account management
Centralize control of identity and security
Automatically add or remove user access to applications based on group membership
This article explains how Azure AD and Application Proxy give remote users a single sign-on (SSO ) experience.
Users securely connect to on-premises apps without a VPN or dual-homed servers and firewall rules. This article
helps you understand how Application Proxy brings the capabilities and security advantages of the cloud to your
on-premises web applications. It also describes the architecture and topologies that are possible.
Remote access in the past

Previously, your control plane for protecting internal resources from attackers while facilitating access by remote
users was all in the DMZ, or perimeter network. But the VPN and reverse proxy solutions deployed in the DMZ
used by external clients to access corporate resources aren't suited to the cloud world. They typically suffer from
the following drawbacks:
Hardware costs
Maintaining security (patching, monitoring ports, etc.)
Authenticating users at the edge
Authenticating users to web servers in the perimeter network
Maintaining VPN access for remote users with the distribution and configuration of VPN client software. Also,
maintaining domain-joined servers in the DMZ, which can be vulnerable to outside attacks.
In today's cloud-first world, Azure AD is best suited to control who and what gets into your network. Azure AD
Application Proxy integrates with modern authentication and cloud-based technologies, like SaaS applications and
identity providers. This integration enables users to access apps from anywhere. Not only is App Proxy more
suited for today's digital workplace, it's more secure than VPN and reverse proxy solutions and easier to
implement. Remote 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. Furthermore, App Proxy doesn't require you to open inbound connections through your
firewall. With App Proxy, you simply set it and forget it.
The future of remote access

In today's digital workplace, users work anywhere with multiple devices and apps. The only constant is user
identity. That's why the first step to a secure network today is to use Azure AD's identity management capabilities
as your security control plane. A model that uses identity as your control plane is typically comprised of the
following components:
An identity provider to keep track of users and user-related information.
Device directory to maintain a list of devices that have access to corporate resources. This directory includes
corresponding device information (for example, type of device, integrity etc.).
Policy evaluation service to determine if a user and device conforms to the policy set forth by security admins.
The ability to grant or deny access to organizational resources.
With Application Proxy, Azure AD keeps track of users who need to access web apps published on-premises and
in the cloud. It provides a central management point for those apps. While not required, it's recommended you
also enable Azure AD Conditional Access. By defining conditions for how users authenticate and gain access, you
further ensure the right people have access to applications.
Note: It's important to understand that Azure AD Application Proxy is intended as a VPN or reverse proxy
replacement for roaming (or remote) users who need access to internal resources. It's not intended for internal
users on the corporate network. Internal users who unnecessarily use Application Proxy can introduce unexpected
and undesirable performance issues.
An overview of how App Proxy works
Application Proxy is an Azure AD service you configure in the Azure portal. It enables you to publish an external
public HTTP/HTTPS URL endpoint in the Azure Cloud, which connects to an internal application server URL in
your organization. These on-premises web apps can be integrated with Azure AD to support single sign-on. End
users can then access on-premises web apps in the same way they access Office 365 and other SaaS apps.
Components of this feature include the Application Proxy service, which runs in the cloud, the Application Proxy
connector, which is a lightweight agent that runs on an on-premises server, and Azure AD, which is the identity
provider. All three components work together to provide the user with a single sign-on experience to access on-
premises web applications.
After signing in, external users can access on-premises web applications by using a familiar URL or the MyApps
access panel from their desktop or iOS/MAC devices. For example, App Proxy can provide remote access and
single sign-on to Remote Desktop, SharePoint sites, Tableau, Qlik, Outlook on the web, and line-of-business (LOB )
applications.
Authentication
There are several ways to configure an application for single sign-on and the method you select depends on the
authentication your application uses. Application Proxy supports the following types of applications:
Web applications
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 )
App Proxy works with apps that use the following native authentication protocol:
Integrated Windows Authentication (IWA ). For IWA, the Application Proxy connectors use Kerberos
Constrained Delegation (KCD ) to authenticate users to the Kerberos application.
App Proxy also supports the following authentication protocols with third-party integration or in specific
configuration scenarios:
Header-based authentication. This sign-on method uses a third-party authentication service called
PingAccess and is used when the application uses headers for authentication. In this scenario, authentication is
handled by PingAccess.
Forms- or password-based authentication. With this authentication method, 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. In this scenario, authentication is handled by Azure AD.
SAML authentication. SAML -based single sign-on is supported for applications that use either SAML 2.0 or
WS -Federation protocols. With SAML single sign-on, Azure AD authenticates to the application by using the
user's Azure AD account.
For more information on supported methods, see Choosing a single sign-on method.
Security benefits
The remote access solution offered by Application Proxy and Azure AD support several security benefits
customers may take advantage of, including:
Authenticated access. Application Proxy is best suited to publish applications with pre-authentication to
ensure that only authenticated connections hit your network. For applications published with pre-
authentication, no traffic is allowed to pass through the App Proxy service to your on-premises
environment, without a valid token. Pre-authentication, by its very nature, blocks a significant number of
targeted attacks, as only authenticated identities can access the backend application.
Conditional Access. Richer policy controls can be applied before connections to your network are
established. With Conditional Access, you can define restrictions on the traffic that you allow to hit your
backend application. You create policies that restrict sign-ins based on location, strength of authentication,
and user risk profile. As Conditional Access evolves, more controls are being added to provide additional
security such as integration with Microsoft Cloud App Security (MCAS ). MCAS integration enables you to
configure an on-premises application for real-time monitoring by leveraging Conditional Access to monitor
and control sessions in real-time based on Conditional Access policies.
Traffic termination. All traffic to the backend application is terminated at the Application Proxy service in
the cloud while the session is re-established with the backend server. This connection strategy means that
your backend servers are not exposed to direct HTTP traffic. They are better protected against targeted DoS
(denial-of-service) attacks because your firewall isn't under attack.
All access is outbound. The Application Proxy connectors only use outbound connections to the
Application Proxy service in the cloud over ports 80 and 443. With no inbound connections, there's no need
to open firewall ports for incoming connections or components in the DMZ. All connections are outbound
and over a secure channel.
Security Analytics and Machine Learning (ML ) based intelligence. Because it's part of Azure Active
Directory, Application Proxy can leverage Azure AD Identity Protection (requires Premium P2 licensing).
Azure AD Identity Protection combines machine-learning security intelligence with data feeds from
Microsoft's Digital Crimes Unit and Microsoft Security Response Center to proactively identify
compromised accounts. Identity Protection offers real-time protection from high-risk sign-ins. It takes into
consideration factors like accesses from infected devices, through anonymizing networks, or from atypical
and unlikely locations to increase the risk profile of a session. This risk profile is used for real-time
protection. Many of these reports and events are already available through an API for integration with your
SIEM systems.
Remote access as a service. You don't have to worry about maintaining and patching on-premises servers
to enable remote access. Application Proxy is an internet scale service that Microsoft owns, so you always
get the latest security patches and upgrades. Unpatched software still accounts for a large number of
attacks. According to the Department of Homeland Security, as many as 85 percent of targeted attacks are
preventable. With this service model, you don't have to carry the heavy burden of managing your edge
servers anymore and scramble to patch them as needed.
Intune integration. With Intune, corporate traffic is routed separately from personal traffic. Application
Proxy ensures that the corporate traffic is authenticated. Application Proxy and the Intune Managed
Browser capability can also be used together to enable remote users to securely access internal websites
from iOS and Android devices.
Roadmap to the cloud
Another major benefit of implementing Application Proxy is extending Azure AD to your on-premises
environment. In fact, implementing App Proxy is a key step in moving your organization and apps to the cloud. By
moving to the cloud and away from on-premises authentication, you reduce your on-premises footprint and use
Azure AD's identity management capabilities as your control plane. With minimal or no updates to existing
applications, you have access to cloud capabilities such as single sign-on, multi-factor authentication, and central
management. Installing the necessary components to App Proxy is a simple process for establishing a remote
access framework. And by moving to the cloud, you have access to the latest Azure AD features, updates, and
functionality, such as high availability and the disaster recovery.
To learn more about migrating your apps to Azure AD, see the Migrating Your Applications to Azure Active
Directory white paper.
Architecture
The following diagram illustrates in general how Azure AD authentication services and Application Proxy work
together to provide single sign-on to on-premises applications to end users.
1. After the user has accessed the application through an endpoint, the user is redirected to the Azure AD sign-in
page. If you've configured Conditional Access policies, specific conditions are checked at this time to ensure
that you comply with your organization's security requirements.
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.
4. Application Proxy forwards the request, which is picked up by the Application Proxy connector.
5. The connector performs any additional authentication required on behalf of the user (Optional depending on
authentication method), requests the internal endpoint of the application server and sends the request to the
on-premises application.
6. The response from the application server is sent through the connector to the Application Proxy service.
7. The response is sent from the 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.
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.
Azure AD Application Proxy consists of the cloud-based Application Proxy service and an on-premises connector.
The connector listens for requests from the Application Proxy service and handles connections to the internal
applications. It's important to note that all communications occur over SSL, and always originate at the connector
to the Application Proxy service. That is, communications are outbound only. The connector uses a client certificate
to authenticate to the Application Proxy service for all calls. The only exception to the connection security is the
initial setup step where the client certificate is established. See the Application Proxy Under the hood for more
details.
Application Proxy Connectors
Application Proxy connectors are lightweight agents deployed on-premises that facilitate the outbound connection
to the Application Proxy service in the cloud. The connectors must be installed on a Windows Server that has
access to the backend application. Users connect to the App Proxy cloud service that routes their traffic to the apps
via the connectors as illustrated below.
Setup and registration between a connector and the App Proxy service is accomplished as follows:
1. The IT administrator opens ports 80 and 443 to outbound traffic and allows access to several URLs that are
needed by the connector, the App Proxy service, and Azure AD.
2. The admin signs into the Azure portal and runs an executable to install the connector on an on-premises
Windows server.
3. The connector starts to "listen" to the App Proxy service.
4. The admin adds the on-premises application to Azure AD and configures settings such as the URLs users need
to connect to their apps.
For more information, see Plan an Azure AD Application Proxy deployment.
It's recommended that you always deploy multiple connectors for redundancy and scale. The connectors, in
conjunction with the service, take care of all the high availability tasks and can be added or removed dynamically.
Each time a new request arrives it's routed to one of the connectors that is available. When a connector is running,
it remains active as it connects to the service. If a connector is temporarily unavailable, it doesn't respond to this
traffic. Unused connectors are tagged as inactive and removed after 10 days of inactivity.
Connectors also poll the server to find out if there is a newer version of the connector. Although you can do a
manual update, connectors will update automatically as long as the Application Proxy Connector Updater service
is running. For tenants with multiple connectors, the automatic updates target one connector at a time in each
group to prevent downtime in your environment.
Note: You can monitor the Application Proxy version history page to be notified when updates have been released
by subscribing to its RSS feed.
Each Application Proxy connector is assigned to a connector group. Connectors in the same connector group act
as a single unit for high availability and load balancing. You can create new groups, assign connectors to them in
the Azure portal, then assign specific connectors to serve specific applications. It's recommended to have at least
two connectors in each connector group for high availability.
Connector groups are useful when you need to support the following scenarios:
Geographical app publishing
Application segmentation/isolation
Publishing web apps running in the cloud or on-premises
For more information about choosing where to install your connectors and optimizing your network, see Network
topology considerations when using Azure Active Directory Application Proxy.
Other use cases

Up to this point, we've focused on using Application Proxy to publish on-premises apps externally while enabling
single sign-on to all your cloud and on-premises apps. However, there are other use cases for App Proxy that are
worth mentioning. They include:
Securely publish REST APIs. When you have business logic or APIs running on-premises or hosted on
virtual machines in the cloud, Application Proxy provides a public endpoint for API access. API endpoint access
lets you control authentication and authorization without requiring incoming ports. It provides additional
security through Azure AD Premium features such as multi-factor authentication and device-based Conditional
Access for desktops, iOS, MAC, and Android devices using Intune. To learn more, see How to enable native
client applications to interact with proxy applications and Protect an API by using OAuth 2.0 with Azure Active
Directory and API Management.
Remote Desktop Services (RDS ). Standard RDS deployments require open inbound connections. However,
the RDS deployment with Application Proxy has a permanent outbound connection from the server running
the connector service. This way, you can offer more applications to end users by publishing on-premises
applications through Remote Desktop Services. You can also reduce the attack surface of the deployment with a
limited set of two-step verification and Conditional Access controls to RDS.
Publish applications that connect using WebSockets. Support with Qlik Sense is in Public Preview and
will be expanded to other apps in the future.
Enable native client applications to interact with proxy applications. You can use Azure AD Application
Proxy to publish web apps, but it also can be used to publish native client applications that are configured with
the Azure AD Authentication Library (ADAL ). Native client applications differ from web apps because they're
installed on a device, while web apps are accessed through a browser.
Conclusion
The way we work and the tools we use are changing rapidly. With more employees bringing their own devices to
work and the pervasive use of Software-as-a-Service (SaaS ) applications, the way organizations manage and
secure their data must also evolve. Companies no longer operate solely within their own walls, protected by a
moat that surrounds their border. Data travels to more locations than ever before -- across both on-premises and
cloud environments. This evolution has helped increase users' productivity and ability to collaborate, but it also
makes protecting sensitive data more challenging.
Whether you're currently using Azure AD to manage users in a hybrid coexistence scenario or are interested in
starting your journey to the cloud, implementing Azure AD Application Proxy can help reduce the size of your on-
premises footprint by providing remote access as a service.
Organizations should begin taking advantage of App Proxy today to take advantage of the following benefits:
Publish on-premises apps externally without the overhead associated with maintaining traditional VPN or
other on-premises web publishing solutions and DMZ approach
Single sign-on to all applications, be they Office 365 or other SaaS apps and including on-premises
applications
Cloud scale security where Azure AD leverages Office 365 telemetry to prevent unauthorized access
Intune integration to ensure corporate traffic is authenticated
Centralization of user account management
Automatic updates to ensure you have the latest security patches
New features as they are released; the most recent being support for SAML single sign-on and more granular
management of application cookies
Next steps
For information about planning, operating, and managing Azure AD Application Proxy, see Plan an Azure AD
Application Proxy deployment.
To schedule a live demo or get a free 90-day trial for evaluation, see Getting started with Enterprise Mobility +
Security.
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, select Azure Active Directory.
2. In the Azure Active Directory pane, select Enterprise applications.
3. The All applications pane opens to show a random sample of the applications in your Azure AD tenant.
Select New application at the top of the All applications pane to add a gallery app to your tenant.
4. In the Categories pane, you'll see icons under the Featured applications area that are a random sample
of gallery applications. To see more applications, you could select Show more but we don't recommend
searching this way because there are thousands of applications in the gallery.
5. 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 select Add. The following example shows the Add app
form that appears after searching for github.com.
6. 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.
7. When you've finished making changes to the properties, select Add.
8. A getting started page appears with the options for configuring the application for your organization.
You've 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 to
do is find your application.
3. From the Application Type drop-down menu, select All Applications, and then select 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, select Show more one or more times.
5. To quickly find an application in your tenant, enter the application name in the search box and select Apply.
This example finds the GitHub-test application added previously.
Configure user sign-in properties

Now that you've found the application, you can open it and configure application properties.
To edit the application properties:
1. Select the application to open it.
2. Select Properties to open the properties pane for editing.
3. Take a moment to understand the sign-in options. The options determine how users who are assigned or
unassigned to the application can sign into the application. And, the options also determine if a 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 aren't 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 best options 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
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've already found your application, select the application.
3. In the left pane, select Properties.
4. Upload the logo.
5. When you're finished, select Save.
Next steps
Now that you've added the application to your Azure AD organization, choose a single sign-on method you want
to use and refer to the appropriate article below:
Configure SAML -based single sign-on
Configure password 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 choose Apply. A random sample
of your tenant applications appears.
4. To view more applications, select Load 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

Select options according to what you're looking for.
1. You can view the applications by 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 aren't visible to users.
5. After choosing the options you want, select Apply.
Search for a tenant application

To search for a particular application:
1. In the Application Type menu, select All applications, and choose Apply.
2. Enter the name of the application you want to find. If the application has been added to your Azure AD
tenant, it appears in the search results. This example shows that GitHub hasn't 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. You learned 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've found the application you were looking for, you can continue to Add more applications to your
tenant. Or, you can select the application to view or edit properties and configuration options. For example, you
could configure single sign-on.
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 on-premises application to Azure AD, you need:
A Microsoft Azure AD premium subscription
An application administrator account
User identities must be synchronized from an on-premises directory or created directly within your
Azure AD tenants. Identity synchronization allows Azure AD to pre-authenticate users before granting
them access to App Proxy published applications and to have the necessary user identifier information
to perform single sign-on (SSO ).
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 or span trusting domains. Having the servers in the same domain or trusting domains 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.
TLS requirements
The Windows connector server needs to have TLS 1.2 enabled before you install the Application Proxy
connector.
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.
IMPORTANT
To provide the best-in-class encryption to our customers, the Application Proxy service limits access to only TLS 1.2
protocols. These changes were gradually rolled out and effective since August 31, 2019. Make sure that all your
client-server and browser-server combinations are updated to use TLS 1.2 to maintain connection to Application
Proxy service. These include clients your users are using to access applications published through Application Proxy.
See Preparing for TLS 1.2 in Office 365 for useful references and resources.
Prepare your on-premises environment

Start by enabling communication to Azure data centers to prepare your environment for Azure AD
Application Proxy. If there's a firewall in the path, make sure it's open. An open firewall allows the connector
to 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.
Allow access to URLs
Allow access to the following URLs:
URL HOW IT'S USED
*.msappproxy.net Communication between the connector and the

*.servicebus.windows.net Application Proxy cloud service
URL HOW IT'S USED
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

secure.aadcdn.microsoftonline-p.com process.
*.microsoftonline.com
*.microsoftonline-p.com
*.msauth.net
*.msauthimages.net
*.msecnd.net
*.msftauth.net
*.msftauthimages.net
*.phonefactor.net
enterpriseregistration.windows.net
management.azure.com
policykeyservice.dc.ad.msft.net
You can allow connections to *.msappproxy.net and *.servicebus.windows.net if your firewall or proxy lets
you configure DNS allow lists. If not, you need to allow access to the Azure IP ranges and Service Tags -
Public Cloud. The IP ranges are updated each week.
Install and register a connector

To use Application Proxy, install a connector on each Windows server you're using 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 [email protected]
or any other admin alias on that domain.
2. Select your username in the upper-right corner. Verify you're signed in to a directory that uses
Application Proxy. If you need to change directories, select Switch directory and choose a directory
that uses Application Proxy.
3. In left navigation panel, select Azure Active Directory.
4. Under Manage, select Application proxy.
5. Select Download connector service.
6. Read the Terms of Service. When you're ready, select Accept terms & Download.
7. At the bottom of the window, select Run to install the connector. An install wizard opens.
8. Follow the instructions in the wizard to install the service. 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 Configuration is set to Off.
General remarks
If you've previously installed a connector, reinstall to get the latest version. To see information about
previously released versions and what changes they include, see Application Proxy: Version Release History.
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.
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 the installation through Azure portal
To confirm the connector installed and registered correctly:
1. Sign in to your tenant directory in the Azure portal.
2. In the left navigation panel, select Azure Active Directory, and then select Application Proxy
under the Manage section. All of your connectors and connector groups appear on this page.
3. View a connector to verify its details. The connectors should be expanded by default. If the connector
you want to view isn't expanded, expand the connector to view the 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 Problem installing the Application Proxy Connector.
Verify the installation through your 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 to select 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. In the left navigation panel, select Azure Active Directory.
3. Select Enterprise applications, and then select New application.
4. Select On-premises application.
5. In the Add your own on-premises application section, 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 AD to access the application. You can
still set up authentication requirements on the
backend.
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.
6. 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. At default, the backend
application timeout has a length of 85 seconds. When
set to long, the backend timeout is increased to 180
seconds.
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. Only use this setting for
applications that can't 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.
7. 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. Select Enterprise applications, and then select the application you want to test.
2. Select Getting started, and then select Assign a user for testing.
3. Under Users and groups, select Add user.
4. Under Add assignment, select Users and groups. The User and groups section appears.
5. Choose the account you want to add.
6. Choose Select, and then select Assign.
Test the sign-on
To test the sign-on to the application:
1. In your browser, navigate to the external URL that you configured during the publish step. You should
see the start screen.
2. Sign 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.
Plan an Azure Active Directory access panel
deployment
The Azure Active Directory access panel is a web-based portal that enables you to lower support costs, increase
productivity and security, and reduce user frustration. The system includes detailed reporting that tracks when
users access the system, and notifies administrators to misuse or abuse.
The Azure Active Directory access panel enables users to:
Discover and access all their company’s Azure Active Directory connected resources, such as applications.
Request access to new apps and groups or manage access to these resources for others.
Manage self-service password resets and multi-factor authentication settings.
Manage their devices.
It also allows administrators to manage:
Terms of service
Organizations
Access reviews
Benefits of Azure Active Directory access panel integration

The Microsoft Azure Active Directory (Azure AD ) access panel benefits businesses in the following ways:
Provides intuitive user experience: Enabling the access panel provides users with the ability to have single
launch pad for all their Azure single-sign on connected applications. As capabilities like group management and
self-service password reset are added, users continue to have a unified portal to find these settings. The intuitive
experience will allow users to get back to work faster and be more productive, while reducing their frustration.
Increases productivity: All user applications in the access panel have single sign-on (SSO ) enabled. Enabling
single sign-on across enterprise applications and Office 365 provides a superior sign in experience for existing
users, reducing or eliminating additional sign in prompts. The access panel enables self-service and dynamic
membership, and improves the overall security of your identity system by ensuring the right people manage access
to the applications. The access panel serves as a coherent landing page for a user to quickly find resources and
continue work tasks.
Manages cost: Enabling the access panel with Azure Active Directory may allow divestment of on-premise
infrastructures. It reduces support costs by enabling users to have a consistent portal to find all their apps, request
access to resources, and manage their account.
Increases flexibility and security: The access panel lets you access the security and flexibility that a cloud
platform provides. Administrators can easily change settings to applications and resources and accommodate new
security requirements without affecting users.
Enables robust auditing and usage tracking: Auditing and usage tracking for all end-user capabilities let you
know when users are using their resources and ensures you to assess security.
Licensing considerations
The access panel is free and requires no licenses to use at a basic all users. However, the number of objects in your
directory and the features you wish to deploy may require additional licenses. Common Azure AD scenarios
include the following security features that do have licensing requirements.
Azure Multi-Factor Authentication
Group based membership
Self-service password requirement
Identity Protection
See the full licensing guide for Azure Active Directory.
Prerequisites for deploying the Azure AD access panel
The following prerequisites must be completed before the beginning of this project.
Application SSO integration
Azure AD user and group infrastructure
Plan the Azure AD access panel deployment

The following table outlines the key use cases for an access panel deployment:
AREA DESCRIPTION
Access Access panel portal is accessible from corporate and personal

devices within the corporate network.
Access Access panel portal is accessible to corporate devices outside

of the corporate network.
Auditing Usage data is downloaded into corporate systems at least

every 29 days.
Governance Lifecycle of user assignments to Azure AD connected

applications and groups are defined and monitored.
Security Access to resources is controlled via user and group

assignments. Only authorized users can manage resource
access.
Performance Access assignment propagation timelines are documented and

monitored.
User Experience Users are aware of the access panel capabilities and how to
use them.
User Experience Users can self-manage their access to applications and groups.
User Experience Users can manage their accounts.
User Experience Users are aware of browser compatibility.
Support Users can find support for access panel issues.
Best practices for deploying the Azure AD access panel

The functionality of the access panel can be enabled gradually. We recommend the following order of deployment:
1. My Apps
App launcher
Self-service app management
Microsoft Office 365 integration
2. Self-service app discovery
Self-service password reset
Multi-factor authentication settings
Device management
Terms of use
Manage organizations
3. My Groups
Self-service group management
4. Access reviews
Access review management
Starting with My Apps introduces users to the portal as a common place for accessing resources. The addition of
self-service application discovery builds on the My Apps experience. My Groups and access reviews build on the
self-service capabilities.
Plan configurations for the Azure AD access panel
The following table lists several important access panel configurations and the typical values you might use:
CONFIGURATION TYPICAL VALUES
Determine the pilot group(s) Identify the Azure AD security group to be used and ensure all
pilot members are a part of the group.
Determine the group or groups to be enabled for production. Identify the Azure AD security group(s), or AD groups synced
to Azure AD, to be used. Ensure all pilot members are a part
of the group.
Allow users to use single sign on to what types of applications Federated SSO, OAuth, Password SSO, App Proxy
Allow users to use self-service password reset Yes
Allow users to use multi-factor authentication Yes
Allow users to use self-service group management for what Security groups, O365 groups
types of groups
Allow users to use self-service app management Yes
Allow users to use access reviews Yes
Plan consent strategy

Users or administrators must consent to any application’s terms of use and privacy policies. If possible given your
business rules, we advise using Administrator consent, which gives users a better experience.
To use administrator consent, you must be a global administrator of the tenant, and the applications must be:
Registered in your tenant, or
Registered in another Azure AD tenant and previously consented by at least one end user.
For more information, see Configure the way end-users consent to an application in Azure Active Directory.
Engage the right stakeholders
When technology projects fail, they typically do so because of mismatched expectations on impact, outcomes, and
responsibilities. To avoid these pitfalls, ensure that you're engaging the right stakeholders and that stakeholder
roles in the project are well understood.
Plan communications
Communication is critical to the success of any new service. Proactively inform your users how and when their
experience will change, and how to gain support if needed.
While the access panel doesn't typically create user issues, it's important to prepare. Create guides and a list of all
resources for your support personnel before your launch.
Communications templates
Microsoft provides customizable templates for emails and other communications for the access panel. You can
adapt these assets for use in other communications channels as appropriate for your corporate culture.
Plan your SSO configuration

When a user signs in to an application, they go through an authentication process and are required to prove who
they are. Without single sign-on, a password stored at the application, and the user is required to know this
password. With single sign-on (SSO ) users’ credentials are passed to the application so they do not need to reenter
passwords for each application.
To launch applications in My Apps, single sign-on (SSO ) must be enabled for the applications.
Azure AD supports three different ways to enable single sign-on to applications:
Federated single sign-on
Enables an application to redirect to Azure AD for user authentication instead of prompting for a
password.
Is supported for applications using protocols such as SAML 2.0, WS -Federation, or OpenID Connect,
and is the richest mode of single sign-on.
Password-based single sign-on
Enables secure application password storage and replay using a web browser extension or mobile app.
Leverages the existing sign in process provided by the application but enables an administrator to
manage the passwords. User is not required to know the password.
Existing single sign-on
Enables Azure AD to leverage any existing single sign-on that has been configured for the application.
Enables these applications to be linked to the Office 365 or Azure AD access panel portals.
Enables additional reporting in Azure AD when the applications are launched there.
Includes using Azure Application Proxy and the linked single sign-on mode.
Learn how to configure an application’s SSO mode here: Single sign-on to applications in Azure Active Directory.
For the best experience with the My Apps page, we recommend starting with the integration of cloud applications
available for federated SSO. Federated SSO allows users to have a consistent one-click experience across their app
launching surfaces and tends to be more robust in configuration control.
Use Federated SSO with Azure AD (OpenID Connect / SAML ) when an application supports it, instead of
password-based SSO and ADFS.
For more information on how to deploy and configure you SaaS applications, see the SaaS SSO deployment plan.
Plan to deploy the My Apps browser extension
If password-based SSO applications are made available to end users, they need to install the My Apps secure sign
in extension to sign in. The extension executes a script that transmits the password into the application’s sign in
form. Users will be prompted to install the extension when they first launch the password-based SSO application.
More information about the extension can found in our documentation on installing the access panel browser
extension.
If you must integrate password-based SSO applications,, you should define a mechanism to deploy the extension
at scale with supported browsers. Options include:
Group Policy for Internet Explorer
System Center Configuration Manager (SCCM ) for Internet Explorer
User driven download and configuration for Chrome, Firefox, Microsoft Edge, or IE
Learn more: How to configure password single sign on.
Users not using password-based SSO applications also benefit from the extension. These benefits include the
ability to launch any app from its search bar, finding access to recently used applications, and having a link to the
My Apps page.
Here’s what the user will see when launching a password-based SSO application for the first time:
Plan for mobile access

A browser protected with Intune policy (Microsoft Edge or Intune Managed Browser) will be necessary for mobile
users launching password-based SSO applications. A policy-protected browser enables the transfer of the
password saved for the application. Microsoft Edge or the managed browser provides a set of web data protection
features. You can also use Microsoft Edge for enterprise scenarios on iOS and Android devices. Microsoft Edge
supports the same management scenarios as the Intune Managed Browser and improves the end-user experience.
Learn more: Manage web access using a Microsoft Intune policy-protected browser
Plan your My Apps Deployment

The foundation of the access panel is the application launcher My Apps, which users access at
https://myapps.microsoft.com. The My Apps pages give users a single place to start their work and get to their
necessary applications. Here, users find a list of all the applications they have single sign-on access to.
The same applications will be shown in the Office 365 app launcher when users are using the Office 365 portal.
Plan the order in which you'll add applications to the My Apps launcher, and whether you'll roll them out gradually
or all at once. To do so, create an application inventory listing the type of authentication and any existing single
sign-on (SSO ) integrations for each application.
Add applications to the My Apps panel
Any Azure AD SSO -enabled application can be added to the My Apps launcher. Other applications are added by
using the Linked SSO option. You can configure an application tile that links to the URL of your existing web
application. Linked SSO allows you to start directing users to the My Apps portal without having to migrate all the
applications to Azure Active Directory SSO. You can gradually move to Azure AD SSO -configured applications
without disrupting the users' experience.
Plan whether to use My Apps or an existing portal
Your users may already have an application or portal other than My Apps. If so, decide whether to support both
portals, or if you will only use one.
If an existing portal is already being used as a starting point for users, you can integrate My Apps functionality by
using “user access URLs.” User access URLs function as direct links to the applications available in the My Apps
portal. These URLs can be embedded within any existing website. When a user clicks the link, it launches the
application from the My Apps portal.
You can find the User access URL property in the Properties area of the application in the Azure portal.
Plan self-service application discovery and access
Once a core set of applications are deployed to a user’s My Apps page, we recommend enabling self-service app
management features. Self-service app discovery enables:
Users to find new apps they may add to their My Apps.
Users to add optional apps that you may not know they need during setup.
Approval workflows are available for explicit approval to access applications. Users who are approvers will receive
notifications within the My Apps portal when there are pending request for access to the application.
Plan self-service group membership

You can enable users to create and manage their own security groups or Office 365 groups in Azure Active
Directory (Azure AD ). The owner of the group can approve or deny membership requests and delegate control of
group membership. Self-service group management features aren't available for mail-enabled security groups or
distribution lists.
To plan for self-service group membership, determine if you'll allow all users in your organization to create and
manage groups, or only a subset of users. If a subset of users, you'll need to set up a group to which those people
are added. See Set up self-service group management in Azure active Directory for details on enabling these
scenarios.
Plan reporting and auditing

Azure AD provides reports that offer technical and business insights. Work with your business and technical
application owners to assume ownership of and consume these reports on a regular basis. The table below
provides some examples of typical reporting scenarios.
GOVERNANCE AND
MANAGE RISK INCREASE PRODUCTIVITY COMPLIANCE
Report types Application permissions and Account provisioning activity Review who is accessing the
usage. applications
Potential actions Audit access; revoke Remediate any provisioning Revoke access
permissions errors
Azure AD keeps most auditing data for 30 days. The data is available via Azure Admin Portal or API for you to
download into your analysis systems.
Auditing
Audit logs for application access are available for 30 days. If security auditing within your enterprise requires
longer retention, the logs need to be exported into a Security Information Event and Management (SIEM ) tool
such as Splunk or ArcSight.
For auditing, reporting, and disaster recovery backups, document the required frequency of download, the target
system is, and who is responsible for managing each backup. You may not need separate auditing and reporting
backups. Your disaster recovery backup should be a separate entity.
Deploy applications to users’ My Apps panel

After an application has been configured for SSO, groups are assigned access. Users in the assigned groups will
have access and will see the application in their My Apps and the Office 365 app launcher
See Assign users and groups to an application in Active Directory.
If during testing or deployment you want to add the groups, but not yet allow the applications to show in My Apps,
see Hide an application from user’s experience in Azure Active Directory.
Deploy Microsoft Office 365 applications to My Apps
For Office 365 applications, users receive a copy of Office based on licenses assigned to them. A prerequisite for
access to Office applications is assigning users to the correct licenses tied to the Office applications. When you
assign a user the license they'll automatically see the applications associated with the license in their My Apps page
and in the O365 app launcher.
If you want to hide a set of Office applications from users, there's an option to hide apps from the My Apps portal,
while still allowing access from the O365 portal. Find these settings in the User settings portion of the application.
Learn more: Hide an application from user’s experience in Azure Active Directory.
Deploy application self-service capabilities
Self-service application access allows users to self-discover and request access to any applications. Users are given
the freedom to get access to the apps they need without going through an IT-group each time to request access.
When a user requests access and is approved either automatically or manually by an app owner, they're added to a
group on the back end. Reporting is enabled on who has requested, approved, or removed access, and gives you
control over managing the roles assigned.
You can delegate approval of application access requests to business approvers. The business approver can set the
app-access passwords right from the business approver’s My Apps page.
Learn more: How to use self-service application access
Validate your deployment
Ensure your access panel deployment is thoroughly tested and a rollback plan is in place.
The following tests should be conducted with both corporate-owned devices and personal devices. These test cases
should also reflect your business use cases. Following are a few cases based on the sample business requirements
in this document, and on typical technical scenarios. Add others specific to your needs.
Application SSO access test case examples:
BUSINESS CASE EXPECTED RESULT
User signs in into the My Apps portal User can sign in and see their applications
User launches a federated SSO application User is automatically signed into the application
User launches a password SSO application for the first time User needs to install the My Apps extension
User launches a password SSO application a subsequent time User is automatically signed into the application
User launches an app from O365 Portal User is automatically signed into the application
User launches an app from the Managed Browser User is automatically signed into the application
Application self-service capabilities test case examples
BUSINESS CASE EXPECTED RESULT
User can manage membership to the application User can add/remove members who have access to the app
User can edit the application User can edit the application’s description and credentials for
password SSO applications
Rollback steps
It’s important to plan what to do in case your deployment doesn’t go as planned. If SSO configuration fails during
deployment, you must understand how to troubleshoot SSO issues and reduce impact to your users. In extreme
circumstances, you may need to rollback SSO.
Manage your implementation

Microsoft recommends using the least privileged role to accomplish a required task within Azure Active Directory.
Microsoft recommends review the different roles that are available and choosing the right one to solve your needs
for each persona for this application. Some roles may need to be applied temporarily and removed after the
deployment has been completed.
PERSONAS ROLES AZURE AD ROLE
Help Desk Admin Tier 1 Support None
Identity Admin Configure and Debug when issues Global Admin

impact Azure AD
Application Admin User attestation in application, None

configuration on users with permissions
PERSONAS ROLES AZURE AD ROLE
Infrastructure Admins Cert Rollover Owner Global Admin
Business Owner/Stakeholder User attestation in application, None

We recommend using Privileged Identity Management to manage your roles to provide additional auditing,
control, and access review for users with directory permissions.
Troubleshoot access panel issues
Create troubleshooting guides for your support organization with common scenarios and pointing to Microsoft
documentation on their resolutions. You may want to create guides that break support into the tiers used by your
organization.
See the below troubleshooting guides for reference:
Applications not appearing
Unexpected applications appearing
User cannot sign in to the access panel
Problems using self-service application access
Issues with the browser extension
Next steps
Plan a deployment of Azure Active Directory Multi-factor authentication
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
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 and on-premises 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.
SINGLE SIGN-ON METHOD APPLICATION TYPES WHEN TO USE
Linked cloud and on-premises Choose linked 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.
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 Microsoft Graph. We provide easy to adopt SDKs for your app, and
additionally, your app will be ready to use Microsoft Graph.
For more information, see:
OAuth 2.0
OpenID Connect 1.0
Microsoft identity platform 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 a SaaS 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 .
To configure an on-premises application for SAML -based single sign-on, see SAML single-sign-on for on-
premises applications with Application Proxy.
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
NOTE
Internet Explorer is on limited support and no longer receives new software updates. Microsoft Edge is the
recommended browser.
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 an cloud application for password-based single sign-on, see Configure 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 sign-on
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.
To configure an application for linked sign-on, see Configure linked sign-on.
Linked sign-on for application migration
Linked sign-on 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 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
Configuring SAML -based single sign-on
Configuring password-based single sign on
Configuring linked sign-on
Introduction to Managing Access to applications
Download link: Single sign-on deployment plan.
Enable Single Sign-on for your multi-tenant
application
When you offer your application for use by other companies through a purchase or subscription, you make your
application available to customers within their own Azure tenants. This is known as creating a multi-tenant
application. For overview of this concept, see Multitenant Applications in Azure and Tenancy in Azure Active
Directory.
What is Single Sign-On

Single sign-on (SSO ) adds security and convenience when users sign on to applications by using Azure Active
Directory and other identities. When an application is SSO enabled, users don't have to enter separate credentials
to access that application. For a full explanation of Single sign-on. See Single sign-on to applications in Azure
Active Directory.
Why Enable Single Sign-on in your application?

There are many advantages to enabling SSO in your multi-tenant application. When you enable SSO for your
application:
Your application can be listed in the Azure Marketplace, where your app is discoverable by millions of
organizations using Azure Active Directory.
Enables customers to quickly configure the application with Azure AD.
Your application can be discoverable in the Office 365 App Gallery, the Office 365 App Launcher and within
Microsoft Search on Office.com
Your application can use the Microsoft Graph REST API to access the data that drives user productivity that
is available from the Microsoft Graph.
You reduce support costs by making it easier for your customers.
Application-specific documentation coproduced with the Azure AD team for our mutual customers eases
adoption.
If one-click SSO is enabled, your customers’ IT Administrators don't have to learn how to configure your
application for use in their organization.
You provide your customers the ability to completely manage their employee and guest identities’
authentication and authorization.
Placing all account management and compliance responsibility with the customer owner of those
identities.
Providing ability to enable or disable SSO for specific identity providers, groups, or users to meet
their business needs.
You increase your marketability and adoptability. Many large organizations require that (or aspire to) their
employees have seamless SSO experiences across all applications. Making SSO easy is important.
You reduce end-user friction, which may increase end-user usage and increase your revenue.
How to enable Single Sign-on in your published application
1. Choose the right federation protocol for your multi-tenant application.
2. Implement SSO in your application
See guidance on authentication patterns
See Azure active Directory code samples for OIDC and OAuth protocols
3. Create your Azure Tenant and test your application
4. Create and publish SSO documentation on your site.
5. Submit your application listing and partner with Microsoft to create documentation on Microsoft’s site.
6. Join the Microsoft Partner Network (free) and create your go to market plan.
Create an Azure tenant for a multi-tenant application
To provide access to your multi-tenant application you must create an Azure Active Directory tenant to register the
application and enable the federation of your customer’s identities. See Choosing the right federation protocol for
your multi-tenant application. This tenant will allow you to test your application and the federation in an
environment that is similar to your customers Azure AD environments.
Costs of hosting a multi-tenant application

Azure Active Directory is available in multiple editions. See the detailed feature comparison.
You can create your Azure subscription and Azure active directory for free, and use basic features.
Create your tenant

1. Create your Tenant. See Set up a dev environment.
2. Enable and test single sign-on access to your application,
a. For OIDC or Oath applications, Register your application as a multi-tenant application. Select the
Accounts in any organizational directory and personal Microsoft accounts option in Supported Account
types
b. For SAML - and WS -Fed-based applications, you Configure SAML -based Single sign-on applications
using a generic SAML template in Azure AD.
You can also convert a single-tenant application to multi-tenant if necessary.
Next Steps
Integrate SSO in your application
Choose the right federation protocol for your multi-
tenant application
When you develop your software as a service (SaaS ) application, you must select the federation protocol that best
meets your and your customers’ needs. This decision is based on your development platform, and your desire to
integrate with data available within your customers’ Office 365 and Azure AD ecosystem.
See the complete list of protocols available for SSO integrations with Azure Active Directory. The following table
compares
Open Authentication 2.0 (OAuth 2.0)
Open ID Connect (OIDC )
Security Assertion Markup Language (SAML )
Web Services Federation (WSFed)
CAPABILITY OAUTH / OIDC SAML / WSFED
Web-based Single sign-on √ √
Web-based Single sign-out √ √
Mobile-based Single sign-on √ √*
Mobile-based Single sign-out √ √*
Conditional Access policies for mobile √ X

applications
Seamless MFA experience for mobile √ X

applications
Access Microsoft Graph √ X
*Possible, but Microsoft doesn't provide samples or guidance.
OAuth 2.0 and Open ID Connect

OAuth 2.0 is an industry-standard protocol for authorization. OIDC (OpenID Connect) is an industry standard
identity authentication layer built on top of the Oath 2.0 protocol.
Benefits
Microsoft recommends using OIDC/OAuth 2.0 as they have authentication and authorization built in to the
protocols. With SAML, you must additionally implement authorization.
The authorization inherent in these protocols enables your application to access and integrate with rich user and
organizational data through the Microsoft Graph API.
Using OAuth 2.0 and OIDC simplifies your customers’ end-user experience when adopting SSO for your
application. You can easily define the permission sets necessary, which are then automatically represented to the
administrator or end user consenting.
Additionally, using these protocols enables your customers to use Conditional Access and MFA policies to control
access to the applications. Microsoft provides libraries and code samples across multiple technology platforms to
aid your development.
Implementation
You register your application with Microsoft Identity, which is an OAuth 2.0 provider. You could then also register
your OAuth 2.0-based application with any other Identity Provider that you wish to integrate with.
For information on how to register your application and implement these protocols for SSO to web apps, see
Authorize access to web applications using OpenID Connect and Azure Active Directory. For information on how
to implement these protocols for SSO in mobile apps, see the following:
Android
iOS
Universal Windows Platform
SAML 2.0 and WSFed

Security Assertion Markup Language (SAML ) is usually used for web applications. See How Azure uses the SAML
protocol for an overview.
Web Services Federation (WSFed) is an industry standard generally used for web applications that are developed
using the .Net platform.
Benefits
SAML 2.0 is a mature standard and most technology platforms support open-source libraries for SAML 2.0. You
can provide your customers an administration interface to configure SAML SSO. They can configure SAML SSO
for Microsoft Azure AD, and any other identity provider that supports SAML 2
Trade -offs
When using SAML 2.0 or WSFed protocols for mobile applications, certain conditional access policies including
Multi-factor Authentication (MFA) will have a degraded experience. Additionally, if you want to access the
Microsoft Graph, you will need to implement authorization through OAuth 2.0 to generate necessary tokens.
Implementation
Microsoft does not provide libraries for SAML implementation or recommend specific libraries. There are many
open-source libraries available.
SSO and Using Microsoft Graph Rest API

Microsoft Graph is the data fabric across all of Microsoft 365, including Office 365, Windows 10 and Enterprise
Mobility and Security, and additional products such as Dynamics 365. This includes the core schemas of the
entities such as Users, Groups, Calendar, Mail, Files, and more, that drive user productivity. Microsoft Graph offers
three interfaces for developers a REST based API, Microsoft Graph data connect, and Connectors that allow
developers to add their own data into the Microsoft Graph.
Using any of the above protocols for SSO enables your application’s access to the rich data available through the
Microsoft Graph REST API. This enables your customers to get more value from their investment in Microsoft
365. For example, your application can call the Microsoft Graph API to integrate with your customers’ Office 365
instance and surface users’ Microsoft Office and SharePoint items within your application.
If you are using Open ID Connect to authenticate, then your development experience is seamless because you will
use OAuth2, the foundation of Open ID Connect, to acquire tokens can be used for invoking Microsoft Graph
APIs. If your application is using SAML or WSFed, you must add additional code within your application to get
these OAuth2 to acquire the tokens required to invoking Microsoft Graph APIs.
Next Steps
Enable SSO for your multi-tenant application
Create documentation for your multi-tenant application
Create and publish single sign-on documentation for
your application
Documentation on your site

Ease of adoption is a significant factor in enterprise software decisions. Clear easy-to-follow documentation
supports your customers in their adoption journey and reduces support costs. Working with thousands of
software vendors, Microsoft has seen what works.
We recommend that your documentation on your site at a minimum include the following items.
Introduction to your SSO functionality
Protocols supported
Version and SKU
Supported Identity Providers list with documentation links
Licensing information for your application
Role-based access control for configuring SSO
SSO Configuration Steps
UI configuration elements for SAML with expected values from the provider
Service provider information to be passed to identity providers
If OIDC/OAuth
List of permissions required for consent with business justifications
Testing steps for pilot users
Troubleshooting information, including error codes and messages
Support mechanisms for customers
Documentation on the Microsoft Site

When you list your application with the Azure Active Directory Application Gallery, which also publishes your
application in the Azure Marketplace, Microsoft will generate documentation for our mutual customers explaining
the step-by-step process. You can see an example here. This documentation is created based on your submission
to the gallery, and you can easily update it if you make changes to your application using your GitHub account.
Next Steps
List your application in the Azure AD Application Gallery
Plan a single sign-on deployment
Single sign-on (SSO ) means accessing all applications and resources a user needs by signing in only once using a
single user account. With SSO, users can access all needed applications without being required to authenticate a
second time.
Benefits of SSO
Single sign-on (SSO ) adds security and convenience when users sign on to applications in Azure Active Directory
(Azure AD ).
Many organizations rely on software as a service (SaaS ) applications, such as Office 365, Box, and Salesforce, for
end user productivity. Historically, IT staff needed to individually create and update user accounts in each SaaS
application, and users needed to remember a password for each.
The Azure Marketplace has over 3000 applications with pre-integrated SSO connections, making it easy to
integrate them in your tenant.
Licensing
Azure AD licensing - SSO for pre-integrated SaaS applications is free. However, the number of objects in
your directory and the features you wish to deploy may require additional licenses. For a full list of license
requirements, see Azure Active Directory Pricing.
Application licensing - You'll need the appropriate licenses for your SaaS applications to meet your business
needs. Work with the application owner to determine whether the users assigned to the application have the
appropriate licenses for their roles within the application. If Azure AD manages the automatic provisioning
based on roles, the roles assigned in Azure AD must align with the number of licenses owned within the
application. Improper number of licenses owned in the application may lead to errors during the
provisioning/updating of a user.
Plan your SSO team

Engage the right stakeholders - When technology projects fail, it's typically due to mismatched expectations
on impact, outcomes, and responsibilities. To avoid these pitfalls, ensure that you're engaging the right
stakeholders and that stakeholders understand their roles.
Plan communications - Communication is critical to the success of any new service. Proactively communicate
to your users about how their experience will change, when it will change, and how to gain support if they
experience issues. Review the options for how end-users will access their SSO enabled applications, and craft
your communications to match your selection.
Plan your SSO protocol

An SSO implementation based on federation protocols improves security, reliability, and end user experiences and
is easier to implement. Many applications are pre-integrated in Azure AD with step-by step guides available. You
can find them on our Azure Marketplace. Detailed information on each SSO method can be found in the article
Single sign-on to applications in Azure Active Directory.
There are two primary ways in which you can enable your users to single sign-on to your apps:
With federated single sign-on Azure AD authenticates the user to the application by using their Azure
AD account. This method is supported for applications that support protocols such as SAML 2.0, WS -
Federation, or OpenID Connect, and is the richest mode of single sign-on. We recommend using Federated
SSO with Azure AD when an application supports it, instead of password-based SSO and ADFS.
With password-based single sign-on users sign in 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 enables secure application password storage and replay using a
web browser extension or mobile app. This option leverages the existing sign-in process provided by the
application, enables an administrator to manage the passwords, and doesn't require the user to know the
password.
Considerations for federation-based SSO
Using OpenID Connect and OAuth - If the application you're connecting to supports it, use the OIDC/OAuth
2.0 method to enable your SSO to that application. This method requires less configuration and enables a
richer user experience. For more information, see OAuth 2.0, OpenID Connect 1.0, and Azure Active Directory
developer’s guide.
Endpoint Configurations for SAML -based SSO - If you use SAML, your developers will need specific
information prior to configuring the application. For more info, see Edit the Basic SAML Configuration.
Certificate management for SAML -based SSO - When you enable Federated SSO for your application,
Azure AD creates a certificate that is by default valid for three years. You can customize the expiration date for
that certificate if needed. Ensure that you have processes in place to renew certificates prior to their expiration.
To learn more, see Azure AD Managing Certificates.
Considerations for password-based SSO
Using Azure AD for password-based SSO requires deploying a browser extension that will securely retrieve the
credentials and fill out the login forms. Define a mechanism to deploy the extension at scale with supported
browsers. Options include:
Group Policy for Internet Explorer
System Center Configuration Manager (SCCM ) for Internet Explorer
User driven download and configuration for Chrome, Firefox, Microsoft Edge, or IE
To learn more, see How to configure password single sign on.
Capturing login forms metadata for applications that aren't in the gallery
Microsoft supports capturing metadata on a web application for password vaulting (capturing the username and
password fields). Navigate to the login URL during the process of configuring the application to capture the forms
metadata. Ask the application owner for the exact login URL. This information is used during the sign-on process,
mapping Azure AD credentials to the application during sign-on.
To learn more, see What is application access and SSO with Azure AD? – Password-based SSO.
Indications that metadata in forms needs to be recaptured
When applications change their HTML layout, you might need to recapture the metadata to adjust for the changes.
Common symptoms that indicate that the HTML layout has change include:
Users reporting that clicking on the application gets “stuck” in the login page
Users reporting that the username or password isn't populated
Shared accounts
From the sign-in perspective, applications with shared accounts aren't different from a gallery application that uses
password SSO for individual users. However, there are some additional steps required when planning and
configuring an application meant to use shared accounts:
1. Work with application business users to document the following:
a. Set of users in the organization who will use the application
b. Existing set of credentials in the application associated with the set of users
2. For each combination of user set and credentials, create a security group in the cloud or on-premises based on
your requirements.
3. Reset the shared credentials. Once the app is deployed in Azure AD, individuals don't need the password of the
shared account. Since Azure AD will store the password, consider setting it to be very long and complex.
4. Configure automatic rollover of the password if the application supports it. That way, not even the
administrator who did the initial setup will know the password of the shared account.
Plan your authentication method

Choosing the correct authentication method is a crucial first decision in setting up an Azure AD hybrid identity
solution. Implement the authentication method that is configured by using Azure AD Connect, which also
provisions users in the cloud.
To choose an authentication method, you need to consider the time, existing infrastructure, complexity, and cost of
implementing your choice. These factors are different for every organization and might change over time. You
should choose the one that most closely matches your specific scenario. For more information, see Choose the
right authentication method for your Azure Active Directory hybrid identity solution.
Plan your security and governance

Identity is the new primary pivot for security attention and investments because network perimeters have become
increasingly porous and less effective with the explosion of BYOD devices and cloud applications.
Plan access reviews
Access Reviews enable organizations to efficiently manage group memberships, access to enterprise applications,
and role assignments. You should plan to review user access on a regular basis to make sure only the right people
have continued access.
Some of the key topics to plan for while setting up access reviews include:
1. Identifying a cadence for access reviews that fits your business need. This can be as frequent as once a
week, monthly, annually, or as an on-demand exercise.
2. Create groups that represent the reviewers of the app access reports. You'll need to ensure that
stakeholders most familiar with the app and its target users and use cases are participants in your access
reviews
3. Completing an access review includes taking away app access permissions to users who no longer need
access. Plan for handling potential support requests from denied users. A deleted user will remain deleted in
Azure AD for 30 days during which time they can be restored by an administrator if necessary. After 30
days, that user is permanently deleted. Using the Azure Active Directory portal, a Global Administrator can
explicitly permanently delete a recently deleted user before that time period is reached.
Plan auditing
Azure AD provides reports containing technical and business insights.
Both security and activity reports are available. Security reports show users flagged for risk, and risky sign-ins.
Activity reports help you understand the behavior of users in your organization by detailing sign-in activity and
providing audit trails of all logins. You can use reports to manage risk, increase productivity, and monitor
compliance.
REPORT TYPE ACCESS REVIEW SECURITY REPORTS SIGN-IN REPORT

REPORT TYPE ACCESS REVIEW SECURITY REPORTS SIGN-IN REPORT
Use to review Application permissions and Potentially compromised Who is accessing the
usage. accounts applications
Potential actions Audit access; revoke Revoke access; force security Revoke access
permissions reset
Azure AD retains most auditing data for 30 days and makes the data available through the Azure admin portal or
through an API for you to download into your analysis systems.
Consider using Microsoft Cloud Application Security
Microsoft Cloud App Security (MCAS ) is a Cloud Access Security Broker (CASB ) solution. It gives you visibility
into your cloud apps and services, provides sophisticated analytics to identify and combat cyberthreats, and
enables you to control how your data travels.
Deploying MCAS enables you to:
Use Cloud Discovery to map and identify your cloud environment and the cloud apps your organization is
using.
Sanctioning and un-sanction apps in your cloud
Use easy-to-deploy app connectors that take advantage of provider APIs, for visibility and governance of apps
that you connect to
Use Conditional Access App Control protection to get real-time visibility and control over access and activities
within your cloud apps
Helps you have continuous control by setting, and then continually fine-tuning, policies.
Microsoft Cloud Application Security (MCAS ) Session control is available for any browser on any major platform
on any operating system. Mobile apps and desktop apps can also be blocked or allowed. By natively integrating
with Azure AD, any apps that are configured with SAML, or Open ID Connect apps with single sign-on in Azure
AD can be supported, including several featured apps.
For information about MCAS, see the Microsoft Cloud App Security overview. MCAS is a user-based subscription
service. You can review licensing details in the MCAS licensing datasheet.
Use Conditional Access
With Conditional Access, you can automate criteria-based access control decisions for your cloud apps.
Conditional Access policies are enforced after the first-factor authentication has been completed. Therefore,
Conditional Access is not intended as a first line defense for scenarios like denial-of-service (DoS ) attacks, but can
use signals from these events to determine access. For example the sign-in risk level, location of the request, and
so on can be used. For more information about Conditional Access, see the overview and the deployment plan.
Azure SSO technical requirements

The following section details the requirements to configure your specific application including the necessary
environment(s), endpoints, claim mapping, required attributes, certificates, and protocols used. You'll need this
information to configure SSO in the Azure AD portal.
Authentication mechanism details
For all pre-integrated SaaS apps, Microsoft provides a tutorial and you won't need this information. If the
application isn't in our application marketplace / gallery, you may need to collect the following pieces of data:
Current identity provider the application uses for SSO if applicable - For example: AD FS, PingFederate,
Okta
Protocols supported by the target application - For example, SAML 2.0, OpenID Connect, OAuth, Forms-
Based Auth, WS -Fed, WS -Trust
Protocol being configured with Azure AD - For example, SAML 2.0 or 1.1, OpenID Connect, OAuth,
Forms-Based, WS -Fed
Attribute requirements
There's 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 such as groups. Plan the mapping of user attributes
from Azure AD to your application and customize the default attribute-mappings according to your business
needs.
Certificate requirements
The certificate for the application must be up-to-date, or there's a risk of users not being able to access the
application. Most SaaS application certificates are good for 36 months. You change that certificate duration in the
application blade. Make sure to document the expiration and know how you will manage your certificate renewal.
There are two ways to manage your certificates.
Automatic certificate rollover - Microsoft supports Signing key rollover in Azure AD. While this is our
preferred method for managing certificates, not all ISV’s supports this scenario.
Manually updating - Every application has its own certificate that expires based on how it's defined.
Before the application’s certificate expires, create a new certificate and send it to the ISV. This information
can be pulled from the federation metadata. Read more on federation metadata here.
Implement SSO
Use the following phases to plan for and deploy your solution in your organization:
User configuration for SSO
Identify your test users
Contact to the app owner and ask them to create a minimum of three test users within the application.
Ensure the information that you'll use as the primary identifier is populated correctly and matches an
attribute that is available in Azure AD. In most cases this will map to the “NameID” for SAML -based
applications. For JWT tokens, it's the “preferred_username.”
Create the user in Azure AD either manually as a cloud-based user or sync the user from on-premises using
the Azure AD Connect sync engine. Ensure the information matches the claims being sent to the application.
Configure SSO
From the list of applications, locate and open the SSO tutorial for your application, then follow the tutorial’s
steps on to successfully configure your SaaS application.
If you can’t locate your application, see Custom Application documentation. This will walk you through on
how to add an application that is not located in the Azure AD gallery.
Optionally, you can use claims issued in the SAML token for the enterprise application using Microsoft’s
guidance documentation. Ensure this maps to what you expect to receive in the SAML response for your
application. If you encounter issues during configuration, use our guidance on how to Debug SSO
integration.
Custom application onboarding is an Azure AD Premium P1 or P2 licenses feature.
Provide SSO change communications to end users
Implement your communication plan. Make sure you're letting your end users know that a change is coming, when
it has arrived, what to do now, and how to seek assistance.
Verify end user scenarios for SSO
You can use the following test cases to conduct tests on corporate-owned and personal devices to ensure your
SSO configurations are working as expected. The scenarios below assume that a user is navigating to an
application URL and going through an authentication flow initiated by the service provider (SP -initiated auth flow ).
SCENARIO EXPECTED RESULT ON SP-INITIATED AUTH FLOW BY USER
Login to application with IE while on corpnet. Integrated Windows Authentication (IWA) occurs with no
additional prompts.
Login to application with IE while off corpnet with new login Forms-based prompt at AD FS Server. User successfully logs in
attempt. and browser prompts for MFA.
Login to application with IE while off corpnet with a current User does not receive prompt for first factor. User receives
session and has never performed MFA. prompt for MFA.
Login to application with IE while off corpnet with a current User does not receive prompt for first factor. User does not
session and has already performed MFA in this session. receive MFA. User SSOs into application.
Login to application with Chrome/Firefox/Safari while off User does not receive prompt for first factor. User does not
corpnet with a current session and has already performed receive MFA. User SSO’s into application.
MFA in this session.
Login to into application with Chrome/Firefox/Safari while off Forms-based prompt at AD FS Server. User successfully logs in
corpnet with new login attempt. and browser prompts for MFA.
Login to application with Chrome/Firefox while on corporate User does not receive prompt for first factor. User does not
network with a current session. receive MFA. User SSO’s into application.
Login to application with application mobile app with a new Forms-based prompt at AD FS Server. User successfully logs in
login attempt. and ADAL client prompts for MFA.
Unauthorized user attempts to log into application with login Forms-based prompt at AD FS Server. User fails to login with
URL. first factor.
Authorized user attempts to log in but enters an incorrect User navigates to application URL and receives bad
password. username/password error.
Authorized user clicks on link in an email and is already User clicks on URL and is signed into the application with no
authenticated. additional prompts.
Authorized user clicks on link in an email and is not yet User clicks on URL and is prompt to authenticate with first
authenticated. factor.
Authorized User logs into application with application mobile Forms-based prompt at AD FS Server. User successfully logs in
app (SP-initiated) with a new login attempt. and ADAL client prompts for MFA.
Unauthorized User attempts to log into application with login Forms-based prompt at AD FS Server. User fails to login with
URL (SP-initiated). first factor.
Authorized user attempts to log in but enters an incorrect User navigates to application URL and receives bad
password. username/password error.
SCENARIO EXPECTED RESULT ON SP-INITIATED AUTH FLOW BY USER
Authorized user logs out and then logs in again. If Sign-out URL is configured, user is logged out of all services
and prompt to authenticate.
Authorized user logs out and then logs in again. If Sign-out URL is not configured, user will be automatically
logged back in using existing token from the existing Azure
AD browser session.
Authorized user clicks on link in an email and is already User clicks on URL and is signed into the application with no
authenticated. additional prompts.
Authorized user clicks on link in an email and is not yet User clicks on URL and is prompt to authenticate with first
authenticated. factor.
Manage SSO
This section outlines the requirements and recommendations to successfully manage SSO.
Required administrative roles
Always use the role with the fewest permissions available to accomplish the required task within Azure Active
Directory. Microsoft recommends review the different roles that are available and choose the right one to solve
your needs for each persona for this application. Some roles may need to be applied temporarily and removed
after the deployment has been completed.
PERSONA ROLES AZURE AD ROLE (IF REQUIRED)
Help desk admin Tier 1 support None
Identity admin Configure and debug when issues Global admin

impact Azure AD
Application admin User attestation in application, None

Infrastructure admins Cert rollover owner Global admin
Business owner/stakeholder User attestation in application, None

We recommend using Privileged Identity Management (PIM ) to manage your roles to provide additional auditing,
control, and access review for users with directory permissions.
SSO certificate lifecycle management
It’s important to identify the right roles and email distribution lists tasked with managing the lifecycle of the
signing certificate between Azure AD and the application that is being configured with single sign-on. Here are
some of the key roles we recommend having in place:
Owner for updating user properties in application
Owner On-Call for application break/fix support
Closely monitored email distribution list for certificate-related change notifications
The maximum lifetime of a certificate is three years. We recommend establishing a process on how you'll handle a
certificate change between Azure AD and your application. This can help prevent or minimize an outage due to a
certificate expiring or force certificate rollover.
Rollback process
After you complete testing based on your test cases, it’s time to move into production with your application.
Moving to production means you will implement your planned and tested configurations in your production
tenant and roll it out to your users. However, it's important to plan what to do in case your deployment doesn’t go
as planned. If the SSO configuration fails during the deployment, you must understand how to mitigate any
outage and reduce impact to your users.
The availability of authentication methods within the application will determine your best strategy. Always ensure
you have detailed documentation for app owners on exactly how to get back to the original login configuration
state in case your deployment runs into issues.
If your app supports multiple identity providers, for example LDAP and AD FS and Ping, do not delete
the existing SSO configuration during rollout. Instead, disable it during migration in case you need to switch
it back later.
If your app does not support multiple IDPs but allows users to log in using forms-based authentication
(username/password), ensure that users can fall back to this approach in case the new SSO configuration
rollout fails.
Access management
We recommend choosing a scaled approach when managing access to resources. Common approaches include
utilizing on-premises groups by syncing via Azure AD Connect, creating Dynamic Groups in Azure AD based on
user attributes, or creating self-service groups in Azure AD managed by a resource owner.
Monitor security
We recommend setting up a regular cadence in which you review the different aspects of SaaS app security and
perform any remedial actions that are required.
Troubleshooting
The following links present troubleshooting scenarios. You may want to create a specific guide for your support
staff that incorporates these scenarios and the steps to fix them.
Consent issues
Unexpected consent error
User consent error
Sign-in issues
Problems signing in from a custom portal
Problems signing in from access panel
Error on application sign-in page
Problem signing into a Microsoft application
SSO issues for applications listed in the Azure Application Gallery
Problem with password SSO for applications listed in the Azure Application Gallery
Problem with federated SSO for applications listed in the Azure Application Gallery
SSO issues for applications NOT listed in the Azure Application Gallery
Problem with password SSO for applications NOT listed in the Azure Application Gallery
Problem with federated SSO for applications NOT listed in the Azure Application Gallery
Next steps
Debug SAML -based SSO
Claim mapping for Apps via PowerShell
Customizing claims issued in SAML token
Single Sign-on SAML protocol
Single Sign-Out SAML protocol
Azure AD B2B (for external users such as partners and vendors)
Azure AD Conditional Access
Azure Identity Protection
SSO access
Application SSO Tutorial
One-click app configuration of single sign-on
In this tutorial, you learn how to perform one-click, single sign-on (SSO ) configuration for SAML -supporting,
Azure Active Directory (Azure AD ) applications from the Azure Marketplace.
Introduction to one-click SSO

The one-click SSO feature is designed to configure single sign-on for Azure Marketplace apps that support SAML
protocol. On the Azure AD SSO configuration page, this option allows you to automatically configure the Azure
AD metadata on the application side. In this way, you can quickly set up SSO with minimal manual effort.
Advantages of one-click SSO

Quick SSO configuration of Azure Marketplace applications that require manual setup on application side.
More efficient and accurate SSO configuration.
No partner communication or support needed for setup. The application provides the UI for SAML
configuration.
Prerequisites
An active subscription of the application to configure with SSO. You also need admin credentials.
The My Apps Secure Sign-in extension from Microsoft installed in the browser. For more information, see
Access and use apps on the My Apps portal.
One-click SSO configuration steps

1. Add the application from the Azure Marketplace.
2. Select Single sign-on.
3. Select Enable single sign-on.
4. Populate the mandatory configuration values in the Basic SAML Configuration section.
NOTE
If the application has custom claims that you need to configure, handle them before performing one-click SSO.
5. If the one-click SSO feature is available for your Azure Marketplace application, you see following screen.
You might have to install the My Apps Secure Sign-in browser extension by selecting Install the
extension.
6. After you add the extension to the browser, select Setup <Application Name>. After you're redirected to
the application admin portal, sign in as an administrator.
7. The browser extension automatically configures SSO on the application. Confirm by selecting Yes.
NOTE
If SSO configuration for your application requires additional steps, following the prompts to perform the steps.
8. After the configuration has finished, select OK to save the changes.
9. A confirmation window displays to let you know that the SSO settings are successfully configured.
10. After the configuration is successful, you're signed out of the application and returned to the Azure portal.
11. You can select Test to test single sign-on.
Additional resources
List of tutorials on how to integrate SaaS apps with Azure Active Directory
What is the My Apps Secure Sign-in browser extension?
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. Over 500 of the applications support single sign-on by using the Security Assertion
Markup Language (SAML ) 2.0 protocol, such as the NetSuite application. When a customer authenticates to an
application through Azure AD by using SAML, Azure AD sends a token to the application (via an HTTP POST).
The application then validates and uses the token to sign in the customer 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.
In Azure AD, 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 you select this
option, Azure AD as an Identity Provider (IdP ) signs the SAML assertion and certificate with the X.509
certificate of the application.
Sign SAML response. If you select this option, Azure AD as an IdP signs the SAML response with the
X.509 certificate of the application.
Sign SAML response and assertion. If you select this option, Azure AD as an IdP signs the entire SAML
token with the X.509 certificate of the application.
Certificate signing algorithms

Azure AD supports two signing algorithms, or secure hash algorithms (SHAs), 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
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 algorithm is older, and it's treated as less secure than SHA-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.
Change certificate signing options and signing algorithm

To change an application's SAML certificate signing options and the certificate signing algorithm, select the
application in question:
1. In the Azure Active Directory portal, sign in to your account. The Azure Active Directory admin center
page appears.
2. In the left pane, select Enterprise applications. A list of the enterprise applications in your account
appears.
3. Select an application. An overview page for the application appears.
Next, change the certificate signing options in the SAML token for that application:
1. In the left pane of the application overview page, select Single sign-on.
2. If the Set up Single Sign-On with SAML - Preview page appears, go to step 5.
3. If the Select a single sign-on method page doesn't appear, select Change single sign-on modes to
display that page.
4. In the Select a single sign-on method page, select SAML if available. (If SAML isn't available, the
application doesn't support SAML, and you may ignore the rest of this procedure and article.)
5. In the Set up Single Sign-On with SAML - Preview page, find the SAML Signing Certificate heading
and select the Edit icon (a pencil). The SAML Signing Certificate page appears.
6. In the Signing Option drop-down list, choose Sign SAML response, Sign SAML assertion, or Sign
SAML response and assertion. Descriptions of these options appear earlier in this article in the Certificate
signing options.
7. In the Signing Algorithm drop-down list, choose SHA -1 or SHA -256. Descriptions of these options
appear earlier in this article in the Certificate signing algorithms section.
8. If you're satisfied with your choices, select Save to apply the new SAML signing certificate settings.
Otherwise, select the X to discard the changes.
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
Azure Active Directory
In this article, we cover common questions and information related to certificates that Azure Active Directory
(Azure AD ) creates to establish federated single sign-on (SSO ) to your software as a service (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 Security Assertion Markup
Language (SAML ) federation.
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 (by selecting Single
sign-on > SAML from the application overview page), Azure AD generates a certificate for the application that is
valid for three years. To download the active certificate as a security certificate (.cer) file, return to that page
(SAML -based sign-on) and select a download link in the SAML Signing Certificate heading. You can choose
between the raw (binary) certificate or the Base64 (base 64-encoded text) certificate. For gallery applications, this
section might also show a link to download the certificate as federation metadata XML (an .xml file), depending
on the requirement of the application.
You can also download an active or inactive certificate by selecting the SAML Signing Certificate heading's Edit
icon (a pencil), which displays the SAML Signing Certificate page. Select the ellipsis (...) next to the certificate
you want to download, and then choose which certificate format you want. You have the additional option to
download the certificate in privacy-enhanced mail (PEM ) format. This format is identical to Base64 but with a
.pem file name extension, which isn't recognized in Windows as a certificate format.
Customize the expiration date for your federation certificate and roll it
over to a new certificate
By default, Azure configures a certificate to expire after three years when it is created automatically during SAML
single sign-on configuration. Because you can't change the date of a certificate after you save it, you have to:
1. Create a new certificate with the desired date.
2. Save the new certificate.
3. Download the new certificate in the correct format.
4. Upload the new certificate to the application.
5. Make the new certificate active in the Azure Active Directory portal.
The following two sections help you perform these steps.
Create a new certificate
First, create and save new certificate with a different expiration date:
1. Sign in to the Azure Active Directory portal. The Azure Active Directory admin center page appears.
2. In the left pane, select Enterprise applications. A list of the enterprise applications in your account appears.
3. Select the affected application. An overview page for the application appears.
4. In the left pane of the application overview page, select Single sign-on.
5. If the Select a single sign-on method page appears, select SAML.
6. In the Set up Single Sign-On with SAML - Preview page, find the SAML Signing Certificate heading and
select the Edit icon (a pencil). The SAML Signing Certificate page appears, which displays the status (Active
or Inactive), expiration date, and thumbprint (a hash string) of each certificate.
7. Select New Certificate. A new row appears below the certificate list, where the expiration date defaults to
exactly three years after the current date. (Your changes haven't been saved yet, so you can still modify the
expiration date.)
8. In the new certificate row, hover over the expiration date column and select the Select Date icon (a calendar).
A calendar control appears, displaying the days of a month of the new row's current expiration date.
9. Use the calendar control to set a new date. You can set any date between the current date and three years after
the current date.
10. Select Save. The new certificate now appears with a status of Inactive, the expiration date that you chose, and
a thumbprint.
11. Select the X to return to the Set up Single Sign-On with SAML - Preview page.
Upload and activate a certificate
Next, download the new certificate in the correct format, upload it to the application, and make it active in Azure
Active Directory:
1. View the application's additional SAML sign-on configuration instructions by either:
Selecting the configuration guide link to view in a separate browser window or tab, or
Going to the set up heading and selecting View step-by-step instructions to view in a sidebar.
2. In the instructions, note the encoding format required for the certificate upload.
3. Follow the instructions in the Auto-generated certificate for gallery and non-gallery applications section
earlier. This step downloads the certificate in the encoding format required for upload by the application.
4. When you want to roll over to the new certificate, go back to the SAML Signing Certificate page, and in
the newly saved certificate row, select the ellipsis (...) and select Make certificate active. The status of the
new certificate changes to Active, and the previously active certificate changes to a status of Inactive.
5. Continue following the application's SAML sign-on configuration instructions that you displayed earlier, so
that you can upload the SAML signing certificate in the correct encoding format.
Add email notification addresses for certificate expiration

Azure AD will send an email notification 60, 30, and 7 days before the SAML certificate expires. You may add
more than one email address to receive notifications. To specify the email address(es) you want the notifications to
be sent to:
1. In the SAML Signing Certificate page, go to the notification email addresses heading. By default, this
heading uses only the email address of the admin who added the application.
2. Below the final email address, type the email address that should receive the certificate's expiration notice, and
then press Enter.
3. Repeat the previous step for each email address you want to add.
4. For each email address you want to delete, select the Delete icon (a garbage can) next to the email address.
5. Select Save.
You will receive the notification email from [email protected]. To avoid the email going to your spam
location, add this email to your contacts.
Renew a certificate that will soon expire

If a certificate is about to expire, you can renew it using a procedure that results in no significant downtime for
your users. To renew an expiring certificate:
1. Follow the instructions in the Create a new certificate section earlier, using a date that overlaps with the
existing certificate. That date limits the amount of downtime caused by the certificate expiration.
2. If the application can automatically roll over a certificate, set the new certificate to active by following these
steps:
a. Go back to the SAML Signing Certificate page.
b. In the newly saved certificate row, select the ellipsis (...) and then select Make certificate active.
c. Skip the next two steps.
3. If the app can only handle one certificate at a time, pick a downtime interval to perform the next step.
(Otherwise, if the application doesn’t automatically pick up the new certificate but can handle more than
one signing certificate, you can perform the next step anytime.)
4. Before the old certificate expires, follow the instructions in the Upload and activate a certificate section
earlier.
5. Sign in to the application to make sure that the certificate works correctly.
Related articles
Tutorials for integrating SaaS applications with Azure Active Directory
Application management with Azure Active Directory
Single sign-on to applications in Azure Active Directory
Debug SAML -based single sign-on to applications in Azure Active Directory
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 software as a service (or 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.
The Azure Active Directory (Azure AD ) solution to this challenge is a feature called tenant restrictions. With tenant
restrictions, organizations can 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.
With tenant restrictions, organizations can 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: This infrastructure is a proxy device capable of Secure Sockets
Layer (SSL ) inspection. You must configure the proxy 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 the proxy infrastructure can intercept traffic. Browser-based Office 365 applications currently
support tenant restrictions, as do Office clients that use modern authentication (like OAuth 2.0).
4. Modern Authentication: Cloud services must use modern authentication to use tenant restrictions and
block access to all non-permitted tenants. You must configure Office 365 cloud services 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. Tenant restrictions requires SSL inspection only 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. First, make sure that your clients can connect to the right
addresses. Second, 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 fully qualified domain names (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 public key infrastructure (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, use 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, use 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 Active Directory 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 shouldn't be able
to edit or disable the PAC files.
The user experience

This section describes 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 an
access denial message, which says you're trying to access a resource that belongs to an organization unapproved
by your IT department.
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:
1. Sign in to the Azure Active Directory portal. The Azure Active Directory admin center dashboard
appears.
2. In the left pane, select Azure Active Directory. The Azure Active Directory overview page appears.
3. In the Other capabilities heading, select Tenant restrictions.
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 time interval, user, application, client, or status. If you select the Columns button, you can choose to display
data with any combination of the following fields:
User
Application
Status
Date
Date (UTC ) (where UTC is Coordinated Universal Time)
MFA Auth Method (multifactor authentication method)
MFA Auth Detail (multifactor authentication detail)
MFA Result
IP Address
Client
Username
Location
Target tenant ID
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. SharePoint Online already enables Modern
authentication by default.
Office 365 browser-based applications (the Office Portal, Yammer, SharePoint sites, Outlook on the Web, and
more) currently support tenant restrictions. Thick clients (Outlook, Skype for Business, Word, Excel, PowerPoint,
and more) can enforce tenant restrictions only when using modern authentication.
Outlook and Skype for Business clients that support modern authentication may still able to use legacy protocols
against tenants where modern authentication isn't enabled, effectively bypassing tenant restrictions. Tenant
restrictions may block applications that use legacy protocols 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, you have 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.
For specific details, refer to your proxy server documentation.
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
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 User
access URLs can be found under the properties of available enterprise applications. In the Azure portal, select
Azure Active Directory > Enterprise applications. Select the application, and then select Properties.
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
Using System for Cross-Domain Identity
Management (SCIM) to automatically provision users
and groups from Azure Active Directory to
applications
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 article 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 How to: List your
application in the Azure AD application gallery.
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're 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 - Common Language Infrastructure (CLI)
libraries along with code samples show you how to develop 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
constantly keep users in sync between Azure AD and the target application, and implements a very specific set of standard
operations. It's important to understand these behaviors 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:
1. Sign in to the Azure Active Directory portal.
2. Select Enterprise applications from the left pane. A list of all configured apps is shown, including apps
that were added from the gallery.
3. Select + New application > All > Non-gallery application.
4. Enter a name for your application, and select Add to create an app object. The new app is added to the list
of enterprise applications and opens to its app management screen.
Figure 2: Azure AD application gallery
5. In the app management screen, select Provisioning in the left panel.
6. In the Provisioning Mode menu, select Automatic.
Figure 3: Configuring provisioning in the Azure portal

7. In the Tenant URL field, enter the URL of the application's SCIM endpoint. Example:
https://api.contoso.com/scim/
8. 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, 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.
9. Select Test Connection to have Azure Active Directory attempt to connect to the SCIM endpoint. If the
attempt fails, 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.
10. If the attempts to connect to the application succeed, then select Save to save the admin credentials.
11. 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 Save to commit any changes.
NOTE
You can optionally disable syncing of group objects by disabling the "groups" mapping.
12. Under Settings, the Scope field defines which users and groups are synchronized. Select Sync only
assigned users and groups (recommended) to only sync users and groups assigned in the Users and
groups tab.
13. Once your configuration is complete, set the Provisioning Status to On.
14. Select Save to start the Azure AD provisioning service.
15. If syncing only assigned users and groups (recommended), be sure to select the Users and groups tab and
assign the users or groups you want to sync.
Once the initial synchronization has started, you can select Audit logs in the left panel to monitor progress, which
shows all actions done 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 later syncs, which occur approximately every 40 minutes as long as the service
is running.
Understanding the Azure AD SCIM implementation

If you're 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've 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 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 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.
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 isn't necessary to include the entire resource in the PATCH response.
Microsoft Azure AD only uses the following operators:
eq
and
Don't 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's 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 about users in two ways:
Requests to retrieve groups specify 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 and 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": "[email protected]"
}],
"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": "[email protected]",
"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": [{
"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": [{
"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",
},
{
"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": [{
"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",
}]
}
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": "[email protected]",
"name": {
},
"active": true,
"emails": [{
"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 isn't advisable.
It isn't 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",
"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 that can connect 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're 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, which 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 <ip-address> 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 run 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 access this endpoint in the cloud.
To register the sample SCIM endpoint in Azure AD
3. Select + New application > All > Non-gallery application.
4. Enter a name for your application, and select Add 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.
5. In the app management screen, select Provisioning in the left panel.
6. In the Provisioning Mode menu, select Automatic.
7. In the Tenant URL field, enter the URL of the application's SCIM endpoint. Example:
https://api.contoso.com/scim/
8. 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, 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.
9. Select Test Connection to have Azure Active Directory attempt to connect to the SCIM endpoint. If the
attempt fails, 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
10. If the attempts to connect to the application succeed, then select Save to save the admin credentials.
11. 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 Save to commit any changes.
12. Under Settings, the Scope field defines which users and or groups are synchronized. Select "Sync only
assigned users and groups (recommended) to only sync users and groups assigned in the Users and
groups tab.
13. Once your configuration is complete, set the Provisioning Status to On.
14. Select Save to start the Azure AD provisioning service.
15. If syncing only assigned users and groups (recommended), be sure to select the Users and groups tab and
assign the users or groups you want to sync.
Once the initial synchronization has started, you can select Audit logs in the left panel to monitor progress, which
shows all actions done 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:
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 let the developer 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.
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
Developers using the CLI 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 for 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 for
which the token was issued. The audience for the token will be the application template id for the app in the
gallery. The application template id for all custom apps is 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. The
application template id for each app in the gallery varies. Please contact [email protected] for
questions on the application template id for a gallery application. Each of the applications 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 for 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 = "8adf8e6e-67b2-4cf2-a259-e3dc5476c621"
};
// 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
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. Also, 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.
System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource[]> Query(
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 doesn't 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":"[email protected]",
"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 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.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 can be 0 and the value of the index y can be 1, or the value of x can be 1 and
the value of y can 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.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 can be 0 and the value of the index y can be 1, or the value of x can be 1 and
the value of y can 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
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.
Group resources are identified by the schema identifier, urn:ietf:params:scim:schemas:core:2.0:Group . Table 2
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
AZURE ACTIVE DIRECTORY GROUP URN:IETF:PARAMS:SCIM:SCHEMAS:CORE:2.0:GROUP
mail emails[type eq "work"].value
mailNickname displayName
members members
objectId ID
proxyAddresses emails[type eq "other"].Value
Allow IP addresses used by the Azure AD provisioning service to make

SCIM requests
Certain apps allow inbound traffic to their app. In order for the Azure AD provisioning service to function as
expected, the IP addresses used must be allowed. For a list of IP addresses for each service tag/region, see the
JSON file - Azure IP Ranges and Service Tags – Public Cloud. You can download and program these IPs into your
firewall as needed. The reserved IP ranges for Azure AD provisioning can be found under
"AzureActiveDirectoryDomainServices."
Related articles
Automate User Provisioning/Deprovisioning to SaaS Apps
Customizing Attribute Mappings for User Provisioning
Writing Expressions for Attribute Mappings
Scoping Filters for User Provisioning
Account Provisioning Notifications
List of Tutorials on How to Integrate SaaS Apps
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.
Application Proxy is recommended for giving remote users access to internal resources. Application Proxy
replaces the need for a VPN or reverse proxy. It is not intended for internal users on the corporate network.
These users who unnecessarily use Application Proxy can introduce unexpected and undesirable performance
issues.
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.
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-
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.
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
Plan an Azure AD Application Proxy deployment
Azure Active Directory (Azure AD ) Application Proxy is a secure and cost-effective remote access solution for on-
premises applications. It provides an immediate transition path for “Cloud First” organizations to manage access
to legacy on-premises applications that aren’t yet capable of using modern protocols. For additional introductory
information, see What is Application Proxy.
Application Proxy is recommended for giving remote users access to internal resources. Application Proxy
replaces the need for a VPN or reverse proxy for these remote access use cases. It is not intended for users who
are on the corporate network. These users who use Application Proxy for intranet access may experience
undesirable performance issues.
This article includes the resources you need to plan, operate, and manage Azure AD Application Proxy.
Plan your implementation

The following section provides a broad view of the key planning elements that will set you up for an efficient
deployment experience.
Prerequisites
You need to meet the following prerequisites before beginning your implementation. You can see more
information on setting up your environment, including these prerequisites, in this tutorial.
Connectors: Connectors are lightweight agents that you can deploy onto:
Physical hardware on-premises
A VM hosted within any hypervisor solution
A VM hosted in Azure to enable outbound connection to the Application Proxy service.
See Understand Azure AD App Proxy Connectors for a more detailed overview.
Connector machines must be enabled for TLS 1.2 before installing the connectors.
If possible, deploy connectors in the same network and segment as the back-end web application
servers. It's best to deploy connectors after you complete a discovery of applications.
We recommend that each connector group has at least two connectors to provide high availability
and scale. Having three connectors is optimal in case you may need to service a machine at any
point. Review the connector capacity table to help with deciding what type of machine to install
connectors on. The larger the machine the more buffer and performant the connector will be.
Network access settings: Azure AD Application Proxy connectors connect to Azure via HTTPS (TCP Port
443) and HTTP (TCP Port 80).
Terminating connector TLS traffic isn't supported and will prevent connectors from establishing a
secure channel with their respective Azure App Proxy endpoints.
Avoid all forms of inline inspection on outbound TLS communications between connectors and
Azure. Internal inspection between a connector and backend applications is possible, but could
degrade the user experience, and as such, isn't recommended.
Load balancing of the connectors themselves is also not supported, or even necessary.
Important considerations before configuring Azure AD Application Proxy
The following core requirements must be met in order to configure and implement Azure AD Application Proxy.
Azure onboarding: Before deploying application proxy, user identities must be synchronized from an on-
premises directory or created directly within your Azure AD tenants. Identity synchronization allows Azure
AD to pre-authenticate users before granting them access to App Proxy published applications and to have
the necessary user identifier information to perform single sign-on (SSO ).
Conditional Access requirements: We do not recommend using Application Proxy for intranet access
because this adds latency that will impact users. We recommend using Application Proxy with pre-
authentication and Conditional Access policies for remote access from the internet. An approach to provide
Conditional Access for intranet use is to modernize applications so they can diretly authenticate with AAD.
Refer to Resources for migrating applications to AAD for more information.
Service limits: To protect against overconsumption of resources by individual tenants there are throttling
limits set per application and tenant. To see these limits refer to Azure AD service limits and restrictions.
These throttling limits are based on a benchmark far above typical usage volume and provides ample buffer
for a majority of deployments.
Public certificate: If you are using custom domain names, you must procure a public certificate issued by
a non-Microsoft trusted certificate authority. Depending on your organizational requirements, getting a
certificate can take some time and we recommend beginning the process as early as possible. Azure
Application Proxy supports standard, wildcard, or SAN -based certificates.
Domain requirements: Single sign-on to your published applications using Kerberos Constrained
Delegation (KCD ) requires that the server running the Connector and the server running the app are
domain joined and part of the same domain or trusting domains. For detailed information on the topic, see
KCD for single sign-on with Application Proxy. The connector service runs in the context of the local system
and should not be configured to use a custom identity.
DNS records for URLs
Before using custom domains in Application Proxy you must create a CNAME record in public DNS,
allowing clients to resolve the custom defined external URL to the pre-defined Application Proxy
address. Failing to create a CNAME record for an application that uses a custom domain will prevent
remote users from connecting to the application. Steps required to add CNAME records can vary
from DNS provider to provider, so learn how to manage DNS records and record sets by using the
Azure portal.
Similarly, connector hosts must be able to resolve the internal URL of applications being published.
Administrative rights and roles
Connector installation requires local admin rights to the Windows server that it's being installed
on. It also requires a minimum of an Application Administrator role to authenticate and register the
connector instance to your Azure AD tenant.
Application publishing and administration require the Application Administrator role.
Application Administrators can manage all applications in the directory including registrations, SSO
settings, user and group assignments and licensing, Application Proxy settings, and consent. It
doesn't grant the ability to manage Conditional Access. The Cloud Application Administrator role
has all the abilities of the Application Administrator, except that it does not allow management of
Application Proxy settings.
Licensing: Application Proxy is available through an Azure AD Premium subscription. Refer to the Azure
Active Directory Pricing page for a full list of licensing options and features.
Application Discovery
Compile an inventory of all in-scope applications that are being published via Application Proxy by collecting the
following information:
INFORMATION TYPE INFORMATION TO COLLECT
Service Type For example: SharePoint, SAP, CRM, Custom Web Application,
API
Application platform For example: Windows IIS, Apache on Linux, Tomcat, NGINX
Domain membership Web server’s fully qualified domain name (FQDN)
Application location Where the web server or farm is located in your infrastructure
Internal access The exact URL used when accessing the application internally.
If a farm, what type of load balancing is in use?
Whether the application draws content from sources other
than itself.
Determine if the application operates over WebSockets.
External access The vendor solution that the application is already exposed to
externally.
The URL you want to use for external access. If SharePoint,
ensure Alternate Access Mappings are configured per this
guidance. If not, you will need to define external URLs.
Public certificate If using a custom domain, procure a certificate with a

corresponding subject name. if a certificate exists note the
serial number and location from where it can be obtained.
Authentication type The type of authentication supported by the application

support such as Basic, Windows Integration Authentication,
forms-based, header-based, and claims.
If the application is configured to run under a specific domain
account, note the Fully Qualified Domain Name (FQDN) of the
service account.
If SAML-based, the identifier and reply URLs.
If header-based, the vendor solution and specific requirement
for handling authentication type.
Connector group name The logical name for the group of connectors that will be
designated to provide the conduit and SSO to this backend
application.
Users/Groups access The users or user groups that will be granted external access
to the application.
Additional requirements Note any additional remote access or security requirements

that should be factored into publishing the application.
You can download this application inventory spreadsheet to inventory your apps.
Define organizational requirements
The following are areas for which you should define your organization’s business requirements. Each area
contains examples of requirements
Access
Remote users with domain joined or Azure AD joined devices users can access published applications
securely with seamless single sign-on (SSO ).
Remote users with approved personal devices can securely access published applications provided they are
enrolled in MFA and have registered the Microsoft Authenticator app on their mobile phone as an
authentication method.
Governance
Administrators can define and monitor the lifecycle of user assignments to applications published through
Application Proxy.
Security
Only users assigned to applications via group membership or individually can access those applications.
Performance
There is no degradation of application performance compared to accessing application from the internal
network.
User Experience
Users are aware of how to access their applications by using familiar company URLs on any device platform.
Auditing
Administrators are able to audit user access activity.
Best practices for a pilot
Determine the amount of time and effort needed to fully commission a single application for remote access with
Single sign-on (SSO ). Do so by running a pilot that considers its initial discovery, publishing, and general testing.
Using a simple IIS -based web application that is already preconfigured for Integrated Windows Authentication
(IWA) would help establish a baseline, as this setup requires minimal effort to successfully pilot remote access and
SSO.
The following design elements should increase the success of your pilot implementation directly in a production
tenant.
Connector management:
Connectors play a key role in providing the on-premises conduit to your applications. Using the Default
connector group is adequate for initial pilot testing of published applications before commissioning them into
production. Successfully tested applications can then be moved to production connector groups.
Application management:
Your workforce is most likely to remember an external URL is familiar and relevant. Avoid publishing your
application using our pre-defined msappproxy.net or onmicrosoft.com suffixes. Instead, provide a familiar
top-level verified domain, prefixed with a logical hostname such as intranet.<customers_domain>.com.
Restrict visibility of the pilot application’s icon to a pilot group by hiding its launch icon form the Azure
MyApps portal. When ready for production you can scope the app to its respective targeted audience,
either in the same pre-production tenant, or by also publishing the application in your production tenant.
Single sign-on settings: Some SSO settings have specific dependencies that can take time to set up, so avoid
change control delays by ensuring dependencies are addressed ahead of time. This includes domain joining
connector hosts to perform SSO using Kerberos Constrained Delegation (KCD ) and taking care of other time-
consuming activities. For example, Setting up a PING Access instance, if needing header-based SSO.
SSL Between Connector Host and Target Application: Security is paramount, so TLS between the connector
host and target applications should always be used. Particularly if the web application is configured for forms-
based authentication (FBA), as user credentials are then effectively transmitted in clear text.
Implement incrementally and test each step. Conduct basic functional testing after publishing an application
to ensure that all user and business requirements are met by following the directions below:
1. Test and validate general access to the web application with pre-authentication disabled.
2. If successful enable pre-authentication and assign users and groups. Test and validate access.
3. Then add the SSO method for your application and test again to validate access.
4. Apply Conditional Access and MFA policies as required. Test and validate access.
Troubleshooting Tools: When troubleshooting, always start by validating access to the published application
from the browser on the connector host, and confirm that the application functions as expected. The simpler your
setup, the easier to determine root cause, so consider trying to reproduce issues with a minimal configuration such
as using only a single connector and no SSO. In some cases, web debugging tools such as Telerik’s Fiddler can
prove indispensable to troubleshoot access or content issues in applications accessed through a proxy. Fiddler can
also act as a proxy to help trace and debug traffic for mobile platforms such as iOS and Android, and virtually
anything that can be configured to route via a proxy. See the troubleshooting guide for more information.
Implement Your Solution

Deploy Application Proxy
The steps to deploy your Application Proxy are covered in this tutorial for adding an on-premises application for
remote access. If the installation isn't successful, select Troubleshoot Application Proxy in the portal or use the
troubleshooting guide for Problems with installing the Application Proxy Agent Connector.
Publish applications via Application Proxy
Publishing applications assumes that you have satisfied all the pre-requisites and that you have several connectors
showing as registered and active in the Application Proxy page.
You can also publish applications by using PowerShell.
Below are some best practices to follow when publishing an application:
Use Connector Groups: Assign a connector group that has been designated for publishing each respective
application. We recommend that each connector group has at least two connectors to provide high
availability and scale. Having three connectors is optimal in case you may need to service a machine at any
point. Additionally, see Publish applications on separate networks and locations using connector groups to
see how you can also use connector groups to segment your connectors by network or location.
Set Backend Application Timeout: This setting is useful in scenarios where the application might require
more than 75 seconds to process a client transaction. For example when a client sends a query to a web
application that acts as a front end to a database. The front end sends this query to its back-end database
server and waits for a response, but by the time it receives a response, the client side of the conversation
times out. Setting the timeout to Long provides 180 seconds for longer transactions to complete.
Use Appropriate Cookie Types
HTTP -Only Cookie: Provides additional security by having Application Proxy include the
HTTPOnly flag in set-cookie HTTP response headers. This setting helps to mitigate exploits such as
cross-site scripting (XSS ). Leave this set to No for clients/user agents that do require access to the
session cookie. For example, RDP/MTSC client connecting to a Remote Desktop Gateway published
via App Proxy.
Secure Cookie: When a cookie is set with the Secure attribute, the user agent (Client-side app) will
only include the cookie in HTTP requests if the request is transmitted over a TLS secured channel.
This helps mitigate the risk of a cookie being compromised over clear text channels, so should be
enabled.
Persistent Cookie: Allows the Application Proxy session cookie to persist between browser closures
by remaining valid until it either expires or is deleted. Used for scenarios where a rich application
such as office accesses a document within a published web application, without the user being re-
prompted for authentication. Enable with caution however, as persistent cookies can ultimately leave
a service at risk of unauthorized access, if not used in conjunction with other compensating controls.
This setting should only be used for older applications that can't share cookies between processes.
It's better to update your application to handle sharing cookies between processes instead of using
this setting.
Translate URLs in Headers: You enable this for scenarios where internal DNS cannot be configured to
match the organization’s public namespace(a.k.a Split DNS ). Unless your application requires the original
host header in the client request, leave this value set to Yes. The alternative is to have the connector use the
FQDN in the internal URL for routing of the actual traffic, and the FQDN in the external URL, as the host-
header. In most cases this alternative should allow the application to function as normal, when accessed
remotely, but your users lose the benefits of having a matching inside & outside URL.
Translate URLs in Application Body: Turn on Application Body link translation for an app when you
want the links from that app to be translated in responses back to the client. If enabled, this function
provides a best effort attempt at translating all internal links that App Proxy finds in HTML and CSS
responses being returned to clients. It is useful when publishing apps that contain either hard-coded
absolute or NetBIOS shortname links in the content, or apps with content that links to other on-premises
applications.
For scenarios where a published app links to other published apps, enable link translation for each application so
that you have control over the user experience at the per-app level.
For example, suppose that you have three applications published through Application Proxy that all link to each
other: Benefits, Expenses, and Travel, plus 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, so that users accessing the applications from outside the corporate network can
access them. Links from Expenses and Travel back to Benefits don't work because link translation hasn't been
enabled for those two apps. The link to Feedback isn't redirected because there's no external URL, so users using
the Benefits app won't be able to access the feedback app from outside the corporate network. See detailed
information on link translation and other redirect options.
Access your application
Several options exist for managing access to App Proxy published resources, so choose the most appropriate for
your given scenario and scalability needs. Common approaches include: using on-premises groups that are being
synced via Azure AD Connect, creating Dynamic Groups in Azure AD based on user attributes, using self-service
groups that are managed by a resource owner, or a combination of all of these. See the linked resources for the
benefits of each.
The most straight forward way of assigning users access to an application is going into the Users and Groups
options from the left-hand pane of your published application and directly assigning groups or individuals.
You can also allow users to self-service access to your application by assigning a group that they aren't currently a
member of and configuring the self-serve options.
If enabled, users will then be able to log into the MyApps portal and request access, and either be auto approved
and added to the already permitted self-service group, or need approval from a designated approver.
Guest users can also be invited to access internal applications published via Application Proxy through Azure AD
B2B.
For on premises applications that are normally accessible anonymously, requiring no authentication, you may
prefer to disable the option located in the application’s Properties.
Leaving this option set to No allows users to access the on-premises application via Azure AD App Proxy without
permissions, so use with caution.
Once your application is published, it should be accessible by typing its external URL in a browser or by its icon at
https://myapps.microsoft.com.
Enable pre -authentication
Verify that your application is accessible through Application Proxy accessing it via the external URL.
1. Navigate to Azure Active Directory > Enterprise applications > All applications and choose the app
you want to manage.
2. Select Application Proxy.
3. In the Pre-Authentication field, use the dropdown list to select Azure Active Directory, and select Save.
With pre-authentication enabled, Azure AD will challenge users first for authentication and if single sign-on is
configued then the back-end application will also verify the user before access to the application is granted.
Changing the pre-authentication mode from Passthrough to Azure AD also configures the external URL with
HTTPS, so any application initially configured for HTTP will now be secured with HTTPS.
Enable Single Sign-On
SSO provides the best possible user experience and security because users only need to sign in once when
accessing Azure AD. Once a user has pre-authenticated, SSO is performed by the Application Proxy connector
authenticating to the on-premises application, on behalf of the user. The backend application processes the login
as if it were the user themselves.
Choosing the Passthrough option allows users to access the published application without ever having to
authenticate to Azure AD.
Performing SSO is only possible if Azure AD can identify the user requesting access to a resource, so your
application must be configured to pre-authenticate users with Azure AD upon access for SSO to function,
otherwise the SSO options will be disabled.
Read Single sign-on to applications in Azure AD to help you choose the most appropriate SSO method when
configuring your applications.
Working with other types of applications
Azure AD Application Proxy can also support applications that have been developed to use our Azure AD
Authentication Library (ADAL ) or Microsoft Authentication Library (MSAL ). It supports native client apps by
consuming Azure AD issued tokens received in the header information of client request to perform pre-
authentication on behalf of the users.
Read publishing native and mobile client apps and claims-based applications to learn about available
configurations of Application Proxy.
Use Conditional Access to strengthen security
Application security requires an advanced set of security capabilities that can protect from and respond to complex
threats on-premises and in the cloud. Attackers most often gain corporate network access through weak, default,
or stolen user credentials. Microsoft identity-driven security reduces use of stolen credentials by managing and
protecting both privileged and non-privileged identities.
The following capabilities can be used to support Azure AD Application Proxy:
User and location-based Conditional Access: Keep sensitive data protected by limiting user access based on
geo-location or an IP address with location-based Conditional Access policies.
Device-based Conditional Access: Ensure only enrolled, approved, and compliant devices can access
corporate data with device-based Conditional Access.
Application-based Conditional Access: Work doesn't have to stop when a user isn't on the corporate
network. Secure access to corporate cloud and on-premises apps and maintain control with Conditional
Access.
Risk-based Conditional Access: Protect your data from malicious hackers with a risk-based Conditional
Access policy that can be applied to all apps and all users, whether on-premises or in the cloud.
Azure AD Access Panel: With your Application Proxy service deployed, and applications securely published,
offer your users a simple hub to discover and access all their applications. Increase productivity with self-
service capabilities, such as the ability to request access to new apps and groups or manage access to these
resources on behalf of others, through the Access Panel.
Manage your implementation

Required roles
Microsoft advocates the principle of granting the least possible privilege to perform needed tasks with Azure AD.
Review the different Azure roles that are available and choose the right one to address the needs of each persona.
Some roles may need to be applied temporarily and removed after the deployment is completed.
BUSINESS ROLE BUSINESS TASKS AZURE AD ROLES
Help desk admin Typically limited to qualifying end user Helpdesk Administrator
reported issues and performing limited
tasks such as changing users’
passwords, invalidating refresh tokens,
and monitoring service health.
Identity admin Read Azure AD sign in reports and Security reader

audit logs to debug App Proxy related
issues.
Application owner Create and manage all aspects of Application Admin

enterprise applications, application
registrations, and application proxy
settings.
Infrastructure admin Certificate Rollover Owner Application Admin
Minimizing the number of people who have access to secure information or resources will help in reducing the
chance of a malicious actor obtaining unauthorized access, or an authorized user inadvertently impacting a
sensitive resource.
However, users still need to carry out day to day privileged operations, so enforcing just-in-time (JIT) based
Privileged Identity Management policies to provide on-demand privileged access to Azure resources and Azure
AD is our recommended approach towards effectively managing administrative access and auditing.
Reporting and monitoring
Azure AD provides additional insights into your organization’s application usage and operational health through
audit logs and reports. Application Proxy also makes it very easy to monitor connectors from the Azure AD portal
and Windows Event Logs.
Application audit logs
These logs provide detailed information about logins to applications configured with Application Proxy and the
device and the user accessing the application. Audit logs are located in the Azure portal and in Audit API for
export. Additionally, usage and insights reports are also available for your application.
Application Proxy Connector monitoring
The connectors and the service take care of all the high availability tasks. You can monitor the status of your
connectors from the Application Proxy page in the Azure AD Portal. For more information about connector
maintainence see Understand Azure AD Application Proxy Connectors.
Windows event logs and performance counters

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. Logs and counters are located in Windows Event
Logs for more information see Understand Azure AD Application Proxy Connectors. Follow this tutorial to
configure event log data sources in Azure Monitor.
Troubleshooting guide and steps
Learn more about common issues and how to resolve them with our guide to troubleshooting error messages.
The following articles cover common scenarios that can also be used to create troubleshooting guides for your
support organization.
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
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 machine running Windows Server 2012 R2 or later. 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. To
enable TLS 1.2 on the server:
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.
To see information about previously released versions and what changes they include, see Application Proxy-
Version Release History.
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. We recommend that each connector group has at least two connectors to provide high
availability and scale. Having three connectors is optimal in case you may need to service a machine at any
point.
In general, the more users you have, the larger a machine you'll need. Below is a table giving an outline of the
volume and expected latency 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 also recommend having
additional machines so that the distributed load across the machines always provides ample buffer. 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 perimeter network, also known as 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/region 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/region. 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
High availability and load balancing of your
Application Proxy connectors and applications
This article explains how traffic distribution works with your Application Proxy deployment. We'll discuss:
How traffic is distributed among users and connectors, along with tips for optimizing connector
performance
How traffic flows between connectors and back-end app servers, with recommendations for load balancing
among multiple back-end servers
Traffic distribution across connectors

Connectors establish their connections based on principles for high availability. There's no guarantee that traffic
will always be evenly distributed across connectors and there is no session affinity. However, usage varies and
requests are randomly sent to Application Proxy service instances. As a result, traffic is typically distributed almost
evenly across the connectors. The diagram and steps below illustrate how connections are established between
users and connectors.
1. A user on a client device tries to access an on-premises application published through Application Proxy.
2. The request goes through an Azure Load Balancer to determine which Application Proxy service instance
should take the request. Per region, there are tens of instances available to accept the request. This method
helps to evenly distribute the traffic across the service instances.
3. The request is sent to Service Bus.
4. Service Bus checks if the connection previously used an existing connector in the connector group. If so, it
reuses the connection. If no connector is paired with the connection yet, it chooses an available connector at
random to signal to. The connector then picks up the request from Service Bus.
In step 2, requests go to different Application Proxy service instances, so connections are more likely
to be made with different connectors. As a result, connectors are almost evenly used within the group.
A connection is only reestablished if the connection is broken or an idle period of 10 minutes occurs.
For example, the connection may be broken when a machine or connector service restarts or there's a
network disruption.
5. The connector passes the request to the application’s back-end server. Then the application sends the
response back to the connector.
6. The connector completes the response by opening an outbound connection to the service instance from
where the request came. Then this connection is immediately closed. By default, each connector is limited to
200 concurrent outbound connections.
7. The response is then passed back to the client from the service instance.
8. Subsequent requests from the same connection repeat the steps above until this connection is broken or is
idle for 10 minutes.
An application often has many resources and opens multiple connections when it's loaded. Each connection goes
through the steps above to become allocated to a service instance, select a new available connector if the
connection has not yet previously paired with a connector.
Best practices for high availability of connectors

Because of the way traffic is distributed among connectors for high availability, it's essential to always have
at least two connectors in a connector group. Three connectors are preferred to provide additional buffer
among connectors. To determine the correct number of connectors you needed, follow capacity planning
documentation.
Place connectors on different outbound connections to avoid a single point of failure. If connectors use the
same outbound connection, a network problem with the connection may impact all connectors using it.
Avoid forcing connectors to restart when connected to production applications. Doing so could negatively
impact the distribution of traffic across connectors. Restarting connectors causes more connectors to be
unavailable and forces connections to the remaining available connector. The result is an uneven use of the
connectors initially.
Avoid all forms of inline inspection on outbound TLS communications between connectors and Azure. This
type of inline inspection causes degradation to the communication flow.
Make sure to keep automatic updates running for your connectors. If the Application Proxy Connector
Updater service is running, your connectors update automatically and receive the latest upgraded. If you
don’t see the Connector Updater service on your server, you need to reinstall your connector to get any
updates.
Traffic flow between connectors and back-end application servers

Another key area where high availability is a factor is the connection between connectors and the back-end servers.
When an application is published through Azure AD Application Proxy, traffic from the users to the applications
flows through three hops:
1. The user connects to the Azure AD Application Proxy service public endpoint on Azure. The connection is
established between the originating client IP address (public) of the client and the IP address of the Application
Proxy endpoint.
2. The Application Proxy connector pulls the HTTP request of the client from the Application Proxy Service.
3. The Application Proxy connector connects to the target application. The connector uses its own IP address for
establishing the connection.
X -Forwarded-For header field considerations
In some situations (like auditing, load balancing etc.), sharing the originating IP address of the external client with
the on-premises environment is a requirement. To address the requirement, Azure AD Application Proxy connector
adds the X-Forwarded-For header field with the originating client IP address (public) to the HTTP request. The
appropriate network device (load balancer, firewall) or the web server or back-end application can then read and
use the information.
Best practices for load balancing among multiple app servers

When the connector group that's assigned to the Application Proxy application has two or more connectors, and
you’re running the back-end web application on multiple servers (server farm), a good load-balancing strategy is
required. A good strategy ensures that servers pick up client requests evenly and prevents over- or under-
utilization of servers in the server farm.
Scenario 1: Back-end application does not require session persistence
The simplest scenario is where the back-end web application doesn’t require session stickiness (session
persistence). Any request from the user can be handled by any back-end application instance in the server farm.
You can use a layer 4 load balancer and configure it with no affinity. Some options include Microsoft Network Load
Balancing and Azure Load Balancer or a load balancer from another vendor. Alternatively, round-robin DNS can be
configured.
Scenario 2: Back-end application requires session persistence
In this scenario, the back-end web application requires session stickiness (session persistence) during the
authenticated session. All requests from the user must be handled by the back-end application instance that runs
on the same server in the server farm. This scenario can be more complicated because the client usually establishes
multiple connections to the Application Proxy service. Requests over different connections might arrive at different
connectors and servers in the farm. Because each connector uses its own IP address for this communication, the
load balancer can't ensure session stickiness based on the IP address of the connectors. Source IP Affinity can't be
used either. Here are some options for scenario 2:
Option 1: Base the session persistence on a session cookie set by the load balancer. This option is
recommended because it allows the load to be spread more evenly among the back-end servers. It requires
a layer 7 load balancer with this capability and that can handle the HTTP traffic and terminate the SSL
connection. You can use Azure Application Gateway (Session Affinity) or a load balancer from another
vendor.
Option 2: Base the session persistence on the X-Forwarded-For header field. This option requires a layer 7
load balancer with this capability and that can handle the HTTP traffic and terminate the SSL connection.
Option 3: Configure the back-end application to not require session persistence.
Refer to your software vendor's documentation to understand the load-balancing requirements of the back-end
application.
Next steps
Enable 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 Proxy 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
Add a gallery app to your Azure AD organization
Azure Active Directory (Azure AD ) has a gallery that contains thousands of pre-integrated applications that are
enabled with Enterprise single sign-on. This article describes the general steps for adding an app from the gallery
to your Azure AD organization.
IMPORTANT
First, check for your app in the List of tutorials on how to integrate SaaS apps with Azure Active Directory. You'll likely find
step-by-step guidance for adding and configuring the gallery app you want to add.
Add a gallery application

1. Sign in to the Azure portal as a global admin for your Azure AD tenant, a cloud application admin, or an
application admin.
4. Select New application.

5. Under Add from the gallery, in the search box, enter the name of the application you want to add.
6. Select the application from the results.

7. (Optional) In the application-specific form, you can edit the name of the application to match the needs of
your organization.
8. Select Add. The application Overview page opens.

2. Set the following options to determine how users who are assigned or unassigned to the application can
sign into the application and if a user can see the application in the access panel.
User assignment required determines whether users who aren't 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.
APPLICATION
SETTINGS EXPERIENCE
application?*
yes yes yes yes yes
yes yes no yes no

APPLICATION
SETTINGS EXPERIENCE
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
APPLICATION
SETTINGS EXPERIENCE
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
3. To use a custom logo, create a logo that is 215 by 215 pixels, and save it in PNG format. Then browse to
your logo and upload it.
Next steps
Add an unlisted (non-gallery) application to your
Azure AD organization
In addition to the choices in the Azure AD application gallery, you have the option to add a non-gallery
application. You can add any application that already exists in your organization, or any third-party application
from a vendor who is not already part of the Azure AD gallery. Depending on your license agreement, the
following capabilities are available:
Self-service integration of any application that supports Security Assertion Markup Language (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 System for Cross-Domain Identity Management (SCIM )
protocol for user provisioning
Ability to add links to any application in the Office 365 app launcher or the Azure AD access panel
This article describes how to add a non-gallery application to Enterprise Applications in the Azure portal
without writing code. If instead you're looking for developer guidance on how to integrate custom apps with Azure
AD, see Authentication Scenarios for Azure AD. When you develop an app that uses a modern protocol like
OpenId Connect/OAuth to authenticate users, you can register it with the Microsoft identity platform by using the
App registrations experience in the Azure portal.
Add a non-gallery application

1. Sign in to the Azure Active Directory portal using your Microsoft identity platform administrator account.
2. Select Enterprise Applications > New application.
3. (Optional but recommended) In the Add from the gallery search box, enter the display name of the
application. If the application appears in the search results, select it and skip the rest of this procedure.
4. Select Non-gallery application. The Add your own application page appears.
5. Enter the display name for your new application.
6. Select Add. The application Overview page opens.

2. Set the following options to determine how users who are assigned or unassigned to the application can
sign into the application and if a user can see the application in the access panel.
User assignment required determines whether users who aren't 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.
APPLICATION
SETTINGS EXPERIENCE
application?*
yes yes yes yes yes
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
APPLICATION
SETTINGS EXPERIENCE
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
3. To use a custom logo, create a logo that is 215 by 215 pixels, and save it in PNG format. Then browse to
your logo and upload it.
Next steps
Change the name or logo of an enterprise
application in Azure Active Directory
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
application.
How do I change an enterprise application's name or logo?

1. Sign in to the Azure Active Directory portal with an account that's a global admin for the directory. The
Azure Active Directory admin center page appears.
2. In the left pane, select Enterprise applications. The list of your enterprise applications appears.
3. Select an application. The application overview page appears.
4. In the application overview pane, under the Manage heading, select Properties. The Properties page
appears.
5. If you want to change the name, select the Name box, type the new name, and press Enter.
6. If you want to change the logo, find the Logo field, and select the folder icon next to the Select a file box,
which is below the application's current logo image.
Otherwise, if you aren't changing the logo, go to step 8.

7. In the file picker, select the file you want as the new logo. The name of the file appears in the box below the
current logo image.
NOTE
Azure requires the logo image to be a PNG file, and it applies limits on width, height, and file size.
8. Select Save. If you chose a new logo, the Logo field's image changes to reflect the new logo file.
Next steps
Quickstart: View your organization's groups and members in Azure Active Directory
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
Configure SAML-based single sign-on to non-
gallery applications
When you add a gallery app or a non-gallery web app to your Azure AD Enterprise Applications, one of the
single sign-on options available to you is SAML -based single sign-on. Choose SAML whenever possible for
applications that authenticate using one of the SAML protocols. 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. You can map users to specific application roles
based on rules you define in your SAML claims. This article describes how to configure SAML -based single
sign-on for a non-gallery app.
NOTE
Adding a gallery app? Find step-by-step setup instructions in the list of SaaS app tutorials
To configure SAML 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.
Before you begin

If the application hasn't been added to your Azure AD tenant, see Add a non-gallery app.
Step 1. Edit the Basic SAML Configuration

1. Sign in to the Azure portal as a cloud application admin, or an application admin for your Azure AD
tenant.
2. Navigate to Azure Active Directory > Enterprise applications and select the application from the list.
To search for the application, in the Application Type menu, select All applications, and then select
Apply. Enter the name of the application in the search box, and then select the application from the
results.
3. Under the Manage section, select Single sign-on.
4. Select SAML. The Set up Single Sign-On with SAML - Preview page appears.
5. To edit the basic SAML configuration options, select the Edit icon (a pencil) in the upper-right corner of
the Basic SAML Configuration section.
6. Enter the following settings. You should get the values from the application vendor. You can manually
enter the values or upload a metadata file to extract the value of the fields.
BASIC SAML
CONFIGURATION SETTING SP-INITIATED IDP-INITIATED DESCRIPTION
Identifier (Entity ID) Required for some apps Required for some apps Uniquely identifies the
application. 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. You can find
this value as the Issuer
element in the
AuthnRequest (SAML
request ) sent 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. You
can use the additional
reply URL fields to specify
multiple reply URLs. For
example, you might need
additional reply URLs for
multiple subdomains. Or,
for testing purposes you
can specify multiple reply
URLs (local host and
public URLs) at one time.
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 performs IdP-
initiated sign-on when a
user launches the
application from Office
365, the Azure AD Access
Panel, or the Azure AD
SSO URL.
BASIC SAML
CONFIGURATION SETTING SP-INITIATED IDP-INITIATED DESCRIPTION
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.
Logout URL Optional Optional Used to send the SAML

Logout responses back to
the application.
For more information, see Single sign-on SAML protocol.
Step 2. Configure User attributes and claims

When a user authenticates to the application, Azure AD issues the application a SAML token with information
(or claims) about the user that uniquely identifies them. By default, this information includes the user's
username, email address, first name, and last name. You might need to customize these claims if, for example,
the application requires specific claim values or a Name format other than username. Requirements for gallery
apps are described in the application-specific tutorials, or you can ask the application vendor. The general steps
for configuring user attributes and claims are described below.
1. In the User Attributes and Claims section, select the Edit icon (a pencil) in the upper-right corner.
2. Verify the Name Identifier Value. The default value is user.principalname. 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. To modify the Name Identifier Value, select the Edit icon (a pencil) for the Name Identifier Value
field. Make the appropriate changes to the identifier format and source, as needed. For details, see Editing
NameId. Save the changes when you're done.
4. To configure group claims, select the Edit icon for the Groups returned in claim field. For details, see
Configure group claims.
5. To add a claim, select Add new claim at the top of the page. Enter the Name and select the appropriate
source. If you select the Attribute source, you'll need to choose the Source attribute you want to use. If
you select the Translation source, you'll need to choose the Transformation and Parameter 1 you want
to use. For details, see Adding application-specific claims. Save the changes when you're done.
6. Select Save. The new claim appears in the table.
NOTE
For additional ways to customize the SAML token from Azure AD to your application, see the following resources.
To create custom roles via the Azure portal, see Configure role claims.
To customize the claims via PowerShell, see Customize claims - PowerShell.
To modify the application manifest to configure optional claims for your application, see Configure optional
claims.
To set token lifetime policies for refresh tokens, access tokens, session tokens, and ID tokens, see Configure
token lifetimes. Or, to restrict authentication sessions via Azure AD Conditional Access, see authentication
session management capabilities.
Step 3. Manage the SAML signing certificate

Azure AD uses a certificate to sign the SAML tokens it sends to the application. 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. For more information, see Manage certificates for federated single sign-on and
Advanced certificate signing options in the SAML token.
From Azure AD, you can download the active certificate in Base64 or Raw format directly from the main Set up
Single Sign-On with SAML page. Alternatively, you can get the active certificate by downloading the
application metadata XML file or by using the App federation metadata URL. To view, create, or download your
certificates (active or inactive), follow these steps.
1. Go to the SAML Signing Certificate section.
2. Verify the certificate has:

The desired expiration date. You can configure the expiration date for up to three years into the future.
A status of active for the desired certificate. If the status is Inactive, change the status to Active. To
change the status, right-click the desired certificate's row and select Make certificate active.
The correct signing option and algorithm.
The correct notification email address(es). When the active certificate is near the expiration date, Azure
AD sends a notification to the email address configured in this field.
3. To download the certificate, select one of the options for Base64 format, Raw format, or Federation
Metadata XML. Azure AD also provides the App Federation Metadata Url where you can access the
metadata specific to the application in the format
https://login.microsoftonline.com/<Directory ID>/federationmetadata/2007-06/federationmetadata.xml?
appid=<Application ID>
.
4. To manage, create, or import a certificate, select the Edit icon (a pencil) in the upper-right corner of the
SAML Signing Certificate section.
Take any of the following actions:

To create a new certificate, select New Certificate, select the Expiration Date, and then select Save.
To activate the certificate, select the context menu (...) and select Make certificate active.
To upload a certificate with private key and pfx credentials, select Import Certificate and browse to
the certificate. Enter the PFX Password, and then select Add.
To configure advanced certificate signing options, use the following options. For descriptions of these
options, see the Advanced certificate signing options article.
In the Signing Option drop-down list, choose Sign SAML response, Sign SAML assertion,
or Sign SAML response and assertion.
In the Signing Algorithm drop-down list, choose SHA -1 or SHA -256.
To notify additional people when the active certificate is near its expiration date, enter the email
addresses in the Notification email addresses fields.
5. If you made changes, select Save at the top of the SAML Signing Certificate section.
Step 4. Set up the application to use Azure AD

The Set up <applicationName> section lists the values that need to be configured in the application so it will
use Azure AD as a SAML identity provider. The required values vary according to the application. For details, see
the application's SAML documentation. To find the documentation, go to the Set up <application name>
heading and select View step-by-step instructions. The documentation appears in the Configure sign-on
page. That page guides you in filling out the Login URL, Azure AD Identifier, and Logout URL values in the
Set up <application name> heading.
1. Scroll down to the Set up <applicationName> section.
2. Copy the value from each row in this section as needed and follow the application-specific instructions for
adding the value to the application. For gallery apps, you can view the documentation by selecting View
step-by-step instructions.
The Login URL and Logout URL values both resolve to the same endpoint, which is the SAML
request-handling endpoint for your instance of Azure AD.
The Azure AD Identifier is the value of the Issuer in the SAML token issued to the application.
3. When you've pasted all the values into the appropriate fields, select Save.
Step 5. Validate single sign-on

Once you've configured your application to use Azure AD as a SAML -based identity provider, you can test the
settings to see if single sign-on works for your account.
2. Scroll to the Validate single sign-on with section.
3. Select Validate. The testing options appear.

4. Select Sign in as current user.
If sign-on is successful, you're ready to assign users and groups to your SAML application. If an error message
appears, complete the following steps:
1. Copy and paste the specifics into the What does the error look like? box.
2. Select Get resolution guidance. The root cause and resolution guidance appear. In this example, the
user wasn't assigned to the application.
3. Read the resolution guidance and then, if possible, fix the issue.
4. Run the test again until it completes successfully.
For more information, see Debug SAML -based single sign-on to applications in Azure Active Directory.
Next steps
Assign users or groups to the application
Configure automatic user account provisioning
When you add a gallery app or a non-gallery web app to your Azure AD Enterprise Applications, one of the single
sign-on options available to you is password-based single sign-on. This option is available for any web with 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's also useful for scenarios
where several users need to share a single account, such as to your organization's social media app accounts.
Password-based SSO 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 a username and password to be used by individuals or groups when
signing in to the application by using the Update Credentials feature
Before you begin

If the application hasn't been added to your Azure AD tenant, see Add a gallery app or Add a non-gallery app.
Open the app and select password single sign-on

1. Sign in to the Azure portal as a cloud application admin, or an application admin for your Azure AD tenant.
2. Navigate to Azure Active Directory > Enterprise applications. A random sample of the applications in
your Azure AD tenant appears.
3. In the Application Type menu, select All applications, and then select Apply.
4. Enter the name of the application in the search box, and then select the application from the results.
6. Select Password-based.
7. Enter the URL of the application's web-based sign-in page. This string must be the page that includes the
username input field.
8. Select Save. Azure AD tries to parse the sign-in page for a username input and a password input. If the
attempt succeeds, you're done.
NOTE
Your next step is to Assign users or groups to the application. After you've assigned users and groups, you can provide
credentials to be used on behalf of a user when they sign in to the application. Select Users and groups, select the
checkbox for the user's or group's row, and then click Update Credentials. Then, enter the username and password to be
used on behalf of the user or group. Otherwise, users will be prompted to enter the credentials themselves upon launch.
Manual configuration
If Azure AD's parsing attempt fails, you can configure sign-on manually.
1. Under <application name> Configuration, select Configure <application name> Password Single
Sign-on Settings to display the Configure sign-on page.
2. Select Manually detect sign-in fields. Additional instructions describing the manual detection of sign-in
fields appear.
3. Select Capture sign-in fields. A capture status page opens in a new tab, showing the message metadata
capture is currently in progress.
4. If the Access Panel Extension Required box appears in a new tab, select Install Now to install the My
Apps Secure Sign-in Extension browser extension. (The browser extension requires Microsoft Edge,
Chrome, or Firefox.) Then install, launch, and enable the extension, and refresh the capture status page.
The browser extension then opens another tab that displays the entered URL.
5. In the tab with the entered URL, go through the sign-in process. Fill in the username and password fields,
and try to sign in. (You don't have to provide the correct password.)
A prompt asks you to save the captured sign-in fields.
6. Select OK. The browser extension updates the capture status page with the message Metadata has been
updated for the application. The browser tab closes.
7. In the Azure AD Configure sign-on page, select Ok, I was able to sign-in to the app successfully.
8. Select OK.
After the capture of the sign-in page, you may assign users and groups, and you can set up credential policies just
like regular password SSO applications.
NOTE
You can upload a tile logo for the application using the Upload Logo button on the Configure tab for the application.
Next steps
When you add a gallery or non-gallery web application, one of the single sign-on options available to you is
linked sign-on. Select this option to add a link to the application in your organization's Azure AD Access Panel or
Office 365 portal. You can use this method to add links to custom web applications 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.
Before you begin

If the application hasn't been added to your Azure AD tenant, see Add a gallery app or Add a non-gallery app.
Open the app and select linked sign-on
1. Sign in to the Azure portal as a cloud application admin, or an application admin for your Azure AD tenant.
2. Navigate to Azure Active Directory > Enterprise applications. A random sample of the applications in
your Azure AD tenant appears.
3. In the Application Type menu, select All applications, and then select Apply.
4. Enter the name of the application in the search box, and then select the application from the results.
6. Select Linked.
7. Enter the URL of the application to link to. Type the URL and select Save.
8. You may assign users and groups to the application, which causes the application to appear in the Office
365 app launcher or the Azure AD access panel for those users.
9. Select Save.
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. Select the app for consent.
6. Select Permissions and then click Grant admin consent. You'll be prompted to sign in to administrate the
application.
7. Sign in with an account that has permissions to grant admin consent for the application.
8. 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:
1. Sign in to the Azure portal as a global administrator.
2. Navigate to the App Registrations blade.
3. Select the application for the consent.
4. Select API permissions.
5. Click Grant admin consent.
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.
The availability of group-based assignment is determined by your license agreement. Group-based assignment is
supported for Security groups only. Nested group memberships and O365 groups are not currently supported.
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:
1. Open the Azure portal and sign in as a Global Administrator.
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 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. Click the Add button on top of the Users and Groups list to open the Add Assignment pane.
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.
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.
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.
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
groups you have selected.
15. Click the Assign button to assign the application to the selected groups.
After a short period of time, the users within the groups you have selected will 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 approve access to the application.
Next steps
Provide single sign-on to your apps with Application Proxy
Assign a user or group to an enterprise app in Azure
Active Directory
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. For Microsoft Applications (such as Office 365
apps), use PowerShell to assign users to an enterprise app.
NOTE
For licensing requirements for the features discussed in this article, see the Azure Active Directory pricing page.
Assign a user to an app - portal

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. Select Enterprise applications.
4. On the Enterprise applications - All applications pane, you see a list of the apps you can manage.
Select an app.
5. On the appname pane (that is, the pane with the name of the selected app in the title), select Users &
Groups.
6. On the appname - User and groups pane, select Add user.
7. On the Add Assignment pane, select Users and groups.
8. On the Users and groups pane, select one or more users or groups from the list and then choose the
Select button at the bottom of the pane.
9. On the Add Assignment pane, select Role. Then, on the Select Role pane, select a role to apply to the
selected users or groups, then select OK at the bottom of the pane.
10. On the Add Assignment pane, select the Assign button at the bottom of the pane. 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

3. Select Enterprise applications.
4. On the Enterprise applications pane, select All applications. This lists the apps you can manage.
5. On the Enterprise applications - All applications pane, select an app.
6. On the appname pane, select Properties.
7. On the appname - Properties pane, set the User assignment required? setting to No.
The User assignment required? option:
If this option is set to yes, then users must first be assigned to this application before being able to access it.
If this option is set to no, then any users who navigate to the application deep-link URL or application URL
directly will be granted access
Doesn't 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, Application Proxy
applications that use Azure Active Directory Pre-Authentication or applications built directly on the Azure AD
application platform that use OAuth 2.0 / OpenID Connect Authentication after a user or admin has
consented to that application. See Single sign-on for applications. See Configure the way end-users consent
to an application.
This option has no effect when an application is configured for any of the other Single Sign-on modes.
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 = "[email protected]"
$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
See all of my groups
Change the name or logo of an enterprise app
How to use self-service application access
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.
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
14. Click the Save button at the top of the blade 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 approve access to the application.
Next steps
Setting up Azure Active Directory for self-service group management
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:
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.
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
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 assigned access to one of your enterprise applications in Azure Active
Directory (Azure AD ). You need 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?
3. On the Azure Active Directory - directoryname page (that is, the Azure AD page for the directory you're
managing), select Enterprise applications.
4. On the Enterprise applications - All applications page, you'll see a list of the apps you can manage. Select
an app.
5. On the appname overview page (that is, the page with the name of the selected app in the title), select Users
& Groups.
6. 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
See all of my groups
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 no users can sign in to it in Azure Active Directory (Azure AD ). You
need 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're
managing), select Enterprise applications.
4. On the Enterprise applications - All applications pane, you see a list of the apps you can manage. Select an
app.
5. On the appname pane (that is, the pane with the name of the selected app in the title), select Properties.
6. On the appname - Properties pane, select No for Enabled for users to sign-in?.
7. Select the Save command.
Next steps
See all my groups
How to configure self-service application assignment
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.
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
approver may approver access to the application.
Next steps
Configure Azure Active Directory sign in behavior for
an application by using a Home Realm Discovery
policy
This article 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 following cmdlet to list the service principals and their IDs.
Get-AzureADServicePrincipal
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 -id <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 -id <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 Single sign-on to applications in Azure Active Directory.
Visit the Active Directory developer's guide for an overview of all developer-related content.
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
App sign-on URL URL of the sign-in page N/A In Azure AD, the sign- N/A
of this application. This on URL is configured
is where the user goes within the Azure portal
to sign in to the app in in the application’s
an SP-initiated SAML Single sign-on
flow. properties as the sign-
on URL.
(You might have to
select Show advanced
URL settings to see the
sign-on URL.)
CORRESPONDING
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 in
(IdP’s) perspective. This the app. Right-click the within the Azure portal the SAML token.
is where the user and relying party, select in the application’s Example value:
token are sent after the Properties, and then Single sign-on https://contoso.my.salesforce.com
user has signed on at select the Endpoints properties as the reply
the IdP. tab. URL.
This is sometimes called (You might have to
the “SAML assertion select Show advanced
consumer endpoint.” URL settings to see the
reply URL.)
App sign-out URL URL to which “sign-out Find it in AD FS N/A. Azure AD does not N/A
cleanup” requests are Management under support “single logout,”
sent when a user signs Relying Party Trusts. meaning sign-out of all
out from an app, to Right-click the relying apps. It simply signs
sign out all other apps party, select out the user from Azure
to which the IdP has Properties, and then AD itself.
signed on the user. select the Endpoints
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. Right- identifier is configured Audience element in
perspective. The sign- click the relying party within the Azure portal the SAML token.
on URL value is often trust, select Properties, in the application’s
used for the identifier and then select the Single sign-on
(but not always). Identifiers tab. properties as the
Sometimes the app identifier under
calls this the “entity ID." Domain and URLs.
(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 not N/A
metadata federation metadata. federation metadata support consuming
The IdP uses it to URL in the AD FS application federation
automatically update relying party trust for metadata directly.
specific configuration the app. Right-click the
settings, such as trust, select Properties,
endpoints or and then select the
encryption certificates. Monitoring tab.
User identifier/NameID Attribute that is used In AD FS, you can find In Azure AD, you can Communicated from
to uniquely indicate the this as a claim rule on find the user identifier the IdP to the app as
user identity from the relying party. In within the Azure portal the NameID element in
Azure AD or AD FS to most cases, the claim in the application’s the SAML token.
your app. rule issues a claim with Single sign-on
This attribute is a type that ends with properties under the
typically either the UPN “nameidentifier.” header User
or the email address of Attributes.
the user. By default, the UPN is
used.
CORRESPONDING
Other claims to be sent In addition to the user In AD FS, you can find In Azure AD, you can N/A
to the app identifier/NameID, this as other claim rules find it within the Azure
other claim information on the relying party. portal in the
is commonly sent from application’s Single
the IdP to the app. sign-on properties
Examples include first under the header User
name, last name, email Attributes. Select View
address, and groups and edit all other user
that the user is a attributes.
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 The corresponding value for
sign-on the app’s perspective (where AD FS federation service name Azure AD follows the pattern
URL the user is redirected for login). followed by “/adfs/ls/.” For where {tenant-id} is replaced
example: with your tenant ID. Find it in
https://fs.contoso.com/adfs/ls/ the Azure portal under Azure
Active Directory >
Properties as Directory ID.
For apps that use the SAML-P
protocol:
https://login.microsoftonline.co
m/{tenant-id}/saml2
For apps that use the WS-

Federation protocol:
m/{tenant-id}/wsfed
CONFIGURATION ELEMENT DESCRIPTION AD FS AZURE AD
IdP Sign-out URL of the IdP from For AD FS, the sign-out URL is The corresponding value for
sign-out the app’s perspective (where either the same as the sign-on Azure AD depends on whether
URL the user is redirected when URL, or the same URL with the app supports SAML 2.0
they choose to sign out of the “wa=wsignout1.0” appended. sign-out.
app). For example: If the app supports SAML
https://fs.contoso.com/adfs/ls/ sign-out, the value follows the
?wa=wsignout1.0 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:
m/{tenant-id}/saml2
If the app does not support

SAML sign-out:
m/common/wsfederation?
wa=wsignout1.0
Token Certificate whose private key Find the AD FS token signing In Azure AD, you can find the
signing the IdP uses to sign issued certificate in AD FS token signing certificate within
certificate tokens. It verifies that the Management under the Azure portal in the
token came from the same IdP Certificates. application’s Single sign-on
that the app is configured to properties under the header
trust. 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-id}
In the SAML token, the value Management under Service > is replaced with the tenant ID.
appears as the Issuer element. Edit Federation Service Find it in the Azure portal
Properties. For example: under Azure Active
http://fs.contoso.com/adfs/serv Directory > Properties as
ices/trust Directory ID:
https://sts.windows.net/{tenant
-id}/
IdP Location of the IdP’s publicly Find the AD FS federation The corresponding value for
federation available federation metadata. metadata URL in AD FS Azure AD follows the pattern
metadata (Some apps use federation Management under Service > https://login.microsoftonline.co
metadata as an alternative to Endpoints > Metadata > m/{TenantDomainName}/Feder
the administrator configuring Type: Federation Metadata. ationMetadata/2007-
URLs, identifier, and token For example: 06/FederationMetadata.xml.
signing certificate individually.) https://fs.contoso.com/Federati The value for
onMetadata/2007- {TenantDomainName} is
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 identity providers
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
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 with 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 up the error in our systems
Example – 71a2f329-ca29-402f-aa72-bc00a7aca603
UPN – the user who performed the operation
Example – [email protected]
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":"[email protected]","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.
How to see the details of a portal notification

You can see the details of any portal notification by following the steps below:
1. click 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
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 – [email protected]
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
since it is already in use"}\],"timeStampUtc":"2017-03-
23T19:50:26.465743Z","clientRequestId":"302fd775-3329-4670-a9f3-
bea37004f0bb","internalTransactionId":"ea5b5475-03b9-4f08-8e95-
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 has 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
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.
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.
General issues to check first

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 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.
Checking the deeplink

To check if you have the correct deeplink, follow these steps:
navigation menu.
4. click Enterprise Applications from the Azure Active Directory left-hand 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.
How to install the Access Panel Browser extension

To install the Access Panel Browser extension, follow these steps:
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 these direct links:
Chrome Access Panel Extension
Firefox Access Panel Extension
How to configure password single sign-on for an Azure AD gallery

application
To configure an application from the Azure AD gallery, you must:
Add an application from the Azure AD gallery
Configure the application for password single sign-on
To add an application from the Azure AD Gallery, follow these steps:
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. To add the application, click Add.
After a short period, you are able to 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.
7. Once the application loads, click the Single sign-on from the application’s left-hand navigation menu.
8. Select the mode Password-based Sign-on.
9. Assign users to the application.
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.
How to configure password single sign-on for a non-gallery application

To configure an application from the Azure AD gallery, you must:
To add an application from the Azure AD Gallery, follow these steps:
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 are able to see the application’s configuration pane.
To configure single sign-on for an application, follow these steps:
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
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.
How to assign a user to an application directly

To assign one or more users to an application directly, follow these steps:
navigation menu.
7. Once the application loads, click Users and Groups from the application’s left-hand 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.
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.
After a short period, the users you have selected be able to launch these applications in the 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)
TenantID
Browser type
Time zone and time/timeframe during error occurs
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
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

To install the Access Panel Browser extension, follow the steps below:
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
tutorial available. You can access the List of tutorials on how to integrate SaaS apps with Azure Active Directory for
a detail step-by-step guidance.
To configure an application from the Azure AD gallery you need to:
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)
Assign users to the application
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.
9. Click Add button, to add the application.
After a short period, you can 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.
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 is 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 is 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.
To select the User Identifier or add user attributes, follow the steps below:
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
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 doesn’t provide a URL to get the metadata. The metadata can only be retrieved as an XML file.
How to configure federated single sign-on for a non-gallery application
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.
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 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.
How to configure password single sign-on for an Azure AD gallery

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.
6. Select the application you want to configure single sign-on

navigation menu.
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. Ensure
the sign-in fields are visible at the URL.

navigation menu.
list.
you have selected.
If these troubleshooting steps do not the resolve the issue

TenantID
Browser type
Fiddler traces
Next steps
An app page shows an error message after the user
signs in
In this scenario, Azure Active Directory (Azure AD ) signs the user in. But the application displays an error message
and doesn't let the user finish the sign-in flow. The problem is that the app didn't accept the response that Azure
AD issued.
There are several possible reasons why the app didn't accept the response from Azure AD. If the error message
doesn't clearly identify what's missing from the response, try the following:
If the app is the Azure AD gallery, verify that you followed the steps in How to debug SAML -based single
sign-on to applications in Azure AD.
Use a tool like Fiddler to capture the SAML request, response, and token.
Send the SAML response to the app vendor and ask them what's missing.
Attributes are missing from the SAML response

To add an attribute in the Azure AD configuration that will be sent in the Azure AD response, follow these steps:
1. Open the Azure portal and sign in as a global administrator or co-admin.
2. At the top of the navigation pane on the left side, select All services to open the Azure AD extension.
3. Type Azure Active Directory in the filter search box, and then select Azure Active Directory.
4. Select Enterprise Applications in the Azure AD navigation pane.
5. Select All Applications to view a list of your apps.
NOTE
If you don't see the app that you want, use the Filter control at the top of the All Applications List. Set the Show
option to "All Applications."
6. Select the application that you want to configure for single sign-on.
7. After the app loads, select Single sign-on in the navigation pane.
8. In the User Attributes section, select View and edit all other user attributes. Here you can change which
attributes to send to the app in the SAML token when users sign in.
a. Select Add attribute. Enter the Name, and select the Value from the drop-down list.
b. Select Save. You'll see the new attribute in the table.
9. Save the configuration.
The next time that the user signs in to the app, Azure AD will send the new attribute in the SAML response.
The app doesn't identify the user
Signing in to the app fails because the SAML response is missing an attribute such as a role. Or it fails because the
app expects a different format or value for the NameID (User Identifier) attribute.
If you're using Azure AD automated user provisioning to create, maintain, and remove users in the app, verify that
the user has been provisioned to the SaaS app. For more information, see No users are being provisioned to an
Azure AD Gallery application.
Add an attribute to the Azure AD app configuration

To change the User Identifier value, follow these steps:
2. Select All services at the top of the navigation pane on the left side to open the Azure AD extension.
NOTE
6. Select the app that you want to configure for SSO.

7. After the app loads, select Single sign-on in the navigation pane.
8. Under User attributes, select the unique identifier for the user from the User Identifier drop-down list.
Change the NameID format

If the application expects another format for the NameID (User Identifier) attribute, see Editing nameID to change
the NameID format.
Azure AD selects the format for the NameID attribute (User Identifier) based on the value that's selected or the
format that's requested by the app in the SAML AuthRequest. For more information, see the "NameIDPolicy"
section of Single sign-on SAML protocol.
The app expects a different signature method for the SAML response
To change which parts of the SAML token are digitally signed by Azure AD, follow these steps:
NOTE
If you don't see the application that you want, use the Filter control at the top of the All Applications List. Set the
Show option to "All Applications."
6. Select the application that you want to configure for single sign-on.
7. After the application loads, select Single sign-on in the navigation pane.
8. Under SAML Signing Certificate, select Show advanced certificate signing settings.
9. Select the Signing Option that the app expects from among these options:
Sign SAML response
Sign SAML response and assertion
Sign SAML assertion
The next time that the user signs in to the app, Azure AD will sign the part of the SAML response that you
selected.
The app expects the SHA-1 signing algorithm

By default, Azure AD signs the SAML token by using the most-secure algorithm. We recommend that you don't
change the signing algorithm to SHA -1 unless the app requires SHA-1.
To change the signing algorithm, follow these steps:
5. Select All Applications to view a list of your applications.
NOTE
If you don't see the application that you want, use the Filter control at the top of the All Applications List. Set the
Show option to "All Applications."
6. Select the app that you want to configure for single sign-on.
7. After the app loads, select Single sign-on from the navigation pane on the left side of the app.
8. Under SAML Signing Certificate, select Show advanced certificate signing settings.
9. Select SHA -1 as the Signing Algorithm.
The next time that the user signs in to the app, Azure AD will sign the SAML token by using the SHA-1
algorithm.
Next steps
How to debug SAML -based single sign-on to applications in Azure AD.
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
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.
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.

4. Based on your browser you be directed to the download link. Add the extension to your browser.
You may also download the extension for Chrome and Firefox from the direct links below:
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
your users' machines.
The prerequisites include:
You have set up Active Directory Domain Services, and you have joined your users' machines to your
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.
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.

TenantID
Browser type
Fiddler traces
Next steps
Sign-in problems with an Azure AD gallery app
configured for SSO
Access Panel is a web-based portal. It enables users who have Azure Active Directory (Azure AD ) work or school
accounts to access cloud-based apps that they have permissions for. Users who have Azure AD editions can also
use self-service group and app-management capabilities through Access Panel.
Access Panel is separate from the Azure portal. Users don't need an Azure subscription to use Access Panel.
To use password-based single sign-on (SSO ) in Access Panel, the Access Panel extension must be installed in your
browser. The extension downloads automatically when you select an app that's configured for password-based
SSO.
Browser requirements for Access Panel

Access Panel requires a browser that supports JavaScript and has CSS enabled.
The following browsers support password-based SSO:
Internet Explorer 8, 9, 10, and 11 on Windows 7 or later
Chrome on Windows 7 or later or on MacOS X or later
Firefox 26.0 or later on Windows XP SP2 or later or on Mac OS X 10.6 or later
NOTE
The password-based SSO extension become available for Microsoft Edge in Windows 10 when support for browser
extensions was added to Microsoft Edge.
Install the Access Panel Browser extension

Follow these steps:
1. Open Access Panel in a supported browser, and sign in as a user in Azure AD.
2. Select a password-SSO -enabled app in Access Panel.
3. When you're prompted, select Install Now.
4. You'll be directed to a download link based on your browser. Select Add to install the browser extension.
5. If you're prompted, select Enable or Allow.
6. After the installation, restart your browser.
7. Sign in to Access Panel and see if you can start your password-SSO -enabled apps.
You can also directly download the extensions for Chrome and Firefox through these links:
Chrome Access Panel extension
Firefox Access Panel extension
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.
These are the prerequisites:
Active Directory Domain Services must be set up, and your users' machines must be joined to your domain.
You have "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.
To configure the group policy and deploy it to users, see How to deploy the Access Panel extension for Internet
Explorer using group policy.
Troubleshoot Access Panel in Internet Explorer

To access a diagnostics tool and instructions to configure the extension, see Troubleshoot the Access Panel
extension for Internet Explorer.
Configure password SSO for an Azure AD gallery app

To configure an app from the Azure AD gallery, you need to do these things:
Add the app from the Azure AD gallery
Configure the app for password single sign-on
Add the app from the Azure AD gallery
Follow these steps:
4. Select Enterprise Applications from the Azure AD navigation pane.
5. Select Add in the upper-right corner of the Enterprise Applications pane.
6. In the Add from the gallery section, type the name of the app in the Enter a name box.
8. Optional: Before you add the app, you can change its name in the Name box.
9. Click Add to add the app.
After a brief delay, you'll be able to see the app’s configuration pane.
Configure the app for password SSO
Follow these steps:
NOTE

7. After the app loads, select Single sign-on in the pane on the left side of the app.
8. Select Password-based sign-on mode.
9. Assign users to the app.
10. You can also provide credentials for users. (Otherwise, users will be prompted to enter credentials at app
startup.) To do this, select the rows of the users. Then select Update Credentials and enter their user names
and passwords.
To assign users to an app directly, follow these steps:
1. Open the Azure portal and sign in as a global admin.
2. Select All services in the navigation pain on the left side to open the Azure AD extension.
5. Select All Applications to view a list of your applications.
NOTE
6. From the list, select the app that you want to assign a user to.
7. After the application loads, select Users and Groups from the app’s navigation pane on the left side.
8. Select Add at the top of the Users and Groups list to open the Add Assignment pane.
9. Select Users and groups in the Add Assignment pane.
10. In the Search by name or email address box, type the full name or email address of the user that you
want to assign.
11. Hover over the user in the list. Select the check box next to the user’s profile photo or logo to add that user
to the Selected list.
12. Optional: To add another user, type another name or email address in the Search by name or email
address box, and then select the check box to add that user to the Selected list.
13. When you're finished selecting users, click Select to add them to the list of users and groups who are
assigned to the app.
14. Optional: Click Select Role in the Add Assignment pane to select a role to assign to the users that you
selected.
15. Select Assign to assign the app to the selected users.
After a brief delay, the users will be able to access those apps from Access Panel.
Request support
If you get an error message when you set up SSO and assign users, open a support ticket. Include as much of the
following information as possible:
TenantID
Browser type
Time zone and time/time frame when the error occurred
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. This 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 the user’s account
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
Azure Active Directory
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 their 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:
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 group memberships
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.
4. click Users and groups in the navigation menu.
5. click All users.
6. Search for the user you are interested in and click the row to select.
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.
To check a user’s assigned licenses, follow these steps:
navigation menu.
5. click All users.
7. click Licenses to see which licenses the user currently has assigned.
To assign a license to a user, follow these steps:
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 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.
5. click All groups.
6. Search for the group you are interested in and click the row to select.
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.
7. click Licenses to see which licenses the group currently has assigned.
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 that 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.
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.
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

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
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 '[email protected]' 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 a 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
Problem configuring federated single sign-on for an
Azure AD Gallery application
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
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 [email protected] 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
Managing Applications with Azure Active Directory
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
requested by the application in the SAML AuthRequest. For more information visit the article Single Sign-On
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.
Don't know how to customize SAML claims sent to an application
Next steps
Problem configuring password single sign-on for an
Azure AD Gallery application
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.
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 the direct links below:
Next steps
Problems configuring password single sign-on for a
non-gallery application
This article describes common problems that can occur when you configure password single sign-on (SSO ) for a
non-gallery app.
Capture sign-in fields for an app

Sign-in field capture is supported only for HTML -enabled sign-in pages. It's not supported for non-standard sign-
in pages, like those that use Adobe Flash or other non-HTML -enabled technologies.
There are two ways to capture sign-in fields for your custom apps:
Automatic sign-in field capture works well with most HTML -enabled sign-in pages, if they use well-
known DIV IDs for the user name and password fields. The HTML on the page is scraped to find DIV IDs
that match certain criteria. That metadata is saved so that it can be replayed to the app later.
Manual sign-in field capture is used if the app vendor doesn't label the sign-in input fields. Manual
capture is also used if the vendor renders multiple fields that can't be auto -detected. Azure Active Directory
(Azure AD ) can store data for as many fields as there are on the sign-in page, if you tell it where those fields
are on the page.
In general, if automatic sign-in field capture doesn't work, try the manual option.
Automatically capture sign-in fields for an app
To configure password-based SSO by using automatic sign-in field capture, follow these steps:
1. Open the Azure portal. Sign in as a global administrator or co-admin.
2. In the navigation pane on the left side, select All services to open the Azure AD extension.
NOTE
If you don't see the app that you want, use the Filter control at the top of the All Applications list. Set the Show

7. After the app loads, select Single sign-on in the navigation pane on the left side.
8. Select Password-based Sign-on mode.
9. Enter the Sign-on URL, which is the URL of the page where users enter their user name and password to
sign in. Make sure that the sign-in fields are visible on the page for the URL that you provide.
10. Select Save.
The page is automatically scraped for the user name and password input boxes. You can now use Azure AD
to securely transmit passwords to that app by using the Access Panel browser extension.
Manually capture sign-in fields for an app
To manually capture sign-in fields, you must have the Access Panel browser extension installed. Also, your browser
can't be running in inPrivate, incognito, or private mode.
To install the extension, see the Install the Access Panel Browser extension section of this article.
To configure password-based SSO for an app by using manual sign-in field capture, follow these steps:
1. Open the Azure portal. Sign in as a global administrator or co-admin.
2. In the navigation pane on the left side, select All services to open the Azure AD extension.
NOTE
If you don't see the app that you want, use the Filter control at the top of the All Applications list. Set the Show

7. After the app loads, select Single sign-on in the navigation pane on the left side.
8. Select Password-based Sign-on mode.
9. Enter the Sign-on URL, which is the page where users enter their user name and password to sign in. Make
sure that the sign-in fields are visible on the page for the URL that you provide.
10. Select Configure <appname> Password Single Sign-on Settings.
11. Select Manually detect sign-in fields.
12. Select Ok.
13. Select Save.
14. Follow the instructions to use Access Panel.
Troubleshoot problems
I get a “We couldn’t find any sign-in fields at that URL” error
You get this error message when automatic detection of sign-in fields fails. To resolve the issue, try manual sign-in
field detection. See the Manually capture sign-in fields for an application section of this article.
I get an “Unable to save single sign-on configuration” error
Rarely, updating the SSO configuration fails. To resolve this problem, try saving the configuration again.
If you keep getting the error, open a support case. Include the information that's described in the View portal
notification details and Send notification details to a support engineer to get help sections of this article.
I can't manually detect sign-in fields for my app
You might observe the following behaviors when manual detection isn't working:
The manual capture process appeared to work, but the captured fields aren't correct.
The correct fields don’t get highlighted when the capture process runs.
The capture process takes you to the app’s sign-in page as expected, but nothing happens.
Manual capture appears to work, but SSO doesn’t happen when users navigate to the app from Access
Panel.
If you experience any of these problems, do the following things:
Make sure that you have the latest version of the Access Panel browser extension installed and enabled. See
the Install the Access Panel browser extension section of this article.
Make sure that your browser isn't in incognito, inPrivate, or Private mode during the capture process. The
Access Panel extension isn't supported in these modes.
Make sure that your users aren't trying to sign in to the app from Access Panel while in incognito, inPrivate,
or Private mode.
Try the manual capture process again. Make sure that the red markers are over the correct fields.
If the manual capture process seems to stop responding or the sign-in page doesn’t respond, try the manual
capture process again. But this time, after completing the process, press the F12 key to open your browser’s
developer console. Select the console tab. Type window.location="<the sign -in URL that 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 were captured.
Contact support
If you still have problems, open a case with Microsoft Support. Describe what you tried. Include the details that are
described in the View portal notification details and Send notification details to a support engineer to get help
sections of this article (if applicable).
Install the Access Panel browser extension

Follow these steps:
1. Open Access Panel in a supported browser. Sign in to Azure AD as a user.
2. Select password-SSO application in Access Panel.
3. When you're prompted to install the software, select Install Now.
4. You'll be directed to a download page for your browser. Choose to Add the extension.
5. If you're prompted, select Enable or Allow.
6. After the installation, restart your browser.
7. Sign in to Access Panel. See if you can open your password-SSO -enabled apps.
You can also directly download the browser extension for Chrome and Firefox through these links:
Chrome Access Panel extension
Firefox Access Panel extension
View portal notification details

To see the details of any portal notification, follow these steps:
1. Select the Notifications icon (the bell) in the upper-right corner of the Azure portal.
2. Select any notification that shows an Error state. (They have a red "!".)
NOTE
You can't select notifications that are in the Successful or In Progress state.
3. The Notification Details pane opens. Read the information to learn about the problem.
4. If you still need help, share the information with a support engineer or the product group. Select the copy
icon to the right of the Copy error box to copy the notification details to share.
Send notification details to a support engineer to get help

It's important that you share all the details that are listed in this section with support so that they can help you
quickly. To record it, you can take a screenshot or select Copy error.
The following information explains what each notification item means and provides examples.
Essential notification items
Title: the descriptive title of the notification.
Example: Application proxy settings
Description: 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 that your browser made.
Example: 302fd775 -3329 -4670 -a9f3 -bea37004f0bc
Time Stamp UTC: the timestamp of when the notification occurred, in UTC.
Example: 2017 -03 -23T19:50:43.7583681Z
Internal Transaction ID: the internal ID that's used to look up the error in our systems.
Example: 71a2f329-ca29-402f-aa72-bc00a7aca603
UPN: The user who ran the operation.
Example: [email protected]
Tenant ID: the unique ID of the tenant that the user who ran the operation is a member of.
Example: 7918d4b5 -0442 -4a97 -be2d -36f9f9962ece
User object ID: The unique ID of the user who ran the operation.
Example: 17f84be4 -51f8 -483a -b533 -383791227a99
Detailed notification items
Display Name: (can be empty) a more-detailed display name for the error.
Example: Application proxy settings
Status: the specific status of the notification.
Example: Failed
Object ID: (can be empty) the object ID against which the operation was run.
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: Enables you to select the copy icon to the right of the Copy error textbox to copy the
notification details to help with support.
Example:
since it is already in use"}\],"timeStampUtc":"2017-03-23T19:50:26.465743Z","clientRequestId":"302fd775-
3329-4670-a9f3-bea37004f0bb","internalTransactionId":"ea5b5475-03b9-4f08-8e95-
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.
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
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
Troubleshoot 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're an admin, see 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.
To download and install the diagnostic tool:
1. Select this link to download the diagnostic tool.
2. Open the file and extract the contents to your computer.
3. To run the tool, right-click the file named AccessPanelExtensionDiagnosticTool.js and select Open with >
Microsoft Windows Based Script Host.
4. Review the diagnostic results that appear and select Yes to fix the issues. The Check Results dialog box
appears with information about what to do if the extension doesn't work.
5. Read the message and select OK.
Check that the Access Panel Extension is enabled
To verify that you've enabled the Access Panel Extension in Internet Explorer:
1. In Internet Explorer, select the Gear icon on the upper-right corner of the window and select Internet options.
2. Go to the Programs tab and select Manage add-ons.
3. Select Access Panel Extension in the Microsoft Corporation section and select Enable.
4. To save the changes, close all of the Internet Explorer browser windows you have open. The change takes effect
the next time you open Internet Explorer.
Enable extensions for InPrivate Browsing

To enable extensions for InPrivate Browsing:
1. In Internet Explorer, select the Gear icon on the upper-right corner of the window and select Internet options.
2. Go to the Privacy tab and verify that the Disable toolbars and extensions when InPrivate Browsing starts
check box is clear.
3. To save the changes, close all of the Internet Explorer browser windows you have open. The change takes effect
the next time you open Internet Explorer.
Uninstall the Access Panel Extension

To uninstall the Access Panel Extension from your computer:
1. In Control Panel, search for uninstall.
2. In the search results, select Uninstall a program.
3. From the list, select Access Panel Extension and select Uninstall.
4. You can then try to install the extension again to see if the problem has been resolved.
If you run into 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
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

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 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
tutorial available. You can access the List of tutorials on how to integrate SaaS apps with Azure Active Directory for
navigation menu.
Configure single sign-on for an application from the Azure AD gallery
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
10. Optional: click Show advanced URL settings if you want to see the non-required values.
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)
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 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.
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
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.
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
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.
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.
completed.
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:
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.
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.
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.

Tenant ID
Browser type
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 that a user’s authentication contact info is up-to-date to allow Multi-Factor Authentication or

SSO.

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:
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
Firefox 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?
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
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
Enable automatic user provisioning for your multi-
tenant application
Automatic user provisioning is the process of automating the creation, maintenance, and removal of user identities
in target systems like your software-as-a-service applications.
Why enable automatic user provisioning?

Applications that require that a user record is present in the application before a user’s first sign in require user
provisioning. There are benefits to you as a service provider, and benefits to your customers.
Benefits to you as the service provider
Increase the security of your application by using the Microsoft identity platform.
Reduce actual and perceived customer effort to adopt your application.
Reduce your costs in integrating with multiple identity providers (IdPs) for automatic user provisioning by
using System for Cross-Domain Identity Management (SCIM )-based provisioning.
Reduce support costs by providing rich logs to help customers troubleshoot user provisioning issues.
Increase the visibility of your application in the Azure AD app gallery.
Get a prioritized listing in the App Tutorials page.
Benefits to your customers
Increase security by automatically removing access to your application for users who change roles or leave
the organization to your application.
Simplify user management for your application by avoiding human error and repetitive work associated
with manual provisioning.
Reduce the costs of hosting and maintaining custom-developed provisioning solutions.
Choose a provisioning method

Azure AD provides several integration paths to enable automatic user provisioning for your application.
The Azure AD Provisioning Service manages the provisioning and deprovisioning of users from Azure AD
to your application (outbound provisioning) and from your application to Azure AD (inbound provisioning).
The service connects to the System for Cross-Domain Identity Management (SCIM ) user management API
endpoints provided by your application.
When using the Microsoft Graph, your application manages inbound and outbound provisioning of users
and groups from Azure AD to your application by querying the Microsoft Graph API.
The Security Assertion Markup Language Just in Time (SAML JIT) user provisioning can be enabled if your
application is using SAML for federation. It uses claims information sent in the SAML token to provision
users.
To help determine which integration option to use for your application, refer to the high-level comparison table,
and then see the more detailed information on each option.
CAPABILITIES ENABLED OR
ENHANCED BY AUTOMATIC AZURE AD PROVISIONING MICROSOFT GRAPH API
PROVISIONING SERVICE (SCIM 2.0) (ODATA V4.0) SAML JIT
User and group √ √ User only

management in Azure AD
Manage users and groups √* √* User only*

synced from on-premises
Active Directory
Access data beyond users X+ √ X

and groups during
provisioning Access to O365
data (Teams, SharePoint,
Email, Calendar, Documents,
etc.)
Create, read, and update √ √ √

users based on business
rules
Delete users based on √ √ X

business rules
Manage automatic user √ X √

provisioning for all
applications from the Azure
portal
Support multiple identity √ X √

providers
Support guest accounts √ √ √

(B2B)
Support non-enterprise X √ √
accounts (B2C)
* – Azure ADConnect setup is required to sync users from AD to Azure AD.

+– Using SCIM for provisioning does not preclude you from integrating your application with MIcrosoft Graph for
other purposes.
Azure AD Provisioning Service

The Azure AD provisioning services uses SCIM, a protocol supported by many identity providers (IdPs). We
recommend you use the Azure AD provisioning service if you want to support IdPs in addition to Azure AD, as any
SCIM -compliant IdP can connect to your SCIM endpoint.
For more information on how the Azure AD Provisioning Service users SCIM, see:
Using System for Cross-Domain Identity Management (SCIM ) to automatically provision users and groups
from Azure Active Directory to applications
Understand the Azure AD SCIM implementation
Build a SCIM endpoint using Microsoft CLI Libraries
Microsoft Graph for Provisioning
When you use Microsoft Graph for provisioning, you have access to all the rich user data available in Graph. In
addition to the details of users and groups, you can also fetch additional information like the user’s roles, manager
and direct reports, owned and registered devices, and hundreds of other data pieces available in the Microsoft
Graph.
More than 15 million organizations, and 90% of fortune 500 companies use Azure AD while subscribing to
Microsoft cloud services like Office 365, Microsoft Azure, Enterprise Mobility Suite, or Microsoft 365. You can use
Microsoft Graph to integrate your app with administrative workflows, such as employee onboarding (and
termination), profile maintenance, and more.
Learn more about using Microsoft Graph for provisioning:
Microsoft Graph Home page
Overview of Microsoft Graph
Microsoft Graph Auth Overview
Getting started with Microsoft Graph
Use the Microsoft Graph API
Microsoft Graph Explorer
Microsoft Graph permissions reference
Best practices for working with Microsoft Graph
Featured scenarios for Microsoft Graph
Using SAML JIT for provisioning

If you want to provision users only upon first sign in to your application, and do not need to automatically
deprovision users, SAML JIT is an option. Your application must support SAML 2.0 as a federation protocol to use
SAML JIT.
SAML JIT uses the claims information in the SAML token to create and update user information in the application.
Customers can configure these required claims in the Azure AD application as needed. Sometimes the JIT
provisioning needs to be enabled from the application side so that customer can use this feature. SAML JIT is
useful for creating and updating users, but it can't delete or deactivate the users in the application.
Next Steps
Enable Single Sign-on for your application
Submit your application listing and partner with Microsoft to create documentation on Microsoft’s site.
Join the Microsoft Partner Network (free) and create your go to market plan.
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

Use the Azure Active Directory portal to view and manage all applications that are configured for single sign-on in
a directory. Enterprise apps are apps that are deployed and used within your organization. Follow these steps to
view and manage your enterprise applications:
1. Open the Azure Active Directory portal.
3. Select any app to load its resource pane, where you can view reports and manage app settings.
4. Select Provisioning to manage user account provisioning settings for the selected app.
Provisioning modes
The Provisioning pane begins with a Mode menu, which shows the provisioning modes supported for an
enterprise application, and lets you configure them. The available options include:
Automatic - This option is shown if Azure AD supports automatic API-based provisioning or de-
provisioning of user accounts to this application. Select this mode to display an interface that helps
administrators:
Configure Azure AD to connect to the application's user management API
Create account mappings and workflows that define how user account data should flow between Azure
AD and the app
Manage the Azure AD provisioning service
Manual - This option is shown if Azure AD doesn't support automatic provisioning of user accounts to this
application. In this case, 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

Select the Automatic option to specify settings for admin credentials, mappings, starting and stopping, and
synchronization.
Admin Credentials
Expand Admin Credentials to enter the credentials required for Azure AD to connect to the application's user
management API. 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.
Select Test Connection to test the credentials by having Azure AD attempt to connect to the app's provisioning
app using the supplied credentials.
Mappings
Expand Mappings to view and edit the user attributes that flow between Azure AD and the target application
when user accounts are provisioned or updated.
There's 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. Select a mapping in the table to open the
mapping editor to the right, where you can view and customize them.
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.
Filtering the provisioning actions that Azure AD runs on the targeted application. Instead of having Azure
AD fully synchronize objects, you can limit the actions run.
For example, only select Update and Azure AD only updates existing user accounts in an application but
doesn't create new ones. Only select Create and Azure only creates new user accounts but doesn't update
existing ones. This feature lets admins create different mappings for account creation and update
workflows.
Adding a new attribute mapping. Select Add New Mapping at the bottom of the Attribute Mapping
pane. Fill out the Edit Attribute form and select Ok to add the new mapping to the list.
Settings
You can start and stop the Azure AD provisioning service for the selected application in the Settings area of the
Provisioning screen. You can also choose to 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 run an initial sync. It reads
the users assigned in the Users and groups section, queries the target application for them, and then runs the
provisioning actions defined in the Azure AD Mappings section. During this process, the provisioning service
stores cached data about what user accounts it's 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.
Change the Provisioning Status to Off to pause the provisioning service. In this state, Azure doesn't create,
update, or remove any user or group objects in the app. Change the state back to On and the service picks up
where it left off.
Select the Clear current state and restart synchronization checkbox and select Save to:
Stop the provisioning service
Dump the cached data about what accounts Azure AD is managing
Restart the services and run the initial synchronization again
This option lets admins start the provisioning deployment process over again.
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,
G Suite and others. If you enable user provisioning for a third-party SaaS application, the Azure portal controls
its attribute values through attribute-mappings.
There's 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 along with Users, such as Groups.
You can customize the default attribute-mappings according to your business needs. So, you can change or
delete existing attribute-mappings, or create new attribute-mappings.
Editing user attribute-mappings

Follow these steps to access the Mappings feature of user provisioning:
3. Select any app to load its app management pane, where you can view reports and manage app settings.
4. Select Provisioning to manage user account provisioning settings for the selected app.
5. Expand Mappings to view and edit the user attributes that flow between Azure AD and the target
application. If the target application supports it, this section lets you optionally configure provisioning of
groups and user accounts.
6. Select a Mappings configuration to open the related Attribute Mapping screen. Some attribute-
mappings are required by a SaaS application to function correctly. For required attributes, the Delete
feature is unavailable.
In this screenshot, 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.
7. Select an existing Attribute Mapping to open the Edit Attribute screen. Here you can edit the user
attributes that flow between Azure AD and the target application.
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 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's populated
with the Default value that you specify.
Along with 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's not a
value in Azure AD or on the target object. The most common configuration is to leave this blank.
Understanding attribute -mapping properties
In the previous section, you were already introduced to the attribute-mapping type property. Along with this
property, attribute-mappings 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 this mapping should be used to uniquely identify users
between the source and target systems. It's 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're 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 G Suite, support the ability to provision Group
objects and User objects. Group objects can contain group properties such as display names and email aliases,
along with group members.
Group provisioning can be optionally enabled or disabled by selecting the group mapping under Mappings,
and setting Enabled to the option you want 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 don't support schema discovery. So, the Azure AD provisioning service isn't able to dynamically generate
the list of supported attributes by making calls to the application.
However, some applications support custom attributes, and the Azure AD provisioning service can read and
write to custom attributes. To enter their definitions into the Azure portal, select the Show advanced options
check box at the bottom of the Attribute Mapping screen, and then select Edit attribute list for your app.
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, which can be one of the
following types:
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 the attribute is defined as a primary key field in the target object's schema.
Required? - Whether the attribute is required to be populated in the target application or system.
Multi-value? - Whether the attribute supports multiple values.
Exact case? - Whether the attributes values are evaluated in a case-sensitive way.
API Expression - Don't use, unless instructed to do so by the documentation for a specific provisioning
connector (such as Workday).
Referenced Object Attribute - If it's a Reference type attribute, then this menu lets you 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". The reference tables and the primary ID fields supported for a
given application are pre-configured and currently can't 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 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. Doing so sets all mappings as if the
application was just added to your Azure AD tenant from the application gallery.
Selecting this option will effectively force a resynchronization of all users while the provisioning service is
running.
IMPORTANT
We strongly recommend 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.
A recommended best practice is to keep the number of consecutive changes to your attribute-mappings at a
minimum.
Adding a photo attribute to be provisioned to an app is not supported today as you cannot specify the format
to sync the photo. You can request the feature on User Voice
The attribute IsSoftDeleted is often part of the default mappings for an application. IsSoftdeleted can be true
in one of four scenarios (the user is out of scope due to being unassigned from the application, the user is out
of scope due to not meeting a scoping filter, the user has been soft deleted in Azure AD, or the property
AccountEnabled is set to false on the user).
Next steps
Writing Expressions for Attribute-Mappings
Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to
applications
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. To override this default behavior, refer to Skip deletion
for user accounts that go out of scope.
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
Skip deletion of user accounts that go out of scope
By default, the Azure AD provisioning engine deletes or disables users that go out of scope. However, for certain
scenarios like Workday to AD User Inbound Provisioning this behavior may not be the expected and you may
want to override this default behavior.
This guide describes how to use the Microsoft Graph API and the Microsoft Graph API explorer to set the flag
SkipOutOfScopeDeletions that controls the processing of accounts that go out of scope.
If SkipOutOfScopeDeletions is set to 0 (false), then accounts that go out of scope will get disabled in the
target
If SkipOutOfScopeDeletions is set to 1 (true), then accounts that go out of scope will get not be disabled in the
target This flag is set at the Provisioning App level and can be configured using the Graph API.
As this configuration is widely used with the Workday to Active Directory user provisioning app, the steps below
include screenshots of the Workday application. However this can also be used with other provisioning apps.
Step 1: Retrieve your Provisioning App Service Principal ID (Object ID)

1. Launch the Azure portal, and navigate to the Properties section of your provisioning application. For e.g. if
you want to export your Workday to AD User Provisioning application mapping navigate to the Properties
section of that app.
2. In the Properties section of your provisioning app, copy the GUID value associated with the Object ID field.
This value is also called the ServicePrincipalId of your App and it will be used in Graph Explorer
operations.
Step 2: Sign into Microsoft Graph Explorer
1. Launch Microsoft Graph Explorer
2. Click on the "Sign-In with Microsoft" button and sign-in using Azure AD Global Admin or App Admin
credentials.
3. Upon successful sign-in, you will see the user account details in the left-hand pane.
Step 3: Get existing app credentials and connectivity details

In the Microsoft Graph Explorer, run the following GET query replacing [servicePrincipalId] with the
ServicePrincipalId extracted from the Step 1.
GET https://graph.microsoft.com/beta/servicePrincipals/[servicePrincipalId]/synchronization/jobs
Copy the Response into a text file. It will look like the JSON text shown below, with values highlighted in yellow
specific to your deployment. Add the lines highlighted in green to the end and update the Workday connection
password highlighted in blue.
Here is the JSON block to add to the mapping.
{
"key": "SkipOutOfScopeDeletions",
"value": "True"
}
Step 4: Update the secrets endpoint with the

SkipOutOfScopeDeletions flag
In the Graph Explorer, run the command below to update the secrets endpoint with the
SkipOutOfScopeDeletions flag.
In the URL below replace [servicePrincipalId] with the ServicePrincipalId extracted from the Step 1.
PUT https://graph.microsoft.com/beta/servicePrincipals/[servicePrincipalId]/synchronization/secrets
Copy the updated text from Step 3 into the "Request Body" and set the header "Content-Type" to "application/json"
in "Request Headers".
Click on “Run Query”.

You should get the output as "Success – Status Code 204".
Step 5: Verify that out of scope users don’t get disabled

You can test this flag results in expected behavior by updating your scoping rules to skip a specific user. In the
example below, we are excluding the employee with ID 21173 (who was earlier in scope) by adding a new scoping
rule:
In the next provisioning cycle, the Azure AD provisioning service will identify that the user 21173 has gone out of
scope and if the SkipOutOfScopeDeletions property is enabled, then the synchronization rule for that user will
display a message as shown below:
Check the status of user provisioning
The Azure AD provisioning service runs an initial provisioning cycle against the source system and target system,
followed by periodic incremental cycles. When you configure provisioning for an app, you can check the current
status of the provisioning service and see when a user will be able to access an app.
View the provisioning progress bar

On the Provisioning page for an app, you can view the status of the Azure AD provisioning service. The Current
Status section at the bottom of the page shows whether a provisioning cycle has started provisioning user
accounts. You can watch the progress of the cycle, see how many users and groups have been provisioned, and see
how many roles are created.
When you first configure automatic provisioning, the Current Status section at the bottom of the page shows the
status of the initial provisioning cycle. This section updates each time an incremental cycle runs. The following
details are shown:
The type of provisioning cycle (initial or incremental) that is currently running or was last completed.
A progress bar showing the percentage of the provisioning cycle that has completed. The percentage reflects
the count of pages provisioned. Note that each page could contain multiple users or groups, so the percentage
doesn't directly correlate to the number of users, groups, or roles provisioned.
A Refresh button you can use to keep the view updated.
The number of Users and Groups provisioned, and the number of roles created. During the initial cycle, the
Users number counts up by 1 when a user is created or updated, and it counts down by 1 when a user is
deleted. During an incremental cycle, user updates don’t affect the Users count; the number changes only when
users are created or deleted.
A View Audit Logs link, which opens the Azure AD audit logs for details about all operations run by the user
provisioning service, including provisioning status for individual users (see the Use audit logs section below ).
After a provisioning cycle is complete, the Statistics to date section shows the cumulative numbers of users and
groups that have been provisioned to date, along with the completion date and duration of the last cycle. The
Activity ID uniquely identifies the most recent provisioning cycle. The Job ID is a unique identifier for the
provisioning job, and is specific to the app in your tenant.
The provisioning progress can viewed in the Azure portal, in the Azure Active Directory > Enterprise Apps >
[application name] > Provisioning tab.
Use audit logs to check a user's provisioning status
To see the provisioning status for a selected user, consult the Audit logs in Azure AD. All operations run 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, and the user data that was read or written during each operation.
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 “[email protected]”, then search the audit logs for
“[email protected]” 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
For more information on how to read the audit logs in the Azure portal, see the provisioning reporting guide.
How long will it take to provision users?

When using automatic user provisioning with an application, Azure AD automatically provisions and updates user
accounts in an app based on things like user and group assignment at a regularly scheduled time interval, typically
every 40 minutes.
The time it takes for a given user to be provisioned depends mainly on whether your provisioning job is running
an initial sync or an incremental sync.
For initial syncs, the job time depends on many factors, including the number of users and groups in scope
for provisioning, and the total number of users and group in the source system. 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. A comprehensive list of factors that
affect initial sync performance are summarized later in this section.
For incremental syncs after the initial sync, job times tend to 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. The job time depends on the number of changes detected in
that provisioning cycle. If there are fewer than 5,000 user or group membership changes, the job can finish
within a single incremental provisioning 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 G Suite.
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 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 about 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.
Next steps
Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory
Tutorial: Reporting on automatic user account
provisioning
Azure Active Directory (Azure AD ) 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 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, G Suite, 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 portal

To get provisioning report information for a given application, start by launching the Azure 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?
Export or import your provisioning configuration by
using Graph API
You can use Microsoft Graph API and Graph Explorer to export your User Provisioning attribute mappings and
schema to a JSON file and import it back into Azure AD. You can also use the steps captured here to create a
backup of your provisioning configuration.
Step 1: Retrieve your Provisioning App Service Principal ID (Object ID)

1. Launch the Azure portal, and navigate to the Properties section of your provisioning application. For e.g. if
you want to export your Workday to AD User Provisioning application mapping navigate to the Properties
section of that app.
2. In the Properties section of your provisioning app, copy the GUID value associated with the Object ID field.
This value is also called the ServicePrincipalId of your App and it will be used in Graph Explorer
operations.
Step 2: Sign into Microsoft Graph Explorer

1. Launch Microsoft Graph Explorer
2. Click on the "Sign-In with Microsoft" button and sign-in using Azure AD Global Admin or App Admin
credentials.
3. Upon successful sign-in, you will see the user account details in the left-hand pane.
Step 3: Retrieve the Provisioning Job ID of the Provisioning App

In the Microsoft Graph Explorer, run the following GET query replacing [servicePrincipalId] with the
ServicePrincipalId extracted from the Step 1.
GET https://graph.microsoft.com/beta/servicePrincipals/[servicePrincipalId]/synchronization/jobs
You will get a response as shown below. Copy the "id attribute" present in the response. This value is the
ProvisioningJobId and will be used to retrieve the underlying schema metadata.
Step 4: Download the Provisioning Schema

In the Microsoft Graph Explorer, run the following GET query, replacing [servicePrincipalId] and
[ProvisioningJobId] with the ServicePrincipalId and the ProvisioningJobId retrieved in the previous steps.
GET
https://graph.microsoft.com/beta/servicePrincipals/[servicePrincipalId]/synchronization/jobs/[ProvisioningJobId
]/schema
Copy the JSON object from the response and save it to a file to create a backup of the schema.
Step 5: Import the Provisioning Schema

Cau t i on
Perform this step only if you need to modify the schema for configuration that cannot be changed using the Azure
portal or if you need to restore the configuration from a previously backed up file with valid and working schema.
In the Microsoft Graph Explorer, configure the following PUT query, replacing [servicePrincipalId] and
[ProvisioningJobId] with the ServicePrincipalId and the ProvisioningJobId retrieved in the previous steps.
PUT
https://graph.microsoft.com/beta/servicePrincipals/[servicePrincipalId]/synchronization/jobs/[ProvisioningJobId
]/schema
In the "Request Body" tab, copy the contents of the JSON schema file.
In the "Request Headers" tab, add the Content-Type header attribute with value “application/json”
Click on the "Run Query" button to import the new schema.

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.
Can’t save configuration due to app credentials not working

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
Sync an attribute from your on-premises Active
Directory to Azure AD for provisioning to an
application
When customizing attribute mappings for user provisioning, you might find that the attribute you want to map
doesn't appear in the Source attribute list. This article shows you how to add the missing attribute by
synchronizing it from your on-premises Active Directory (AD ) to Azure Active Directory (Azure AD ).
Azure AD must contain all the data required to create a user profile when provisioning user accounts from Azure
AD to a SaaS app. In some cases, to make the data available you might need synchronize attributes from your on-
premises AD to Azure AD. Azure AD Connect automatically synchronizes certain attributes to Azure AD, but not all
attributes. Furthermore, some attributes (such as SAMAccountName) that are synchronized by default might not
be exposed via the Azure AD Graph API. In these cases, you can use the Azure AD Connect directory extension
feature to synchronize the attribute to Azure AD. That way, the attribute will be visible to the Azure AD Graph API
and the Azure AD provisioning service.
If the data you need for provisioning is in Active Directory but isn't available for provisioning because of the
reasons described above, follow these steps.
Sync an attribute
1. Open the Azure AD Connect wizard, choose Tasks, and then choose Customize synchronization options.
2. Sign in as an Azure AD Global Administrator.

3. On the Optional Features page, select Directory extension attribute sync.
4. Select the attribute(s) you want to extend to Azure AD.
NOTE
The search under Available Attributes is case sensitive.
5. Finish the Azure AD Connect wizard and allow a full synchronization cycle to run. When the cycle is
complete, the schema is extended and the new values are synchronized between your on-premises AD and
Azure AD.
6. In the Azure portal, while you’re editing user attribute mappings, the Source attribute list will now contain
the added attribute in the format <attributename> (extension_<appID>_<attributename>) . Select the attribute
and map it to the target application for provisioning.
NOTE
The ability to provision reference attributes from on-premises AD, such as managedby or DN/DistinguishedName, is not
supported today. You can request this feature on User Voice.
Next steps
Define who is in scope for provisioning
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
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. Note that provisioning nested groups or Office
365 groups is not supported. 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
“[email protected]”, then search the audit logs for “[email protected]” 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

Below is a list of the general problem areas that you can drill into if you have an idea of where to start.
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 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.
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 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.
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”. 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
AD Gallery application
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:
navigation menu.
8. To open the Add Assignment pane, click the Add button on top of the Users and Groups list.
list.
you have selected.
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.
8. To open the Add Assignment pane, click the Add button on top of the Users and Groups list.
list.
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
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 you to configure DNS allow lists, you can allow 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.
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 an
application 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
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
Secure access to on-premises APIs with Azure AD
Application Proxy
You may have business logic APIs running on-premises, or hosted on virtual machines in the cloud. Your native
Android, iOS, Mac, or Windows apps need to interact with the API endpoints to use data or provide user
interaction. Azure AD Application Proxy and the Azure Active Directory Authentication Libraries (ADAL ) let your
native apps securely access your on-premises APIs. Azure Active Directory Application Proxy is a faster and more
secure solution than opening firewall ports and controlling authentication and authorization at the app layer.
This article walks you through setting up an Azure AD Application Proxy solution for hosting a web API service
that native apps can access.
Overview
The following diagram shows a traditional way to publish on-premises APIs. This approach requires opening
incoming ports 80 and 443.
The following diagram shows how you can use Azure AD Application Proxy to securely publish APIs without
opening any incoming ports:
The Azure AD Application Proxy forms the backbone of the solution, working as a public endpoint for API access,
and providing authentication and authorization. You can access your APIs from a vast array of platforms by using
the ADAL libraries.
Since Azure AD Application Proxy authentication and authorization are built on top of Azure AD, you can use
Azure AD Conditional Access to ensure only trusted devices can access APIs published through Application Proxy.
Use Azure AD Join or Azure AD Hybrid Joined for desktops, and Intune Managed for devices. You can also take
advantage of Azure Active Directory Premium features like Azure Multi-Factor Authentication, and the machine
learning-backed security of Azure Identity Protection.
Prerequisites
To follow this walkthrough, you need:
Admin access to an Azure directory, with an account that can create and register apps
The sample web API and native client apps from https://github.com/jeevanbisht/API-NativeApp-ADAL -
SampleApp
Publish the API through Application Proxy

To publish an API outside of your intranet through Application Proxy, you follow the same pattern as for publishing
web apps. For more information, see Tutorial: Add an on-premises application for remote access through
Application Proxy in Azure Active Directory.
To publish the SecretAPI web API through Application Proxy:
1. Build and publish the sample SecretAPI project as an ASP.NET web app on your local computer or intranet.
Make sure you can access the web app locally.
2. In the Azure portal, select Azure Active Directory in the left navigation. Then, on the Overview page,
select Enterprise applications.
3. At the top of the Enterprise applications - All applications page, select New application.
4. On the Add an application page, under Add your own app, select On-premises application.
5. If you don't have an Application Proxy Connector installed, you'll be prompted to install it. Select Download
Application Proxy Connector to download and install the connector.
6. Once you've installed the Application Proxy Connector, on the Add your own on-premises application
page:
a. Enter SecretAPI next to Name.
b. Enter the URL you use to access the API from within your intranet next to Internal Url.
c. Make sure Pre-Authentication is set to Azure Active Directory.
d. Select Add at the top of the page, and wait for the app to be created.
7. On the Enterprise applications - All applications page, select the SecretAPI app.
8. On the SecretAPI - Overview page, select Properties in the left navigation.
9. You don't want APIs to be available to end users in the MyApps panel, so set Visible to users to No at the
bottom of the Properties page, and then select Save.
You've published your web API through Azure AD Application Proxy. Now, add users who can access the app.
1. On the SecretAPI - Overview page, select Users and groups in the left navigation.
2. On the Users and groups page, select Add user.
3. On the Add assignment page, select Users and groups.
4. On the Users and groups page, search for and select users who can access the app, including at least
yourself. After selecting all users, select Select.
5. Back on the Add Assignment page, select Assign.
NOTE
APIs that use Integrated Windows Authentication might require additional steps.
Register the native app and grant access to the API

Native apps are programs developed to use on a particular platform or device. Before your native app can connect
and access an API, you must register it in Azure AD. The following steps show how to register a native app and
give it access to the web API you published through Application Proxy.
To register the AppProxyNativeAppSample native app:
1. On the Azure Active Directory Overview page, select App registrations, and at the top of the App
registrations pane, select New registration.
2. On the Register an application page:
a. Under Name, enter AppProxyNativeAppSample.
b. Under Supported account types, select Accounts in any organizational directory and
personal Microsoft accounts.
c. Under Redirect URL, drop down and select Public client (mobile & desktop), and then enter
https://appproxynativeapp.
d. Select Register, and wait for the app to be successfully registered.
You've now registered the AppProxyNativeAppSample app in Azure Active Directory. To give your native app
access to the SecretAPI web API:
1. On the Azure Active Directory Overview > App Registrations page, select the
AppProxyNativeAppSample app.
2. On the AppProxyNativeAppSample page, select API permissions in the left navigation.
3. On the API permissions page, select Add a permission.
4. On the first Request API permissions page, select the APIs my organization uses tab, and then search
for and select SecretAPI.
5. On the next Request API permissions page, select the check box next to user_impersonation, and then
select Add permissions.
6. Back on the API permissions page, you can select Grant admin consent for Contoso to prevent other
users from having to individually consent to the app.
Configure the native app code

The last step is to configure the native app. The following snippet from the Form1.cs file in the NativeClient sample
app causes the ADAL library to acquire the token for requesting the API call, and attach it as bearer to the app
header.
AuthenticationResult result = null;

HttpClient httpClient = new HttpClient();
authContext = new AuthenticationContext(authority);
result = await authContext.AcquireTokenAsync(todoListResourceId, clientId, redirectUri, new
PlatformParameters(PromptBehavior.Auto));
// Append the token as bearer in the request header.

httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer",
result.AccessToken);
// Call the API.

HttpResponseMessage response = await httpClient.GetAsync(todoListBaseAddress + "/api/values/4");
// MessageBox.Show(response.RequestMessage.ToString());
string s = await response.Content.ReadAsStringAsync();
MessageBox.Show(s);
To configure the native app to connect to Azure Active Directory and call the API App Proxy, update the
placeholder values in the App.config file of the NativeClient sample app with values from Azure AD:
Paste the Directory (tenant) ID in the <add key="ida:Tenant" value="" /> field. You can find and copy this
value (a GUID ) from the Overview page of either of your apps.
Paste the AppProxyNativeAppSample Application (client) ID in the <add key="ida:ClientId" value="" />
field. You can find and copy this value (a GUID ) from the AppProxyNativeAppSample Overview page.
Paste the AppProxyNativeAppSample Redirect URI in the <add key="ida:RedirectUri" value="" /> field.
You can find and copy this value (a URI) from the AppProxyNativeAppSample Authentication page.
Paste the SecretAPI Application ID URI in the <add key="todo:TodoListResourceId" value="" /> field. You
can find and copy this value (a URI) from the SecretAPI Expose an API page.
Paste the SecretAPI Home Page URL in the <add key="todo:TodoListBaseAddress" value="" /> field. You can
find and copy this value (a URL ) from the SecretAPI Branding page.
After you configure the parameters, build and run the native app. When you select the Sign In button, the app lets
you sign in, and then displays a success screen to confirm that it successfully connected to the SecretAPI.
Next steps
Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory
Quickstart: Configure a client application to access web APIs
How to enable native client applications to interact with proxy applications
How to enable native client applications to interact
with proxy applications
You can use Azure Active Directory (Azure AD ) Application Proxy to publish web apps, but it also can be used to
publish native client applications that are configured with the Azure AD Authentication Library (ADAL ). Native
client applications differ from web apps because they're installed on a device, while web apps are accessed
through a browser.
To support native client applications, Application Proxy accepts Azure AD -issued tokens that are sent in the
header. The Application Proxy service does the authentication for the users. This solution doesn't use application
tokens for authentication.
To publish native applications, use the Azure AD Authentication Library, which takes care of authentication and
supports many client environments. 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 proxy 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: Register your native application

You now need to register your application in Azure AD, as follows:
1. Sign in to the Azure Active Directory portal. The Dashboard for the Azure Active Directory admin
center appears.
2. In the sidebar, select Azure Active Directory. The Azure Active Directory overview page appears.
3. In the Azure AD overview sidebar, select App registrations. The list of all app registrations appears.
4. Select New registration. The Register an application page appears.
5. In the Name heading, specify a user-facing display name for your application.
6. Under the Supported account types heading, select an access level using these guidelines:
To target only accounts that are internal to your organization, select Accounts in this organizational
directory only.
To target only business or educational customers, select Accounts in any organizational directory.
To target the widest set of Microsoft identities, select Accounts in any organizational directory and
personal Microsoft accounts.
7. In the Redirect URI heading, select Public client (mobile & desktop), and then type the redirect URI for
your application.
8. Select and read the Microsoft Platform Policies, and then select Register. An overview page for the new
application registration is created and displayed.
For more detailed information about creating a new application registration, see Integrating applications with
Step 3: Grant access to your proxy application

Now that you've registered your native application, you can give it access to other applications in your directory,
in this case to access the proxy application. To enable the native application to be exposed to the proxy application:
1. In the sidebar of the new application registration page, select API permissions. The API permissions page
for the new application registration appears.
2. Select Add a permission. The Request API permissions page appears.
3. Under the Select an API setting, select APIs my organization uses. A list appears, containing the
applications in your directory that expose APIs.
4. Type in the search box or scroll to find the proxy application that you published in Step 1: Publish your proxy
application, and then select the proxy application.
5. In the What type of permissions does your application require? heading, select the permission type. If
your native application needs to access the proxy application API as the signed-in user, choose Delegated
permissions. If your native application runs as a background service or daemon without a signed-in user,
choose Application permissions.
6. In the Select permissions heading, select the desired permission, and select Add permissions. The API
permissions page for your native application now shows the proxy application and permission API that you
added.
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 required info in the sample code can be found in the Azure AD portal, as follows:
INFO REQUIRED HOW TO FIND IT IN THE AZURE AD PORTAL
<Tenant ID> Azure Active Directory > Properties > Directory ID
<External Url of Proxy App> Enterprise applications > your proxy application >
Application proxy > External Url
<App ID of the Native app> Enterprise applications > your native application >
Properties > Application ID
<Redirect URI of the Native App> Azure Active Directory > App registrations > your native
application > Redirect URIs
<Proxy App API Url> Azure Active Directory > App registrations > your native
application > API permissions > API / PERMISSIONS
NAME
After you edit the ADAL with these parameters, your users can authenticate to native client applications even
when they're outside of the corporate network.
Next steps
For more information about the native application flow, see Native apps in Azure Active Directory.
Learn about setting up Single sign-on to applications in Azure Active Directory.
Set a custom home page for published apps by using
Azure AD Application Proxy
This article discusses how to configure an app to direct a user to a custom home page. When you publish an app
with Application Proxy, you set an internal URL, but sometimes that's not the page a user should see first. Set a
custom home page so that a user gets the right page when they access the app. A user will see the custom home
page that you set, regardless of whether they access the app from the Azure Active Directory Access Panel or the
Office 365 app launcher.
When a user launches 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 a custom
home page URL when you want an app user to land on a specific page within the app.
Here's one scenario that explains why your company would set a custom home page:
Inside your corporate network, a user goes to https://ExpenseApp/login/login.aspx to sign in and access your
app.
Because you have other assets (such as 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 an external user to
the sign-in page.
You want to set https://ExpenseApp-contoso.msappproxy.net/login/login.aspx as the home page URL instead, so
an external user sees the sign-in page first.
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:
The path that you specify must be a subdomain path of the root domain URL.
For example, if the root-domain URL is 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.
You can set the home page URL either through the Azure portal or by using PowerShell.
Change the home page in the Azure portal

To change the home page URL of your app through the Azure AD portal, follow these steps:
1. Sign in to the Azure portal as an administrator.
2. Select Azure Active Directory, and then App registrations. The list of registered apps appears.
3. Choose your app from the list. A page showing the details of the registered app appears.
4. Under Manage, select Branding.
5. Update the Home page URL with your new path.
6. Select Save.
Change the home page with PowerShell

To configure the home page of an app using PowerShell, you need to:
1. Install the Azure AD PowerShell module.
2. Find the ObjectId value of the app.
3. Update the app's home page URL using PowerShell commands.
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
You get the ObjectId of the app by searching for the app by its display name or 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. This example uses PowerShell to find the ObjectId by searching for the app with a display
name of SharePoint .
Get-AzureADApplication | Where-Object { $_.DisplayName -eq "SharePoint" } | Format-List DisplayName,

Homepage, ObjectId
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
Alternatively, you could just pull the list of all apps, search the list for the app with a specific display name or
home page, and copy the app's ObjectId once the app is found.
Get-AzureADApplication | Format-List DisplayName, Homepage, ObjectId
Update the home page URL

Create the home page URL, and update your app with that value. Continue using the same PowerShell window, or
if you're using a new PowerShell window, sign in to the Azure AD module again using Connect-AzureAD . Then
follow these steps:
1. Create a variable to hold the ObjectId value you copied in the previous section. (Replace the ObjectId value
used for in this SharePoint example with your app's ObjectId value.)
$objguid = "8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4"
2. Confirm that you have the correct app by running the following command. The output should be identical
to the output you saw in the previous section (Find the ObjectId of the app).
Get-AzureADApplication -ObjectId $objguid | Format-List DisplayName, Homepage, ObjectId
3. Create a blank application object to hold the changes that you want to make.
$appnew = New-Object "Microsoft.Open.AzureAD.Model.Application"
4. 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/"
5. Make the update of the home page.

Set-AzureADApplication -ObjectId $objguid -Homepage $homepage
6. To confirm that the change was successful, run the following command from step 2 again.
Get-AzureADApplication -ObjectId $objguid | Format-List DisplayName, Homepage, ObjectId
For our example, the output should now appear as follows:
DisplayName : SharePoint
Homepage : https://sharepoint-iddemo.msappproxy.net/hybrid/
ObjectId : 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
7. Restart the app to confirm that the home page appears as the first screen, as expected.
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
Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active
Directory
Redirect hardcoded links for apps published with
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.
NOTE
Link translation is not supported for hard-coded internal URLs generated through Javascript.
Option 1: Use the Managed Browser or Microsoft Edge – This solution is only applicable if you plan to
recommend or require that users access the application through the Intune Managed Browser or Microsoft Edge
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.
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 and Microsoft Edge Integration

You can use the Intune Managed Browser or Microsoft Edge 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.
To learn more, including how to configure this option, please see the MyApps Browser Extension documentation.
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. Using the MyApps Browser
Extension is preferred to the Link Translation Setting since it gives a more performant experience to users.
NOTE
If you are using option 2 or 3, only one of these should be enabled at a time.
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.
The complete list of HTML code tags that Application Proxy supports link translation for include:
a
audio
base
button
div
embed
form
frame
head
html
iframe
img
input
link
menuitem
meta
object
script
source
track
video
Additionally, within CSS the URL attribute is also translated.
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
To get started, make sure you've met these requirements.
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
Here are some considerations you should take into account for wildcard applications.
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
To learn more about Custom domains, see Working with custom domains in Azure AD Application Proxy.
To learn more about 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.
10. Check that the DNS record is configured correctly by using the nslookup command to see if your
external URL is reachable and the msapproxy.net domain shows up as an alias.
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.
The certificate must include the private key.
Certificates issued by your own public key infrastructure (PKI) can be used if the certificate chain is installed on
your client devices. Intune can be used to deploy these certificates to managed devices. For non-managed
devices these certificates must be manually installed.
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
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 the
Connector pulls the UPN, and the Service Principal Name (SPN ) 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. Select Use any authentication protocol.
6. 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. But in
some environments, due to corporate policies or application dependencies, organizations might have to use
alternate IDs for sign-in. In such cases, 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 ([email protected], [email protected]) and a single domain in the
cloud ([email protected]).
Have non-routable domain name internally ([email protected]) 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, [email protected] vs.
[email protected]
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, [email protected])
Alternate User Principal Name (for example, [email protected])
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 (Azure AD ) Application Proxy has partnered with PingAccess so that your Azure AD
customers can access more of your applications. PingAccess expands the existing Application Proxy offerings to
include single sign-on access to applications that use headers for authentication.
What's PingAccess for Azure AD?

With PingAccess for Azure AD, you can give users access and single sign-on (SSO ) 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. PingAccess sits in front of the
applications and translates the access token from Azure AD into a header. The application then receives the
authentication in the format it can read.
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 apps without
regard to their authentication type, so they’ll still balance loads automatically.
How do I get access?

Since this scenario comes from 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 for people to publish an application with this scenario for the first time. Besides detailing the
publishing steps, it guides you in getting started with both Application Proxy and PingAccess. If you’ve already
configured both services but want a refresher on the publishing steps, skip to the Add your application to Azure
AD with Application Proxy section.
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've enabled Application Proxy enabled and installed a connector already, you can skip this section and go to
Add your application 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 applications. For more detailed installation instructions, see Tutorial: Add an on-premises
application for remote access through Application Proxy in Azure Active Directory.
1. Sign in to the Azure Active Directory portal as an application administrator. The Azure Active Directory
admin center page appears.
2. Select Azure Active Directory > Application proxy > Download connector service. The
Application Proxy Connector Download page appears.
3. Follow the installation instructions.

Downloading the connector should automatically enable Application Proxy for your directory, but if not, you can
select Enable Application Proxy.
Add your application 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 application that you can use during the
PingAccess steps.
Publish your application
You'll first have to publish your application. This action involves:
Adding your on-premises application to Azure AD
Assigning a user for testing the application and choosing header-based SSO
Setting up the application's redirect URL
Granting permissions for users and other applications to use your on-premises application
To publish your own on-premises application:
1. If you didn't in the last section, sign in to the Azure Active Directory portal as an application administrator.
2. Select Enterprise applications > New application > On-premises application. The Add your own
on-premises application page appears.
3. Fill out the required fields with information about your new application. Use the guidance below for the
settings.
NOTE
For a more detailed walkthrough of this step, see Add an on-premises app to Azure AD.
a. 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 application. Use this format:
https://<host name of your PingAccess server>:<port> . The port is 3000 by default, but you can
configure it in PingAccess.
WARNING
For this type of single sign-on, the internal URL must use https and can't use http .
b. Pre-authentication method: Choose Azure Active Directory.

c. Translate URL in Headers: Choose 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. For subsequent applications, the port will need to match the Listener you’ve configured in
PingAccess. Learn more about listeners in PingAccess.
4. Select Add. The overview page for the new application appears.
Now assign a user for application testing and choose header-based single sign-on:
1. From the application sidebar, select Users and groups > Add user > Users and groups (<Number>
Selected). A list of users and groups appears for you to choose from.
2. Select a user for application testing, and select Select. Make sure this test account has access to the on-
3. Select Assign.
4. From the application sidebar, select Single sign-on > Header-based.
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.
5. Select Save.
Then make sure your redirect URL is set to your external URL:
1. From the Azure Active Directory admin center sidebar, select Azure Active Directory > App
registrations. A list of applications appears.
2. Select your application.
3. Select the link next to Redirect URIs, showing the number of redirect URIs set up for web and public clients.
The <application name> - Authentication page appears.
4. Check whether the external URL that you assigned to your application earlier is in the Redirect URIs list. If it
isn't, add the external URL now, using a redirect URI type of Web, and select Save.
Finally, set up your on-premises application so that users have read access and other applications have read/write
access:
1. From the App registrations sidebar for your application, select API permissions > Add a permission >
Microsoft APIs > Microsoft Graph. The Request API permissions page for Microsoft Graph appears,
which contains the APIs for Windows Azure Active Directory.
2. Select Delegated permissions > User > User.Read.

3. Select Application permissions > Application > Application.ReadWrite.All.
4. Select Add permissions.
5. In the API permissions page, select Grant admin consent for <your directory name>.
Collect information for the PingAccess steps
You need to collect these three pieces of information (all GUIDs) to set up your application with PingAccess:
NAME OF AZURE AD FIELD NAME OF PINGACCESS FIELD DATA FORMAT
Application (client) ID Client ID GUID
Directory (tenant) ID Issuer GUID
PingAccess key Client Secret Random string
To collect this information:

1. From the Azure Active Directory admin center sidebar, select Azure Active Directory > App
registrations. A list of applications appears.
2. Select your application. The App registrations page for your application appears.
3. Next to the Application (client) ID value, select the Copy to clipboard icon, then copy and save it. You
specify this value later as PingAccess's client ID.
4. Next the Directory (tenant) ID value, also select Copy to clipboard, then copy and save it. You specify
this value later as PingAccess's issuer.
5. From the sidebar of the App registrations for your application, select Certificates and secrets > New
client secret. The Add a client secret page appears.
6. In Description, type PingAccess key .
7. Under Expires, choose how to set the PingAccess key: In 1 year, In 2 years, or Never.
8. Select Add. The PingAccess key appears in the table of client secrets, with a random string that autofills in
the VALUE field.
9. Next to the PingAccess key's VALUE field, select the Copy to clipboard icon, then copy and save it. You
specify this value later as PingAccess's client secret.
Update GraphAPI to send custom fields (optional)
If you need a custom claim that sends other tokens within the access_token consumed by PingAccess, set the
acceptMappedClaims application field to True . You can use Graph Explorer or the Azure AD portal's application
manifest to make this change.
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 Active Directory portal to update the acceptMappedClaims field:
1. Sign in to the Azure Active Directory portal as an application administrator.
2. Select Azure Active Directory > App registrations. A list of applications appears.
3. Select your application.
4. From the sidebar of the App registrations page for your application, select Manifest. The manifest JSON
code for your application's registration appears.
5. Search for the acceptMappedClaims field, and change the value to True .
6. Select Save.
Use of optional claims (optional)
Optional claims allows you to add standard-but-not-included-by-default claims that every user and tenant has.
You can configure optional claims for your application by modifying the application manifest. For more info, see
the Understanding the Azure AD application manifest article
Example to include email address into the access_token that PingAccess will consume:
"optionalClaims": {
"idToken": [],
"accessToken": [
{
"name": "email",
"source": null,
"essential": false,
"additionalProperties": []
}
],
"saml2Token": []
},
Use of claims mapping policy (optional)

Claims Mapping Policy (preview ) for attributes which do not exist in AzureAD. Claims mapping allows you to
migrate old on-prem apps to the cloud by adding additional custom claims that are backed by your ADFS or user
objects
To make your application use a custom claim and include additional fields, be sure you've also created a custom
claims mapping policy and assigned it to the application.
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.
You can do policy definition and assignment through PowerShell, Azure AD Graph Explorer, or Microsoft Graph. If you're
doing them in PowerShell, you may need to first use New-AzureADPolicy and then assign it to the application with
Add-AzureADServicePrincipalPolicy . For more information, see Claims mapping policy assignment.
Example:
$pol = New-AzureADPolicy -Definition @('{"ClaimsMappingPolicy":{"Version":1,"IncludeBasicClaimSet":"true",

"ClaimsSchema": [{"Source":"user","ID":"employeeid","JwtClaimType":"employeeid"}]}}') -DisplayName
"AdditionalClaims" -Type "ClaimsMappingPolicy"
Add-AzureADServicePrincipalPolicy -Id "<<The object Id of the Enterprise Application you published in the
previous step, which requires this claim>>" -RefObjectId $pol.Id
Enable PingAccess to use custom claims

Enabling PingAccess to use custom claims is optional, but required if you expect the application to consume
additional claims.
When you will configure PingAccess in the following step, the Web Session you will create (Settings->Access-
>Web Sessions) must have Request Profile deselected and Refresh User Attributes set to No
Download PingAccess and configure your application

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. Follow the
instructions in Configure PingAccess for Azure AD to protect applications published using Microsoft Azure AD
Application Proxy on the Ping Identity web site.
Those steps help you install PingAccess and set up a PingAccess account (if you don't already have one). Then, to
create an Azure AD OpenID Connect (OIDC ) connection, you set up a token provider with the Directory
(tenant) ID value that you copied from the Azure AD portal. Next, to create a web session on PingAccess, you
use the Application (client) ID and PingAccess key values. After that, you can set up identity mapping and
create a virtual host, site, and application.
Test your application
When you've completed all these steps, your application should be up and running. To test it, open a browser and
navigate to the external URL that you created when you published the application in Azure. Sign in with the test
account that you assigned to the application.
Next steps
Configure PingAccess for Azure AD to protect applications published using Microsoft Azure AD Application
Proxy
Single sign-on to applications in Azure Active Directory
Troubleshoot Application Proxy problems and error messages
SAML single sign-on for on-premises applications
with Application Proxy
You can provide single sign-on (SSO ) to on-premises applications that are secured with SAML authentication and
provide remote access to these applications through Application Proxy. With SAML single sign-on, Azure Active
Directory (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. You can also map users
to specific application roles based on rules you define in your SAML claims. By enabling Application Proxy in
addition to SAML SSO, your users will have external access to the application and a seamless SSO experience.
The applications must be able to consume SAML tokens issued by Azure Active Directory. This configuration
doesn't apply to applications using an on-premises identity provider. For these scenarios, we recommend
reviewing Resources for migrating applications to Azure AD.
SAML SSO with Application Proxy also works with the SAML token encryption feature. For more info, see
Configure Azure AD SAML token encryption.
The protocol diagrams below describe the single sign-on sequence for both a service provider-initiated (SP -
initiated) flow and an identity provider-initiated (IdP -initiated) flow. Application Proxy works with SAML SSO by
caching the SAML request and response to and from the on-premises application.
Create an application and set up SAML SSO
1. In the Azure portal, select Azure Active Directory > Enterprise applications and select New
application.
2. Under Add your own app, select Non-gallery application.
3. Enter the display name for your new application, and then select Add.
4. On the app's Overview page, select Single sign-on.
5. Select SAML as the single sign-on method.
6. First set up SAML SSO to work while on the corporate network. In the Set up Single Sign-On with
SAML page, go to the Basic SAML Configuration heading and select its Edit icon (a pencil). Follow the
steps in Enter basic SAML configuration to configure SAML -based authentication for the application.
7. Add at least one user to the application and make sure the test account has access to the application. While
connected to the corporate network, use the test account to see if you have single sign-on to the
application.
NOTE
After you set up Application Proxy, you'll come back and update the SAML Reply URL.
Publish the on-premises application with Application Proxy

Before you can provide SSO for on-premises applications, you need to enable Application Proxy and install a
connector. See the tutorial Add an on-premises application for remote access through Application Proxy in Azure
AD to learn how to prepare your on-premises environment, install and register a connector, and test the connector.
Then follow these steps to publish your new application with Application Proxy. For other settings not mentioned
below, refer to the Add an on-premises app to Azure AD section in the tutorial.
1. With the application still open in the Azure portal, select Application Proxy. Provide the Internal URL for
the application. If you're using a custom domain, you also need to upload the SSL certificate for your
application.
NOTE
As a best practice, use custom domains whenever possible for an optimized user experience. Learn more about
Working with custom domains in Azure AD Application Proxy.
2. Select Azure Active Directory as the Pre Authentication method for your application.
3. Copy the External URL for the application. You'll need this URL to complete the SAML configuration.
4. Using the test account, try to open the application with the External URL to validate that Application Proxy
is set up correctly. If there are issues, see Troubleshoot Application Proxy problems and error messages.
Update the SAML configuration

1. With the application still open in the Azure portal, select Single sign-on.
2. In the Set up Single Sign-On with SAML page, go to the Basic SAML Configuration heading and
select its Edit icon (a pencil). The External URL you configured in Application Proxy automatically
populates the Identifier, Reply URL, and Logout URL fields. Don't edit these URLs because they are
required for Application Proxy to work correctly.
3. Edit the Reply URL configured earlier so that its domain is reachable by Application Proxy. For example, if
your External URL is https://contosotravel-f128.msappproxy.net and the original Reply URL was
https://contosotravel.com/acs , you'll need to update the original Reply URL to
https://contosotravel-f128.msappproxy.net/acs .
4. Select the checkbox next to the updated Reply URL to mark it as the default.
If the required Reply URL is already listed, mark this Reply URL as default and delete the
previously configured Reply URL.
For an SP -initiated flow, make sure the back-end application specifies the correct Reply URL or
Assertion Consumer Service URL for receiving the authentication token.
NOTE
If the back-end application expects the Reply URL to be the Internal URL, you'll need to either use custom domains
to have matching internal and external URLS or install the My Apps secure sign-in extension on users' devices. This
extension will automatically redirect to the appropriate Application Proxy Service. To install the extension, see My
Apps secure sign-in extension.
Test your app

When you've completed all these steps, your app should be up and running. To test the app:
1. Open a browser and navigate to the External URL that you created when you published the app.
2. Sign in with the test account that you assigned to the app. You should be able to load the application and have
SSO into the application.
Next steps
How does Azure AD Application Proxy provide single sign-on?
Enable remote access to Power BI Mobile with Azure
AD Application Proxy
This article discusses how to use Azure AD Application Proxy to enable the Power BI mobile app to connect to
Power BI Report Server (PBIRS ) and SQL Server Reporting Services (SSRS ) 2016 and later. Through this
integration, users who are away from the corporate network can access their Power BI reports from the Power BI
mobile app and be protected by Azure AD authentication. This protection includes security benefits such as
conditional access and multi-factor authentication.
Prerequisites
This article assumes you've already deployed Report Services andenabled Application Proxy.
Enabling Application Proxy requires installing a connector on a Windows server and completing the
prerequisites so that the connector can communicate with Azure AD services.
When publishing Power BI, we recommended you use the same internal and external domains. To learn more
about custom domains, see Working with custom domains in Application Proxy.
This integration is available for the Power BI Mobile iOS and Android application.
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 ). When configured,
KCD allows the Application Proxy connector to obtain a Windows token for a user, even if the user hasn’t signed
into Windows directly. To learn more about KCD, seeKerberos Constrained Delegation Overview and Kerberos
Constrained Delegation for single sign-on to your apps with Application Proxy.
There isn’t much to configure on the Reporting Services side. Just be sure to have a valid Service Principal Name
(SPN ) to enable the proper Kerberos authentication to occur. Also make sure the Reporting Services server is
enabled for Negotiate authentication.
To set up KCD for Reporting services, continue with the following steps.
Configure the Service Principal Name (SPN )
The SPN is a unique identifier for a service that uses Kerberos authentication. You'll need to make sure you have a
proper HTTP SPN present for your report server. For information on how to configure the proper Service Principal
Name (SPN ) for your report server, seeRegister a Service Principal Name (SPN ) for a Report Server. You can
verify that the SPN was added by running the Setspn command with the -L option. To learn more about this
command, seeSetspn.
Enable Negotiate authentication
To enable a report server to use Kerberos authentication, configure the Authentication Type of the report server to
be RSWindowsNegotiate. Configure this setting using the rsreportserver.config file.
<AuthenticationTypes>
<RSWindowsNegotiate />
<RSWindowsKerberos />
<RSWindowsNTLM />
</AuthenticationTypes>
For more information, seeModify a Reporting Services Configuration FileandConfigure Windows Authentication
on a Report Server.
Ensure the Connector is trusted for delegation to the SPN added to the Reporting Services application pool
account
Configure KCD so that the Azure AD Application Proxy service can delegate user identities to the Reporting
Services 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 Reporting Services in this case.
To configure KCD, repeat the following steps for each connector machine:
1. Sign in to a domain controller as a domain administrator, and then openActive Directory Users and
Computers.
2. Find the computer that the connector is running on.
3. Double-click the computer, and then select theDelegationtab.
4. Set the delegation settings toTrust this computer for delegation to the specified services only. Then,
selectUse any authentication protocol.
5. Select Add, and then select Users or Computers.
6. Enter the service account that you're using for Reporting Services. This is the account you added the SPN to
within the Reporting Services configuration.
7. ClickOK. To save the changes, clickOKagain.
For more information, see Kerberos Constrained Delegation for single sign-on to your apps with Application Proxy.
Step 2: Publish Report Services through Azure AD Application Proxy

Now you're ready to configure Azure AD Application Proxy.
1. Publish Report Services through Application Proxy with the following settings. For step-by-step instructions
on how to publish an application through Application Proxy, seePublishing applications using Azure AD
Application Proxy.
Internal URL: Enter the URL to the Report Server that the connector can reach in the corporate
network. Make sure this URL is reachable from the server the connector is installed on. A best
practice is using a top-level domain such as https://servername/ to avoid issues with subpaths (for
example, https://servername/reports/ and https://servername/reportserver/ ) not published through
Application Proxy.
NOTE
We recommend using a secure HTTPS connection to the Report Server. See Configure SSL connections on a
native mode report server for information how to.
External URL: Enter the public URL the Power BI mobile app will connect to. For example, it may
look like https://reports.contoso.com if a custom domain is used. To use a custom domain, upload a
certificate for the domain, and point a DNS record to the default msappproxy.net domain for your
application. For detailed steps, see Working with custom domains in Azure AD Application Proxy.
Pre-authentication Method: Azure Active Directory
2. Once your app is published, configure the single sign-on settings with the following steps:
a. On the application page in the portal, selectSingle sign-on.
b. For Single Sign-on Mode, selectIntegrated Windows Authentication.
c. Set Internal Application SPN to the value that you set earlier.
d. Choose the Delegated Login Identityfor the connector to use on behalf of your users. For more
information, seeWorking with different on-premises and cloud identities.
e. Click Save to save your changes.
To finish setting up your application, go to theUsers and groupssection and assign users to access this application.
Step 3: Modify the Reply URI's for the application

Before the Power BI mobile app can connect and access Report Services, you must configure the Application
Registration that was automatically created for you in step 2.
1. On the Azure Active Directory Overview page, select App registrations.
2. Under the All applications tab search for the application you created in step 2.
3. Select the application, then select Authentication.
4. Add the following Redirect URIs based on which platform you are using.
When configuring the app for Power BI Mobile iOS, add the following Redirect URIs of type Public Client
(Mobile & Desktop):
msauth://code/mspbi-adal%3a%2f%2fcom.microsoft.powerbimobile
msauth://code/mspbi-adalms%3a%2f%2fcom.microsoft.powerbimobilems
mspbi-adal://com.microsoft.powerbimobile
mspbi-adalms://com.microsoft.powerbimobilems
When configuring the app for Power BI Mobile Android, add the following Redirect URIs of type Public
Client (Mobile & Desktop):
urn:ietf:wg:oauth:2.0:oob
mspbi-adal://com.microsoft.powerbimobile
IMPORTANT
The Redirect URIs must be added for the application to work correctly. If you are configuring the app for both Power
BI Mobile iOS and Android, add the following Redirect URI of type Public Client (Mobile & Desktop) to the list of
Redirect URIs configured for iOS: urn:ietf:wg:oauth:2.0:oob .
Step 4: Connect from the Power BI Mobile App

1. In the Power BI mobile app, connect to your Reporting Services instance. To do this, enter theExternal
URLfor the application you published through Application Proxy.
2. Select Connect. You'll be directed to the Azure Active Directory sign in page.
3. Enter valid credentials for your user and selectSign in. You'll see the elements from your Reporting Services
server.
Step 5: Configure Intune policy for managed devices (optional)

NOTE
This functionality will not be available until 7/31/19.
You can use Microsoft Intune to manage the client apps that your company's workforce uses. Intune allows you to
use capabilities such as data encryption and additional access requirements. To learn more about app management
through Intune, see Intune App Management. To enable the Power BI mobile application to work with the Intune
policy, use the following steps.
1. Go to Azure Active Directoryand thenApp Registrations.
2. Select the application configured in Step 3 when registering your native client application.
3. On the application’s page, select API Permissions.
4. Click Add a permission.
5. Under APIs my organization uses, search for “Microsoft Mobile Application Management” and select it.
6. Add the DeviceManagementManagedApps.ReadWrite permission to the application
7. Click Grant admin consent to grant the permission access to the application.
8. Configure the Intune policy you want by referring to How to create and assign app protection policies.
Troubleshooting
If the application returns an error page after trying to load a report for more than a few minutes, you might need to
change the timeout setting. By default, Application Proxy supports applications that take up to 85 seconds to
respond to a request. To lengthen this setting to 180 seconds, select the back-end timeout to Long in the App
Proxy settings page for the application. For tips on how to create fast and reliable reports see Power BI Reports
Best Practices.
Next steps
Enable native client applications to interact with proxy applications
View on-premises report server reports and KPIs in the Power BI mobile apps
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.
For the Azure AD pre-authentication flow, users can only connect to resources published to them in the
RemoteApp and Desktops pane. Users can't connect to a desktop using the Connect to a remote PC
pane.
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. Select Azure Active Directory, and then App Registrations. Choose your app from the list.
5. Under Manage, select Branding.
6. 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.
NOTE
As a best practice, use custom domains whenever possible. With a custom domain, you can configure the same URL for
both the Internal URL and the External URL. Then, the same link can be used to access the application from either inside or
outside of your network. This configuration optimizes the experience for users and other applications that need to access
your application. Learn more about Working with custom domains in Azure AD Application Proxy.
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
Follow these 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 the most suitable option for your Active Directory forest
configuration. For example if you have a single AD domain in your forest, select On-premises SAM
account name (as shown below ), but if your users are not in the same domain as SharePoint and the
App Proxy Connector servers then select On-premises user principal name (not shown).
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 an application administrator.
2. Select Azure Active Directory > Enterprise applications.
3. Select Add at the top of the blade.
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.
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.
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.
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 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 following the Qlik Community
Articles:
Azure AD with Integrated Windows Authentication using a Kerberos Constrained Delegation with Qlik Sense
Qlik Sense integration with Azure AD Application Proxy
Next steps
Publish applications with Application Proxy
Working with Application Proxy connectors
Troubleshoot Application Proxy problems and error
messages
When troubleshooting Application Proxy issues, we recommend you start with reviewing the troubleshooting
flow, Debug Application Proxy Connector issues, to determine if Application Proxy connectors are configured
correctly. If you're still having trouble connecting to the application, follow the troubleshooting flow in Debug
Application Proxy application issues.
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. 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.
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'll probably get this
error. This error occurs when there is a networking error on
your system. Make sure that it's 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
proceed entered the wrong username or password. Try again.
Connector registration failed: Make sure you enabled You're 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're 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,
information found in either the request or implied by any if the Azure AD domain is contoso.com, the admin should
provided credentials and search by service principal URI has be [email protected].
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 isn't 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 domain. Your Connector is always installed for the directory
register the Connector. Error: 'The registration request was that owns the user’s domain. Make sure that the admin
denied.' account you're trying to sign in with has atleast application
administrator permissions to the Azure AD tenant.
The Connector was unable to connect to the service due to The connector is unable to connect to the Application Proxy
networking issues. The Connector tried to access the cloud service. This may happen if you have a firewall rule
following URL. blocking the connection. Make sure that you have allowed
access to the correct ports and URLS listed in Application
Proxy prerequisites.
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
permitted Kerberos authentication attempts to the backend Azure AD and the backend application server, or a problem
server. in time 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 There is a problem with the STS configuration. Fix the UPN
behalf of the user because there is no UPN in the edge claim configuration in the STS.
token or in the access cookie.
13019 - Azure AD cannot retrieve a Kerberos ticket on This event may indicate incorrect configuration between
behalf 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.
Verify that Azure AD and the backend application server are
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 This event may indicate incorrect configuration between
behalf of the user because the backend server SPN is not Azure AD and the domain controller server, or a problem in
defined. time and date configuration on both machines. The domain
controller declined the Kerberos ticket created by Azure AD.
Verify that Azure AD and the backend application server are
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
attempts with an HTTP 401 error. in time 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. 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 Your user may get this error when trying to access the app
authorized to access this application. Authorization failed. you published if they use Microsoft accounts instead of their
Make sure to 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 user 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 Your user may get this error when trying to access the app
authorized to access this application. Authorization failed. you published if they weren't explicitly assigned with a
Make sure that the user has a license for Azure Active Premium license by the subscriber’s administrator. Go to the
Directory Premium. subscriber’s Active Directory Licenses tab and make sure
that this user or user group is assigned a Premium license.
A server with the specified host name could not be found. Your user may get this error when trying to access the app
you published if the application's custom domain is not
configured correctly. Make sure you've uploaded a certificate
for the domain and configured the DNS record correctly by
following the steps in Working with custom domains in
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
Debug Application Proxy connector issues
This article helps you troubleshoot issues with Azure Active Directory (Azure AD ) Application Proxy connectors. If
you're using the Application Proxy service for remote access to an on-premises web application, but you're having
trouble connecting to the application, use this flowchart to debug connector issues.
Before you begin

This article assumes you have installed the Application Proxy connector and are having an issue. When
troubleshooting Application Proxy issues, we recommend you start with this troubleshooting flow to determine if
Application Proxy connectors are configured correctly. If you're still having trouble connecting to the application,
follow the troubleshooting flow in Debug Application Proxy application issues.
For more information about Application Proxy and using its connectors, see:
Remote access to on-premises applications through Application Proxy
Application Proxy connectors
Flowchart for connector issues

This flowchart walks you through the steps for debugging some of the more common connector issues. For
details about each step, see the table following the flowchart.
ACTION DESCRIPTION
ACTION DESCRIPTION
1 Find the connector group assigned to You probably have a connector installed
the app on multiple servers, in which case the
connectors should be assigned to
connector groups. To learn more about
connector groups, see Publish
applications on separate networks and
locations using connector groups.
2 Install the connector and assign a If you don't have a connector installed,
group see Install and register a connector.
If the connector isn't assigned to a
group, see Assign the connector to a
group.
If the application isn't assigned to a
connector group, see Assign the
application to a connector group.
3 Run a port test on the connector server On the connector server, run a port
test by using telnet or other port
testing tool to check if ports 443 and
80 are open.
4 Configure the domains and ports Make sure that your domains and ports
are configured correctly For the
connector to work properly, there are
certain ports that must be open and
URLs that your server must be able to
access.
5 Check if a back-end proxy is in use Check to see if the connectors are using
back-end proxy servers or bypassing
them. For details, see Troubleshoot
connector proxy problems and service
connectivity issues.
6 Update the connector and updater to If a back-end proxy is in use, you'll want
use the back-end proxy to make sure the connector is using the
same proxy. For details about
troubleshooting and configuring
connectors to work with proxy servers,
see Work with existing on-premises
proxy servers.
7 Load the app's internal URL on the On the connector server, load the app's
connector server internal URL.
8 Check internal network connectivity There's a connectivity issue in your

internal network that this debugging
flow is unable to diagnose. The
application must be accessible internally
for the connectors to work. You can
enable and view connector event logs
as described in Application Proxy
connectors.
ACTION DESCRIPTION
9 Lengthen the time-out value on the In the Additional Settings for your
back end application, change the Backend
Application Timeout setting to Long.
See Add an on-premises app to Azure
AD.
10 If issues persist, target specific flow Use the Debug Application Proxy
issues, review app and SSO debugging application issues troubleshooting flow.
flows
Next steps
Debug Application Proxy application issues
This article helps you troubleshoot issues with Azure Active Directory (Azure AD ) Application Proxy applications.
If you're using the Application Proxy service for remote access to an on-premises web application, but you're
having trouble connecting to the application, use this flowchart to debug application issues.
Before you begin

When troubleshooting Application Proxy issues, we recommend you start with the connectors. First, follow the
troubleshooting flow in Debug Application Proxy Connector issues to make sure Application Proxy connectors are
configured correctly. If you're still having issues, return to this article to troubleshoot the application.
For more information about Application Proxy, see:
Remote access to on-premises applications through Application Proxy
Flowchart for application issues

This flowchart walks you through the steps for debugging some of the more common issues with connecting to
the application. For details about each step, see the table following the flowchart.
ACTION DESCRIPTION
1 Open a browser, access the app, and Try using your credentials to sign in to
enter your credentials the app, and check for any user-related
errors, like This corporate app can't be
accessed.
ACTION DESCRIPTION
2 Verify user assignment to the app Make sure your user account has
permission to access the app from
inside the corporate network, and then
test signing in to the app by following
the steps in Test the application. If sign-
in issues persist, see How to
troubleshoot sign-in errors.
3 Open a browser and try to access the If an error appears immediately, check
app to see that Application Proxy is
configured correctly. For details about
specific error messages, see
problems and error messages.
4 Check your custom domain setup or If the page doesn't display at all, make
troubleshoot the error sure your custom domain is configured
correctly by reviewing Working with
custom domains.
If the page doesn't load and an error
message appears, troubleshoot the
error by referring to Troubleshoot
Application Proxy problems and error
messages.
If it takes longer than 20 seconds for an
error message to appear, there could be
connectivity issue. Go to the Debug
troubleshooting article.
5 If issues persist, go to connector There could be a connectivity issue

debugging between the proxy and the connector
or between the connector and the back
end. Go to the Debug Application Proxy
connectors troubleshooting article.
6 Publish all resources, check browser Make sure the publishing path includes
developer tools, and fix links all the necessary images, scripts, and
style sheets for your application. For
details, see Add an on-premises app to
Azure AD.
Use the browser's developer tools (F12
tools in Internet Explorer or Microsoft
Edge) and check for publishing issues as
described in Application page does not
display correctly.
Review options for resolving broken
links in Links on the page don't work.
7 Check for network latency If the page loads slowly, learn about
ways to minimize network latency in
Considerations for reducing latency.
8 See additional troubleshooting help If issues persist, find additional

troubleshooting articles in the
Application Proxy troubleshooting
documentation.
Next steps
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 [email protected]. 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 helps 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.
SAML single sign-on: 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. For information about setting up SAML single sign-on, see
SAML for single sign-on with Application Proxy.
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
Password vaulting for single sign-on with Application Proxy
Kerberos Constrained Delegation for single sign-on with Application Proxy
Header-based authentication for single sign-on with Application Proxy
SAML for single sign-on 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
using Azure AD Application Proxy.
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 too intrusive 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:
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 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 multi-
hop 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 allowed.
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 allowed.
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 open

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 at least an application 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". 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
Understand and solve Azure Active Directory
Application Proxy CORS issues
Cross-origin resource sharing (CORS ) can sometimes present challenges for the apps and APIs you publish
through the Azure Active Directory Application Proxy. This article discusses Azure AD Application Proxy CORS
issues and solutions.
Browser security usually prevents a web page from making AJAX requests to another domain. This restriction is
called the same-origin policy, and prevents a malicious site from reading sensitive data from another site. However,
sometimes you might want to let other sites call your web API. CORS is a W3C standard that lets a server relax the
same-origin policy and allow some cross-origin requests while rejecting others.
Understand and identify CORS issues

Two URLs have the same origin if they have identical schemes, hosts, and ports ( RFC 6454), such as:
http://contoso.com/foo.html
http://contoso.com/bar.html
The following URLs have different origins than the previous two:
http://contoso.net - Different domain
http://contoso.com:9000/foo.html - Different port
https://contoso.com/foo.html - Different scheme
http://www.contoso.com/foo.html - Different subdomain
Same-origin policy prevents apps from accessing resources from other origins unless they use the correct access
control headers. If the CORS headers are absent or incorrect, cross-origin requests fail.
You can identify CORS issues by using browser debug tools:
1. Launch the browser and browse to the web app.
2. Press F12 to bring up the debug console.
3. Try to reproduce the transaction, and review the console message. A CORS violation produces a console error
about origin.
In the following screenshot, selecting the Try It button caused a CORS error message that https://corswebclient-
contoso.msappproxy.net wasn't found in the Access-Control-Allow -Origin header.
CORS challenges with Application Proxy
The following example shows a typical Azure AD Application Proxy CORS scenario. The internal server hosts a
CORSWebService web API controller, and a CORSWebClient that calls CORSWebService. There's an AJAX
request from CORSWebClient to CORSWebService.
The CORSWebClient app works when you host it on-premises, but either fails to load or errors out when published
through Azure AD Application Proxy. If you published the CORSWebClient and CORSWebService apps separately
as different apps through Application Proxy, the two apps are hosted at different domains. An AJAX request from
CORSWebClient to CORSWebService is a cross-origin request, and it fails.
Solutions for Application Proxy CORS issues
You can resolve the preceding CORS issue in any one of several ways.
Option 1: Set up a custom domain
Use an Azure AD Application Proxy custom domain to publish from the same origin, without having to make any
changes to app origins, code, or headers.
Option 2: Publish the parent directory
Publish the parent directory of both apps. This solution works especially well if you have only two apps on the web
server. Instead of publishing each app separately, you can publish the common parent directory, which results in
the same origin.
The following examples show the portal Azure AD Application Proxy page for the CORSWebClient app. When the
Internal URL is set to contoso.com/CORSWebClient, the app can't make successful requests to the
contoso.com/CORSWebService directory, because they're cross-origin.
Instead, set the Internal URL to publish the parent directory, which includes both the CORSWebClient and
CORSWebService directories:
The resulting app URLs effectively resolve the CORS issue:
https://corswebclient-contoso.msappproxy.net/CORSWebService
https://corswebclient-contoso.msappproxy.net/CORSWebClient
Option 3: Update HTTP headers
Add a custom HTTP response header on the web service to match the origin request. For websites running in
Internet Information Services (IIS ), use IIS Manager to modify the header:
This modification doesn't require any code changes. You can verify it in the Fiddler traces:
Post the Header Addition
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/plain; charset=utf-8
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5 Microsoft-HTTPAPI/2.0
Access-Control-Allow-Origin: https://corswebclient-contoso.msappproxy.net
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Content-Length: 17
Option 4: Modify the app
You can change your app to support CORS by adding the Access-Control-Allow -Origin header, with appropriate
values. The way to add the header depends on the app's code language. Changing the code is the least
recommended option, because it requires the most effort.
Option 5: Extend the lifetime of the access token
Some CORS issues can't be resolved, such as when your app redirects to login.microsoftonline.com to authenticate,
and the access token expires. The CORS call then fails. A workaround for this scenario is to extend the lifetime of
the access token, to prevent it from expiring during a user’s session. For more information about how to do this,
see Configurable token lifetimes in Azure AD.
See also
Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory
Plan an Azure AD Application Proxy deployment
Remote access to on-premises applications through Azure Active Directory Application Proxy
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/l
ibrary/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 and replacementValue are provided:
The function applies the regexPattern to the source string and you can use the regex group names to
construct the string for replacementValue
When regexPattern, regexGroupName, replacementValue are provided:
The function applies the regexPattern to the source string and replaces all values matching
regexGroupName with replacementValue
When regexPattern, regexGroupName, replacementAttributeName are provided:
If source has no value, source is returned
If source has a value, the function applies the regexPattern to the source string and replaces all values
matching regexGroupName with the value associated with replacementAttributeName
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
replacementPropertyNam
e is used, pattern to extract
value from
e.
regexGroupName Optional String Name of the group inside

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

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

me used for replacement 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 cannot be applied to attributes that have a matching precedence.
3. 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): "[email protected]"
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): "[email protected]"
OUTPUT: "[email protected]"
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: "[email protected]"
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: "[email protected]" if UPN value of [email protected] doesn't already exist in the
directory
OUTPUT: "[email protected]" if UPN value of [email protected] already exists in the directory
OUTPUT: "[email protected]" if the above two UPN values already exist in the directory
Related Articles
Customizing Attribute Mappings for User Provisioning
Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to applications
Account Provisioning Notifications
Azure AD Connect Provisioning Agent: Version
release history
This article lists the versions and features of Azure AD Connect Provisioning Agent that have been released. The
Azure AD team regularly updates the Provisioning Agent with new features and functionality. Provisioning Agents
are updated automatically when a new version is released.
We recommend enabling auto update for your agents to ensure that you have the latest features and bug fixes.
Microsoft provides direct support for the latest agent version and one version before.
1.1.67.0
Release status
September 9, 2019: Released for auto update
New features and improvements
Ability to configure additional tracing and logging for debugging provisioning agent issues
Ability to fetch only those AD attributes that are configured in the mapping to improve performance of sync
Fixed issues
Fixed a bug where-in the agent went into an unresponsive state if there were issues with AD connection failures
Fixed a bug that caused issues when binary data was read from Active Directory
Fixed a bug where-in the agent failed to renew trust with the cloud Hybrid Identity Service
1.1.30.0
Release status
Jan 23, 2019: Released for download
Revamped Provisioning Agent & Connector architecture for better performance, stability and reliability
Simplified Provisioning Agent configuration using UI-driven Installation Wizard
Added support for automatic agent updates
Azure AD Application Proxy: Version release history
This article lists the versions and features of Azure Active Directory (Azure AD ) Application Proxy that have been
released. The Azure AD team regularly updates Application Proxy with new features and functionality. Application
Proxy connectors are updated automatically when a new version is released.
We recommend making sure that auto-updates are enabled for your connectors to ensure you have the latest
features and bug fixes. Microsoft provides direct support for the lastest connector version and one version before.
Here is a list of related resources:
RESOURCE DETAILS
How to enable Application Proxy Pre-requisites for enabling Application Proxy and installing
and registering a connector are described in this tutorial.
Understand Azure AD Application Proxy connectors Find out more about connector management and how
connectors auto-upgrade.
Azure AD Application Proxy Connector Download Download the latest connector.
1.5.612.0
Release status
September 20, 2018: Released for download
Added WebSocket support for the QlikSense application. To learn more about how to integrate QlikSense with
Application Proxy, see this walkthrough.
Improved the installation wizard to make it easier to configure an outbound proxy.
Set TLS 1.2 as the default protocol for connectors.
Added a new End-User License Agreement (EULA).
Fixed issues
Fixed a bug that caused some memory leaks in the connector.
Updated the Azure Service Bus version, which includes a bug fix for connector timeout issues.
1.5.402.0
Release status
January 19, 2018: Released for download
Fixed issues
Added support for custom domains that need domain translation in the cookie.
1.5.132.0
Release status
May 25, 2017: Released for download
Improved control over connectors' outbound connection limits.
1.5.36.0
Release status
April 15, 2017: Released for download
Simplified onboarding and management with fewer required ports. Application Proxy now requires opening
only two standard outbound ports: 443 and 80. Application Proxy continues to use only outbound connections,
so you still don't need any components in a DMZ. For details, see ourconfiguration documentation.
If supported by your external proxy or firewall, you can now open your network by DNS instead of IP range.
Application Proxy services require connections to *.msappproxy.net and *.servicebus.windows.net only.
Earlier versions
If you're using an Application Proxy connector version earlier than 1.5.36.0, update to the latest version to ensure
you have the latest fully supported features.
Next steps
Learn more about Remote access to on-premises applications through Azure AD Application Proxy.
To start using Application Proxy, see Tutorial: Add an on-premises application for remote access through
Application Proxy.

APPs Management Azure

Uploaded by

Copyright:

Available Formats

APPs Management Azure

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

APPs Management Azure

Uploaded by

Copyright:

Available Formats

Contents

Application management documentation

Why manage applications with a cloud solution?

What types of applications can I integrate with Azure AD?

Manage risk with Conditional Access policies

Improve productivity with single sign-on

Address governance and compliance

This feature lets you:

Why use automated provisioning?

How does automatic provisioning work?

What applications and systems can I use with Azure AD automatic

Connecting applications that support SCIM 2.0

How do I set up automatic provisioning to an application?

What happens during provisioning?

How long will it take to provision users?

How can I tell if users are being provisioned properly?

How do I troubleshoot issues with user provisioning?

Frequently asked questions

Remote access in the past

The future of remote access

Endpoint The endpoint is a URL or an end-user portal. Users can reach

Azure AD Azure AD performs the authentication using the tenant

Active Directory (AD) Active Directory runs on-premises to perform authentication

On-premises application Finally, the user is able to access an on-premises application.

Other use cases

Before you begin

Add an application to your Azure AD tenant

Find your Azure AD tenant application

Configure user sign-in properties

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

Search for a tenant application

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

443 All outbound communication with the Application Proxy

URL HOW IT'S USED

*.msappproxy.net Communication between the connector and the

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

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

Install and register a connector

Verify the connector installed and registered correctly

Add an on-premises app to Azure AD

Name The name of the application that will appear on the

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

Pre Authentication How Application Proxy verifies users before giving

Azure Active Directory - Application Proxy redirects

Passthrough - Users don't have to authenticate

Connector Group Connectors process the remote access to your