I ran into an issue the other day that was difficult to troubleshoot due to the obscure error that arose. The scenario: I was attempting to use Certificate or Token based Authentication to do an application-based authentication with Azure (instead of the regular interactive password based authentication).
After setting everything up and connecting to Teams PowerShell, there was a persistent error any time a Skype for Business *Cs* command was run.
The error referenced the WinRM client not being able to process the request.
Here’s the error in question:
PowerShell Error:
PS C:\> Connect-MicrosoftTeams -CertificateThumbprint "897a047bc435843b2a32126544e5a7a8001fee8c"
-ApplicationId "216d0455-8988-45b0-b425-222ca02e8ede" -TenantId contoso.onmicrosoft.com
Account Environment
Tenant
TenantId
------- -----------
------
--------
219d0455-8988-45b0-b425-222ca01e8ece AzureCloud 6364a50-c3d7-4eee-834c-21a2371df363 6364a50-c3d7-4eee-834c-21a237...
PS C:\> Get-CsOnlineUser
2022-11-22T23:02:46Z [Error] ERROR: Connecting to remote
server api.interfaces.records.teams.microsoft.com failed with the following
error message : The WinRM client cannot process the request. The authentication
mechanism requested by the client is not supported by the server or unencrypted
traffic is disabled in the service configuration. Verify the unencrypted
traffic setting in the service configuration or specify one of the
authentication mechanisms supported by the server. To use Kerberos, specify the
computer name as the remote destination. Also verify that the client computer
and the destination computer are joined to a domain. To use Basic, specify the
computer name as the remote destination, specify Basic authentication and
provide user name and password. Possible authentication mechanisms reported by
server: For more information, see the about_Remote_Troubleshooting Help topic.
From the error it seemed like an issue on the client side to do with the method being used to authenticate or communicate with the cloud endpoint on the client side… However, after exhaustively chasing down anything to do with the client side WinRM settings, nothing was working… This was on the latest 4.9.1 Teams PowerShell module which in its release notes listed application authentication as being made GA (https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-release-notes). As a result, it’s not likely there was a bug in the module that meant that all *CS* commands just didn’t work...
At this point I looked to the cloud. When configuring application-based
authentication for the Teams PowerShell module, you need to set up an App Registration
and assign it permissions and RBAC roles to allow it to access Teams. In
the deployment I was working on, the following permissions were assigned:
The documentation (https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-application-authentication) from Microsoft says that the following settings
were required:
User.Read.All
Group.ReadWrite.All
AppCatalog.ReadWrite.All
TeamSettings.ReadWrite.All
Channel.Delete.All
ChannelSettings.ReadWrite.All
ChannelMember.ReadWrite.All
Note: For the record, you also need to
assign the Teams Administrator RBAC role to the Application Service Principal in the Roles and Administrators area (but
this wasn’t the issue in this case).
It appears that all of these permissions were included. So
it should be fine, right?
….Wrong.
What I found out was that the “Skype and Teams Tenant Admin
API” permissions that were included here were to blame for the error. After removing
and revoking both of the innocuous “Skype and Teams Tenant Admin API”
permissions, I was able to connect and run *CS* commands to my heart's desire…
So to anyone who says “you can never have too many
permissions” it appears that you actually can...
Note: There may be other permissions that also cause this to happen, so make sure you haven't assigned more permissions than are required.
The Solution
Remove the offending “Skype and Teams Tenant Admin API” permissions:
After this, you shouldn't get the WinRM error anymore when running CS commands!
Be sure that you have applied the Teams Administrator RBAC role to the App Registration Service Principal as well. Go to: Azure Active Directory > Roles and administrators > Teams Administrator > Add Assignments Button > Search for your App Registration Name and assign it:
The Wrap Up
I hope that helped out a few of you poor people banging your head against the wall about the WinRM error situation. If you want to check out a full walk through of setting up Certificate or Token based Authentication with the Teams PowerShell Module, check out these posts:
Certificate-based Authentication post
Token-based Authentication post
See ya next time!
