Powershell unattended teams acces

PowerShell Help
1

Hi all,
I’m running on fumes here, spent an afternoon looking into what I might be doing wrong:

I have a basic powershell script (almost 1-1 from ms docs)

$tenantId = "mytoken"
$ApplicationID = "mytoken"
$clientSecret = "mytoken"



$graphtokenBody = @{   
   Grant_Type    = "client_credentials"   
   Scope         = "https://graph.microsoft.com/.default"   
   Client_Id     = $ApplicationID   
   Client_Secret = $ClientSecret   
}  

$graphToken = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $graphtokenBody | Select-Object -ExpandProperty Access_Token 

$teamstokenBody = @{   
   Grant_Type    = "client_credentials"   
   Scope         = "48ac35b8-9aa8-4d74-927d-1f4a14a0b239/.default"   
   Client_Id     = $ApplicationID   
   Client_Secret = $ClientSecret 
} 

$teamsToken = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $teamstokenBody | Select-Object -ExpandProperty Access_Token 

Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken")

this succesfully connects;
i get the nice reply containing account environment tenant etc.

I can after this also run get-team and it fetches all my teams.

I’m now trying to use the CS scripts simple stuff like ‘Get-CsOnlineUser’
but I immediatly get unauthorized reply…

I’ve made the registerred app teams admin givin it waaaay to many permissions in graph but still to no avail…

Is there any known way to check the permissions that I could need to give / log more?

If i run the Get-CsOnlineUser code with my admin user it just works…

Extra info:
I’m using step 6 →
Connect-MicrosoftTeams (MicrosoftTeamsPowerShell) | Microsoft Learn

in the documentation it even states:

  • For *-Cs cmdlets - the Microsoft Graph API permission needed is Organization.Read.All.

which I have given (even delegated):

image
image698×60 1.81 KB

2

What role did you assign to the app?

  1. Assign Microsoft Entra roles to the application. Refer to this Assign a role procedure, but search for the application instead of a user.

The application needs to have the appropriate RBAC roles assigned. Because the apps are provisioned in Microsoft Entra ID, you can use any of the supported built-in roles.

3

Yeah Doug may be right there. I have setup App based access to Exchange and it was somewhat similar in that you had to configure perms in multiple places (needed both a role in Entra ID and API perms to function, and there’s even a different scenario where you can 'map a SP in entra to Exchange and lock it down further). We have not done it with Teams yet because they only very recently rolled out support for some of the other cmdlets, but its still missing a few we need for one of our apps.

FWIW: I don’t think you need the delegated perms there, just the application perms (delegated is used when the app runs on behalf of the signed in user).

It appears you are authenticating as the app itself (users are not authenticating to the app), so in this case and the corresponding service principal is performing the actions.

Another thing to check - did you 'approve or ‘consent’ the application-level permissions on the app registration? Your SS is cut off. There’s a status column. Simply ‘adding’ the permission to the application is not enough. you need to also ‘consent’ by clicking `Grant admin consent for {tenant}} on the API Permissions blade. You probably should remove any of the extra graph perms too.

Also, I know this is not necessarily on topic, but consider configuring a certificate to auth, instead of using two tokens. Just my 2C, it’s more straightforward and if you’re truly configuring an app that runs code, you can code it so you don’t need to update said code when the cert expires

4

I’ve given it:
Teams administrator
Teams Telephony administrator

5

yeah I’ve approved them with my admin account,
I’ve given it way to many rights as of now to my liking.

I will idd switch to a cert when the script is ready to go to prod,
but since I get an ‘ok’ on the authenticating part, I don’t think the issue is the authentication type (atm?)

Too many to be good ofc but I’d eleminate them all if i could locate the issue:

image
image704×1067 19 KB

6

Remove all that. Leave just application organization.read.all.
image

Then go to Entra and go to Roles and Admins and assign your app to Teams Communications Support Engineer. I just confirmed these two settings allowed Get-CsOnlineUser to work. You will need to disconnect and reconnect in powershell.
image

7

Yea - seems like you just sorta threw a ton of perms at it to try and get it to work. I really think you should get rid of most of that and just leave organizational.read.all. You shouldn’t even need to be teams administrator but I’m not sure what was you will be using this app for. one of the lower level roles should work, though I am not in a place to test atm.

Humor me - have you tried getting new tokens? and reconnecting? Any chance you generated those access tokens prior to approving those perms?

8

Change this line to be this

Scope = "https://graph.microsoft.com/organization.read.all"

9

Ah, so that sort of makes sense. when using access tokens you need to specify the scope each time whereas that’s all handled automatically when you use cert based auth (once approved, the scopes are automatically applied on the next connection).

Probably could even confirm with Get-MGContext on the graph connection.

10

I used the OPs code (which is the example 6 code) exactly and it worked fine with the Role assigned and the Application organization.read.all API permission

When I remove the Teams Role, the connection succeeds but Get-CsOnlineUser gets back Access Denied

11

if I try this I do get:

Invoke-RestMethod : {“error”:“invalid_scope”,“error_description”:"AADSTS1002012: The provided value for scope https://graph.microsoft.com/organization.read.all is not valid. ’

12

The weird thing is I added the support api rights and left organisation.read.all
→ still same error.

Tried on new machine just to be sure no tokens were stuck → elas to no avail

UPDATE: apparently that did it but took some time, even when changing machine…

I’d have to test, with remove the role and rerunning to see if I get the same error.

Last technical question: could having to much rights on the api lead to issues with access too?
or is that just a security risk as it makes an app potentially far to powerfull

13

Last technical question: could having to much rights on the api lead to issues with access too?
or is that just a security risk as it makes an app potentially far to powerfull

Definitely a security risk especially considering Microsoft reporting that %80+ of azure apps are not even being used and those that are used typically use %5 or less of the assigned permissions.

Also, delegated rights are typically for user level access. I’ve encountered issues with azure apps where the engineer had erroneously assigned delegated permissions instead of application permissions and it broke the ability for the app to be used in automation. Take a look at this page, especially the highlighted section.

In contrast, delegated access is usually a poor choice for scenarios that must run without a signed-in user, like automation. It may also be a poor choice for scenarios that involve accessing many users’ resources, like data loss prevention or backups. Consider using application-only access for these types of operations.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.