Use SDK Cmdlets to Create or Update Password Protection Policy Settings

A reader asks if the script written for the article about updating the Entra ID banned password list can be used to update other settings in the Entra ID password protection policy. The answer is “of course.” The code is PowerShell, and it can be adapted to update any of the password protection settings found in the Entra admin center (Figure 1).

A few considerations must be remembered when updating the Entra ID password protection policy:

• You don’t need additional licenses to use the default password protection policy. If you create a custom policy by updating settings, user accounts must be licensed with Entra P1 or P2.
• Custom password policy settings are immediately effective across the entire tenant. You can’t assign a custom password policy to specific users or groups.
• In a hybrid environment, password protection can extend to Active Directory.

Creating a Password Protection Policy

The underlying concepts for creating a custom password policy are similar to the management of other Entra ID policies (like the Microsoft 365 groups policy):

Check if a custom policy exists, or rather, a directory setting object created using the directory setting template for password rules. The template always has the identifier 5cf42378-d67d-4f36-ba46-e8b86229381d, so we can check if a custom password protection policy exists follows:

$Policy = (Get-MgBetaDirectorySetting | Where-Object {$_.TemplateId -eq "5cf42378-d67d-4f36-ba46-e8b86229381d"})

A client-side filter is used because the Graph API does not support server-side filtering against template identifiers.

If a password policy object is not available, you can create a new password policy object. The values for the policy settings are in a hash table containing an array of values. Each value (a setting) is a hash table consisting of the setting name and its value. For example, this code creates the hash table to hold the setting for lockout duration:

$Value5 = @{}
$Value5.Add("Name", "LockoutDurationInSeconds")
$Value5.Add("Value", $LockoutDuration -as [int32])

After populating values for all settings (or just the ones that are different from the default), run the New-MgBetaDirectorySetting cmdlet to create the new custom password policy:

$NewBannedListParameters = @{}
$NewBannedListParameters.Add("templateId", "5cf42378-d67d-4f36-ba46-e8b86229381d")
$NewBannedListParameters.Add("values", ($Value1, $Value2, $Value3, $Value4, $Value5, $Value6))
$Policy = New-MgBetaDirectorySetting -BodyParameter $NewBannedListParameters -ErrorAction Stop

Updating the Password Protection Policy

If a custom policy already exists, fetch the policy settings, update the value for the settings that you want to change, and use the Update-MgBetaDirectorySetting cmdlet to update the policy. This example changes the lock out duration time to 120 seconds (the default is 60 seconds):

[array]$PolicyValues = Get-MgBetaDirectorySetting -DirectorySettingId $Policy.Id | Select-Object -ExpandProperty Values
($PolicyValues | Where-Object {$_.Name -eq "LockOutDurationInSeconds"}).Value = 120
Update-MgBetaDirectorySetting -DirectorySettingId $Policy.id -Values $PolicyValues -ErrorAction Stop

The code for these operations is the same as used in the script to update the banned passwords list. Grab what you need from that script and repurpose it to do whatever you need to. For instance, some organizations like to validate that the password policy settings in the tenants that they manage are consistent and up to date. This is easily done on a periodic basis by creating a PowerShell runbook in Azure Automation. I imagine that checking the password policy would only be one of the Entra ID configuration checks that such a runbook would process. At least, that’s how I would do it.

Next Step – Testing Configurations

The Maester utility includes some checks against the password policy and it would be easy to expand test coverage to whatever aspect of the password policy you consider needs to be checked. Once you’ve mastered programmatic manipulation of the Entra ID password protection policy settings, anything is possible.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!

Making Conditional Access and the My Sign-Ins Portal Work Better

A couple of weeks ago, I attended a keynote at the TEC 2025 conference where Alex Simons, Microsoft Corporate VP for Entra, discussed the investments Entra is making to develop agents to help tenant administrators to work smarter. There’s a cost to these agents in the form of Entra premium licenses and the security compute units required to run the agents. Microsoft’s bet is that they can deliver sufficient value to customers through agents to take the cost question off the table. Time will tell.

The Conditional Access optimization agent is one of the agents Microsoft has available in preview. I think both agents can do more and have said so both in print and in person. At this point, the conditional access agent seems more practical and likely to have an impact simply because it’s so easy to screw up conditional access policies.

Which brings me to a LinkedIn post by David Nündel reporting that Microsoft has exposed several additional first-party applications in the Entra admin center. There’s nothing really surprising here because Microsoft 365 and Entra ID are constructed from many multitenant applications. Instances of these applications exist in customer tenants (or rather, service principals for the applications) that can then be used in different aspects of tenant management.

Applications and the My Sign-Ins Portal

What is surprising and useful is that the newly-exposed applications relate to the My Sign-ins portal where users can perform actions such as changing their password, removing themselves as guest accounts from other Microsoft 365 tenants, and viewing recent sign-in activity (Figure 1).

The point is that the My Sign-ins portal relies on access to several applications to display the information revealed by the various menu options. If access to the applications is blocked by something like a conditional access policy, then the portal cannot function. And as it so happens, the newly revealed applications are those that are needed by the My Sign-Ins portal. Six applications are in the set with the following display names and application identifiers:

• My Signins: 19db86c3-b2b9-44cc-b339-36da233a3be2
• My Profile: 8c59ead7-d703-4a27-9e55-c96a0054c8d2
• Microsoft App Access Panel: 0000000c-0000-0000-c000-000000000000
• AADReporting: 1b912ec3-a9dd-4c4d-a53e-76aa7adb28d7
• Windows Azure Active Directory: 00000002-0000-0000-c000-000000000000
• Azure Credential Configuration Endpoint Service: ea890292-c8c8-4433-b5ea-b09d0668e1a6

Checking Service Principals for the My Sign-Ins Portal Applications

Service principals for most or maybe all of these applications are likely already present in your tenant. When I checked using the Microsoft Graph PowerShell SDK command shown below, only the My SignIns application was missing:

Get-MgServicePrincipal -filter "displayName eq 'Azure Credential Configuration Endpoint Service' or displayName eq 'Windows Azure Active Directory' or displayName eq 'AADReporting' or displayName eq 'Microsoft App Access Panel' or displayName eq 'My Profile' or displayName eq 'My SignIns'" | Format-Table DisplayName, Id, AppId

DisplayName                                     Id                                   AppId
-----------                                     --                                   -----
My Profile                                      1f1f813e-0778-4b5b-a379-a924c97e023f 8c59ead7-d703-4a27-9e55-c96a0054c8d2
AADReporting                                    31bd9b44-bc6b-42df-9be6-3030109b84a5 1b912ec3-a9dd-4c4d-a53e-76aa7adb28d7
Microsoft App Access Panel                      10334c63-ac46-4b2a-a80a-dc9c62e34dd8 0000000c-0000-0000-c000-000000000000
Windows Azure Active Directory                  2be71509-6ab9-44d7-bfd8-eff4e50bfc7c 00000002-0000-0000-c000-000000000000
Azure Credential Configuration Endpoint Service 6d1fdc7c-f64b-4aeb-9133-5246b467035c ea890292-c8c8-4433-b5ea-b09d0668e1a6

The problem was easily fixed by running the New-MgServicePrincipal cmdlet:

New-MgServicePrincipal -AppId 19db86c3-b2b9-44cc-b339-36da233a3be2

DisplayName Id                                   AppId                                SignInAudience      ServicePrincipalType
----------- --                                   -----                                --------------      --------------------
My Signins  a7cda215-2932-4042-8e3e-631ecf7ae23b 19db86c3-b2b9-44cc-b339-36da233a3be2 AzureADMultipleOrgs Application

The command to create a service principal from an application identifier works because the My SignIns application is a multitenant application owned by Microsoft. We can prove this by using the tenant relationship API to check the value of the identifier for the owning tenant. Using the Find-MgTenantRelationshipTenantInformationByTenantId cmdlet requires the Graph CrossTenantInformation.ReadBasic.All permission:

$AppTenantOwner = (Get-MgServicePrincipal -ServicePrincipalId a7cda215-2932-4042-8e3e-631ecf7ae23b).AppOwnerOrganizationId
Find-MgTenantRelationshipTenantInformationByTenantId -TenantId $AppTenantOwner
Write-Host ("The tenant name is {0} and its default domain is {1}" -f $TenantInfo.displayName, $TenantInfo.DefaultDomainName)

The tenant name is Microsoft Services and its default domain is sharepoint.com

No Point in Repeating What’s Already Available

With all the applications in place, you can use them in conditional access policies. I don’t like repeating information that’s already online, and I hate seeing many different descriptions of a new feature published by people who haven’t bothered to add any personal insight or knowledge to help others understand the technology better.

With that point in mind, you can read about how these applications could be used in a description of configuring conditional access for guest users by MVP Kenneth Van Surksum. Kenneth adds a few more applications to the “must exclude from blocking” list, so it’s important that you read the article. Excluding applications in conditional access policies simply allows users to access applications that they need to do their jobs, or to make functionality work, like the exclusion required by Outlook to handle sensitivity labels.

Now all I want to know is whether the Entra conditional access optimization agent is ready to optimize for this condition. I suspect not, because it’s clear that first generation agents solve immediate issues (like stopping people from locking themselves out) rather than delivering great insight into more subtle policy details.

Home-Brewed PowerShell or Microsoft Solutions for Guest Account Management

A recent podcast from the genial Merill Fernando featured Microsoft’s Jeremy Conley to talk about “how to really govern guest access.” The tagline “many tenants have 2-4x more guests than employees” captures the focus of the episode (a good listen) and while many organizations might not believe that guest accounts are quite so numerous in their Microsoft 365 tenants, the simple fact is that it’s all too easy to accumulate a vast collection of guests.

Microsoft 365 is responsible for this sad state of affairs. I started talking about the problems of guest accounts “going bad” (aging) soon after the introduction of Azure AD guest accounts for Office 365 groups in 2016 and the situation hasn’t improved much since. Things really took off with the introduction of Teams in 2017 and later, the adoption of guest accounts by SharePoint Online as the basis for sharing. My basic recommendation has always been to review guest accounts annually with the aim of removing unused guests.

Use Entra ID Governance or PowerShell for Guest Account Management

Microsoft has solutions to help, but only if organizations invest in Entra P2 licenses (naturally) to liberate ID governance features like lifecycle management and access reviews. If you can afford the licenses, you should certainly investigate using lifecycle management and access reviews to control guest accounts. But you don’t need to spend any money on additional licenses because controlling guest accounts is a reasonably straightforward task using PowerShell. Let’s discuss some of the tactics that tenants could adopt for guest management.

First, Microsoft doesn’t implement an expiration date for guest accounts, but this is easily done by assigning an expiration date to guest accounts and using that date as the basis for checking if guest accounts are still needed.

For any type of guest account management, it’s a good idea to review guest sign-in activity. If a guest account doesn’t sign into a tenant within a certain period (say, 90 days), it’s probably obsolete and can be removed.

Entra ID supports the concepts of account sponsorship. In other words, one or more sponsor accounts can be associated with member or guest accounts. Sponsors are not assigned by default, but setting a default sponsor is easily done for guest accounts. The problem with default sponsors is that the selected account might not have any insight into how a guest account is used, but a default sponsor is better than none, and the lack of activity should always be the primary reason for considering an account to be inactive and a candidate for removal.

Sponsors are supposed to know why an account exists, so if a guest account is deemed obsolete due to lack of sign-in activity, you can report this fact and use the report data to contact the sponsors to ask if accounts should be removed or kept.

The Need to Nag Sponsors

One thing I haven’t done yet is to send nagging email to account sponsors to say that their sponsored guest accounts will be automatically removed in a week or so if they don’t reply with a justification for keeping the accounts. This is a good example of where a scheduled Azure Automation runbook is a good choice to run the code to check for obsolete guest accounts and email the account sponsors. I must write that script!

No one wants to remove guest accounts that are required for business purposes. Teams is probably the best example of where important guest accounts that appear underused might exist. I’ve documented five practical actions to manage guest accounts used with Teams topic in this article. Enforcing multifactor authentication for guest accounts through a conditional access policy is a critical step.

Act to Make Sure Your Tenant Implements Guest Account Management

Whether you decide to manage guest accounts using your own code or with Microsoft’s solutions really doesn’t matter. The important thing is to manage guest accounts, especially in terms of a regular clean-out of obsolete accounts. Insisting on multifactor authentication removes most of any security risk associated with having some underused guest accounts in Entra ID, but who doesn’t like a clean directory?

Need some assistance to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Should Microsoft 365 Tenants Disable Keep Me Signed In?

When I wrote about the Entra ID Keep Me Signed In (KMSI) feature in February 2022, I concluded that growing threats might have made the feature less valuable than it once was. Like anything to do with Microsoft 365, the passing of time requires re-evaluation of attitudes and opinions, and this is true for KMSI too. Here’s my best attempt at summarizing the current state of the art.

Recapping How the Keep Me Signed In Feature Works

As a recap, KMSI is the option presented to users after they authenticate to “stay signed in” to reduce the number of times Entra ID forces the user to sign in. If the user chooses to stay signed in by choosing the Yes option (Figure 1), Entra ID creates a persistent authentication cookie that can last for up to 90 days (as opposed to 24 hours, which is the lifetime of a non-persistent cookie). With a persistent autentication cookie available, the user can connect to applications without signing in for the lifetime of the cookie. Because the cookie is persistent, it doesn’t matter if the browser session is restarted.

The Don’t show this again checkbox has nothing to do with the creation of the persistent authentication cookie. The checkbox controls whether Entra displays the prompt on the device for future sign-ins.

Obviously, a persistent authentication cookie is a bad idea if workstations are shared, but when workstations are personal and only used by a single person, keep me signed in is a nice way to reduce the friction of signing in. In fact, the Entra ID sign-in flow contains some logic to detect if a sign-in originates from a shared device and won’t show the stay signed in screen in this case. The same is true if Entra ID considers a sign-on to be high risk.

Clearing browser cookies on a workstation will remove the persistent authentication cookie.

Conditional Policies and Sign-in Frequency

Conditional access policies can interfere with the operation of persistent authentication cookies. If a conditional access policy insists that users reauthenticate based on a certain frequency, the full authentication process is invoked, and users must provide credentials. Some tenants impose unreasonable demands on users (or just guest accounts) and insist on very frequent authentication, so it’s a matter of achieving balance between annoying users and maintaining the desired level of security.

Considering the Question of Enabling Keep Me Signed In

All of which brings me back to the question of whether Microsoft 365 tenants should enable or disable KMSI. Generally speaking, I don’t see anything wrong with KMSI when the following conditions are true:

• People use personal rather than shared workstations. Authentication processing for people who use shared workstations can be controlled by specific conditional access policies.
• Strong multi-factor authentication is in place to ensure that the initial authentication is secure and is unlikely to be compromised by external attackers. In other words, use the Microsoft authenticator app or passkeys.
• Conditional access policies are in place to impose a reasonable sign-in frequency. Monthly seems about right. After using a weekly frequency for the last few years (for one tenant that I access frequently as a guest), I think this interval creates too much friction.

As always, the first order of business is to prevent user accounts being compromised. If an account is not compromised, KMSI is unlikely to cause a problem. The widespread adoption of continuous access evaluation by Microsoft 365 workloads makes closing off compromised account access easier, but that’s no excuse to avoid deploying strong multifactor authentication everywhere to protect every Microsoft 365 account.

Configuring Keep Me Signed In

To configure KMSI for everyone in a tenant, use the checkbox in User settings in the Entra admin center (Figure 2). KMSI is either enabled or disabled. It can’t be enabled for a specific group of users and disabled for everyone else.

KMSI is Fine in the Right Conditions

Microsoft 365 users have enough on their plate to cope with the ongoing and constant change in the apps they use daily. Reducing friction from sign-ins through features like KMSI seems like a good idea, providing it can be done securely and doesn’t compromise the tenant. Deploying strong multifactor authentication and effective conditional access policies go a long way to establishing the right conditions for KMSI. But if your tenant is open to compromise because it still uses single factor authentication (passwords) or lets people use weak multifactor authentication methods, don’t blame KMSI when you are compromised. At that point, persistent authentication cookies are the least of your worries.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.

Customize the Microsoft 365 Profile Card Through the Admin Center

A July 3 LinkedIn post by Microsoft’s Wictor Wilén revealed that the Settings section of the Microsoft 365 admin center now has a People Settings section where tenant administrators and people administrators can customize the properties that appear on the Microsoft 365 people card. Figure 1 shows the properties available for inclusion in the profile card.

No Custom Properties

The thing about the set of properties shown by the Microsoft 365 admin center is that they don’t include any custom properties (the Exchange custom properties referred to by Entra ID as the on-premises extension properties) added to the profile card through the Microsoft Graph. To keep focus, properties ingested from another source, like Copilot connectors for people data, are out of scope for this discussion.

For example, the profile card for my tenant features three custom properties for Employee Id, Employee Type, and Cost Center (see this article about how to customize the Microsoft 365 user profile card with PowerShell). Similar properties are in the list shown in Figure 1, but these are Entra ID properties rather than the custom properties I used.

Two of the properties (EmployeeId and EmployeeType) have been available in Entra ID for several years, but never featured in the set surfaced in the profile card (which is why I used custom attributes)

The CostCenter property is part of the CompanyDetail Graph resource type that’s currently in beta. Looking at the other optional properties listed in Figure 1, we find that the Division property is also part of the CompanyDetail resource, while the Role property is part of the PositionDetail resource, another beta resource.

Because these properties are in beta, you cannot update them for user accounts through the Entra admin center or Microsoft 365 admin center. Instead, you’ll need to use cmdlets like New-MgBetaUserProfilePosition (which updates the Role property), or the Update-MgUser cmdlet to update the CostCenter and Division properties. As shown below, after updating the properties for a user account, the Get-MgUser cmdlet can retrieve the updated values:

$Parameters = @{
  employeeOrgData = @{
   "costCenter" = "881-22993"
   "division" = "CEO Office"
  }
}

Update-MgUser -UserId Tony.Redmond@office365itpros.com -BodyParameter $Parameters

Get-MgUser -Userid Tony.Redmond@office365itpros.com -Property id, displayName, userPrincipalName, employeeOrgData | Select-Object -ExpandProperty employeeOrgData

CostCenter Division
---------- --------
881-22993  CEO Office

Microsoft 365 Profile Card In a State of Transition

The Microsoft 365 profile card is in a state of transition. Some properties come from Entra ID, and some come from SharePoint Online, which can end up in a messy profile card with apparent duplications. Add in some custom properties derived from Exchange custom attributes, and it’s a recipe for confusion.

The good news is that Microsoft is attempting to solve the problem by defining the properties required by Microsoft 365 tenants in Graph resources. If Graph resources include rich descriptions of about people and their roles, then there’ll be no need to use custom properties.

Tenants use custom properties today because it has been the only way to present customized information about people on the profile card. A migration to move values from custom to standard properties will have to occur in the future. For example, my tenant needs to extract values from the custom properties used by the profile card today and transfer the values to the default Graph properties. The transition will be completed by updating the set of properties shown on the user profile card to use the default rather than custom properties. You can download a script from the Office365itpros GitHub repository that demonstrates the general principle.

More Settings for the Microsoft 365 Profile Card to Come

The big expansion of the People Settings section in the Microsoft 365 admin center needs to be filled with more than the single option to customize the people card. I expect that Microsoft will use the page to present all the settings that affect the profile card, including the display of personal pronouns and name pronunciation recordings. It just takes time to roll these changes out, but I wouldn’t be surprised to see the other settings appear in the Microsoft 365 admin center before the end of the year.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

New Summary Methods for Entra ID Authentication Methods

Three new Entra ID Graph resources are available in the authentication methods usage reports API to help track adoption of authentication methods, especially the progress towards usage of strong authentication methods for multifactor authentication. It’s easy enough to create a report detailing the authentication methods in use with PowerShell. These resources deliver summary information in a very accessible manner, providing that you have the necessary Entra P1 or P2 licenses needed to access report data via the Graph.

Microsoft doesn’t add to the Graph without good reason. In this case, it’s likely that these resources and methods will be used for reporting in the Entra admin center. Microsoft Graph PowerShell SDK cmdlets aren’t available for the APIs yet, so the examples below use the Invoke-MgGraphRequest cmdlet to run requests. Like all Entra ID sign-in data, information is available for the last 30 days. To run the requests, the Graph SDK session needs the AuditLog.Read.All permission and the signed-in user must hold one of the roles specified in the documentation like Reports Reader or Security Administrator.

User Events Summary

The userEventsSummary resource provides a list of events associated with user activities to register an authentication method or reset using SSPR. The method supports several different filters to allow events to be found based on user principal name, display name, success or failure, and authentication method. Here’s an example which looks for every matching event that’s available. Only one event is available in my tenant, where a user set up SMS as a secondary authentication method. This isn’t a strong authentication method and the user deserves to be nagged to use a stronger method, like the Microsoft authenticator app.

$Uri = 'https://graph.microsoft.com/beta/reports/authenticationMethods/userEventsSummary'
[array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method GET -OutputType PSObject | Select-Object -ExpandProperty Value

$Data

id                : d93bdb0a-8cb7-4303-a8ef-48c488997c38
feature           : registration
userPrincipalName : John.Jameson@office365itpros.com
userDisplayName   : John Jameson
isSuccess         : True
authMethod        : sms
failureReason     :
eventDateTime     : 01/08/2025 12:35:30

User Registration Method Summary

The userRegistrationMethodSummary resource is a summary of the number of users registered for each authentication method. To access the summary, run the request as follows:

$Uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/usersRegisteredByMethod(includedUserTypes='all',includedUserRoles='all')"
[array]$data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PSObject | Select-Object -ExpandProperty userRegistrationMethodCounts

$Data

authenticationMethod               userCount
--------------------               ---------
password                                   0
email                                     11
mobilePhone                              126
alternateMobilePhone                       0
officePhone                                0
microsoftAuthenticatorPush               115
softwareOneTimePasscode                   15
hardwareOneTimePasscode                    0
microsoftAuthenticatorPasswordless         2
windowsHelloForBusiness                    1
fido2SecurityKey                           0
temporaryAccessPass                        0
securityQuestion                           0
macOsSecureEnclaveKey                      0
passKeyDeviceBound                         1
passKeyDeviceBoundAuthenticator            1
passKeyDeviceBoundWindowsHello             0
externalAuthMethod                         0

User MFA Sign-In Summary

The userMfaSignInSummary list method is the one that interested me the most. Essentially, the report gives a daily sign-in report for 30 days detailing the total sign-ins and the number for MFA and single-factor sign-ins. A record looks like this:

id                  : f7c6b675-e664-44dc-9523-947501b0fac6
createdDateTime     : 15/07/2025 00:00:00
totalSignIns        : 59
singleFactorSignIns : 17
multiFactorSignIns  : 42

I used the report to interrogate the sign-in audit log for days when single-factor sign-ins occurred to discover which accounts and apps are involved. The command used to find single-factor sign-ins for a day looks like this (the beta cmdlet is used because the V1.0 cmdlet doesn’t currently return the authentication requirement):

[array]$SignInRecords = Get-MgBetaAuditLogSignIn -Filter "createdDateTime gt $StartDate and createdDateTime lt $EndDate and AuthenticationRequirement eq 'singleFactorAuthentication' and status/errorCode eq 0" -Sort "createdDateTime DESC"

Figure 1 shows the report output. The idea is that administrators can use this information to figure out why single-factor authentications still happen. Most of the accounts highlighted by the report are guest accounts that don’t use MFA because I disabled the conditional access policy to enforce MFA for guest accounts.

You can download the full script from the Office 365 for IT Pros GitHub repository.

Looking for Usage

Any API is only useful if it has a purpose. Hopefully, these notes spark some ideas for how to use the report data in campaigns to improve multifactor adoption within Microsoft 365 tenants. At least, that’s the general idea…

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Automatic Management of Access Tokens

Some years ago, I wrote about the access (bearer) tokens used by Entra ID. At the time, I focused on the access tokens obtained by apps from https://login.microsoftonline.com rather than those used by the Microsoft Graph PowerShell SDK.

One of the big advantages of using the Microsoft Graph PowerShell SDK is that developers don’t need to manage token renewal. When a script or app runs the Connect-MgGraph cmdlet to authenticate, an access token is obtained to allow cmdlets to run. When that access token approaches its expiration time, the Graph SDK requests a new token automatically.

Unless you knew that automatic renewal happens, you probably won’t realize how the Graph PowerShell SDK acquires and manages access tokens because details of the access token aren’t surfaced by a cmdlet like Get-MgContext. Although Get-MgContext reveals details of the current authentication context such as whether delegated or app-only authentication was used and the scopes (permissions) available to the session, there’s no trace of the access token.

Finding the Access Token Used by a Microsoft Graph PowerShell SDK Interactive Session

Some might be surprised that it’s not easier to find what access token is being used during a Graph PowerShell SDK session. However, automatic token management means that knowing what an access token is and when the token will expire is not information that’s necessary for a session to function, so it’s reasonable to keep the data hidden behind the scenes.

To find the access token, it’s necessary to make a special form of request to any Graph API. The request can be made in an interactive session or an app-only session. This example uses a request against the drives endpoint to retrieve retention label information for a file, but any request will work:

$Uri = ("https://graph.microsoft.com/v1.0/drives/{0}/items/{1}/retentionLabel" -f $OneDriveInfo.Id, $File.Id)
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType HttpResponseMessage

The key point here is that the Invoke-MgGraphRequest cmdlet specifies that it should receive a HTTP response rather than data. The request specified in the URI is simply a way to ask the Graph for the HTTP response. The response contains several interesting components:

Version             : 2.0
Content             : System.Net.Http.DecompressionHandler+GZipDecompressedContent
StatusCode          : OK
ReasonPhrase        : OK
Headers             : {[Cache-Control, System.String[]], [Vary, System.String[]], [Strict-Transport-Security, System.String[]], [request-id, System.String[]]…}
TrailingHeaders     : {}
RequestMessage      : Method: GET, RequestUri: 'https://graph.microsoft.com/v1.0/drives/b!_xwZzApnQEeEWOYGdTfHR_FlEFWmBHl                      JixksigwWMZ_hpEW05Pd_R7OzPT4YdqXq/items/01R343MZ43HNLCSCCT3ZBLLUIJGB3GJ5B3/retentionLabel',
                      Version: 2.0, Content: <null>, Headers:
                      {
                        User-Agent: Mozilla/5.0
                        User-Agent: (Windows NT 10.0; Microsoft Windows 10.0.26100; en-IE)
                        User-Agent: PowerShell/7.5.2
                        User-Agent: Invoke-MgGraphRequest
                        FeatureFlag: 00000003
                        Cache-Control: no-store, no-cache
                        Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IlZrTmh0QjdFajZpSUhRVkRwdmZYeVVldUEyeFFBbFhyR1M

The access token is at the bottom of the output and can be retrieved with:

$Data.RequestMessage.Headers.Authorization.Parameter

Decrypting an Access Token

Isolating the access token makes it easier to copy and input into the jwt.io token decoder. Figure 1 shows the raw JSON output; selecting the claims table tab presents the information in a more easily understood fashion (this reference page also helps).

The decoded token reveals details like the app in use (Microsoft Graph Command Line Tools), its identifier, the user, and the available permissions

"app_displayname": "Microsoft Graph Command Line Tools",
  "appid": "14d82eec-204b-4c2f-b7e8-296a70dab67e",
  "family_name": "Redmond",
  "given_name": "Tony",
  "idtyp": "user",
  "ipaddr": "109.78.233.203",
  "name": "Tony Redmond",
  "oid": "eff4cd58-1bb8-4899-94de-795f656b4a18",
  "scp": "AccessReview.Read.All Agreement.Read.All Analytics.Read APIConnectors.Read.All Application.Read.All Application.ReadWrite.All AppRoleAssignment.ReadWrite.All AuditLog.Read.All AuditLogsQuery.Read.All
...

The token also contain timestamps in UNIX epoch format for when the token was issued and when it will expire. The claims table output shows the date in local time. You can also convert these dates with PowerShell:

$UnixEpochValue = 1752763429
$Date = [DateTimeOffset]::FromUnixTimeSeconds($UnixEpochValue).ToLocalTime().DateTime
Write-Host "UNIX epoch $UnixEpochValue is" $(Get-Date $Date -format 'dd-MMM-yyyy HH:mm')
UNIX epoch 1752763429 is  17-Jul-2025 15:43

Down further in the token you’ll find the wids array, which holds the identifiers for the Entra ID roles held by the user. Remember, during an interactive Graph SDK session the available permissions are the intersection between delegated permissions and administrative roles. In other words, if access to data isn’t available through a permission, it might be through a role.

Reusing a Graph Access Token

You can take the access token used by the Graph interactive session and use it to retrieve information without using a Graph SDK cmdlet. In this code snippet, we prepare a hash table containing the access token formatted in the way that Graph requests expect the data to be presented and use the token with the Invoke-RestMethod cmdlet to find the details of the signed-in user.

$Headers = @{}
$Headers.Add("Authorization", ("{0} {1}" -f $Data.RequestMessage.Headers.Authorization.Scheme, $Data.RequestMessage.Headers.Authorization.Parameter))

$Me = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me" -Headers $Headers
$Me.displayName
Tony Redmond

Interesting But Not Very Useful Information

All of this is firmly in the interesting but not very useful category. If an app wants to make Graph API requests without using the Microsoft Graph PowerShell SDK, it will do the norm and obtain an access token programmatically before running any requests. The permissions available to the app are the set of delegated and application permissions held by the app’s service principal. If the app runs for over an hour, it will need to renew the access token.

Apart from testing code to write this article, I don’t think I have ever looked at the access token in a Microsoft Graph PowerShell SDK session. I might in the future, but right now I can’t think of a good reason why I should.

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Conditional Access Optimization Agent Keeps a Wary Eye on Connections

All around Microsoft, program managers and executives are seeking opportunities to deploy artificial intelligence in products, preferably if that usage justifies the requirement for an additional license. Some of the resulting ideas are good, like the Facilitator agent for Teams group chats. Others need more time to appreciate the use case, if one exists. The point is that you can expect more AI-powered features (whether Copilot in apps or a variety of agents) to appear in Microsoft 365 applications as time passes.

Entra ID Brings AI to the Table

All of which brings me to New innovations in Microsoft Entra to strengthen AI security and identity protection, published on March 24, 2025, where Alex Simons sets out the case for using AI to increase security and explains how Microsoft is applying AI in Entra ID.

Before I go further, let me know how disappointed I am that many technical conferences focusing on Microsoft 365 ignore or give lip service to Entra ID. The foundation of any successful and secure Microsoft 365 tenant is a well-managed Entra ID instance. It’s regrettable that Entra ID doesn’t receive the attention that it should on the schedules for even some major conferences. For instance, the current session lineup for the “Microsoft 365 Community conference” mentions Entra once and Copilot 46 times. That tells a story, mostly in terms of where Microsoft marketing money is going.

Smarter Policy Management Through the Conditional Access Optimization Agent

In any case, my attention was drawn to the Conditional Access Optimization Agent (now in private preview), which offers “smarter policy management.” Apparently, the agent monitors how an Entra ID tenant processes inbound connections to understand where the connections originate, the resources they access, and the authentication paths used. It picks up details like new user accounts and applications. The agent then puts the information together to figure out if the conditional access policies used by the tenant can be optimized.

I like this idea. It’s a good example of applying artificial intelligence to a bounded set of data with a clear intention (that the tenant can alter with custom instructions). Unlike human administrators, some of whom are well capable of assessing the state of health of conditional access within a tenant, agents work all the time with a relentless focus on their instructions and the data they’ve been given.

The claims advanced in the article seem a little misleading (the agent hardly “protected” 700K sign-ins for the example tenant just by watching and processing connection data, and creating a new group containing 16 users to add to an existing conditional access policy isn’t rocket science either), but it’s possible to see the value that such an agent can bring by relieving administrators of the mundane task of reviewing conditional policy settings and sign-in logs on an ongoing basis to look for potential gaps and anomalies worth investigating.

Security Copilot Brings the AI Smarts

The Conditional Access Optimization Agent is one of six Security Copilot agents unveiled on March 24. Getting Security Copilot (the “proactive problem solver”) on board is where the cost arises. It’s hard to know just how much putting manners on your policies will cost because Security Copilot charges on the basis of Security Compute Units (SCU). Provisioned SCUs cost $4/hour in the U.S., but there’s no information available about how many SCUs the Conditional Access Optimization Agent will consume over a month or however long it takes for the agent to come up with its suggestions.

Organizations that use Security Copilot already probably have a good grasp on costs and can estimate (better than I can) the costs to add extra tasks. One way to look at it is that an experienced consultant who knows conditional access inside out might charge a day or two to review a tenant’s policies. For the purpose of easy maths, let’s say that the bill is $2,000, or 500 SCUs. Looking at the situation like that seems to make using Security Copilot a no-brainer. However, it’s a very black and white example and IT is full of grey. It will be interesting to learn about the real-life experience of operational tenants in terms of both agent output and cost.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. 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.

Block ChatGPT Access to OneDrive and SharePoint Files

ChatGPT allows people to connect their personal and work OneDrive accounts. Connecting to OneDrive doesn’t mean that ChatGPT can reason over OneDrive files in the same way that Microsoft 365 Copilot can when it generates responses. However, it does mean that users can upload files from OneDrive for Business or any SharePoint Online site that they can access to interact with their content through ChatGPT. Figure 1 shows ChatGPT summarizes the content of a file uploaded from OneDrive for Business.

Of course, people shouldn’t store very confidential and sensitive information in OneDrive for Business accounts, but they do. And the temptation to use ChatGPT is obvious when the price of a Microsoft 365 Copilot license is high, so what can organizations do to stop this behavior.

ChatGPT Cannot Access Protected Files

One way to block ChatGPT access to OneDrive for Business is to encrypt the files with sensitivity labels. ChatGPT cannot process these files even after the owner of the file uploads them to ChatGPT. Sensitivity label encryption is based on rights management, and ChatGPT cannot authenticate with the rights management service to obtain the use license necessary to access files protected with sensitivity labels. That’s a pretty effective way to stop ChatGPT opening the file to copy its contents into memory to reason over the data. Microsoft 365 Copilot Chat faces much the same barrier if the sensitivity label assigned to a file doesn’t grant the EXTRACT usage right to the signed-in user (the new DLP policy for Microsoft 365 Copilot also uses sensitivity labels but blocks access in a different way).

Block Consent for Users

Not every Microsoft 365 tenant uses sensitivity labels, and even users in tenants that do don’t always protect files the way that they should. A more fundamental way to block ChatGPT access to OneDrive is to prevent users from being able to grant consent for apps (Figure 2). Make sure to select the “do not allow user consent” setting or allow consent for “low impact” apps.

If users can grant consent, the first user who attempts to connect their OneDrive for Business account to ChatGPT will create an enterprise app in Entra ID for ChatGPT with permissions to read user data (Figure 3). Note the permission to read items in all site collections. This is what allows the user to select files from SharePoint Online to upload to ChatGPT.

This isn’t an abnormal situation because many app publishers (including Microsoft) create enterprise apps in customer tenants in the same way. However, it’s better to have administrative oversight over requests to create new enterprise apps. When created, the ChatGPT app will have a service principal to hold its permissions. The same application identifier (e0476654-c1d5-430b-ab80-70cbd947616a) is used in all tenants.

$ChatGPTApp = Get-MgServicePrincipal -Filter "displayName eq 'ChatGPT'"
$ChatGPTApp

DisplayName Id                                   AppId                                SignInAudience                     ServicePrincipalType
----------- --                                   -----                                --------------                     --------------------
ChatGPT     db277364-71ae-4fa4-9b02-370699b75a0a e0476654-c1d5-430b-ab80-70cbd947616a AzureADandPersonalMicrosoftAccount Application

App consent events are captured in the audit log and can be checked there.

Track What’s Happening

If the ChatGPT app exists in a tenant, it’s easy to check if anyone is using it by looking for sign-in events in the Entra ID log. Here’s some PowerShell to check the sign-in logs for anyone using the ChatGPT application:

[array]$Logs = Get-MgAuditLogSignIn -Filter "AppDisplayName eq 'ChatGPT'" -All
$Logs | Group-Object UserDisplayName | Sort-Object Count -Descending | Format-Table Name, Count

Name                Count
----                -----
Kim Akers (She/Her)     5
René Artois             4

A more precise version checks for successful sign-ins using the ChatGPT application:

[array]$Logs = Get-MgAuditLogSignIn -Filter "AppDisplayName eq 'ChatGPT' and status/errorCode eq 0" -All

It’s worth emphasizing that stopping the ChatGPT app does not prevent people from being able ot upload local copies of files synchornized from OneDrive for Business or SharePoint Online to their PC. Sensitivity labels are the only way to protect local copies.

Remove the ChatGPT App

If the ChatGPT app is in use, the easiest way to block ChatGPT access to OneDrive for Business is to remove the service principal for its app:

Remove-MgServicePrincipal -ServicePrincipalId $ChatGPTApp.id

Access won’t terminate immediately because ChatGPT sessions might have obtained access tokens that are still valid, but once those tokens expire (within an hour), ChatGPT won’t be able to authenticate with Entra ID because the enterprise app is no longer present in the tenant. Anyone wanting to use ChatGPT to access OneDrive for Business files after that point will need to seek consent to use the app again. And by now, you’ll have blocked that route!

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

People Administrator is the 116^th Entra ID Role

Message center notification MC992218 (30 January 2025) announces the arrival of the new People administrator role for Entra ID. There’s nothing remarkable about Microsoft creating a new Entra ID roles because People administrator is the 116^th role.

Not every role is used inside every Microsoft 365 tenant. Right now, my tenant uses 36 roles. In fact, the way that things work is that Microsoft defines roles as sets of permissions to allow accounts or apps to perform specific actions. The roles are published as templates which are common across Entra ID and then become “real” roles when first assigned to a holder.

To see the full set of roles, run the Get-MgDirectoryRoleTemplate cmdlet, while to see the set used in a tenant, run Get-MgDirectoryRole. Microsoft documentation also lists the available roles.

New Role to Manage People Settings

People administrator sounds as if it’s like User administrator. In a way, that’s true, but only if equate people with users and assume that the two roles do the same thing, which they don’t. One way of comparing the new roles is that User administrator is all about maintaining user accounts and their attributes whereas People administrator assigns “permissions for managing people-related settings and profile photos without needing the high privileges of Global admin or User admin roles.” In other words, the new role is the implementation of the principle of least privilege to manage settings for the user profile card.

People settings have a very specific meaning within Microsoft 365 and are closely related to the profile card. Along with a bunch of information extracted from different parts of Microsoft 365, you’ll find the user’s photo, pronouns, pronunciation, and custom profiles set by the tenant.

What Assignees with the People Administrator Role Can Do

Holders of the People administrator role will be able to:

• Upload new photos on behalf of users. This capability is controlled by the new user photo update policy. People administrator joins the set of default Entra ID roles allowed to update photos.
• Enable personal pronouns for display on the profile card (Figure 1)
• Enable pronunciation recordings for the profile card.
• Define custom properties for display on the profile card. For instance, many tenants use custom properties to reveal organizational information like cost center designations.

Apart from photos, people administrators cannot update the values that appear in the profile card. Other roles, like User administrator, are required to update settings like change a phone number or a surname.

Processes such as those that update user photos from central (often HR) systems can use the new role instead of a higher-permissioned role like User administrator. This is likely the most important point to review and amend. The other functionality enabled by people administrator are, for now at least, one-off operations. After all, tenants don’t usually customize the properties shown on the people card every week or decide to pronouns off or on periodically.

The interesting aspect of this development is that Microsoft is obviously dedicating resources to building out capabilities around what they call “people-related tasks.” Giving users the ability to record their personal name pronunciation was the most recent example before now. I don’t know what else Microsoft has up their sleeves in this respect, but it’s certainly an interesting area to watch.

Check Your Role Assignments

The advent of the People administrator role is a reminder that some active role assignments might be for elevated roles that aren’t absolutely necessary. It’s probably a good idea to review the set of active and eligible role assignments to decide which remain justified and valid and if any assignments are no longer necessary or require adjustment. Any assignment that’s been in place for a year or more deserves a check. Leaving things alone is a recipe for permission inflation and that’s a horrible thing.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. 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.

No Good Reason Why Users Can Update User Principal Names

Update 24 January 14:00 UTC: Microsoft appears to have reacted and has blocked the ability of users to update their UPNs. Here’s what the Entra admin center now displays when an attempt is made.

Update 26 January: An update released on Twitter by Alex Simons, Microsoft VP of Product Management, Microsoft Identity and Network Access Division, said:

“It was a bug caused by recent update to the service. When we the learned from Entra Advisors about the issue, team immediately rolled back to a known good build.

Fix in the newer build is completed and being rolled out slowly. We will do an internal investigation and PIR to identify the root cause and make process changes to prevent this (and any similar class of issues) from happening in future. Will also review log files for inappropriate usage and notify customers if found.”

It’s unclear if Microsoft has updated the default permissions assigned to Entra user accounts, but it is now possible for unprivileged users to update user principal names through interfaces like the Entra admin center and PowerShell. To be clear, an unprivileged user can update the user principal name for their Entra ID account and not for other accounts. Nevertheless, I can’t think of a good reason why any organization would want to allow people to update something fundamental like a user principal name, but they can.

To test the theory, I created a new account for Eric Hammon and attempted to sign into the Entra admin center. I then navigated to the Users section to access the account properties. As you can see from Figure 1, the user principal name is editable.

I went ahead and updated the account to make the user principal name Eric.B.Hammond@office365itpros.com. For good measure, I uploaded a new user photo. The update proceeded without a problem and the result is shown in Figure 2.

A side effect of updating a user principal name is that the user’s primary SMTP address also changes. This is because of the dual write arrangement between Exchange Online and Entra ID whereby updates to mail-related properties occur in both directories. The update to the user principal name also updates the account’s Mail property, and this ripples through to Exchange Online, meaning that the full set of proxy addresses includes a new primary SMTP address (indicated by SMTP:). The previous primary SMTP address is preserved as a proxy to make sure that Exchange Online can deliver messages addressed to the old primary SMTP address.

Get-Mailbox -identity eric.b.hammond@office365itpros.com | Select-Object -ExpandProperty emailaddresses
SIP:eric.b.hammond@office365itpros.com
SMTP:Eric.B.Hammond@office365itpros.com
smtp:Eric.A.Hammond@office365itpros.com
smtp:Eric.Hammond@office365itpros.com

If administrators reverse the the user principal name, the extra email proxy address will remain in place unless it is explicitly removed. The possibilities of impersonation are obvious. For instance, some could change their user principal name to CEO@office365itpros.com to get that email address and the change their user principal name back to revert to the original value. If administrators aren’t checking audit logs, they might miss this change.

Update User Principal Name with PowerShell

After validating that it is possible for a user to update their user principal name and photo via the Entra admin center, I tried with the Microsoft Graph PowerShell SDK (Figure 3). I expected this to work because much of the Entra admin center is built on top of the Microsoft Graph, especially anything to do with user accounts and groups (you can validate this by running the Graph X-Ray tool).

Essentially, these tests indicate that any tool based on the Microsoft Graph Users API will allow users to update their user principal name. I’m not bothered by the Entra admin center allowing people to update their photo because that facility is available elsewhere, notably in OWA and the new Outlook for Windows.

Blocking Access to the Entra Admin Center

Some control can be exerted for the Entra admin center by setting the option to restrict access to users that hold administrative roles (Figure 4).

This is only a partial block because accounts with relatively unprivileged roles, like Reports Reader, can still access the Entra admin center and update their user principal names. On the other hand, it does block casual access and is therefore a recommended setting to have in place.

Blocking Access to the Microsoft Graph PowerShell SDK

The ability to create an interactive session with the Microsoft Graph PowerShell SDK is governed by controls on the Microsoft Graph Command Line Tools enterprise app. Like other enterprise apps created by third parties for use in multiple Entra ID tenants, the instantiation for the app is a service principal that holds the consented permissions available in Graph SDK sessions. It can also hold a set of users and groups who are allowed to access the app. By default, the list of users assigned to the app is empty, which means that any user can run the Connect-MgGraph cmdlet in a PowerShell session to connect to the Graph.

Obviously, allowing open access to such a powerful capability isn’t a good idea, and tenants should take steps to secure access to the Microsoft Graph Command Line Tools app. With controls in place, anyone who isn’t on the approved list will see an AADSTS50105 error and be blocked from access (Figure 5).

And if you’re blocking access to PowerShell for the Graph SDK, consider doing the same for other Microsoft 365 PowerShellmodules.

No Apparent Justification for People to Update User Principal Names

Microsoft doesn’t make changes without reason, so something must have happened to convince the Entra ID developers to allow users to update user principal names. I can’t think of a convincing reason for such a change, but perhaps the logic will become apparent over time. In the meantime, if you don’t like people being able to change user principal names, consider applying the blocks described above.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Add Eligible and Active PIM Role Assignment Requests

I recently wrote about Microsoft’s recommendation to use the UnifiedRoleDefinition Graph API instead of the older DirectoryRole API. In that article, I show how to use the Microsoft Graph PowerShell SDK to make role assignments to user accounts. Assignments made in this manner are effective immediately. The assignments are permanent and last until an administrator removes them from accounts.

In many Microsoft 365 tenants where a limited set of administrators run operations, permanent role assignments work well. However, in larger tenants, some additional control is often desirable. Microsoft’s answer is Entra ID Privileged Identity Management (PIM), designed to enable administrators “manage, control, and monitor access to important resources in your organization.” PIM assignments can be permanent, but more commonly the assignments are time-limited to allow administrators to perform tasks on a just-in-time basis without their account needing elevated permissions on an ongoing basis. PIM is not part of the basic Entra ID license granted with Microsoft 365 and administrators need a license like Entra ID P2 to use PIM. See this page for more licensing information.

Microsoft’s Recommendation to use Entra Admin Center to Manage PIM Role Assignments

The PIM overview contains the interesting recommendation that tenants should use “PIM to manage active role assignments over using the unifiedRoleAssignment or the directoryRole resource types to manage them directly.” In other words, Microsoft thinks it better to use the GUI built into the Entra admin center to create and manage PIM role assignments. The reason for this might be that the GUI includes guardrails to stop administrators from making mistakes, which is something to avoid when assigning privileged roles.

In any case, PIM organizes role assignments into two categories:

• Eligible assignments are roles granted to users, groups, or service principals (apps) that are not active. These assignments must be activated by the holder (principal) before they can perform the privileged tasks enabled by the role. By default, eligible assignments are activated for a maximum of 8 hours, after which the activation can be extended or renewed.
• Active assignments are roles that are currently available for use. An active assignment can be permanent, but more often in PIM it is time-limited.

Both categories have a schedule, and Graph APIs and SDK cmdlets are available to add requests to add, update, and remove assignments from the schedules.

Creating an Eligible PIM Role Assignment

Here’s the PowerShell code to create a new eligible assignment schedule request to add a user account to the User administrator role. Before the New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest cmdlet can run, a certain amount of setup is necessary to fetch the identifiers for the account and role and define the period during which the assignment is eligible. You also need to decide whether the assignment is for the entire directory or an administrative unit.

$User = Get-MgUser -UserId Lotte.Vetler@office365itpros.com
[array]$DirectoryRoles = Get-MgRoleManagementDirectoryRoleDefinition | Sort-Object DisplayName
$UserAdminRoleId = $DirectoryRoles | Where-Object {$_.DisplayName -eq "User administrator"} | Select-Object -ExpandProperty Id
[string]$StartAssignmentDate = Get-Date -format "yyyy-MM-ddTHH:mm:ssZ"
[string]$EndAssignmentDate = (Get-Date).AddDays(30).ToString("yyyy-MM-ddTHH:mm:ssZ")

$ScheduleInfo = @{}
$ScheduleInfo.Add("startDateTime", $StartAssignmentDate)

$ExpirationInfo = @{}
$ExpirationInfo.Add("type", "afterDateTime")
$ExpirationInfo.Add("endDateTime", $EndAssignmentDate)

$ScheduleInfo.Add("expiration", $ExpirationInfo)

$AssignmentParameters = @{}
$AssignmentParameters.Add("action", "adminAssign")
$AssignmentParameters.Add("justification", "Assign User administrator role to user")
$AssignmentParameters.Add("roleDefinitionId", $UserAdminRoleId)
$AssignmentParameters.Add("directoryScopeId", "/")
$AssignmentParameters.Add("principalId", $User.Id)
$AssignmentParameters.Add("scheduleInfo", $ScheduleInfo)

$Status = New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $AssignmentParameters
If ($Status.Id) {
   Write-Host ("Assignment for user administrator role for {0} added to eligibility schedule" -f $User.displayName)
}

The values in the hash table holding the parameters for the new assignment looks like this:

$AssignmentParameters

Name                           Value
----                           -----
justification                  Assign User administrator role to user
scheduleInfo                   {[startDateTime, 2024-11-12T17:51:03Z], [expiration, System.Collections.Hashtable]}
directoryScopeId               /
roleDefinitionId               fe930be7-5e62-47db-91af-98c3a49a38b1
principalId                    ce0e26f8-da88-4efa-90ad-d16df1d9500d
action                         adminAssign

The result of a successful assignment as seen in the Entra admin center looks like the example shown in Figure 1.

The assigned user receives email about the assignment and can use the link in the message to activate their assignment (Figure 2). See this article about approval workflows that you might like to use to control activations.

Accounts holding the Privileged Role Administrator or Global Administrator role also receive email to inform them about the new assignment.

Creating an Active PIM Role Assignment

The code to create a PIM active role assignment request is like that used for the PIM eligible role assignment request. In this example, we create an active role assignment schedule request for the Groups administrator role and limit the assignment to a six hour period from now. The duration is expressed in ISO8601 duration format, so PT6H means six hours.

$GroupsAdminRoleId = $DirectoryRoles | Where-Object {$_.DisplayName -eq "Groups administrator"} | Select-Object -ExpandProperty Id
[string]$StartAssignmentDate = Get-Date -format "yyyy-MM-ddTHH:mm:ssZ"
$ScheduleInfo = @{}
$ScheduleInfo.Add("startDateTime", $StartAssignmentDate)

$ExpirationInfo = @{}
$ExpirationInfo.Add("type", "afterDuration")
$ExpirationInfo.Add("duration","PT6H")

$ScheduleInfo.Add("expiration", $ExpirationInfo)

$AssignmentParameters = @{}
$AssignmentParameters.Add("action", "adminAssign")
$AssignmentParameters.Add("justification", "Assign Groups administrator role to user")
$AssignmentParameters.Add("roleDefinitionId", $GroupsAdminRoleId)
$AssignmentParameters.Add("directoryScopeId", "/")
$AssignmentParameters.Add("principalId", $User.Id)
$AssignmentParameters.Add("scheduleInfo", $ScheduleInfo)
$Status = New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $AssignmentParameters
If ($Status.Id) {
   Write-Host ("Assignment for Groups administrator role for {0} added to active schedule" -f $User.displayName)
}

To remove a role assignment from a schedule, create another role assignment schedule request and state the action to be “adminRemove” rather than “adminAssign.” For example, the request to remove the assignment request created above is:

$AssignmentParameters = @{}
$AssignmentParameters.Add("action", "adminRemove")
$AssignmentParameters.Add("justification", "Remove Groups administrator role to user")
$AssignmentParameters.Add("roleDefinitionId", $GroupsAdminRoleId)
$AssignmentParameters.Add("directoryScopeId", "/")
$AssignmentParameters.Add("principalId", $User.Id)
$Status = New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $AssignmentParameters#
If ($Status.Status -eq "Revoked") { Write-Host "Active assignment revoked" }

Required Permissions for PIM

Adding role assignments requires the RoleManagement.ReadWrite.Directory permission. If you’re only reading role information, the RoleManagement.Read.Directory permission is sufficient. In addition, when using delegated permissions, read operations are only possible when the signed-in account holds one of the Global Reader, Security Operator, Security Reader, Security Administrator, or Privileged Role Administrator roles. Write operations, like adding a new role assignment to a schedule, require the signed-in account to hold the Privileged Role Administrator (or Global administrator) role.

Most Will Use the Entra Admin Center

Although it’s straightforward to create and manage PIM role assignment schedule requests with PowerShell, it’s easier to use the Entra admin center. Microsoft has done the work to create and refine the GUI and create the necessary checks to make sure that administrators don’t do something silly. I suspect that most administrators will interact with PIM through the Entra admin center, but it’s nice to know that the option to automate with PowerShell exists too.

Need more advice about how to write PowerShell for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Dynamic Group Rule Builder Blocks Contains Operators

It was interesting to read message center notification MC705357 (January 9, 2024) and learn that Microsoft implemented a change to the dynamic group rule builder GUI in both the Entra ID and Intune admin centers to “encourage performant dynamic group rules.” In other words, Microsoft detected that some of the membership rules created for dynamic groups are not as efficient as they might be.

In this instance, Microsoft removed the ability to use the ‘contains’ and ‘notContains’ operators from the dynamic group rule builder. The logic is that these operators are “less performant.” Microsoft says that rules containing the contains or notContains operators “should only be used when absolutely necessary.” The change is effective now.

Membership Rule Processing

Entra ID processes membership rules by querying its database to compute the set of members for dynamic groups. This processing happens in the background. Membership changes due to updated rules or the addition of new objects to process usually happen reasonably quickly, but as the number of dynamic groups (including those used by dynamic teams) plus dynamic administrative units grow, the resources consumed to update group memberships must be noticeable, even in an infrastructure like Microsoft 365.

If the unavailability of system resources slow the processing updates, inaccuracies grow in group memberships. Those inaccuracies might or might not affect users. For instance, administrators change the properties of an account to bring it within the scope of a membership rule for a Microsoft 365 group. The user can’t access group resources like documents in its SharePoint Online site or channel conversations until Entra ID processes the membership change.

No Effect on Existing Dynamic Groups

An important point to realize is that the change does not affect dynamic groups that have rules that use the “less performant” operators. Entra ID will continue to use these rules to process membership updates. The change only kicks in if you want to update the membership rule. At that point, you’ll discover that the admin center displays an error to say that some items could not be displayed in the rule builder. This is because of the presence of either the contains or notContains operator in the rule (Figure 1).

Use the Dynamic Group Rule Builder to Change Rules

It’s good that the change has no impact on existing groups, but what happens when you create new dynamic groups or need to change the membership rule for an existing group? Two options are available:

Edit the membership rule without using the rule builder. Click the Edit icon and compose the rule. Often this is the quickest and simplest way to proceed. As shown in Figure 1, the contains and notContains operators can be included in the rule. In this case, the rule finds any member or guest account that has the string “United” in the country property, so it finds accounts with a country property like “United States” and “United Kingdom.”

Remove the membership rule and replace it with another rule. To do this, edit the rule to remove it. When you exit the editor, the rule builder recognizes that the contains operators are not present and allows you to compose a new rule. In Figure 2, I’ve updated the rule to do an equals comparison against the expected strings. Another way of doing the same thing is to use the in operator to compare against a set of values. For example, (user.country -in [“United Status”,”United Kingdom”])

It’s not always possible to change a rule that uses the contains operator to gain the same effect. In these situations, the only alternative is to edit the rule manually.

An Innocuous Change

Some might ask why Microsoft removed the ability to create a type of rule that still works. It’s clear that something provoked the decision, probably telemetry that identified a performance issue caused by these rules. It would have been much worse if Microsoft had stopped rules working and forced customers to update rules to a supported configuration. This change shouldn’t have much impact, once you understand the options.

Make sure that you’re not surprised about changes that appear inside Entra ID and Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Use PowerShell to Find and Report Details of Admin Consent Requests

Dinesh asked “How can I generate a report of Admin Consent Requests received by Entra ID? I’m specifically looking for information such as who sent the consent request, which application was involved, what API permissions the application requested, and how many users have already requested the consent.”

I was busy and didn’t pay too much attention to the question apart from offering some suggestions about using Fiddler (or even Graph X-Ray) to see what requests the Entra ID admin center generated. Like in many situations with Microsoft 365, the key to starting a PowerShell script is to find out what cmdlet to fetch information with.

In any case, I was delighted when Dinesh reported that he had found the necessary cmdlet (Get-MgIdentityGovernanceAppConsentRequest from the Microsoft Graph PowerShell SDK) to answer his question. It’s always great (and far too rare) when someone who asks a question goes ahead to do the necessary research to answer their own question.

Workflow for Admin Consent Requests

Administrator consent requests are an Entra ID workflow to allow users to request administrators to grant consent for enterprise applications that they want to use. You do not want end users to grant consent for applications to access data, but you also don’t want to get in the way of people doing real work. The answer is to enable the workflow to permit users to submit requests for administrator approval.

When the workflow is active, when users attempt to use an enterprise application with permissions that are not yet approved, Entra ID prompts the user to request approval. Figure 1 shows what happens when a user attempts to sign into the Microsoft Technical Community.

The first time this happens in a tenant, the application attempts to create a service principal as its representation in the tenant. This cannot happen until consent is gained for the permissions it needs. In this case, the user cannot grant consent, so Entra ID routes the request to the users identified as approvers. Requests arrive via email (Figure 2). The user who generates the request also receives email notification that their request is under review.

Oddly, the request email shows the alternative email address for the requestor instead of their primary SMTP address. This might be a glitch. In any case, when the reviewer opens the request in the Entra ID admin center, they see details of the application (Figure 3). To approve the request, they must sign in to see the requested permissions and proceed to give or refuse consent.

The user who generates a request receives an email notification to tell them about the reviewer’s decision. Overall, it’s a simple but effective workflow.

The Code

Dinesh’s code works and is a good example of extracting and processing Entra ID information. I reworked it a little to add a check for high-profile permissions that should draw additional attention from administrators. These permissions include the ability to read everything from the directory, access all users, groups, sites, and so on. The data returned for consent requests includes some user details (user principal name and identifier). I added a call to Get-MgUser to retrieve other details that might be useful such as their department, job title, and country.

You can download the script from GitHub. Normal caveats apply – better error checking and formatting of the output would be beneficial. Nevertheless, the code proves the principles involved in using PowerShell to retrieve and process admin consent requests.

The Power of Community

I receive many requests for assistance, some of which are along the lines of “please write a script for me.” I ignore these requests because I am not in the business of doing work that other people should do for themselves. It’s always better when someone works out how to accomplish a task using their own brainpower, just like Dinesh did.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Registration Campaigns Push for Stronger Authentication Methods

A year ago, Microsoft VP for Identity Security Alex Weinert spoke at the TEC 2022 conference and was critical about the slow adoption of multi-factor authentication (MFA) within Microsoft 365 tenants. At the time, only 26.64% of all Entra ID accounts used MFA (34.15% for accounts holding an administrative role). During his presentation, Alex talked about some of the initiatives Microsoft planned to drive MFA adoption and more secure authentication, including changes to the authenticator app, the introduction of authenticator-lite in Outlook mobile, and differentiation of authentication strengths for conditional access policies.

The changes discussed at TEC 2022 are now in production, but there’s still room for improvement. On July 17, Alex Weinert published a Microsoft Technical Community post titled Advancing Modern Strong Authentication focused on Microsoft’s push to get users off SMS responses to use a stronger method such as the Authenticator app. Alex noted that Microsoft telemetry records SMS and voice phone calls still being used for 44% of responses, He also said that Microsoft research concludes that SMS is 40% less effective at repelling compromise by bad actors compared to the Authenticator app, possibly due to an increase in man-in-the-middle attacks.

Entra ID includes a feature called registration campaigns to help organizations move users to the Authenticator app. Essentially, administrators create a campaign and users start to see prompts to “improve your sign ins.” Users can snooze the prompt for a predefined period of up to 14 days but eventually they’ll need to select the authentication method defined for the campaign (the Authenticator app). Nagging until you do something…

The Mail Announcing the Registration Campaign Arrives

Bringing things back to TEC, as I prepared to travel to Atlanta for the 2023 conference this week, I received a note from Microsoft saying that users in my tenant that use SMS and voice methods for MFA responses would be prompted to switch to the Authenticator app (Figure 1).

Good as it is for users to upgrade their authentication method, I didn’t want users to receive an unexpected “Improve Your Sign-in” prompt while I was out of the office. Atlanta isn’t too far away, but the five hours dislocation from my normal working hours would definitely interfere with communications.

Pausing the Campaign

The reason why I received the notification was that the tenant settings for Entra ID had an enabled campaign. I’m not quite sure how the campaign was initiated, but it’s probably due to something I did in the past when checking out new Entra ID features. Microsoft complied and launched the campaign by warning me that it was about to begin.

The short-term solution is simple. I edited the campaign settings to put it into a disabled state (Figure 2).

The available settings for a registration campaign are Disabled, Enabled, and Microsoft controlled. The latter allows Microsoft to control a registration campaign, which is fine if everyone’s prepared for the change. For instance, it’s a good idea to help users install the Authenticator app on their mobile devices in advance.

It’s also wise to brief people about why using the Authenticator app is easy. The first time a user sees number matching and the additional context (location) displayed by the app when responding to an MFA challenge, they might conclude that it’s a more complex process than typing in a simple code received by SMS. But when they understand that number matching makes it harder for attackers to compromise MFA and the additional context helps them recognize suspicious activity (like an unexpected app provoking a challenge), it usually leads to a good result.

The Campaign Relaunches Soon

It’s a good idea to get rid of SMS and voice responses to MFA challenges, so I’ll relaunch the registration campaign when I return from TEC 2023. Life should be calmer then. At least, that’s the plan until the next emergency arises.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Entra ID and the rest of the Microsoft 365 ecosystem. 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.

Improvements to Cross-Tenant Access Settings Based on Customer Feedback

Microsoft launched Azure AD (Entra ID) cross-tenant access settings in February 2022 to support the introduction of Teams shared channels. The new mechanism established a way for tenants to trust each other and created the basis for sharing. Reflecting the experience of how customers use cross-tenant access settings (Figure 1) in production, on August 30 Microsoft announced some changes due to roll out soon.

The changes are:

• Custom roles for cross-access tenant policy management.
• New method of storing partner policies.
• Integration of blocks in cross-tenant access settings when sending B2B invitations.

Like any other change, these updates might not affect how you work. I think it’s fair to say that the larger the tenant, the more important the updates are to you. But let’s consider what the changes do.

Custom Roles for Cross-Tenant Policy Management

Up to now, only users holding the global administrator or security administrator roles can manage cross-tenant access settings. For most tenants, this arrangement works well. Creating a new cross-tenant arrangement is not something that happens every day and requires coordination with the administrators of the other tenant.

Tenants with Entra ID Premium P1 or P2 licenses can create custom administrative roles to allow users perform specific management tasks for Entra ID. This capability now extends to cross-tenant access policy management where roles such as “Cross-tenant policy reader” might be created to allow users to review but not update settings. Again, this isn’t something that every tenant needs or wants, but at least tenants now have the flexibility to use a custom role to manage cross-tenant access settings if they see value in it.

New Method of Storing Partner Policies

According to Microsoft’s posts, some tenants need to manage cross-tenant access settings for thousands of partners (hopefully, they don’t do this manually and use some form of automation such as PowerShell scripts). Microsoft noted that the way Entra ID stored cross-tenant policy configurations limited the number of individual partner policies that a tenant could manage. Accordingly, a change is rolling out to change the way Entra ID stores policy configurations so that each partner tenant has its own policy. Microsoft says that the new mechanism is scalable and should be capable of storing as many policies as tenants need.

The change to the way Entra ID stores partner policies is happening behind the scenes and shouldn’t be noticed by tenants. Graph APIs interact with policies in the same way for both the old and new storage, so the changeover shouldn’t cause any disruption.

Integration of Blocks with B2B Invitations

The Entra ID B2B Collaboration policy for a tenant can contain a blocklist of tenants that applications aren’t allowed to invite as guest members. For instance, if you add Gmail.com to the blocklist, Entra ID blocks team owners if they attempt to invite people with Gmail.com addresses to become guest members.

The problem is that up to now, Entra ID didn’t check cross-tenant access settings when it assessed whether to send an invitation to a new guest. This meant that you could get into a situation where cross-tenant access settings blocked Contoso.com but the B2B collaboration policy did not. Teams or other applications that use B2B collaboration could go ahead and invite people from Contoso.com to become guest members, but when the Contoso.com users attempted to redeem their invitations and access resources, cross-tenant access settings blocked their attempt.

Obviously, blocking guests who seemed to receive perfectly good invitations is a recipe for frustration for team owners or people who want to share documents and folders from SharePoint Online. The change now being introduced means that Entra ID checks both the B2B Collaboration policy and cross-tenant access settings before deciding to issue an invitation or block a user from an external tenant. It’s a logical way to close a disconnect between two parts of Entra ID.

Learning Through Experience

Cross-tenant access settings are becoming increasingly important. The latest advance is the cross-tenant synchronization used by Microsoft 365 multi-tenant organizations. Synchronization can’t happen if cross-tenant settings aren’t configured correctly. It’s good to see these changes ironing out real-life defects.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Defining Guest Account Sponsors with GUI and PowerShell

In July 2023, Microsoft added a new preview feature to allow organizations to assign ‘sponsors’ for Entra ID guest accounts. The idea is that an organization should be able to assign people or groups to be the sponsor of guest accounts. The sponsor should be “a responsible individual,” meaning someone who understand why a guest account is present in the directory, how that guest account is used, and what access they have to data. A sponsor can be an individual account or a group, and a guest account can have up to five sponsors (a mixture of accounts and groups).

When the time comes to review guest accounts and decide to keep or remove the account, sponsors can justify the retention of the guest account or ask for its removal. For instance, if a group owner uses a tool like Entra ID Access Review to conduct a periodic review of the membership of a group (team) and doesn’t recognize a guest account, they can contact the sponsor for more information. Whether or not the group owner gets anything useful from the sponsor is another matter.

Defining Entra ID Guest Account Sponsors

According to Microsoft’s documentation, “If you don’t specify a sponsor, the inviter will be added as a sponsor.” They then go on to explain how to invite an external user and add a sponsor to the new Entra ID guest account (Figure 1).

However, if you don’t add a sponsor to the new external account, the sponsor information is not filled in with the identifier of the account used to create and send the invitation. Maybe my tenant is missing some bits, which is entirely possible.

Sponsor information isn’t filled in either if you add a guest account by adding an external user to a team or sharing a document with them. This isn’t surprising because the sponsors feature is in preview and it takes time for applications like Teams, Outlook, SharePoint Online, and OneDrive for Business to catch up and populate new guest account properties.

In summary, if you want to update the sponsor for a guest account using a GUI, the only way is to edit the account properties in the Entra ID admin center.

Programmatic Updates for Guest Account Sponsors

A beta Graph API is available to list, update, and remove guest account sponsors. As usual, the Graph Explorer is an invaluable tool to help understand how a Graph API works (Figure 2).

The Get-MgBetaUser cmdlet from the beta module of the Microsoft Graph PowerShell SDK (now at V2.3) can fetch information about sponsors. For example, this code fetches information about a guest account including the sponsors. It then uses the Get-MgUser cmdlet to resolve the set of user identifiers into display names.

$User = Get-MgBetaUser -UserId 7bfd3f83-be63-4a5a-bbf8-c821e2836920 -Property Id, displayName, Sponsors -ExpandProperty Sponsors
ForEach ($Id in $User.Sponsors.Id) { Get-MgUser -UserId $Id | Select-Object DisplayName }

Of course, the code doesn’t handle the situation where a sponsor is a group, but that’s easily added if needed.

If you wanted to scan all guest accounts that don’t have sponsors defined and add a default sponsor, you could do something like this. The code:

• Defines an account to be the default sponsor.
• Builds a payload to use when updating the guest accounts.
• Finds guest accounts in the tenant.
• Checks each guest account for sponsors. If none are found, the script applies the default sponsor.

Connect-MgGraph -Scopes User.ReadWrite.All

$DefaultSponsorId = (Get-MgUser -UserId James.Ryan@office365itpros.com).Id
$Body = '{"@odata.id": "https://graph.microsoft.com/beta/users/' + $DefaultSponsorId + '"}'

[array]$Guests = Get-MgBetaUser -Filter "userType eq 'Guest'" -All -Property Id, displayName, Sponsors -ExpandProperty Sponsors | Sort-Object displayName
If ($Guests) {
    Write-Host "Scanning for sponsors"
    ForEach ($Guest in $Guests) {
      If ($Null -eq $Guest.Sponsors.Id) {
         Write-Host ("Guest {0} has no sponsors - updating with default sponsor" -f $Guest.displayName) 
         $Uri = ("https://graph.microsoft.com/beta/users/{0}/sponsors/`$ref" -f $Guest.Id)
         Invoke-MgGraphRequest -Uri $Uri -Method Post -Body $Body
      }
    }
}

Auditing Updates to Guest Account Sponsors

Last week I wrote about the way that Entra ID auditing does not capture details of changes to the usage location property for user accounts. As it turns out, updating a guest account with sponsor information creates an audit record without details of the change. Again, this could be a matter of timing and an update is coming to make sure that audit log events for account updates capture sponsor information correctly.

Tracking Guest Additions

Since Azure B2B Collaboration introduced guest accounts in summer 2016, administrators have been tracking the creation of guest accounts in different ways (for instance, here’s how to track the addition of guest accounts to teams). In many cases, the reason for doing so was to know who was responsible for the creation of a guest account. With sponsors, that need might go away, or at least it might be easier to retrieve the “who created that account information” by using the sponsor information stored for accounts. That is, once the apps record sponsors.

Learn about using Entra ID, PowerShell, the Microsoft Graph, and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Audit User Account Changes – But Not For All Properties

In a Twitter (X) discussion about Microsoft Entra ID logging, one of the participants commented that “On the small end, just being able to see who changed a user account property like UsageLocation” would be a good thing. The point here is that changing the usage location of a user account can have licensing implications.

The complaint is that the Entra ID audit log doesn’t disclose who updated a user account and changes the usage location. And as it turns out, the statement is true, as a quick test reveals. Update a user account and change several properties, including the usage location. Wait for a few minutes and check what the Entra ID audit log reports. It should show something like Figure 1. The changes made to all other properties are there, but there’s no trace of the change made to move the account’s usage location (in this case, from Ireland to France).

Later on in the conversation, the original complainant stated that they had “opened a case last year on the UsageLocation issue. I was told that the missing data is ‘by design’ and it was closed.” That response seems strange. Why would Entra ID consider that not logging changes made to account user locations is a design feature? After all, their documentation emphasizes that “you must specify the Usage location for all members.”

How the Audit Log Stores Details of User Account Updates

Entries from the Entra ID audit log flow through to the unified audit log (now holding 180 days of audit data for Office 365 E3 accounts). Perhaps the data ingested by the unified audit log would hold the missing usage location information. It’s always worth checking.

Many workloads pump information to the unified audit log, and it’s a great source of who-did-what knowledge covering situations like permission consent grants, usage of sensitivity labels, and keeping an eye on membership changes in Microsoft 365 groups. Knowing how to extract information from the audit log is a skill that every Microsoft 365 enterprise tenant administrator should have.

Unfortunately, while some fields are standard, the bulk of the interesting audit information is in the AuditData property. Workloads can stick whatever they like into AuditData, and some workloads take free liberty to do their own thing. The result is that interpreting the content of audit events is always “interesting” and takes more time than it should.

In this case, the action we want to check is “update user.” (with or without the full stop). Not all of the events logged for this action are interesting because some originate from background processes. Checking a bunch of events revealed that the ones which hold relevant data have an entry in the ModifiedProperties property called “Included Updated Properties.” For instance, the Entra ID audit record shown in Figure 1 includes this data when ingested into the unified audit log:

$Auditdata.ModifiedProperties | fl

Name     : City
NewValue : [
             "Flayosc"
           ]
OldValue : [
             "Dublin"
           ]

Name     : Country
NewValue : [
             "France"
           ]
OldValue : [
             "Ireland"
           ]

Name     : TelephoneNumber
NewValue : [
             "+33 4 9242554"
           ]
OldValue : [
             "01-2070807"
           ]

Name     : StreetAddress
NewValue : [
             "24 Chemin de Floriege"
           ]
OldValue : [
             "15 Fairways"
           ]

Name     : State
NewValue : [
             "Var"
           ]
OldValue : [
             "Dublin"
           ]

Name     : PostalCode
NewValue : [
             "83780"
           ]
OldValue : [
             "D18A6R4"
           ]

Name     : Included Updated Properties
NewValue : City, Country, TelephoneNumber, StreetAddress, State, PostalCode
OldValue :

Six properties are described in the Included Updated Properties property, but there’s no trace of UsageLocation. So no joy there…

Writing a Script to Report Changed Properties

After discovering how audit records hold details about updated properties, it didn’t take too long to create a script to report changed properties for user accounts. The biggest problem is extracting data in a reportable format from the AuditData property. With some trial and error and some persistence, it’s possible to generate a reasonable report. Figure 2 shows the script output.

You can download the script from GitHub. It is very much an example to illustrate the principal of extracting this information and can be improved. For instance, detailing the exact changes made to licenses assigned to an account.

The Hassle of Dealing with Non-Standard Audit Events

The unified audit log is a huge benefit for enterprise tenants. It’s just a pity that the Microsoft development groups make it so difficult for administrators to extract information from the audit log because of some quixotic approaches to how they format data written in log events. It would be nice if all groups used a standard method to format audit entries, but I guess that’s not going to happen. But it would be nice if Entra ID logged changes to the usage location property.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Taking Account of PIM When Blocking User Access to Exchange Online PowerShell

Updated 13 November 2024 – See this article for more information about PIM role assignments and this article for an updated reporting script.

In May, I wrote a Practical365.com article about disabling PowerShell access to Exchange Online for all but administrative accounts. Given the happiness of attackers to use PowerShell to attack Exchange (mostly against Exchange Server, but certainly also Exchange Online), it makes sense to remove the ability of “normal” users to run Exchange cmdlets.

In any case, the example script I use in the article demonstrates how to use the Get-MgDirectoryRoleMember cmdlet to find holders of the Exchange administrator and Global administrator roles. These are the people who need to run PowerShell against Exchange Online, so the script leaves their accounts intact. For anyone else, the script calls the Set-User cmdlet to disable PowerShell access. I suggest that the script is a good candidate for Azure Automation to make sure that new accounts can’t use PowerShell.

Privileged Identity Management

Everything works for most tenants. The problem is that some tenants use Azure AD Privileged Identity Management (PIM), an optional service that requires Azure AD Premium P2 licenses. PIM is most commonly used by large enterprises to control access to resources. Unlike normal open-ended permanent assignments to privileged roles like Exchange administrator, PIM allows the assignments to be time-limited on an on-demand basis.

To do this, PIM differentiates between eligible and active role assignments. An eligible role assignment is not currently effective. If needed, an administrator can activate the assignment to allow its holder to use the permissions available to active role holders. Assignments can be time-limited and expire after a certain period. A comment for the original article pointed out that it didn’t handle PIM assignments and the script is therefore unusable in tenants that use PIM.

If you look at role assignments through the Privileged Identity Management section of the Microsoft Entra admin center, you can see those with eligible, active, and expired assignments for the different roles used in the tenant. Figure 1 shows the active assignments for the Exchange administrator and Global administrator roles. You can see that some service principals are in the set of Exchange administrators. Azure Automation uses these service principals to allow managed identities to sign into Exchange Online and run cmdlets as an administrator.

The problem is that the Get-MgDirectoryRoleMember cmdlet only reports active role assignments. The assignments eligible for activation are ignored. For the purposes of this exercise, tenants using PIM must include accounts with eligible assignments when determining what accounts can access PowerShell.

Privileged Identity Management APIs

After some searching, I found a script written by Paul Contreras that explains how to get PIM role assignments for Azure AD. The script uses the Get-AzureADMSPrivilegedRoleAssignment cmdlet from the AzureADPreview module to retrieve assignments.

Given that the AzureADPreview module is due for deprecation in March 2024, I looked for an equivalent Microsoft Graph PowerShell SDK cmdlet. Microsoft’s cmdlet map to help developers move from the Azure AD and MSOL modules to the SDK didn’t help. I had great hope for the Get-MgBetaRoleManagementDirectoryRoleAssignment cmdlet but the cmdlet appears to only return “normal” role assignments.

One complication is that the current (beta) Graph API for governance role assignments is due for deprecation. Its documentation points to “Privileged Identity Management iteration 2 APIs.” Obviously, the underlying APIs are in a state of change, so the lack of SDK support isn’t surprising.

Amending the Role Assignment Script for PIM (Updated)

I amended the original script to use the Get-AzureADMSPrivilegedRoleAssignment cmdlet to fetch the assignments known for the Global administrator and Exchange administrator roles. This was fine until the retirement of the AzureAD module. V2.0 of the script replaces the AzureAD cmdlet with the Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule cmdlet from the Microsoft Graph PowerShell SDK (V2.22).

Write-Output "Retrieving assignment information from Privileged Identity Management..."                    
# Get PIM assignments for accounts holding Exchange administrator or Global administrator roles
[array]$ActiveAssignments = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "(RoleDefinitionId eq '$($ExoAdminRoleId)') or (RoleDefinitionId eq '$($GlobalAdminRoleId)')" -ExpandProperty RoleDefinition, Principal, DirectoryScope -All

# Filter out the Exchange administrators
[array]$ExoRoleMembers = $ActiveAssignments | Where-Object {$_.RoleDefinitionId -eq $ExoAdminRoleId} | Select-Object RoleDefinitionId, Principal, MemberType   
If (!($ExoRoleMembers)) { Write-Output "Can't find any Exchange administrators! Exiting..." ; break }                                                                                                

# Do the same for global administrators
[array]$GARoleMembers = $ActiveAssignments | Where-Object {$_.RoleDefinitionId -eq $GlobalAdminRoleId} | Select-Object RoleDefinitionId, Principal, MemberType
If (!($GARoleMembers)) { Write-Output "Can't find any global administrators! Exiting..." ; break }

The script then loops through the arrays of assignments to fetch details of user account (with Get-MgUser) and members of groups used for PIM (with Get-MgGroupMember). The script stores information about the assignments that we can report (Figure 2).

The next step is to create an array of administrator user principal names to check against Exchange mailboxes. Basically, if a mailbox belongs to an administrator, we allow PowerShell access. If it doesn’t, we block PowerShell access.

[array]$ExoMailboxes = Get-ExoMailbox -Filter {CustomAttribute5 -eq $Null} -ResultSize Unlimited -RecipientTypeDetails UserMailbox -Properties CustomAttribute5
ForEach ($Mbx in $ExoMailboxes) {
   # If not an admin holder, go ahead and block PowerShell
   If ($Mbx.userPrincipalName -notin $AdminAccounts) {
     Write-Output ("Blocking PowerShell access for mailbox {0}..." -f $Mbx.displayName)
     Try {
         Set-User -Identity $Mbx.userPrincipalName -RemotePowerShellEnabled $False -Confirm:$False
         $MessageText = "PowerShell disabled on " + (Get-Date -format s)
         Set-Mailbox -Identity $Mbx.userPrincipalName -CustomAttribute5 $MessageText
     }
     Catch {
         Write-Output ("Error disabling PowerShell for mailbox {0}" -f $Mbx.userPrincipalNane )
     }
   }
} # End ForEach

An improvement to the original script is that the final step is to check that administrator accounts have PowerShell access. This is to pick up new administrators that receive individual PIM assignments or join a group with a PIM assignment.

Write-Output "Checking administrator mailboxes to make sure that they have PowerShell access..."
ForEach ($Mbx in $AdminAccounts) {
   [string]$mbx = $mbx
   $PSEnabled = (Get-User -Identity $Mbx  -ErrorAction SilentlyContinue).RemotePowerShellEnabled
   If (!($PsEnabled)) {
        Write-Output ("Resetting PowerShell access for admin account {0}" -f $Mbx)
        Set-User -Identity $Mbx -RemotePowerShellEnabled $True -Confirm:$False 
   }
}

The full script is available from GitHub.

Always Learning

The nice thing about working with Microsoft 365 is that there’s always something to learn. Authors learn from the comments posted for our articles. The comments force us to research before we can answer questions posed by readers. That’s a good thing.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Org Explorer Brings Data from Multiple Microsoft 365 Sources

Updated 28 February 2023

About 18 months ago, I wrote about the importance of maintaining user account attributes in Entra ID. At the time, my focus was on Teams, because the application exposes where someone fits in the organizational structure when viewing their details. If you use Exchange Online dynamic distribution lists, the queries used to resolve list membership also depend on accurate directory data.

Organizational information is also available in the Office 365 profile card (which now shows local time information for users to make meetings easier to arrange). And now, organizational views are coming to Outlook desktop clients.

Introducing Outlook’s Org Explorer

Announced in message center post MC315746 (last updated January 21, 2022) and in preview since February (see Microsoft 365 roadmap item 84785), a new Org Explorer tab is available in Outlook’s navigation bar in Insider builds. Microsoft originally disclosed the feature in July 2021. At that time, Microsoft said that the Org Explorer is available to users with an Microsoft 365 E3 or E5 or Microsoft 365 Business license.

Update: According to message center notification MC492902 (updated 7 February 2023), the Outlook Org Explorer is only available to users with the “Microsoft Viva Suite” or “Microsoft Viva Suite with Glint” licenses. It’s odd that Microsoft would change the license requirements in mid-course, but they can do so at any time before a feature becomes generally available, which is the case here.

Oddly enough, given that OWA usually picks up new features first, the Outlook Org Explorer isn’t yet available in OWA, or the preview build of the One Outlook (“Monarch”) client.

Choosing Org Explorer opens what feels like a web page. The content shown on the page combines organizational information, personal information (like their address), presence information, and people insights derived from the Microsoft Graph from user activity (Figure 1). The user picker at the top right-hand conner can only search for user accounts within the tenant. In this instance, the person is an individual contributor without any direct reports. However, their manager appears at the top of the screen.

The Outlook Org Explorer tells you how many people report to the person in focus. You can expand the raw count to see the full set. Navigation down through the organization works well but navigating back up a level or two doesn’t work as well, even when attempting to move from a user with a direct manager.

Exchange Online must cache the information displayed by the Org Explorer. Changes made to reporting relationships didn’t appear for several hours after the update. Caching data is reasonable because the Org Explorer shows a lot of information extracted from different sources. I’m sure a background process collects the data periodically to make it available to Outlook.

Roaming Signatures Coming Closer

Also for Outlook,. Microsoft has been working on roaming signatures for Outlook desktop clients for several years, Message Center post MC305463 (15 December 2021) announced a delay for Roaming Signatures, and Microsoft later said that the new target date is July 2022. The good news is that the latest Insider builds and the One Outlook preview both include a way to insert Outlook Web Signatures into a message (Figure 2).

Outlook web signatures are no more than the signature defined for OWA (which can also be set for a mailbox using PowerShell). The good news is that the method works, which means that you can insert OWA signatures into Outlook very easily.

The latest version of OWA (and the One Outlook preview) allow users to define multiple web signatures. In the past, OWA had just one signature, but that seems to be in the past. In addition to being able to define multiple signatures (and insert any of the signatures into a message), users can choose default signatures for new messages and replies.

This flurry of change in OWA and Outlook points to OWA mailbox-based signatures being the way forward. No doubt Microsoft will reveal all in July. It will be nice to only have to define signatures in one place and have all Outlook clients use those signatures.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Critical Piece When Connecting to the Microsoft Graph

By now, most people who write PowerShell code to interact with Microsoft 365 workloads understand that sometimes it’s necessary to use Microsoft Graph API queries instead of “pure” PowerShell cmdlets. The Graph queries are usually faster and more reliable when retrieving large quantities of data, such as thousands of Microsoft 365 Groups. Over the last few years, as people have become more familiar with the Microsoft Graph, an increased number of scripts have replaced cmdlets with Graph queries. All these scripts use Entra ID (Azure AD) access tokens, as does any utility which interacts with the Microsoft Graph, like the Graph Explorer (Figure 1).

In the remainder of this article, I explore what an Entra ID access token contains.

The Need for Access Tokens

Graph queries need authentication before they can run and the Graph API uses modern authentication. Entra ID registered applications bridge the gap between PowerShell and the Graph. The apps hold details used during authentication such as the app name, its identifier, the tenant identifier, and some credentials (app secret or certificate. The app also holds permissions granted to access data through Graph APIs and other APIs. When the time comes to authenticate, the service principal belonging to an app uses this information to request an access token from Entra ID. Once Entra ID issues the access token, requests issued to the Invoke-RestMethod or Invoke-WebRequest cmdlets can include the access token to prove that the app has permission to access information.

At first glance, an access token is a confused mass of text. Here’s how PowerShell reports the content of an access token:

eyJ0eXAiOiJKV1QiLCJub25jZSI6IlFQaVN1ck1VX3gtT2YzdzA1YV9XZzZzNFBZRFUwU2NneHlOeDE0eVctRWciLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1yNS1BVWliZkJpaTdOZDFqQmViYXhib1hXMCIsImtpZCI6Ik1yNS1BVWliZkJpaTdOZDFqQmViYXhib1hXMCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9iNjYyMzEzZi0xNGZjLTQzYTItOWE3YS1kMmUyN2Y0ZjM0NzgvIiwiaWF0IjoxNjQ0ODQ1MDc3LCJuYmYiOjE2NDQ4NDUwNzcsImV4cCI6MTY0NDg0ODk3NywiYWlvIjoiRTJaZ1lEaW1McEgwTSt5QTk5NmczbWZUUXlYN0FBPT0iLCJhcHBfZGlzcGxheW5hbWUiOiJHZXRUZWFtc0xpc3QiLCJhcHBpZCI6IjgyYTIzMzFhLTExYjItNDY3MC1iMDYxLTg3YTg2MDgxMjhhNiIsImFwcGlkYWNyIjoiMSIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0L2I2NjIzMTNmLTE0ZmMtNDNhMi05YTdhLWQyZTI3ZjRmMzQ3OC8iLCJpZHR5cCI6ImFwcCIsIm9pZCI6IjM4NTRiYjA4LTNjMmMtNGI1Ny05NWZjLTI0ZTA3OGQzODY4NSIsInJoIjoiMC5BVndBUHpGaXR2d1Vva09hZXRMaWYwODBlQU1BQUFBQUFBQUF3QUFBQUFBQUFBQmNBQUEuIiwicm9sZXMiOlsiVGVhbVNldHRpbmdzLlJlYWRXcml0ZS5BbGwiLCJUZWFtTWVtYmVyLlJlYWQuQWxsIiwiR3JvdXAuUmVhZC5BbGwiLCJEaXJlY3RvcnkuUmVhZC5BbGwiLCJUZWFtLlJlYWRCYXNpYy5BbGwiLCJUZWFtU2V0dGluZ3MuUmVhZC5BbGwiLCJPcmdhbml6YXRpb24uUmVhZC5BbGwiLCJBdWRpdExvZy5SZWFkLkFsbCJdLCJzdWIiOiIzODU0YmIwOC0zYzJjLTRiNTctOTVmYy0yNGUwNzhkMzg2ODUiLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiRVUiLCJ0aWQiOiJiNjYyMzEzZi0xNGZjLTQzYTItOWE3YS1kMmUyN2Y0ZjM0NzgiLCJ1dGkiOiI3RVkyWnVXV2JFYVF0T3piVVlwOUFBIiwidmVyIjoiMS4wIiwid2lkcyI6WyIwOTk3YTFkMC0wZDFkLTRhY2ItYjQwOC1kNWNhNzMxMjFlOTAiXSwieG1zX3RjZHQiOjEzMDI1NDMzMTB9.N9yvmkCedti2fzT44VfBkN7GvuCInrIgiMgNxdyZeAyxnbdZjEhxHmNdU6HLLHQ3J-GonpPdt28dKwYxgLcrSibGzSPVHddh6MDPYutSwfIxh2oRanxhgFOWVJADfbFoCxsRFDhKJNT39bsauIUiRNzGzbb6dvWuZQ8LrgWjZzjae2qxVxj9jvYgjXEypeYZgLvPOzJiBCuluAMH3TjPuS-CuglFK_edn4CS-ztCwM0hmDFD5BLNZqng5P2KqGTEgjkMKoyIJ8yTGBJpASfdqqEFqWzQwcQ9ese924qNC3hJR_5TWHp2Fl73bpdhwBHRL5UwGTPi9_ysYdndKhXwgA

Deciphering an Access Token

Access tokens issued by Entra ID comply with the OAuth 2.0 bearer token standard (RFC6750) and are structured as JSON-formatted Web Tokens. We can’t see the JSON content because it is base64Url encoded and signed. However, if you paste the token into a site like https://jwt.ms/, the site will decrypt the list of claims included in the token and we’ll see something like the details shown below for the access token featured above:

{ "typ": "JWT", 
"nonce": "gq3zmJhybfXGDGqt6RO2PX9s0cimmRpSRrTO90sQ4w4", 
"alg": "RS256",
 "x5t": "Mr5-AUibfBii7Nd1jBebaxboXW0", 
"kid": "Mr5-AUibfBii7Nd1jBebaxboXW0" 
}.
{ "aud": "https://graph.microsoft.com", 
"iss": "https://sts.windows.net/a662313f-14fc-43a2-9a7a-d2e27f4f3478/", 
"iat": 1644833772, 
"nbf": 1644833772,
 "exp": 1644837672,
 "aio": "E2ZgYJif1+eocevtzqRIrgDGA2V3AQ==",
 "app_displayname": "ReportDLs", 
"appid": "76c31534-ca1f-4d46-959a-6159fcb2f77a", 
"appidacr": "1",
 "idp": "https://sts.windows.net/a662313f-14fc-43a2-9a7a-d2e27f4f3478/", 
"idtyp": "app",
 "oid": "4449ce36-3d83-46fb-9045-2d1721e8f032",
 "rh": "0.AVwAPzFitvwUokOaetLif080eAMAAAAAAAAAwAAAAAAAAABcAAA.",
 "roles": 
[ "Group.Read.All", "Directory.Read.All", "User.Read.All" ],
 "sub": "4449ce36-3d83-46fb-9045-2d1721e8f032", 
"tenant_region_scope": "EU", 
"tid": "a662313f-14fc-43a2-9a7a-d2e27f4f3478",
 "uti": "BU1RVc7mHkmBq2FMcZdTAA", 
"ver": "1.0", 
"wids": [ "0997a1d0-0d1d-4acb-b408-d5ca73121e90" ],
 "xms_tcdt": 1302543310 
}
.[Signature]

The deciphered token divides into three parts: header, payload, and signature. The aim of a token is not to hide information, so the signature is not protected by encryption. Instead, it’s signed using a private key by the issuer of the token. Details of the algorithm and private key used to sign an access token are in its header. An application can validate the signature of an access token if necessary, but this is not usually done when running a PowerShell script. The payload is the location for the claims made by the token and is the most interesting place to check.

Another way to check what’s in an access token is to use the JWTDetails PowerShell module, which is available in the PowerShell Gallery. To install this (very small) module, run:

Install-Module -Name JWTDetails -RequiredVersion 1.0.0 -Scope AllUsers

Afterward, you can examine a token with the Get-JWTDetails cmdlet. Here’s an example revealing that the access token issued to an app allows it to access Exchange Online using the IMAP4 or POP3 protocols:

Get-JWTDetails -Token $Token

aud             : https://outlook.office.com
iss             : https://sts.windows.net/b662313f-14fc-43a2-9a7a-d2e27f4f3478/
iat             : 1671891468
nbf             : 1671891468
exp             : 1671895368
aio             : E2ZgYDAQS/prW6b0Zsah6KMXtnTEAQA=
app_displayname : POP3 and IMAP4 OAuth 2.0 Authorization
appid           : 6a90af02-6ac1-405a-85e6-fb6ede844d92
appidacr        : 1
idp             : https://sts.windows.net/a662313f-14fc-43a2-9a7a-d2e27f4f3478/
oid             : b7483867-51b6-4fdf-8882-0c43aede8dd5
rh              : 0.AVwAPzFitvwUokOaetLif080eAIAAAAAAPEPzgAAAAAAAABcAAA.
roles           : {POP.AccessAsApp, IMAP.AccessAsApp}
sid             : 1475d8e7-2671-47e9-b538-0ea7b1d43d0c
sub             : b7483867-51b6-4fdf-8882-0c43aede8dd5
tid             : a662313f-14fc-43a2-9a7a-d2e27f4f3478
uti             : COCw22GGpESVXvfdhmEVAQ
ver             : 1.0
wids            : {0997a1d0-0d1d-4acb-b408-d5ca73121e90}
sig             : PdScMpYqwA25qJL1z8q589sz/Ma5CGQ4ea9Bi0lnO2yByrIs530emYPnFPfQNN9EPBIvv4EaAoTLomrw4RMBWYoQSAgkBUXVrYGnC
                  jzAU6a2ZNZgo7+AORHk4iyLO0FpbLEaMJvCvI5vWhP9PHOxnGLcIsCbOmyrCK6lxxIKtBx851EpLrhpyvJ3p05NSw0D/mKzXPRKtc
                  rzQcUwECxOUugbm1zdq8JaE/PmSggBb87VZy7p1S2BXhxQZ5QU17JeIADyhCGm1Ml+avuIHsVS2iat/LPEi/nktbrXMcOzROpUKyZ
                  /7uVhxQ0cscJ6WGxbd+zJm36s25Yp1vMzSHaRxQ==
expiryDateTime  : 24/10/2022 15:22:48
timeToExpiry    : 00:59:34.7611307

Claims and Scopes

The list of claims in the access token includes simple claims and scopes (groups of claims). A claim is an assertion about something related to the token. In this case, the claims tell us details like:

• The tenant (tid).
• The intended consumer of the token (aud): https://graph.microsoft.com.
• The app name (app_displayname).
• The app identifier (appid).
• The security token service (STS) responsible for issuing the token (iss): https://sts.windows.net/a662313f-14fc-43a2-9a7a-d2e27f4f3478/.
• The generation time for the token (iat).
• The time when the token expires (exp). All dates are in Unix epoch time, so 1644837672 means 11:21:12 GMT on February 14, 2022. By default, access tokens issued by Entra ID last one hour, except those used by applications which support continual access evaluation (CAE), where Entra ID issues 28-hour access tokens because it can terminate access at any time and force the user to reauthenticate should a critical user event (like a password change) happen.
• The identifier for the object in the Microsoft identity system used for authentication (oid). In this case, the script uses a registered Entra ID app, so the value is the service principal for the app. You can test this by running the Get-MgServicePrincipal cmdlet from the Microsoft Graph PowerShell SDK:

Get-MgServicePrincipal -Filter "Id eq '4449ce36-3d83-46fb-9045-2d1721e8f032'"

DisplayName Id                                   AppId                                SignInAudience ServicePrincipalTy
                                                                                                     pe
----------- --                                   -----                                -------------- ------------------
ReportDLs   4449ce36-3d83-46fb-9045-2d1721e8f032 77c31534-ca1f-4d46-959a-6159fcb2f77a AzureADMyOrg   Application

Scopes are a logical grouping of claims, and they can serve as a mechanism to limit access to resources. The roles claim contains a scope of Graph API permissions starting with Group.Read.All and ending with User.Read.All. We therefore know that this app has consent from the organization to use the permissions stated in the scope when it executes Graph API queries. The list of permissions is enough to allow the PowerShell script (in this case, one to generate a report of distribution list memberships) to query the Graph for a list of all groups and read the membership of each group.

From bitter experience, I know how easy it is to get Graph permissions wrong. One way to check is sign into the Graph Explorer and run the query (here’s an example) to check what permissions the Explorer uses to execute the query. However, you can also dump the access token to check that the set of permissions in the access token matches what you expect. It’s possible that you might have requested some application permissions for the app and failed to gain administrator consent for the request, meaning that the access token issued to the app by Entra ID won’t include the requested permissions.

Using the Access Token

Once we’re happy that we have a good access token, we can use it with Graph queries. Here’s how to fetch the list of distribution groups in a tenant. The access token is included in the $Headers variable passed to the Invoke-RestMethod cmdlet.

$Headers = @{Authorization = "Bearer $token"}

$Uri = "https://graph.microsoft.com/V1.0/groups?`$filter=Mailenabled eq true and not groupTypes/any(c:c+eq+'Unified')&`$count=true"
[array]$DLs = (Invoke-RestMethod -Uri $Uri -Headers $Headers -Method Get -ContentType "application/json")
$DLs = $DLs.Value

And if everything goes to plan, we should have a set of distribution lists to process. If not, it’s bound to be a problem with your access token, so it’s time to return to square one and restart the acquisition process.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Feature Can Suppress Sign-in Prompts

Entra ID’s Keep Me Signed In (KMSI) feature uses a persistent cookie to allow users with member accounts in the tenant directory to close and resume browser sessions without needing to sign in again. Entra ID generates the persistent cookie if a user responds affirmatively to the Stay signed in? prompt after a successful authentication (Figure 1). Entra ID uses the persistent cookie to extend the user session (and thus avoid sign-in prompts) and revokes the cookie only after the user signs out.

According to Microsoft’s documentation, Entra ID hows the KMSI prompt only when “it can benefit the user” and doesn’t prompt guest accounts, if Entra ID considers the sign-in risk score to be high, if persistent browser session control is configured in a conditional access policy, and if accounts sign in via SSO or AD FS.

The Value of a Persisent Cookie

I understand the value of KMSI for users who work with Microsoft 365 apps through browser sessions. Some applications, like Planner, don’t have desktop clients, so you’re forced to use browser or mobile clients. SharePoint Online and OneDrive for Business are also in this category. However, if a high percentage of user interaction with these workloads is through Teams, I wonder how important persistent connectivity is for their browser sessions.

Overall, given the influence of Teams and mobile clients, the argument for facilitating persistent browser sessions weakens. A good case is arguable that it is better to disable KMSI and force users to reauthenticate if they close the browser as this removes the possibility of compromise should an attacker be able to access a workstation. Requiring reauthentication when opening a session to a Microsoft 365 application seems to take the proactive approach to security endorsed by Microsoft in their Zero Trust model. It also seems to be aligned with recent developments such as enabling continual access evaluation for critical Entra ID events in all Microsoft 365 tenants. In a nutshell, KMSI might not be as valuable as it once was.

Disabling Keep Me Signed In

Unless you deploy conditional access policies to control browser session persistence, the keep me signed in feature is either on or off for everyone in a tenant. If you decide to disable the feature, the way to do so is through Entra ID company branding. Tenants with Entra ID Premium or Microsoft 365 licenses can customize different graphic elements displayed on user sign-in screens, such as the background screen. Company branding is one of those often overlooked features that every tenant should use (Figure 2).

To apply custom branding, go to the Company branding section of the Entra admin center. You can then create elements for the default locale or for individual language-specific locales. Entra ID applies the default locale if custom elements aren’t available for a user’s selected language.

Applying custom branding is straightforward and requires just a few graphic files (PNG preferred, JPEG works fine):

• A background image (1920×1080 pixels). This is the type of image used in Figure 2.
• A banner logo (280×60 pixels). This is the type of image used at the top of the Enter password screen in Figure 2.
• Square logo (240×240 pixels). This image appears elsewhere, like the bottom of email notifications sent when users share files.

Entra ID replaces its standard images with the custom images defined in company branding Figure 3 shows the properties for company branding applied to my tenant. The important point for this discission is that the option for users to remain signed in is off (at the bottom of the screen).

When you disable KMSI, Microsoft notes:

Important: some features of SharePoint Online and Office 2010 have a dependency on users remaining signed in. If you hide this option, users may get additional and unexpected sign in prompts.

Given that Microsoft 365 no longer supports Office 2010, you can safely ignore that warning. I cannot find precise details of what SharePoint Online features the removal of KMSI affects, but so far, I have experienced few problems since I removed KMSI. OWA signs out automatically after a period of inactivity and sometimes users need to reenter credentials to keep a SharePoint Online session active, but that seems to be all. The rebuttal is that signing out and forcing users to reauthenticate after they leave browser sessions inactive for a while is a good thing. It’s less convenient for the users, but more secure for the organization,

It’s possible that the Entra ID warning is old and reflects concerns when Microsoft revamped the KMSI implementation in 2018. Although improvements in Azure, federation, and SharePoint Online since 2018 might have eliminated some or all of the difficulties reported in this Microsoft Technical Community discussion, it’s still worth reading to understand some of the complexities involved in authentication.

I obviously can’t test every authentication flow in use by tenants, so it’s important that anyone considering disabling KMSI should conduct a full suite of tests to validate whether this action causes problems for users.

Prioritizing Administrative Effort

One of the joys of working in the Microsoft 365 ecosystem is that there’s always something to investigate and debate. Disabling KMSI is probably an easier decision for cloud-only tenants. Hybrid deployments invariably introduce complications, especially in authentication. In those scenarios, it might be best to leave KMSI in place as there’s probably more urgent matters to deal with than plunging into the minutiae of testing authentication pathways.

Make sure that you’re not surprised about changes which appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Spring Clean Time for Apps Coming Soon

Last year, I wrote about the need to review and clean up Entra ID integrated applications. That article describes how to extract information from Entra ID o a CSV file and use the CSV to create a Microsoft List. To make it easy to access the list, we create a channel tab in Teams. Everything works to identify suspect apps that might need removal. I think that you should perform such a review periodically. It just makes sense.

Another way to monitor potentially suspicious app activity is to review sign in data for service principals. The intention is to identify unrecognized service principals signing into the tenant and figure out what apps are involved. Sign-ins can originate from well-known service principals used by Microsoft apps, third-party apps, or the service principals automatically created by Entra ID when tenants register apps to interact with the Graph (for instance, to authenticate calls made to Graph APIs in PowerShell scripts). Sign-in data for service principals is available through the Entra admin center (Figure 1) and now it’s accessible using the Microsoft Graph List SignIns API.

The reason why this update is important is that access to sign-in data via the Graph makes it possible to download the information for analysis or store it for long-term retention in an external repository. Although you can download sign-in data as a CSV file from the Entra admin center, it’s more flexible to access the information via Graph queries, especially when you want to probe the activity patterns of certain service principals.

Getting Sign-In Data from the Graph

Any application which wants to interact with the Graph requires consent for permissions to access data. In this instance, consent is needed the Directory.Read.All and AuditLog.Read.All application permissions. Delegate permissions can also be used, and in this case the account used must hold an administrative role capable of accessing the Entra ID sign-in logs.

A suitably-permissioned application can issue queries against the SignIns API. To fetch service principal sign-in data, the query executed by the application must use a Lambda qualifier to filter data. Apart from setting a date range to search for sign-in data, the important point is to filter against the signInEventTypes property to select sign-in events for service principals. Here’s an example of a query to fetch sign-in data for between 17:30 and 22:3 on 19 January.

https://graph.microsoft.com/beta/auditLogs/signIns?&$filter=createdDateTime ge 2022-01-19T17:30:00Z and createdDateTime le 2022-01-19T22:30:00Z and signInEventTypes/any(x:x eq 'servicePrincipal')

To test the query (or one which suits your purposes), use the Graph Explorer to see what the query returns.

I wrote a simple PowerShell script (downloadable from GitHub) to fetch service principal sign-in data for the last seven days. A quick summary of the data revealed that many sign-ins came from an app named Office 365 Reports. Curiously, an app used by a PowerShell script that I had posted on GitHub also showed up with 22 sign-ins. The Information Barrier Processor is the app used by Microsoft 365 to check user accounts against information barrier policies to ensure that no one is communicating with anyone when they shouldn’t.

$Report | Group SpName | Sort Count -Descending | Select Name, Count

Name                                         Count
----                                         -----
Office 365 Reports                             369
Graph Microsoft 365 Groups Membership Report    22
Information Barrier Processor                   21
Security and Audit                               5
PS-Graph                                         1

Resolving the large set of sign-ins was easy. The data stored in the list (Figure 2) revealed the service principal to belong to an Office 365 Reporting app originally published by Cogmotive (acquired by Quadrotech and then by Quest Software). I haven’t used the app in years, but the sign-ins kept on coming.

Over time, it’s easy to accumulate crud in the form of service principals installed for one reason or another. Testing an ISV product is a classic example, which is a good reason to always conduct tests in a test tenant instead of the production tenant. Or if you stop using an app, remember to clean up by removing service principals and other app debris that the app vendor might leave behind.

The sign-ins for the app used by the PowerShell script probably exist because I shared a copy of the script with my tenant identifier, the app identifier, and the app secret in place. I quickly replaced the script with a copy containing obfuscated credentials, but failed to change the app secret, meaning that anyone with an original copy could run the code. Now alerted, I removed the app secret. My suspicions were confirmed when a batch of failed sign-ins subsequently occurred for the app. This goes to prove how easy it is to create a potential compromise if you’re not careful.

Removing a Service Principal with PowerShell

You can clean up unwanted service principals with either the Entra admin center or PowerShell. I always have a PowerShell session open, so I chose that route. In this example, we find the object identifier for a service principal using its display name as a filter for the Get-MgServicePrincipal cmdlet. When sure that this is the right service principal to remove, we use the object identifier to remove the service principal with the Remove-MgServicePrincipal cmdlet.

$SP = Get-MgServicePrinicpal -filter "displayname eq 'Office 365 Reports'"

$SP

DisplayName        Id                                   AppId                                SignInAudience     
-----------        --                                   -----                                --------------     
Office 365 Reports 9ac957ae-160b-48d3-9a6f-f4c27acca040 507bc9da-c4e2-40cb-96a7-ac90df92685c AzureADMultipleOrgs 

Remove-MgServicePrincipal -ServicePrincipalId $Sp.id

Adding Context

A list of service principals known to the tenant is a valuable input to a review for unwanted or unnecessary apps holding some form of consent (permissions) to organization data. Adding context to the data by knowing which service principals are actively signing into the tenant makes it easier to prioritize action. The data is there, it’s available, and it’s up to you to decide what to do with it.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Microsoft 365 Tenants Need to Link their Entra Tenant to Azure Subscription

Tenant administrators are all too aware of the growth of guest user accounts in tenant directories over recent years. The success of Teams and the use of guest accounts in sharing SharePoint Online and OneDrive for Business documents are the biggest factors in driving the growth in guest accounts. As we’ll discuss, some premium features of Microsoft 365 Groups require consideration of Entra ID guest user licensing.

Apart from cluttering up the directory, guest accounts don’t do any harm. You can try to identify and remove obsolete accounts using a variety of methods such as checking the Entra ID sign-in logs to discover the last sign in to the account or using the Microsoft 365 audit log and message tracking logs to figure out if guest accounts are active.

However, one thing you should keep an eye on is the requirement to license guest accounts if you use premium Entra ID features like conditional access policies or dynamic Microsoft 365 groups. In the past, the rule was that guest accounts needed premium licenses at a 1:5 ratio to Entra ID premium licenses. In other words, each premium license covers five guest accounts. Guest accounts don’t need licenses for “normal” activity such as accessing a team or opening a shared document. Entra ID access reviews can help control the need for licenses by forcing group owners to validate continued membership of guests in their groups.

External Identities Licensing Change

In September 2020, Microsoft announced a change in licensing for external identities (Azure B2B and B2C collaboration). Instead of requiring customers to buy premium licenses to cover guest accounts, the new monthly active users (MAU) billing model allows up to 50,000 free MAU for premium activities monthly. Licenses are still needed for tenant accounts that use premium features.

The definition on Microsoft’s billing model for Entra ID external identities page explains that MAU is “the count of unique users with authentication activity within a calendar month.” In other words, the MAU threshold covers all authentication activity by 50,000 external identities (like guest accounts) in a month. Any individual identity within that set can authenticate as many times as they like. If a tenant exceeds the 50,000 MAU threshold, Microsoft bills for authentications by subsequent external identities. Pricing varies according to market and whether an authenticated external identity uses Entra ID P1 or P2 features (see MAU pricing). As an example, in the U.S., an Entra ID P1 MAU costs $0.00163.

To date, Microsoft hasn’t done much to enforce the changeover to MAU pricing, and it’s very possible that Microsoft’s change in licensing strategy passed tenant administrators by without registering. It certainly made no impact on me. However, the signs are that some new features might require tenants to use MAU billing, which requires customers to link their Entra ID tenant to an Azure subscription. If you’ve already done this, you don’t need to do anything else as Microsoft bills you based on the MAU model. If you haven’t, you’ll need to link your tenant to an existing or new subscription.

Switching Entra ID Guest User Licensing to MAU Billing

On the surface, the process to switch to MAU billing seems straightforward:

• Create a new Azure subscription or identify an existing subscription to use for MAU billing.
• Go to the External Directories blade in the Entra admin center and select the Linked subscriptions option. Figure 1 shows the result of successfully linking Entra ID to a Azure subscription.
• Select your directory (most tenants have just one).
• Click Link subscription to select the Azure subscription and resource group (within the subscription) to use for MAU billing. Click Apply to link the directory to the subscription.

Registering the Entra ID Resource Provider

In my case, linking proceeded smoothly until Azure rejected my chosen subscription with the error:

The subscription is not registered to use namespace ‘Microsoft.AzureActiveDirectory’. See https://aka.ms/rps-not-found for how to register subscriptions.

The referenced page contains a lot of information about fixing various problems but nothing I could see relating to Entra ID. Some research (aka web searches) revealed that Microsoft.AzureActiveDirectory is the name of the resource provider for Entra ID. As you might imagine, not every resource provider is registered for every Azure subscription, so the solution is to register Entra ID for the subscription.

You can do this in two ways. First, go to the Subscriptions section of the Azure portal and select the subscription you want to use. Now select resource providers and look for Microsoft.AzureActiveDirectory in the set of providers. Select and register the provider. Figure 2 shows that the provider is registered, which is what you want to see.

Those wanting to live on the edge can register the provider using the Azure Cloud Shell. Start a session by clicking the Cloud Shell icon in the menu bar (it’s the icon which looks vaguely like PowerShell). This opens a small pane in the Azure portal into which you can type commands (you have a choice of Bash-like or PowerShell-like environments).

Accessing Cloud Shell from the Azure portal logs into your account automatically. All you need to do is run two commands to select the subscription you want to update and then register the Microsoft.AzureActiveDirectory provider with the subscription:

Az account set –-subscription "Visual Studio Enterprise Subscription"
Az provider register –-namespace Microsoft.AzureActiveDirectory

If you access the Cloud Shell directly (https://shell.azure.com/), you’ll need to sign in first with:

Az login

In either case, after registering the provider, you can link the subscription to Entra ID and use the MAU billing model.

It seems strange that Microsoft hasn’t optimized the Entra admin center to make sure that a selected subscription has access to Entra ID and if not, offer the administrator to register Entra ID with the subscription. There should be no need to force administrators to solve the problem when software can do it automatically.

Extra SMS Charges

Although Microsoft allows for 50,000 free MAU monthly, the MAU pricing page says:

A flat fee of $0.03 is billed for each SMS/Phone-based multi-factor authentication attempt.

Note the wording. The charge applies whether the attempt to send an SMS code is successful or not and covers the telephony charge involved in sending the SMS. The charge does not apply when external identities use the Microsoft Authenticator app for MFA verification, which is another good reason to encourage guest accounts to use the app.

Entra ID Guest User Licensing Works for Microsoft and Tenants

I’m sure Microsoft likes the new MAU pricing model for external identities because it gives them more control and visibility over the volume of guest account activity with premium Entra ID features. The old 1:5 licensing model was unenforceable and probably ignored in many tenants. On the upside, because MAU pricing is linked to Azure subscriptions, tenants gain more insight into the activity level for guest accounts too. I’ll be keeping an eye on costs as time goes by.

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’s happening.

Deny Guests from Some Domains or Use an Allow List

Updated: 5 September 2023

The ability for applications to use Entra ID B2B collaboration to add guest users is governed by external collaboration settings, aka the Entra ID B2B collaboration policy (previously the Azure AD B2B Collaboration policy). The settings are available through the External identities section of the Entra ID admin center, where they are found under Collaboration restrictions (Figure 1).

Three options are available:

• Allow guest accounts from any external domain. This is the default.
• Deny access to guest accounts from specified domains (deny list).
• Allow access only to guest accounts from specified domains (allow list).

The total size of the policy must be less than 25 KB (25,000 characters). Each domain in an allow or deny list counts against the limit as do other policy settings. Allowing 1,000 bytes for all other settings, an average of 15 characters per domain means that an allow or deny list can accommodate up to 1,600 domains. You can only choose to have a policy with an allow or a deny list and cannot have some domains in a deny list and others in an allow list.

In my case, I use the middle approach to block guest accounts from certain domains. For instance, these might be domains belonging to direct competitors or domains used for consumer rather than business purposes. In Figure 1, you can see that I’ve decided to block access to guests with Google.com and Yahoo.com email addresses.

Entra ID Blocks Bad Guests

Entra ID applies the block rather than applications. For example, in Figure 2, I’ve tried to add a new guest account to Teams, which doesn’t object when I enter tredmondxxxx@yahoo.com to identify the guest. The block descends when Teams tries to create the new guest account in Entra ID. The “Something went wrong” is an uncertain error, but it should be enough for the administrator to know what’s going on when they learn where the guest comes from. OWA doesn’t object to the email address for a new guest but is no more definite in its error (Figure 3). Again, this is because the application fails to create a new guest account in Entra ID.

Knowing What Domains Guests Come From

Before going ahead to update your external collaboration settings, it’s a good idea to understand where current guest accounts come from. This code scans down through guest accounts found in Entra ID to capture details of each user’s home domain. It then populates a hash table with the domain information to create a count for each, followed by sorting in descending order to discover the most popular domains:

$Domains = [System.Collections.Generic.List[Object]]::new()
Connect-MgGraph -NoWelcome -Scopes Directory.Read.All
[array]$Guests = (Get-MgUser -All -Filter "UserType eq 'Guest'" | Select-Object Displayname, UserPrincipalName, Mail, Id | Sort DisplayName)

ForEach ($Guest in $Guests) {
   $Domain = ($Guest.UserPrincipalName.Split("#EXT#")[0]).Split("_")[1]
   $Domains.Add($Domain)
}

$DomainsCount = @{}
$Domains = $Domains | Sort-Object
$Domains | ForEach {$DomainsCount[$_]++}
$DomainsCount = $DomainsCount.GetEnumerator() | Sort-Object -Property Value -Descending
$DomainsCount


Name                           Value
----                           -----
microsoft.com                  59
outlook.com                    11
quest.com                      6
hotmail.com                    5
gmail.com                      4
emea.teams.ms                  4

Now you know what domains are actively in use, you can decide which you might like to ban. Remember that putting a domain on the deny list stops only the creation of new guest accounts. Existing guest accounts remain in the membership of groups and teams. If you want to purge accounts from unwanted domains, you need to find the groups (teams) with guest members and examine each guest to decide if they can stay or be removed. It’s easy enough to find guests from banned domains with PowerShell, or so the saying goes…

The Office 365 for IT Pros eBook is packed full of practical information like this. Learn from the pros by subscribing to Office 365 for IT Pros and receive monthly updates during your subscription period.

Block Guest Access to Teams with Group Settings

Updated 10-Oct-2023

By default, Microsoft 365 tenants can add guest users (people with accounts outside your tenant) to the membership of Microsoft 365 Groups (and Teams). In this article, we’ll explore how to block guests for individual groups and teams.

Tenants control guest access through the Azure Active Directory policy for Groups, which has two relevant settings:

• AllowToAddGuests: Controls if group (or team) owners can add guest users to membership. The default is True.
• AllowGuestsToAccessGroups: Controls if guest accounts can access resources through Office 365 Groups. The default is True.

Settings in the Entra ID directory policy for Microsoft 365 Groups can be changed through PowerShell. For instance, to block group owners from being able to add guests, you change the value of AllowToAddGuests to False. These command fetch the current settings, update the value, and update the policy (assuming that you have already created a tenant policy):

Connect-MgGraph -Scopes Group.Read.All, Directory.ReadWrite.All

$TenantSettings = Get-MgBetaDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}
$Values = $TenantSettings.Values
($Values | Where-Object Name -eq 'AllowToAddGuests').Value = "false"
Update-MgBetaDirectorySetting -DirectorySettingId $TenantSettings.Id -Values $Values

Guests who are members of groups can continue to use their membership. The block simply stops group owners adding new guests. See this article for more information about configuring and managing the settings of the Entra ID policy for Microsoft 365 groups.

Block Guest Access to Teams and Groups on an Individual Basis

The normal course of events is to allow guest users for groups and selectively block access for specific groups that hold confidential information. It’s relatively easy to find and block access to selected groups. In the following example, the code:

• Find the group policy template object for the tenant.
• Finds a set of Microsoft 365 groups whose classification is set to “Secret.” You could use whatever filter you like to find the set of target groups.
• Checks if an existing custom setting exists for a group. If one isn’t present, the code applies a new setting to block guest access. If one is, the setting is updated to block guest access.

$GroupTemplate = (Get-MgBetaDirectorySettingTemplate | Where-Object {$_.DisplayName -eq "Group.Unified.Guest"})
[array]$Groups = (Get-UnifiedGroup -ResultSize Unlimited | Where-Object {$_.Classification -eq "Secret"})

ForEach ($Group in $Groups) {
    $GroupSettings = Get-MgGroupSetting -GroupId $Group.ExternalDirectoryObjectId 
    If ($GroupSettings) {
       # Policy settings already exist for the group - so update them
       $GroupSettings = Get-MgGroupSetting -GroupId $Group.ExternalDirectoryObjectId
       Update-MgGroupSetting -GroupId $Group.ExternalDirectoryObjectId -TemplateId $GroupTemplateId `
         -GroupSettingId $GroupSettings.Id -Values (@{'name'='AllowToAddGuests';'value'='false'}) | ConvertTo-Json
       Write-Host ("External Guest accounts blocked for {0}" -f $Group.DisplayName) 
    } Else {
       # Settings do not exist for the group - so create a new settings object and update
       $Status = New-MgGroupSetting -GroupId $Group.ExternalDirectoryObjectId -TemplateId $GroupTemplateId `
           -Values (@{'name'='AllowToAddGuests';'value'='false'}) | ConvertTo-Json
       Write-Host ("New settings created and guests blocked for {0}" -f $Group.DisplayName) 
    }
}

The process of updating the directory setting to block guests in teams and groups happens when you apply a sensitivity label that blocks guests in teams and group.

Block Guest Access to Teams Individually Trumps Tenant Setting

Some people would like to reverse the process and block guest access to all groups except on a selective basis. This isn’t possible because the tenant-level block trumps settings at an individual group level. Once you set AllowToAddGuests to False at the tenant level, the policy stops any group owner from adding guests to group membership. Only administrators keep the ability to add guests, and they can only do so through an admin interface like running the Add-UnifiedGroupLinks cmdlet or updating group membership in the Microsoft 365 Admin Center or Entra ID admin center.

If you want to block access for guests to all but a small set of groups, you must leave AllowToAddGuests as True at the tenant level and then block all but the set of groups you want to allow guests to join.

Block Guest Access to Teams Through Sensitivity Labels

Generally available from June 2020, if you enable sensitivity labels for use with Groups, Teams, and Sites, the container settings in the labels can be used to block guest users. For example, you can have a label called Confidential which, when applied to a group, stops new guests being added. Existing guests aren’t removed, but you can find them as described here.

This is the kind of topic we cover in Managing Groups chapter of the Office 365 for IT Pros eBook. You can find a lot more about managing Groups there.

Creating Org-wide Team to Communicate with Everyone in Small Organizations

In the latest update distributed to Microsoft 365 tenants, Microsoft includes the ability to create org-wide teams, but only if your tenant has fewer than 10,000 user accounts (see below). If your tenant is under the threshold, you can create up to five org-wide teams.

Company-wide Communications

An org-wide team is designed to facilitate tenant-wide communications for small to medium companies without the need for an administrator or team owner to manually add all the employees to the team membership, including the need to check for new employees and add them periodically. As we explain in the Office 365 for IT Pros eBook, the process of creating a team and populating its membership with PowerShell is not difficult, but some work needs to be done to maintain the membership afterwards.

To create an org-wide team, choose Join or create a team as usual, opt to create a team from scratch, and then choose org-wide from the type of teams available (Figure 1). The choice only appears to global tenant administrators.

Automatically-Generated Membership

When you create an org-wide team, Teams adds all the global admins as team owners. It then adds all “active users” as members. The theory is that accounts that don’t have Office 365, Microsoft 365, or Teams licenses are excluded, as are guest users, and in the past it was certainly true that some odd accounts turned up in org-wide teams, including:

• Shared mailboxes.
• Room and resource mailboxes.
• Service accounts (if they have an Microsoft 365 license).
• Mailboxes used for purposes such as DLP incident reports. These accounts might be licensed, but they shouldn’t really feature in a team.
• Accounts that have a suitable license (like Office 365 E3) but where the Teams service plan is disabled.

Although Microsoft has now fixed the underlying bugs which caused these accounts to be included in org-wide teams, it is still good practice to check the membership after the team is created and remove any account that doesn’t belong. And like for any team with a large membership, consider updating team settings to stop members posting in the General channel, adding channels, or even using @team mentions (because they generate notifications for everyone in the team).

Org-wide teams are indicated by the presence of the Org-wide tag. In addition, as you can see in Figure 2, the Manage team option displays a banner to inform users that the membership of the team is automatically adjusted in line with changes made to Entra ID.

On an ongoing basis, employees leave and join the company and people lose or gain Teams licenses. When someone leaves the company and their Entra ID account is removed, their membership of the team is also removed. To handle new joiners and people who gain or lose Teams licenses, a background process scans the accounts in the tenant periodically (expect weekly) and adds or removes the user as required. Unlike normal teams, members can’t choose to leave an org-wide team.

But I Already Have an Org-Wide Team

If you already created and use an all-employees team without benefit of Microsoft’s new feature, a tenant administrator can convert the team into an org-wide team and gain benefit of the automatic membership management. To do this, select the team you want to convert and then use the Edit team feature to change the privacy setting to org-wide. When you save the setting, Teams updates the membership with all valid accounts. Any users not included in the automatic membership remain in place, including guest users. You can also change an org-wide team to be a private or public team using the same approach, and in this case, the existing membership stays in place but the automatic background refresh of membership is disabled.

Alternatives to Creating Org-Wide Teams

Larger tenants who have more accounts than the maximum limit for org-wide team membership can consider:

• Using dynamic Teams to support discussions for different parts of the organization. For example, you might have a team for each department or each country. Dynamic teams are based on dynamic Microsoft 365 groups.
• Using Viva Engage communities for company-wide communications and collaboration. Viva Engage can easily scale up to handle very large organizations with hundreds of thousands of users.

Remember, a regular team can support up to 25,000 members, so you can always use PowerShell to generate and manage a regular team which effectively serves as an org-wide team.

P.S. The formal documentation for org-wide teams is online. But the book tells you what really happens…

We have over 200 pages of content about Teams in the Office 365 for IT Pros ebook. Shouldn’t you be staying updated with developments about Teams and the rest of Office 365? Subscribe today!