Deploying organizational policies for governing access to applications integrated with Azure AD
In previous sections, you defined your governance policies for an application and integrated that application with Azure AD. In this section, you'll configure the Azure AD conditional access and entitlement management features to control ongoing access to your applications. You'll establish
- Conditional access policies, for how a user authenticates to Azure AD for an application integrated with Azure AD for single sign-on
- Entitlement management policies, for how a user obtains and keeps assignments to application roles and membership in groups
- Access review policies, for how often group memberships are reviewed
Once these policies are deployed, you can then monitor the ongoing behavior of Azure AD as users request and are assigned access to the application.
Deploy conditional access policies for SSO enforcement
In this section, you'll establish the Conditional Access policies that are in scope for determining whether an authorized user is able to sign into the app, based on factors like the user's authentication strength or device status.
Conditional access is only possible for applications that rely upon Azure AD for single sign-on (SSO). If the application isn't able to be integrated for SSO, then continue in the next section.
- Verify users are ready for Azure Active Directory Multi-Factor Authentication. We recommend requiring Azure AD Multi-Factor Authentication for business critical applications integrated via federation. For these applications, there should be a policy that requires the user to have met a multi-factor authentication requirement prior to Azure AD permitting them to sign into the application. Some organizations may also block access by locations, or require the user to access from a registered device. If there's no suitable policy already that includes the necessary conditions for authentication, location, device and TOU, then add a policy to your conditional access deployment.
- Bring the application web endpoint into scope of the appropriate conditional access policy. If you have an existing conditional access policy that was created for another application subject to the same governance requirements, you could update that policy to have it apply to this application as well, to avoid having a large number of policies. Once you have made the updates, check to ensure that the expected policies are being applied. You can see what policies would apply to a user with the Conditional Access what if tool.
- Create a recurring access review if any users will need temporary policy exclusions. In some cases, it may not be possible to immediately enforce conditional access policies for every authorized user. For example, some users may not have an appropriate registered device. If it's necessary to exclude one or more users from the CA policy and allow them access, then configure an access review for the group of users who are excluded from Conditional Access policies.
- Document the token lifetime and application's session settings. How long a user who has been denied continued access can continue to use a federated application will depend upon the application's own session lifetime, and on the access token lifetime. The session lifetime for an application depends upon the application itself. To learn more about controlling the lifetime of access tokens, see configurable token lifetimes.
Deploy entitlement management policies for automating access assignment
In this section, you'll configure Azure AD entitlement management so users can request access to your application's roles or to groups used by the application. In order to perform these tasks, you'll need to be in the Global Administrator, Identity Governance Administrator role, or be delegated as a catalog creator and the owner of the application.
- Access packages for governed applications should be in a designated catalog. If you don't already have a catalog for your application governance scenario, create a catalog in Microsoft Entra entitlement management.
- Populate the catalog with necessary resources. Add the application, as well as any Azure AD groups that the application relies upon, as resources in that catalog.
- Create an access package for each role or group which users can request. For each of the applications, and for each of their application roles or groups, create an access package that includes that role or group as its resource. At this stage of configuring that access package, configure the access package assignment policy for direct assignment, so that only administrators can create assignments. In that policy, set the access review requirements for existing users, if any, so that they don't keep access indefinitely.
- Configure access packages to enforce separation of duties requirements. If you have separation of duties requirements, then configure the incompatible access packages or existing groups for your access package. If your scenario requires the ability to override a separation of duties check, then you can also set up additional access packages for those override scenarios.
- Add assignments of existing users, who already have access to the application, to the access packages. For each access package, assign existing users of the application in that role, or members of that group, to the access package. You can directly assign a user to an access package using the Azure portal, or in bulk via Graph or PowerShell.
- Create policies for users to request access. In each access package, create additional access package assignment policies for users to request access. Configure the approval and recurring access review requirements in that policy.
- Create recurring access reviews for other groups used by the application. If there are groups that are used by the application but aren't resource roles for an access package, then create access reviews for the membership of those groups.
View reports on access
Azure AD, in conjunction with Azure Monitor, provides several reports to help you understand who has access to an application and if they're using that access.
- An administrator, or a catalog owner, can retrieve the list of users who have access package assignments, via the Azure portal, Graph or PowerShell.
- You can also send the audit logs to Azure Monitor and view a history of changes to the access package, in the Azure portal, or via PowerShell.
- You can view the last 30 days of sign-ins to an application in the sign-ins report in the Azure portal, or via Graph.
- You can also send the sign in logs to Azure Monitor to archive sign in activity for up to two years.
Monitor to adjust entitlement management policies and access as needed
At regular intervals, such as weekly, monthly or quarterly, based on the volume of application access assignment changes for your application, use the Azure portal to ensure that access is being granted in accordance with the policies. You can also ensure that the identified users for approval and review are still the correct individuals for these tasks.
Watch for application role assignments and group membership changes. If you have Azure AD configured to send its audit log to Azure Monitor, use the
Application role assignment activityin Azure Monitor to monitor and report on any application role assignments that weren't made through entitlement management. If there are role assignments that were created by an application owner directly, you should contact that application owner to determine if that assignment was authorized. In addition, if the application relies upon Azure AD security groups, also monitor for changes to those groups as well.
Also watch for users granted access directly within the application. If the following conditions are met, then it's possible for a user to obtain access to an application without being part of Azure AD, or without being added to the applications' user account store by Azure AD:
- The application has a local user account store within the app
- The user account store is in a database or in an LDAP directory
- The application doesn't rely solely upon Azure AD for single sign-on.
For an application with the properties in the previous list, you should regularly check that users were only added to the application's local user store through Azure AD provisioning. If users that were created directly in the application, contact the application owner to determine if that assignment was authorized.
Ensure approvers and reviewers are kept up to date. For each access package that you configured in the previous section, ensure the access package assignment policies continue to have the correct approvers and reviewers. Update those policies if the approvers and reviewers that were previously configured are no longer present in the organization, or are in a different role.
Validate that reviewers are making decisions during a review. Monitor that recurring access reviews for those access packages are completing successfully, to ensure reviewers are participating and making decisions to approve or deny user's continued need for access.
Check that provisioning and deprovisioning are working as expected. If you had previously configured provisioning of users to the application, then when the results of a review are applied, or a user's assignment to an access package expires, Azure AD will begin deprovisioning denied users from the application. You can monitor the process of deprovisioning users. If provisioning indicates an error with the application, you can download the provisioning log to investigate if there was a problem with the application.
Update the Azure AD configuration with any role or group changes in the application. If the application adds new application roles in its manifest, updates existing roles, or relies upon additional groups, then you'll need to update the access packages and access reviews to account for those new roles or groups.
Submit and view feedback for