Time for a new section and this time covering the following topics:
- implement and configure consent settings
- discover apps by using MCAS (Defender for Cloud Apps) or ADFS app report
- design and implement access management for apps
- design and implement app management roles
Table of Contents
Implement and configure consent settings
Consents are one of my favorite areas. Consents are crucial for app security, too much is too much.
User consent
A user can authorize an application to access some data at the protected resource, while acting as that user. The permissions that allow this type of access are called “delegated permissions.”
User consent is usually initiated when a user signs in to an application. After the user has provided sign-in credentials, they’re checked to determine whether consent has already been granted. If no previous record of user or admin consent for the required permissions exists, the user is directed to the consent prompt window to grant the application the requested permissions.
User consent by non-administrators is possible only in organizations where user consent is allowed for the application and for the set of permissions the application requires. If user consent is disabled, or if users aren’t allowed to consent for the requested permissions, they won’t be prompted for consent.
Admin consent
During admin consent, a Privileged Administrator may grant an application access on behalf of other users (usually, on behalf of the entire organization). Also during admin consent, applications or services provide direct access to an API, which can be used by the application if there’s no signed-in user.
When your organization purchases a license or subscription for a new application, you might proactively want to set up the application so that all users in the organization can use it. To avoid the need for user consent, an administrator can grant consent for the application on behalf of all users in the organization.
After an administrator grants admin consent on behalf of the organization, users aren’t usually prompted for consent for that application. In certain cases, a user might be prompted for consent even after consent was granted by an administrator. An example might be if an application requests another permission that the administrator hasn’t already granted.
Different options
Let’s go thru with the options that have for getting users access to applications in a multi-tenant environment.
Publisher verification
When Microsoft revoked the possibility for the User to grant consent to their own info they introduced a Publisher verification method.
Why you ask? Well because all the non-gallery apps are un-verified and therefore not trusted by the tenant that will connect to your published application.
You can connect to this menu from branding portal inside app registration.
The only bad thing here is that Your MPN ID suffix has to be the same than the suffix registed to the MPN ID inside Microsoft Partner portal.
User consent
Enabling User based consent is still available but it’s the most unsecure solution of the whole bunch.
You can access User consent options in:
https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConsentPoliciesMenuBlade/UserSettings
In here You can also see an option for the Allow consent for apps from verified publishers (which needs the first MPN solution to be enabled)
Admin approval flow
You can also add an Admin approval flow to register application. All the application consent request will be sent to Admins that are defined as approvers.
You can access this menu from:
You can define a time period for the consent with a maximum of 60 days.
End-users need to provide Justification to send a request to Admins.
Admin gets the request.
And accepts the request.
But the screen is different, there isn’t anymore a box to tick for whole organization.
And the application will be provisioned to Enterprise applications.
Admin consent behalf of the whole organization
If admin user logins to the application and gives their consent for the whole organization, the application will be registered to Enterprise Applications in the source tenant.
And the application will be provisioned inside Enterprise Applications.
Construct the URL for granting tenant-wide admin consent
The following will ask Admin consent and register External Multi-tenant app as Enterprise application to Your own tenant.
https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}
where:
{client-id} is the application’s client ID in the external Azure AD (also known as application ID).
{tenant-id} is your own organization’s tenant ID
Discover apps by using MCAS (Defender for Cloud Apps) or ADFS app report
Defender for Cloud Apps
The Cloud Discovery dashboard is intended to provide you with more information about how cloud apps are used in your company. It shows you what kind of apps are being utilized, your open alerts, and the risk levels of apps in your business at a glance. It also displays your top app users and gives a map of App Headquarter’s location. The Cloud Discovery Dashboard offers a variety of data filtering options. Filtering allows you to build specialized views based on your primary interests, utilizing simple graphics to provide you with a complete image at a look.
Open the Defender for Cloud Apps portal https://portal.cloudappsecurity.com/ and open Cloud Discover dashboard.
In here You will see all apps discovered
in the Discovered apps, you can find all of Your apps that are connected.
And You can tag Your apps.
Sanctioning and unsanctioning an app
Using the Cloud app catalog, you can use Cloud App Security to sanction or unsanction apps in your organization. The Microsoft team of experts has a collection of over 16,000 cloud apps that are ranked and graded according to industry standards. Regulatory certifications, industry standards, and best practices are used to determine the risk of your cloud apps in the Cloud app library. Then, according to your company’s demands, adjust the scores and weights of various parameters. Cloud App Security determines the riskiness of an app based on these scores. More than 80 risk factors that may affect your environment are used to determine your score.
ADFS app report
If you have an on-premises directory with user accounts, you probably have a lot of applications that users log in to. Each of these apps is set up so that users may log in using their identities. Users can also use your on-premises Active Directory to authenticate. Active Directory Federation Services (AD FS) is an on-premises identity service that follows industry standards. AD FS allows users to access single sign-on (SSO) capability across trusted business partners without having to sign in to each application separately. Federation is the term for this. Along with Microsoft 365 and Azure AD-based apps, many businesses have software as a service (SaaS) or custom line-of-business (LOB) apps federated directly to AD FS.
Install the agent
If you installed Azure AD Connect health but still get the prompt to install it or don’t see all of your AD FS applications shown in the report, it’s possible that you don’t have any active AD FS applications or that your AD FS applications are microsoft applications.
The Active Directory Federation Services application activity report provides all AD FS applications in your company that have had active users sign in in the previous 30 days. In addition, microsoft-related reliant parties in AD FS, such as Office 365, are not displayed in the report. ‘urn:federation:MicrosoftOnline’,’microsoftonline’, and’microsoft:winhello:cert:prov:server’, for example, will not appear in the list.
Types of apps to migrate
Migrating all your application authentication to Azure AD is optimal, as it gives you a single control plane for identity and access management.
There are two types of applications to migrate:
- SaaS applications, which are generally procured by the organization.
- Line-of-business applications, which are developed by the organization and not meant to be used by other companies.
Migration status
For each application in the AD FS application activity list, view the Migration status:
Ready to migrate means the AD FS application configuration is fully supported in Azure AD and can be migrated as-is.
Needs review means some of the application’s settings can be migrated to Azure AD, but you’ll need to review the settings that can’t be migrated as-is.
Additional steps required means Azure AD doesn’t support some of the application’s settings, so the application can’t be migrated in its current state.
Design and implement access management for apps
Determining the user experience for accessing apps
Azure AD provides several customizable ways to deploy applications to end users in your organization:
- Azure AD My Apps
- Microsoft 365 application launcher
- Direct sign-on to federated apps (service-pr)
- Deep links to federated, password-based, or existing apps
You can determine whether users assigned to an enterprise app can see it in My Apps and Microsoft 365 application launcher.
How register Enterprise Application and modify Manifest
When add an enterprise app, you have to choose the origin. Like I said before, there is three major categories.
You can choose from on-premises applications thru App Proxy (Different discussion as there is some differences depending on the app) and then there is from the app gallery on non-gallery.
For my example I will choose non-gallery and In this demo I will call my demo, well just demo.
So go and create your app.
There you will find the options above. I will not be covering them all, just opening up SSO and Self-Service and what is the difference with Enterprise app and App registration.
Single Sign-On
There is an options for SAML, which I will cover in this blog.
The different types SSO’s are explained here https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-password-single-sign-on-non-gallery-applications
When you open SAML, you will see the following page.
In this page you can define the metadata for the request. Either manually entering or updating via federation XML file that has the rights attributes from the destination app.
You can give claims to be transferred. If you have user that has username with something different than their email address, you could user emailaddress attribute. There are the sames one that you on in your AD or Azure AD. It really depends on the destination app and what it prefers.
When you create the federation between system, you have to download the certificate in the mode that the destination understands it and you have to do it every single time you update the config as it will need to be re-generated.
When you done, you will download your own federation metadata and send it to app provider to federating their end.
After all you can test the SSO from this single panel, it will give you debugging info if something goes sour.
So, now you have federation in place. Then with the manifest, but first the differences between Enterprise App and App Registrations.
Differences with App and Object ID
This was opened from a Microsoft employee in the forums https://docs.microsoft.com/en-us/answers/questions/270680/app-registration-vs-enterprise-applications.html
“The Application Object is what you see under App Registrations in AAD. This object acts as the template where you can go ahead and configure various things like API Permissions, Client Secrets, Branding, App Roles, etc. All these customizations that you make to your app, get written to the app manifest file. The application object describes three aspects of an application: how the service can issue tokens in order to access the application, resources that the application might need to access, and the actions that the application can take.
The Service Principal Object is what you see under the Enterprise Registration blade in AAD. Every Application Object (created through the Azure Portal or using the Microsoft Graph APIs, or AzureAD PS Module) would create a corresponding Service Principal Object in the Enterprise Registration blade of AAD. A service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.”
Then to Manifest.
Manifest
With manifest you can manipulate the attributes sent to destination app. There is a json-file that you can edit.
But first you need and Unique GUID, doesn’t have to be anything considering your app, just unique.
You can create a unique GUID with powershell
[guid]::NewGuid()
or if you prefer to use GUID generator from the web, just search, there is a lot of them.
So, GUID looks like this.
And every single time you generate new it will be different. Then you go to Azure Active Directory and choose App registrations.
And your freshly configured app.
And Manifest.
Under manifest you find the json file, I like to edit json’s in Visual Studio Code as you lot’s of plugins to provide the necessary support for whatever you are editing.
If you mess up your json, there is no turning back so download it first so you have an backup.
Copy paste to Visual Studio and find the part that says AppRoles
In the AppRoles copy one block and modify based on your needs.
In my demo I created a role called Demo_Role and here is the part you need the Unique GUID
And also add your wanted role to Value field like above.
Then copy paste the json back to online editor and save. If the modification are correct, you will get a popup saying
Then go backup Enterprise applications and find your app.
Assigning users and roles
And choose Assign user and Roles.
Choose Add user / Group and find the user or group that you need to assign the app role.
Note! Nested groups cannot be used, but dynamic groups will work.
After all this you have a user / users that can send an Application Role to the destination app with their login claims.
After this one you can enable Self-service if needed.
Self-service
With Self-service you can provide user to request access to an app and use Access reviews to govern the groups. Nice feature.
Design and implement app management roles
Here is an excellent article from Microsoft about Enterprise App permissions.
Prerequisites
- Azure AD Premium P1 or P2 license
- Privileged Role Administrator or Global Administrator
- AzureADPreview module when using PowerShell
- Admin consent when using Graph explorer for Microsoft Graph API
Create a custom role
Start from scratch
Write microsoft.directory/servicePrincipals/appRoleAssignedTo/update in the search box
And create the role.
Assigning the role
PowerShell
Create a custom role
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# Basic role information $description = "Manage user and group assignments" $displayName = "Can manage user and group assignments for Applications" $templateId = (New-Guid).Guid # Set of permissions to grant $allowedResourceAction = @("microsoft.directory/servicePrincipals/appRoleAssignedTo/update") $resourceActions = @{'allowedResourceActions'= $allowedResourceAction} $rolePermission = @{'resourceActions' = $resourceActions} $rolePermissions = $rolePermission # Create new custom admin role $customRole = New-AzureADMSRoleDefinition -RolePermissions $rolePermissions -DisplayName $displayName -Description $description -TemplateId $templateId -IsEnabled $true |
Assign the custom role
|
1 2 3 4 5 6 7 8 9 10 |
# Get the user and role definition you want to link $user = Get-AzureADUser -Filter "userPrincipalName eq 'chandra@example.com'" $roleDefinition = Get-AzureADMSRoleDefinition -Filter "displayName eq 'Manage user and group assignments'" # Get app registration and construct resource scope for assignment. $appRegistration = Get-AzureADApplication -Filter "displayName eq 'My Filter Photos'" $resourceScope = '/' + $appRegistration.objectId # Create a scoped role assignment $roleAssignment = New-AzureADMSRoleAssignment -ResourceScope $resourceScope -RoleDefinitionId $roleDefinition.Id -PrincipalId $user.objectId |
Things to remember
Implement and configure consent settings
Differences between a User consent and Admin consent
Different consent types.
App ID = client-id and where to find Your Tenant ID
Defender for Cloud apps and ADFS reporting
What filters are inside Cloud discovery dashboard.
Differences between Sanctioned, Unsanctioned apps and Monitoring.
How to monitor ADFS apps.
What is the differences between LOB (Line-of-business) and SaaS applications.
Migration statuses
Enterprise applications
Ways that user can access published apps and Self-service settings
SSO methods, SAML, Password-based and Linked
Differences with App and Object ID
App management roles
How to create, manage and assign Custom roles
Link to main post
RSS - Posts