Microsoft 365 offers a wide variety of services beyond the full stack of services like Exchange Online, Microsoft Teams, etc. In particular, you can use Azure Active Directory as your primary Identity Provider (IdP). This allows you to move authentication of your legacy applications from on-premises to Azure.
I already covered why native cloud authentication in Azure is highly recommended and the most secure authentication (Password Hash Sync) in an older blog post: Password-less Sign-On with AD FS. Therefore, I will not go into detail about the different authentication methods in this post.
Everyone with an on-premises directory may likely have applications that users authenticate to. Each of these applications can be accessed by using user account credentials. You may have an Active Directory Federation Service (AD FS) in place where your users can authenticate directly against your on-premises directory service. AD FS extends the ability to use single sign-on (SSO) between trusted partners without requiring users to sign-in separately to each application.
The current situation may look like this:
To remove your on-premises footprint like AD FS and increase the application security, the goal is to use a single IdP where you can configure and manage access controls and policies for your cloud and on-premises environment in a single place.
To identify your applications that are compatible with Azure AD and what migration steps are needed, the AD FS application activity report can be used to gather all required information. With the activity report, you can:
• Discover AD FS applications and scope your migration
• Prioritize applications for migration
• Run migration tests and fix issues
You need Azure AD Connect Health enabled in your Azure AD tenant and Azure AD Connect Health for AD FS agent must be installed. You can read more information about the prerequisites here. As soon as all prerequisites are met, you can navigate to the Azure Portal with an eligible admin account (global administrator, report reader, security reader, application administrator, or cloud application administrator), select Azure Active Directory
and then Enterprise applications. Under Activity, select Usage & Insights (Preview), and then select AD FS application activity to open a list of all AD FS applications in your organization.
The AD FS application activity report to migrate applications to Azure AD helps you to identify your applications leveraging AD FS and on-premises authentication. As a best practices approach, consider first migrating applications that use modern authentication protocols such as SAML and Open ID Connect.
There are four main types of applications that can be added and managed with Azure AD:
• Azure AD Gallery applications: Microsoft provides pre-integrated applications for single sign-on with Azure AD.
• On-Premises applications with Application Proxy: Azure AD Application Proxy allows you to integrate your on-premises web apps with Azure AD to support single sign-on.
• Custom-developed applications: Line-of-business (LOB) applications can also be integrated with Azure AD. By registering your application with Azure AD, you can control the authentication policy for the application.
• Non-Gallery applications: Support single sign-on for any other apps by adding them to Azure AD.
o Any web link, or application, that renders a username and password field
o Any application that supports SAML or OpenID Connect protocols
o Any application that supports the System for Cross-domain Identity Management (SCIM) standard
By default, Azure AD issues a SAML token to your applications that contains a NameIdentifier claim with the user’s UserPrincipalName (UPN) as value. Therefore, Azure AD can uniquely identify the user. Depending on the application, you can edit the claims issued in the SAML token to the application.
Many on-premises applications are configured in AD FS to use group membership information. You can use synchronized groups for adding group claims to your application, also nested groups are supported. Two main patterns are supported:
• Groups identified by their Azure AD object identifier (OID) attribute
• Groups identified by sAmAccountName or GroupSID attributes for synchronized groups
Important caveats that you should be aware of:
• Groups managed in Azure AD (cloud-only) do not contain sAMAccountName and security identifier (SID) necessary to emit these claims
• It’s recommended to restrict the groups emitted in claims to the relevant groups for the application. The number of groups a user is a member of may exceed the limit (150 groups for SAML token, and 200 for a JWT).
In a nutshell, Application Roles are used to assign permissions to users and/or applications. Application Roles are provided to an application in the roles claim. You can combine RBAC with Application Roles and Role Claims, which allows you to securely enforce authorization in your apps. If you don’t need nested groups, Application Roles are the most secure and compliant way to authorize your users to applications.
Application Roles are defined in the Azure portal in the application’s registration manifest. When a user signs into the application, Azure AD emits a roles claim for each role that the user has been granted.
| "appRoles": [ { "allowedMemberTypes": [ "User" #(this can be Application, or both as well) ], "description": "Standard Platform User", "displayName": "Standard Platform User", "id": "221d23bd-023c-41d0-9aa3-1a4c61fa29b1", "isEnabled": true, "lang": null, "origin": "Application", "value": null } |
For greater control, you should consider that your enterprise applications are configured to require user assignment. When you assign a group to an application, only users in the group will have access. Please note that group-based assignment requires at least Azure AD Premium P1 licenses.
As soon as you assign users and groups to your application, the defined Application Roles in the application’s manifest can be selected. In this example, I added MOD Administrator to the application Salesforce with the assigned role Standard Platform User.
Moving your applications to Azure can be a long journey. It is important that you discover your applications and users that need access, plan the migration, use the usage and insight reporting tools, and test the migration path. You can combine user claims, group claims, and Application roles; one does not exclude the other and all of them can be combined. It offers you a lot of advantages like more security, you can easily add Azure B2B users from partner or external organizations to your apps as well, and you can enforce policies and define granular permissions using RBAC.
This blog post covers a basic understanding about the possibilities how to migrate your applications to Azure. If you would be interested in a deep-dive blog post you can drop me an email or reach out to me on Twitter.
Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Active Directory Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.
Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.