The corresponding cmdlet however might not work as expected. There is no requirement to have all these scopes granted to however, and the module will not prevent you from connecting if one or more of these is missing. Having all of these will ensure that all of the Graph API-based Teams cmdlets will work.
In the case of the Graph API, the full set of scopes includes:, ,, ,, ,.
You will also need to have the corresponding permissions/scopes for each of these APIs. You cannot obtain a Graph API token for one app, and use a different app to obtain the Skype and Teams Tenant Admin API token. And another one for the Graph API resource, represented via and 00000003-0000-0000-c000-000000000000.Īn important requirement, not properly detailed in the documentation, is that both tokens need to have the same AppId claim, in other words you need to have a single app registration with both these resources added. Thus, we need a token for the Skype and Teams Tenant Admin API resource, also represented via the URI or 48ac35b8-9aa8-4d74-927d-1f4a14a0b239 GUID. Why? Because each “resource” needs a separate token. Now, since the Microsoft Teams PowerShell module incorporates both the old-style Skype for Business and new-style Teams cmdlets, under the cover it effectively uses two different access tokens. The official documentation walks you over all the details, but we will of course cover them here too.Īs with all other things Graph, in order to connect you will have to obtain a valid access token. Once the module is updated, you can use the newly introduced – CertificateThumbprint, – ApplicationId, – TenantId and/or – AccessTokens parameters for the Connect-MicrosoftTeams cmdlet. So how do we get this working? First, you need the latest preview version of the Microsoft Teams PowerShell module, namely 4.7.1-preview, which you can get from the usual location over at the PowerShell gallery. However, the module does allow you to pass access tokens (yes, plural) directly, which means you can leverage other flows as needed. The situation with the Microsoft Teams PowerShell module is largely the same, with only certificate-based auth officially supported.
Other methods, such as authenticating via a client secret can also be leveraged, although not in “supported” manner. We covered many such examples for Exchange Online PowerShell, where the V2 module has had support for certificate-based authentication for a while now. Basically, it allows you to run scripts unattended, without a logged in user. Kind of important one at that – the Microsoft Teams PowerShell module has added (preview) support for application context authentication! Seem all I blog about lately is PowerShell… so here’s another article.
0 kommentar(er)
