Table of Contents
Teams ACM Makes It Easier to Manage Access to Teams Apps
Over the years, I have become accustomed to using app permission policies to control access to Teams apps. Now a new sheriff is in town and App-centric management (ACM) is the replacement for app permissions policies.
ACM means that apps store a permission list to say who can use the app. The permission can be:
- Everyone: The app is available to anyone in the organization, including guests.
- Specific users or groups: The app is available only to selected users (including guests) and groups. The groups can be Microsoft 365 groups, security groups, dynamic groups, and distribution lists.
- No one: The app is blocked to everyone in the organization.
Microsoft says that ACM simplifies the app management process because administrators no longer need to edit (or create) an app permission policy and assign the policy to users to allow the users to install apps. Instead, an administrator select the target app in the Teams admin center (Figure 1) and edit the availability for the app to whatever permission should apply.
Getting to Teams ACM
Moving from app permission policies to ACM is a one-time, non-reversable migration run by invoking a wizard in the Teams admin center. You can pause the migration at any time but will eventually have to let it run to completion (Figure 2). During this process, the wizard checks the app permission policies currently defined in the tenant and updates the apps specified in the policies with equivalent ACM permissions to allow users to continue to access the same set of apps.
The time required for the migration depends on the number of app permission policies in the tenant and the number of ACM assignments the wizard must make. The tenant completed in just a few minutes in my tenant, but I suspect that it might take much longer in a large tenant.
Once the migration completes, you cannot access app permission policies through the Teams admin center, but you can with cmdlets from the Teams PowerShell module. For example:
Get-CsTeamsAppPermissionPolicy -Identity 'Global'
The apps defined in the policy are listed in the DefaultCatalogApps and GlobalCatalogApps property. To check the permissions assigned by the migration, select any app and use its identifier to find the app name.
Get-TeamsApp -Id 44263ed4-f1ac-4e96-93aa-d24dd50459ea ExternalId Id DisplayName DistributionMethod ---------- -- ----------- ------------------ 44263ed4-f1ac-4e96-93aa-d24dd50459ea Channel calendar store
Now go to the Teams admin center and check the availability of the app (Figure 3).
The transition to ACM is simple and should not cause any problems for tenants. The best thing about the changeover is that it removes one policy from the set required to manage user accounts and that can’t be a bad thing.
Better Permission Visibility for Teams Apps
Teams Apps use Graph permissions to access user and organizational data. The app developer requests consent for the permissions, which then need an administrator to grant consent.
Details of permissions are available in app properties. However, the presentation of their details has been a tad obscure in the past. Microsoft introduced a change earlier this year (MC713370) to do a better job of highlighting the permissions and the data that the permissions allow access to. For instance, the Teams channel calendar app can use the permissions shown in Figure 4. The text is deliberately geared for humans to understand.
Figure 4 covers an app that has been granted consent. Figure 5 shows the increased level of detail available to an administrator before they grant consent to an app.
Of course, to fully comprehend what data the app is asking to be allowed access, administrators still need to understand Graph permissions and the differences between delegated and app permissions. But at least the information is there and presented in a way that makes it easy to look up a permission to check it out.
Small But Important Changes for Teams App Management
With over 2,500 apps available in the Teams app store, it’s important that every detail of managing apps is as simple and precise as possible. Changes like the changeover to ACM and better presentation of Graph permissions might seem small in the overall scheme, but they really make a difference, and that’s what counts.
Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.
Tested this is 2 separate tenants – app permission policy to restrict access to apps didnt work. Tried blocking the app via the App centric approach in another tenant, didnt work. Left more than 72 hours in both cases to make sure it wasnt replication. 2 separate tenants but the same bad experience. Ticket logged with MS but so far that hasnt proved fruitful.
Wondered if you experienced the same when testing or have i just been unlucky with multiple tenants?
Has this ticket been resolved? We are planning migration in our tenant and readeing this makes us weary.
One shortcoming of this new model is that it isn’t clear/easy to to see what apps you’ve approved or blocked in the manage apps section. You can sort by App status which gets you part of the way there, but it would be really nice if you could filter by app status, do you know if that will be forthcoming?
I’m not sure what the Teams group are working on in this area… and am constrained by NDA!
This is helpful. I feel Microsoft really just flung the door open on what people can install by have 3000+ apps available for install. IMO, default should have been to have them all blocked. We are trying to find the “who” has installed what as there may be a legitimate business reason for installing an app and finding that information is difficult. Security may just want to block all apps but that will irritate the end users who have some of these 3rd party apps installed