Table of Contents
Understanding the Influences over Teams Client Sign-ins
So much stuff happens inside Microsoft 365 that it’s easy to miss something that might be important one day. This thought crossed my mind when reviewing an article about Teams management that mentioned a Microsoft article titled “How different technologies effect Microsoft Teams sign-in.” The article covers how modern authentication, multi-factor authentication, and other factors influence how Teams clients connect to the service.
It’s been a couple of years since I last had the need to investigate Teams sign-in. In that time, everything has worked smoothly, and I’ve not encountered a problem using the desktop, browser (including the Teams Progressive Web App (PWA)), and mobile clients. For sure, other issues have occurred in that time, but once something works, there’s no point in going looking for trouble.
Tenant Identifiers Control Teams Client Sign-ins
The article is an interesting and helpful read. The standout point I learned covers the RestrictTeamsSignInToAccountsFromTenantList registry value, which governs the set of Azure AD tenants that a Teams desktop client can sign into. The value can be inserted into the Windows registry manually or via policy (documented here for an administrative template file). MacOS devices support a similar capability using a PLIST file.
The key holds Azure AD tenant identifiers. Typically, a client only ever signs into their home tenant, so there’s only a single value. To find your tenant identifier, go to the overview page of the Azure AD admin center. You’ll find the identifier listed under basic information. From PowerShell, run the Get-MgOrganization cmdlet:
Connect-MgGraph Welcome To Microsoft Graph! Write-Host "Tenant Id is" (Get-MgOrganization).Id Tenant Id is a662313f-14fc-43a2-9a7a-d2e27f4f3478
Blocking Teams Client Sign-ins from Desktops
To impose the block, use the RegEdit utility to open the system registry and insert a String value for RestrictTeamsSignInToAccountsFromTenantList. Teams checks three places to see if a block exists. The first two are for policy settings, the last is for an ad-hoc registry update for a specific PC:
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Cloud\Office\16.0\Teams HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\Teams HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Teams
Figure 1 shows the block in place in the system registry. I had to create a key for Teams under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\ first. If multiple tenants are acceptable, enter the set of tenant identifiers, separating each value with a comma.
After updating the registry, the next time the Teams desktop client attempts to sign in, it can only do so using an account belonging to the Azure AD tenant. Any other attempt fails (Figure 2) and the user is told that they can’t use the specified account with Teams on the device.
Restriction Only for Teams Desktop
Being able to restrict desktop connections is useful, but it won’t stop people from using the browser client to connect to a tenant from a device. Nor will it stop them using mobile devices to connect. The block has no effect on guest memberships in host tenants either. These connections depend on being able to sign into the home tenant and once that happens, the guest memberships associated with the sign-in account are available. If you want to control outbound guest memberships for users in a tenant, use a cross-tenant access policy.
Not enough hours exist in the day to track change within Microsoft 365. We do our test to monitor what happens to keep the book updated with the most important information. Sometimes we miss things. This was one of those times. We’ll try to do better in the future.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.