Protected Teams API

[dotdk]

Hello all.

We are in the process of getting ready to have some of our customers use the new protected Teams API, that MS introduced recently. And we asked our customers to follow this KB: https://www.veeam.com/kb4322 in order to sign up, and be allowed to use the new API.

However even though customers do get the confirmation e-mail back from MS confirming that their app reg was allowed access:
"Your protected APIs request has been approved.
Thank you for your patience while we were reviewing your request. Your application ID(s) (xxxxxxxxxxxxxxxxxxxxxx) has been approved to call protected APIs in Microsoft Teams. Thank you for using Microsoft Teams!"

90% of the customers dont have access when testing the access by using the script from the community: https://community.veeam.com/script-libr ... s-api-2931

On the customers that we can see has access according to the script from the community, we get this back:
PS C:\Users\XX> C:\Temp\Get-ProtectedAPIStatus.ps1 -TenantId "Customer-TenantID" -AppId "xxxxxxxxx" -CertThumbprint "xxxxxxxxxxxxx"
Microsoft.Graph module already present
Welcome To Microsoft Graph!
Teams Protected API is accessible!

but on a clear majority of customers and our own testing environment we get this back when testing:
PS C:\Users\XX> C:\Temp\Get-ProtectedAPIStatus.ps1 -TenantId "Customer-TenantID" -AppId "xxxxxxxxx" -CertThumbprint "xxxxxxxxxxxxx"
Microsoft.Graph module already present
Welcome To Microsoft Graph!
Teams Protected API is not available.
If you haven't already, you can request access to this API using the instructions highlighed in the below KB article:

https://www.veeam.com/kb4322

We have confirmed that we are using the correct TenantID, AppID and Cert thumprint that matches the customer.

I have asked Veeam for any other way to confirm access before switching to the new API, but there is no official "Veeam" way to do this prior to switching the proxies to use the new API. We have to contact MS in order to understand why this isn't working, and that is a very cumbersome process for our customers.

Did anyone here experience the same, or found any other way to confirm access?

[Mike Resseler]

Unfortunately there is not. We use the same commands to detect if it works or not. I'm afraid if it does not work, there might be either an issue with MSFT (although we never personally had an issue with it) or they have not filled in the correct information in the form.

[Regnor]

Have you tried to run the commands from Mildur's post manually? I've had cases where the API access had been approved and the test ran into a different error. So maybe the access is working in your case.

By the way, we never received a confirmation email from Microsoft after they approved the API.

[dotdk]

Hi Regnor

You post made ys try a few extra things and figured that the reason why the script fails on the majority of our customers, is that the scripts tests a specific team number id:

$teams = Get-MgGroup -Filter "groupTypes/any(c:c eq 'Unified')" | Select-Object Id
Get-MgTeamChannelMessage -TeamID $teams.Id[1]

And that Id 1 in these cases was a team without any messages in it. So doing it manually and selecting another ID from the last, we were able to verify access.

[Mildur]

Hi Thomas

Thanks for the feedback. We will check if how we can update our script.

Best,
Fabian

[chris.arceneaux]

Hi Thomas,

Good sleuthing! I've noted another reason the script doesn't work is because the Azure application being referenced doesn't have the ChannelMessage.Read.All permission. This is highlighted as a requirement in Veeam documentation. As this is a new permission requirement, Azure applications generated using older Veeam versions won't have this permission and will need to be updated in order for this script to work.

From the Veeam side of things, editing an Organization in VB365 and following the wizard prompts using the device code workflow, Veeam automates updating the Azure application with the required permission.

Here's the error message received when executing the Microsoft PowerShell cmdlet manually:



A related question...have you found that customers that have received the confirmation e-mail back from Microsoft have not been enabled for protected API access? I ask as the script was a stop-gap as previously there was no Microsoft communication.

[dotdk]

Hi Chris,

We made sure all customers had assigned the ChannelMessage.Read.All permission, and we also tested on some where we knew this permission weren't assigned and that showed the same error as you have listed above.

All customers that received the confirmation e-mail from Microsoft, with the "Your protected APIs request has been approved." message, did work after testing manually. Some customer who signed up a long time ago, did not receive any confirmation, but we have confirmed access on those customers as well.

So right now, all of our customers who signed up for this new API, has gotten access.

[chris.arceneaux]

Good info. Thanks for the additional insight.

[Mike Resseler]

Thanks Chris and Thomas for the additional info, glad it is solved and they have access. I do believe we need to keep pushing MSFT for the future. I have no issues with paid API's (as it will bring performance and bandwidth) and many vendors will do this, but the "sign-up" procedure will hopefully be a bit easier in the future...