Microsoft Entra is the Latest Microsoft Rebranding Triumph

On July 11, Microsoft announced that the Microsoft Entra brand is absorbing Azure Active Directory (Azure AD), which now becomes Microsoft Entra ID. The announcement came along with news of two new Entra products as Microsoft ventures into the Security Service Edge (SSE) arena to take on competitors such as Zscaler, Palo Alto Networks, and Netskope, all leaders in Gartner’s 2023 Magic Quadrant for the SSE space.

According to the announcement, Microsoft 365 scenarios in Microsoft Entra Internet Access are in preview today. The Microsoft Technical Community blog says that Entra Internet Access includes “unique capabilities for Microsoft 365, including Universal Tenant Restrictions, to prevent data exfiltration to other tenants or personal accounts including anonymous access, near-real time threat detection, higher precision of the risk assessment on user, location, and device, and more seamless access to Microsoft 365 apps.” If you’re interested, head to the preview sign-up page for Entra Internet Access.

A message center notification (MC637368) followed up to make sure that Microsoft 365 tenant administrators heard the news about Azure AD’s new name, even though this is just a rebranding exercise that delivers precisely zero new functionality to any tenant. It’s like previous rebranding triumphs where Microsoft made:

• Microsoft 365 the catch-all brand for Office.
• Microsoft Defender the catch-all brand for Security.
• Microsoft Purview the catch-all brand for Compliance.
• Microsoft Viva the catch-all brand for anything that the marketeers could see.

Web pages might change, documentation might use different terminology, but Azure AD remains the same. Microsoft characterizes the name change as representing “the evolution and unification of the Microsoft Entra product family, and a commitment to simplify secure access experiences for everyone.” This is corporate speak for “we’re stuffing Azure AD into the Microsoft Entra brand to create Entra ID. It makes us look good even if it doesn’t do anything for the end user.” More information about the rebranding is available here.

Microsoft Entra ID Isn’t for On-Premises Software

In my opinion, Azure AD did a good job to deliver secure access experiences with many enhancements delivered over the last two years in the drive to make modern authentication and MFA more pervasive, like adding Authenticator Lite to Outlook mobile, and improving how conditional access policies work by including new capabilities like measuring the authentication strength for connections. The rebrand adds nothing.

A case can be argued that Microsoft is throwing away the reputation accrued over nearly 25 years by Active Directory and Azure Active Directory to give a existing product a new name. Equally, you could argue that renaming Azure AD will remove the confusion that sometimes exists between the cloud and on-premises directories. What’s for sure is that Windows Active Directory is not changing its name because the Entra brand does not extend to on-premises software. The same applies to Active Directory Federation Services (AD FS) and Active Directory Domain Services (AD DS).

On the plus side, Microsoft isn’t changing licensing or pricing. They also say that they’re not changing capabilities, but that’s just corporate fluff too because code doesn’t work differently when it gets a new name. URLs, APIs, and authentication libraries remain the same.

Microsoft Entra Renaming Schedule

Following the 30-day notification period for tenants, Microsoft will roll out the name change over the rest of 2023, with service plan names (the kind you see when assigning licenses to user accounts) due to change on October 1, 2023. You can download a useful CSV file of license and service plan names from Microsoft. I use this data in the Microsoft 365 licensing report script (updated to work with the Microsoft Graph PowerShell SDK V2).

By early 2024, we should all have transferred our allegiance to Microsoft Entra ID and consigned the Azure AD name to the wastebasket of computer brands.

More Work for the Book Team

From the perspective of the Office 365 for IT Pros eBook, we have some work to do to update our chapters to replace Azure AD with Entra ID where appropriate. I guess we don’t have to do this immediately, but it’s certainly something that must happen over time. It’s just another item for our to-do list!

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.

Azure AD B2B Collaboration and Guest Accounts for SharePoint Sharing

Two recent message center notifications highlight closer integration between SharePoint Online and Azure AD. MC526130 (11 March) says that new tenants created after March 31, 2023 will automatically enable the SharePoint Online integration with Azure B2B integration. Existing tenants aren’t impacted by this change. The associated update, also scheduled for roll-out in late March, is MC525663 (10 March). The news here is that SharePoint Online site sharing will use the Azure B2B Invitation manager instead of the legacy SharePoint Invitation Manager (Microsoft 365 roadmap item 117557).

Rationalization Around Azure AD

The two updates rationalize existing sharing methods with external users and focus on Azure AD as the driving force for managing invitations. The journey toward Azure AD B2B Collaboration started in 2021, so it’s been a while coming. The project makes a lot of sense for both customers and Microsoft (their gain is through reduced engineering expenses).

Ten years ago, it was reasonable for SharePoint to manage site sharing invitations. Today, when the site collection-based architecture is replaced by single-sites and most sharing occurs through Microsoft 365 groups and Teams, it’s illogical for SharePoint Online to have its own mechanism. 280 million monthly active Teams users create a lot of work for SharePoint.

Another factor is that site sharing with external users is a relatively uncommon action today. Most external users join groups or teams and gain access to the group-connected site. Although non-group connected sites do exist, they’re in the minority and some of those sites (like hub and communication sites) aren’t candidates for sharing with external people. And of course, even site owners might be blocked from sharing sites by a sensitivity label.

Time to Review Applicable Policies

Overall, I don’t think the change will disrupt many organizations. As Microsoft notes “You may want to review your Azure B2B Invitation Manager policies.” Two policies are worthy of note. The first is the Azure B2B Collaboration policy, which includes an allow or deny list (but not both) of domains.

The policy is now found under Collaboration restrictions in the External Identities section of the Azure AD admin center (Figure 1). It is commonly used to block sharing with consumer domains (deny list) or to restrict collaboration to a set of known domains belonging to partner organizations (allow list). If the organization already supports guest accounts, it’s likely that the collaboration policy already exists. Even so, changes like this are useful reminders of the need for regular review of any policy that affects how external people access tenant resources.

Azure AD cross-tenant access policies are a more powerful and flexible mechanism to control external access through both Azure B2B collaboration and Azure AD direct connect (used for Teams shared channels). Cross-tenant access policies are still relatively new and don’t need to be implemented unless required for a specific reason, so your tenant might not use them yet.

Although the Azure AD B2B Collaboration policy is likely to dominate for the immediate future, over time, I expect a slow transition to take advantage of the granular control available in cross-tenant access policies. When an organization changes over, SharePoint Online will take advantage. Leveraging advances made in Azure AD is an excellent reason for SharePoint Online to embrace Azure AD more fully.

Review Guest Accounts Too

Azure AD B2B collaboration works but that doesn’t mean that you don’t need to manage guest accounts. As more sharing happens, more guest accounts end up in your Azure AD. Some guest accounts are used once to share a document. Others are in ongoing use as guest members of groups and teams access shared documents. It’s a good idea to keep an eye on guest accounts and remove them as they become obsolete.

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.

Use Microsoft Graph PowerShell SDK Cmdlets to Report Accounts Not Yet Set Up for SSPR

A tweet by Nathan McNulty about the Get-MgReportAuthenticationMethodUserRegistrationDetail cmdlet attracted my attention. The cmdlet generates a report about the registered authentication methods for Azure AD accounts. Nathan used the cmdlet to identify accounts that aren’t set up for self-service password reset (SSPR) by filtering the results to find only member accounts where the IsSSPRCapable property is set to False. SSPR is a premium Azure AD feature.

Get-MgReportAuthenticationMethodUserRegistrationDetail outputs filtered results, but two problems exist before the data is really usable. First, the default output for the cmdlet is user identifiers (GUIDs) instead of human-friendly display names for each account. Second, while the filter can isolate member accounts, it can’t refine the query further to drop accounts created for shared mailboxes, resource mailboxes, and other purposes. The first issue is resolved by explicitly selecting the userPrincipalName and userDisplayName properties for output; the second takes more work.

Exploring a Solution

One potential solution is illustrated below. The script uses the Get-MgUser cmdlet to find all accounts with at least one assigned license (the set of returned accounts can include those used for shared mailboxes). Information about account identifiers and display names are loaded into a hash table to make it possible to lookup an identifier very quickly. We can then loop through the set returned by Get-MgReportAuthenticationMethodUserRegistrationDetail and check each account against the hash table. If a match occurs, we know that we have a licensed account that isn’t currently enabled for self-service password result and can report that fact.

Although the Get-MgReportAuthenticationMethodUserRegistrationDetail cmdlet can output user principal name and user display name properties, looking up the user account details against a table created by Get-MgUser allows us to drop the non-user accounts and lay the foundation for retrieving other data, as explained below. Here’s the code:

Connect-MgGraph -Scope Directory.Read.All, UserAuthenticationMethod.Read.All, AuditLog.Read.All
Select-MgProfile Beta

Write-Host "Finding licensed Azure AD accounts"
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All
# Populate a hash table with the details
$UserTable = @{}
$Users.ForEach( { $UserTable.Add([String]$_.Id, $_.DisplayName) } )
Write-Host "Finding user accounts not capable of Self-Service Password Reset (SSPR)"
[array]$SSPRUsers = Get-MgReportAuthenticationMethodUserRegistrationDetail | Where-Object {$_.userType -eq 'member' -and $_.IsSSPRCapable -eq $False} | Select-Object Id, userDisplayName, userPrincipalName, DefaultMfaMethod, IsAdmin, IsMfaCapable, IsMfaRegistered, IsPasswordlessCapable, IsSSPRCapable         
Write-Host "Cross-checking against licensed users..."
[array]$NonSSPR = $Null
ForEach ($S in $SSPRUsers) {
  $DisplayName = $UserTable.Item($S.Id) 
  If ($DisplayName) {
     $NonSSPR += $DisplayName }
}
$PNonSSPR = ($NonSSPR.count/$Users.Count).toString("P")
Write-Host ("{0} out of {1} licensed accounts ({2}) are not enabled for Self-Service Password Reset" -f $NonSSPR.count, $Users.count, $PNonSSPR )
Write-Host ($NonSSPR -join ", ")

Only a list of account display names is output. When I ran the script in my tenant, the following output was generated:

Finding licensed Azure AD accounts
Finding user accounts not capable of Self-Service Password Reset (SSPR)
Cross-checking against licensed users...
23 out of 32 licensed accounts (71.88%) are not enabled for Self-Service Password Reset
Andy Ruth (Director), Ben James, Ben Owens (DCPG), Bruno Satlier, Chris Bishop, , Jackson Hoare, James Abrahams, Jeff Guillet, John C. Adams, Ken Bowers, Lotte Vetler, Marc Vigneau, Michael King, Paul Howett, Peter Bridges, Rene Artois, Sean Landy, Terry Hegarty, Tony Redmond (Office 365 for IT Pros), Vasil Michev (Technical Guru)…

Improving the Output

We can improve the output by including more information in the lookup table. A hash table is fast, but it’s limited to a key and a value, but the value can any PowerShell object. The hash table can then hold more information about each user. For example:

$UserTable = @{}
ForEach ($U in $Users) {
    $ReportLine  = [PSCustomObject] @{          
     Id                  = $U.Id
     DisplayName         = $U.DisplayName
     Department          = $U.Department
     Office              = $U.OfficeLocation  
     Country             = $U.Country
     }
    $UserTable.Add([String]$U.Id, $ReportLine) 
}

I’ve selected five properties for a user account. It’s easy to add more as necessary. With the hash table populated like this, we can grab the information from the PowerShell object in the value when a match occurs for an account and use it to build a nicer report.

ForEach ($S in $SSPRUsers) {
  $Data = $UserTable.Item($S.Id) 
  If ($Data) { # We found a match
     $ReportLine  = [PSCustomObject] @{  
       Id = $Data.Id
       DisplayName = $Data.DisplayName
       Department  = $Data.Department
       Office      = $Data.Office
       Country     = $Data.Country }
     $NonSSPRUsers.Add($ReportLine) }
}

Figure 1 shows the output of the report file.

Checking Accounts Regularly

This is exactly the kind of check against user accounts that tenants might want to run regularly. A scheduled runbook executed by Azure Automation is a good way to process these kinds of operations and the code discussed here would move over easily to a runbook. In the interim, here’s the link to the full script in GitHub for you to improve and enhance it as you like.

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.

Allows CA Policies to Differentiate Between MFA Methods

Building off yesterday’s discussion about Azure AD authentication methods and the discussion at the TEC 2022 conference about the need to do better with MFA, Microsoft released an important improvement to MFA effectiveness this week by enhancing conditional access policies with authentication strength for MFA challenges.

Last year, Microsoft added number matching and additional context to the Authenticator app to help address the issue of MFA fatigue. This is when people mindlessly respond to MFA prompts without registering what they’re doing, something that attackers can exploit to compromise user accounts. However, even if people pay attention to MFA prompts, there’s no doubt that SMS-based challenges deliver weaker protection than other methods.

Expanding Conditional Access Policies

Conditional access (CA) policies operate by applying rules to connections to determine if a user can connect to the requested resource. For example, can they access an Office 365 application like OWA. Combined with authentication policies, CA policies can severely limit the ability of an attacker to compromise user accounts and stop incidents like the OAuth exploit against Exchange Online recently reported by the Microsoft 365 Defender Research Team.

CA policies have been able to insist that accounts use MFA for many years. Up to now, one kind of MFA has been as good as another. Microsoft now differentiates the strength of authentication gained through the available methods (Figure 1).

SMS is graded at medium level and its usability is high because most people have smartphones. I’m not quite sure why it shows up as medium availability. Microsoft defines this as “an indication of the user being able to use the authentication method, not of the service availability in Azure AD”. Most people I know are very able to use SMS given that it’s a messaging capability in general use since the mid-1990s.

In any case, Microsoft acknowledges the problems with SMS when it responds to an authentication challenge, and they want to encourage people to use more secure methods. In reality, this means that Microsoft wants people to use their Authenticator app, Windows Hello, or FIDO2 key.

Using Authentication Strength in CA Policies

To test the new capability, I created a CA policy to control access to Office 365 and set the policy to grant access based on the authentication strength of the user connection. The default strength is multifactor authentication, meaning any of the traditional methods like SMS will satisfy the condition. I selected the next step up, requiring the use of passwordless MFA (Figure 2).

The strongest method is phishing-resistant multifactor authentication. Using a FIDO2 key satisfies this requirement. At TEC 2022, Alex Weinert, Microsoft’s VP for Identity Security, said that the Authenticator app will meet this requirement “soon.”

Note the warning about cross-tenant access settings. These are the Azure AD Direct Connect policies that underpin Teams shared channels. A cross-tenant access policy setting controls if your tenant accepts the multifactor authentication performed by the home tenants of external users who participate in shared channels in your tenant. You should accept those claims to allow external users to continue to collaborate even if they don’t measure up to the authentication strength required for tenant users.

Effect of Authentication Strength

The effectiveness of authentication strength was immediate. Users configured to use the authenticator app continued have access while those who used SMS were allowed to connect and told to select a new authentication method (Figure 3).

In Figure 3, Azure AD shows that a FIDO2 key is the only available method. This was because the user account had the authenticator method but it needed to be fully configured. Once this was done, the user could connect successfully.

Like any other authentication failure due to a CA policy, details of the failed connection are in the Azure AD sign-in log (Figure 4).

Heading to the Sunny Highlands of Secure MFA

It will be interesting to see how many organizations try to move users away from SMS-based MFA to more secure authentication methods. Just because Microsoft wants this to happen is no reason why it will in the real world. Some customers will love the new capability and rush to embrace it, but I suspect that the real challenge that needs to be fought first is to increase the current percentage of Azure AD accounts protected by MFA from 26.64% to well north of 50%. After killing basic password authentication and pausing for a breath, moving to really secure MFA might be the next hill to climb.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

The Many Ways to Stress the Need for Modern Authentication

By now, all Microsoft 365 tenant administrators should be aware that Microsoft is removing support for basic authentication for many Exchange Online connectivity protocols. The aim is to complete the process by October 2022. SMTP AUTH is an exception, but Microsoft will deal with it in time.

What you might not be aware of is that access to Microsoft 365 data using modern authentication requires that the developers must register their app with Azure AD. This applies to any Microsoft API, including the Outlook add-in model and the Graph APIs. If you’ve written PowerShell scripts which make Graph queries, you know that you must register an app to receive consent for the Graph permissions necessary to access the target data. This is a basic registration. Registrations for more sophisticated apps like those sourced from ISVs contain more information about the app, such as a redirect URL for the app. Registration for ISV apps usually happens during the app installation, including the creation of a service principal to allow the app to run with API permissions consented to by tenant administrators.

Previously, I’ve written about the need for tenants to clean out application crud from Azure AD. The crud is composed of unwanted apps and their service principals accumulated over time in Azure AD. Being able to fetch sign-in data for service principals via Graph queries makes it easier to add context to this exercise by knowing what service principals are active.

After cleaning out obsolete applications, Azure AD might be tidy, but do you know much about the apps which remain? The application governance add-on for Microsoft Defender for Cloud Apps might help, but only if your tenant has the necessary licenses.

Microsoft’s App Compliance Program

Fortunately, Microsoft has an App Compliance Program, part of their Zero Trust initiative to help customers verify apps they might want to run in their tenant. App developers go through the process to achieve app certification by providing information about the app and the data it accesses. The program has three phrases or levels:

Publisher verification: The app developer has a Microsoft developer network identity. The app supports modern authentication and is capable of multi-tenant activity. This is the entry-level participation in certification.

Publisher attestation: The app developer completes a questionnaire covering security, data handling, and compliance.

Microsoft 365 certification: Instead of the app developer reporting details of their app, third-party assessors audit the assertions to validate that the app meets Microsoft standards for security and compliance. The process occurs annually, and details gathered during the audit is available online. Figure 1 shows details of a Microsoft certified app in AppSource. The audit information is available through the Microsoft 365 certification link for the app.

The app certification information available online (Figure 2) includes detail of the app permissions, including the reason why the app developers need administrator consent to use the permission.

Obviously, app developers must invest time and effort to satisfy Microsoft criteria for app certification. However, once completed, they should reap the benefits gained by increased customer confidence in their product. At least, that’s the theory.

Downgraded Certification

In April 2020, I reviewed the new Manage Apps section in the Teams admin center and commented on the Microsoft 365 certified status of the Wrike app. The number of apps available for Teams continues to expand (from 462 in April 2020 to 1,402 as I write this in February 2022, or roughly 44 new apps monthly). Checking the online list of Teams apps, it looks like very few apps are Microsoft 365 certified. This begs the question why app developers feel it unnecessary to go through Microsoft’s audit process – or why publishers of apps like Wrike downgraded their apps from certified to publisher attestation.

I’m sure cost has something to do with it, along with a feeling that customers don’t go looking for apps which are Microsoft 365 certified. If a developer gains no business advantage by completing the full certification process for their apps, why bother? It’s a reasonable perspective. Microsoft would obviously like developers to go the whole hog, but this might be an uphill battle.

User Consent for Apps

One way that customers might help persuade developers that app certification is worthwhile is to allow users to grant consent for apps from verified publishers when apps require only “low-impact” permissions. The idea is that if less friction exists to deploy and use an app, it will be more popular and profitable.

The consent settings for a tenant are available in the Azure AD admin center (Figure 3) and include the ability to define what you consider to be low-impact permissions. In this case, the selected option allows users to grant consent, but only for three low-impact permissions such as the ability to read a user’s profile. Tenants can define what they consider to be low-impact permissions through the Permissions Classifications option shown in Figure 3.

Some will be uneasy about the prospect of users granting consents to apps. The safeguard is that consent is only possible for verified publishers; the counterargument is that developers can attain verification too easily to make this status truly valuable. If Microsoft 365 certified apps were the threshold, a different story might ensue. Microsoft recommends that it’s OK to allow users to grant consent to apps, but without stronger controls, this might be a stretch for many organizations.

The Rocky Road to App Certification

The situation is complex. Microsoft wants everyone to use modern authentication to access Microsoft 365. Getting to that position means a great deal of change for clients, apps, users, and organizations. Certification helps customers understand and control the access apps have to data in their tenant. That’s goodness, but only if ISVs co-operate and certify their products. Time enables change. While that happens, keep your app repository clean and tidy. You know it makes sense.

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.

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.

Laying the Foundation for New Collaboration Scenarios Like Teams Shared Channels

Updated: March 22, 2022

On February 7, Microsoft announced that Azure AD cross-tenant collaboration settings are available in preview. Part of Azure AD B2B Direct Connect, Azure AD cross-tenant access means that users can authenticate in their home tenant and use the credentials gained there to access resources in other tenants, subject to the collaboration settings now in preview. Microsoft says that the new settings allow organizations to control how users collaborate with other Azure AD organizations (Microsoft 365 tenants). Inbound and outbound controls are available to control access on a tenant-wide, group, or application basis, together with the ability to trust security claims from external organizations like multi-factor authentication and device compliance.

External Identities Settings

The new settings are available in the External identities section of the Azure AD admin center. The organizational settings tab is where you define settings for individual Azure AD tenants you want to collaborate with (Figure 1) while the default settings tab is where you define settings to apply to Azure AD tenants in general. Specific settings for another tenant take precedence over the default settings.

Being able to define how individual tenants interact with your tenant allows precise control over who can connect and what they can do. For instance, in Figure 2 we see that the inbound access settings for the O365Maestro tenant allow collaboration via just one application (Office 365). You can add other Microsoft applications to the mix or include other applications if registered in Azure AD.

Note the external users and groups tab. By default, any user can connect with your organization. If you don’t want this to happen, the inbound access settings allow you to define exactly whom from another organization can collaborate with people in your organization. Likewise, the outbound access settings give you control over the people in your organization you want to collaborate outside your tenant. Again, because the whole idea of collaboration is to enable people to work together, the default is to allow everyone to collaborate with external organizations. However, sometimes control is necessary, and you might want to manage who connects with specific tenants, and this is where you can exert that control.

Accepting Security Claims

All Azure AD organizations apply the same fundamentals of authentication to allow users access to resources. It therefore makes sense to accept that a process performed for one tenant is valid for connection to another. If your security posture is higher (for instance, your tenant insists on connections from trusted devices), you can still insist that external connections meet this standard while at the same time accepting valid claims established when users sign into the other organization.

The Trust settings tab defines the set of security claims made by another tenant you are willing to accept. For example, let’s assume that the other tenant enforces MFA for all users. The trust settings for the tenant allows you to accept that the tenant has validated the user’s identity with MFA and won’t issue another challenge from your tenant. Reducing the necessity for multiple MFA challenges removes a major source of user irritation. By default, Azure AD accepts connections from another tenant based on that tenant’s assessment of MFA, compliant (trusted) devices, and hybrid Azure AD joined devices. You can enable or disable each of these claims as shown in Figure 3.

Removing some friction from MFA challenges is a good thing. According to Microsoft, Azure AD customers secure only 22% of Azure AD accounts with MFA. That’s a horrible statistic (albeit showing steady growth over the past few years). The simple fact is that MFA helps accounts resist 99% of brute-force attacks designed to crack passwords, so this is an area where Microsoft 365 tenants need to do better.

Default Settings

If you don’t define settings for an Azure AD organization you want to collaborate with, Azure AD uses the default settings (Figure 4). Like those for individual tenants, the settings break down into B2B collaboration and Trust.

More information about configuring default and specific organization settings for cross-tenant access is available online. Like conditional access policies, it will take time to figure out the best approaches for configuring rules for inbound and outbound access. And like conditional access policies, no one wants to make the mistake of applying a change that blocks collaboration for everyone in a tenant. The advice is therefore to go slowly and understand exactly what effect a proposed change will have on users before proceeding.

Teams Connect the First for Cross-Tenant Access

Microsoft has said that people can connect using “native identities” to collaborate Teams shared channels (aka Teams Connect). It’s therefore no secret that Azure AD cross-tenant access is the foundation to allow users to use credentials obtained within their home tenant to connect with people in a shared channel in an external organization.

Teams shared channels (aka Teams Connect) are now in public preview. Many criticized Microsoft’s slowness in delivering shared channels but given that the feature depends on a new way of authentication and Azure AD collaboration that is only just available in preview, it’s understandable why the delay happened. After all, you don’t want authentication from another tenant to potentially compromise sensitive information stored in a shared channel. Teams Connect is likely the first app to exploit cross-tenant access. I don’t think it will be the last.

Azure AD cross-tenant access won’t mean that guest accounts will go away anytime soon. Many valid scenarios exist to demonstrate the usefulness of guest accounts. Cross-tenant access gives organizations a new way of collaborating to add to the methods enabled by guest accounts. It’s all goodness.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

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.

Backup In Case Normal Authentication Fails

An obvious difference between cloud and on-premises management is that Microsoft 365 won’t allow you to sign into the console of a physical computer when all else fails and you need to access a server. Not having to go and reboot a server or perform other maintenance to resurrect a failing application is one of the joys of cloud services.

However, sometimes things do go wrong, and normal administrative sign-ins don’t work. It’s possible that an outage might interfere with the ability to sign into Azure AD to access administrator accounts. The most serious kind of outage is when a tenant comes under attack and the attackers change the password for the administrator accounts. A more mundane reason is that someone changes the password of the administrator accounts (perhaps with the best intentions) and promptly forgets. Or that you follow best practice and enable multi-factor authentication (MFA) for all administrator accounts only for the MFA service to go down as happened in November 2018.

To prevent the complete lock out of administrators when bad things happen, it’s a good idea to create one or more break glass accounts (otherwise known as an emergency access accounts). These are highly-permissioned accounts (perhaps holding the global administrator role) intended for use in emergency situations.

Break glass accounts don’t need Microsoft 365 licenses. Their sole role is to perform administrative actions when regular administrator accounts are unavailable. It’s a waste to assign licenses to these accounts as you’ll end up paying monthly fees for zero utility.

Characteristics of Break Glass Accounts

Break glass accounts have the following characteristics:

• Hosted in the cloud: To avoid any dependency on federation with an external or on-premises directory, break glass accounts are cloud objects. The user principal name for the accounts should use the tenant service domain (tenant.onmicrosoft.com). Although it seems logical to use a value like “Break Glass Account” in the user principal names and display names assigned to these accounts, it might be better to obscure their purpose with names that won’t attract attention like “Building Pipeline Maintenance” or something else that won’t attract attention.
• No simple passwords: Multiple layers of authentication such as MFA protect the accounts. However, you should take care to minimize the number of dependencies used by authentication to ensure that the account is available when needed. For instance, you should exclude break glass accounts from conditional access policies to ensure that a policy doesn’t block a signin attempt for the account.
• Varied authentication: To reduce the possibility that a failure blocks access to all break glass accounts, you should vary the authentication methods used for these accounts. Break glass accounts need MFA to access Azure administrative sites and tools. Don’t use SMS-based responses for MFA as the preferred challenge for all accounts. It’s a weak authentication method and a failure of the SMS service will prevent all access. Use a strong authentication method like a FIDO2 key instead and make sure that the keys are stored securely.

In the past, the recommendation was to give break glass accounts passwords that are complex, long, and obscure. Given the need to use MFA to access Azure administrative sites and tools, the need for such a password is reduced. However, multiple layers of security is usually a good idea, so set good passwords for or break glass accounts and store the passwords securely. The details of the storage location and how administrators can access passwords will vary from organization to organization. Some people suggest storing the passwords in fireproof containers in a locked safe. Others recommend dividing passwords up into several parts and storing each part in a separate network location (OneDrive personal, Google Drive, Dropbox, and so on). The important thing is that the process to retrieve break glass account password works, is documented, and audited to prove that it works.

Checking for Break Glass Sign-In Events

After each use of a break glass account, you should change the password. And to make sure that no unauthorized access happens, you should check Azure AD sign-in data periodically to pick up any attempts to log into the accounts. Microsoft documents how to use Azure Monitor for this purpose. The same Kusto queries will work with Microsoft Sentinel.

It’s also possible to run checks against the Office 365 audit log using the Search-UnifiedAuditLog cmdlet. For example, this code runs an audit log search for log in events for two break glass accounts and displays details of any events it finds.

# Identify the accounts to check
$Accounts = "Break.Glass.Account1@office365itpros.onmicrosoft.com", "Break.Glass.Account2@office365itpros.onmicrosoftcom"
$StartDate = (Get-Date).AddDays(-14); $EndDate = (Get-Date).AddDays(1) # Set your own date span here!
[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -Operations UserLoggedIn -UserIds $Accounts -ResultSize 5000
If (!($Records)) {Write-Host "No audit records found - exiting!"; break}
$Events = [System.Collections.Generic.List[Object]]::new() 	
ForEach ($Rec in $Records) {
   $AuditData = $Rec.AuditData | ConvertFrom-Json
   $DataLine = [PSCustomObject] @{
         ClientIP            = $AuditData.ClientIP
         Date                = $Rec.CreationDate
         User                = $Rec.UserIds
         UserAgent           = $AuditData.ExtendedProperties | ? {$_.Name -eq "UserAgent"} | Select -ExpandProperty Value
         OS                  = $AuditData.DeviceProperties | ? {$_.Name -eq "OS"} | Select -ExpandProperty Value
         Browser             = $AuditData.DeviceProperties | ? {$_.Name -eq "BrowserType"} | Select -ExpandProperty Value
        }
    $Events.Add($DataLine) 

}
If ($Events) {
     CLS
     Write-Host "Log in Events for Break Glass Accounts"
     $Events | Select Date, ClientIP, User, UserAgent
>> }

Log in Events for Break Glass Accounts

Date                ClientIP       User                                                  UserAgent
----                --------       ----                                                  ---------
10/01/2022 17:48:31 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:31 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:29 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:29 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:28 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....

Multiple signin events for an account over a short period of time are not unusual. Teams, for instance, has a habit of generating multiple events when a user connects. The important thing is that evidence exists of sign-in activity for an account which should not be signing in. This deserves immediate investigation.

Not for Everyday Use

Hopefully, you never have to use a break glass account to rescue a tenant. Touching every available piece of wood in the immediate vicinity, I have never had to use my break glass account. But it’s there and waiting. Just in case.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new development as they happen.

Use Teams, PowerShell, or the Graph

Vasil Michev, the Technical Editor of the Office 365 for IT Pros eBook, comes up with all sorts of weird and wonderful insights into Microsoft 365. A recent question he discussed on his blog was how to find the creation date for a tenant. It’s a good question because it forces respondents to know where to look for this information and is exactly the kind of poser we like to tease out as we write content for the book.

As Vasil points out, the obvious answer is to fire up the Teams admin center because the tenant creation date appears on a card displayed on its home screen (Figure 1). The Teams admin center is the only Microsoft 365 portal which shows this information. Why the Teams developers thought that it was useful to highlight the tenant creation date is unknown. After all, the date won’t change over time and static information is not usually featured by workload dashboards.

Opening an administrative portal is no challenge. Vasil suggests several alternate methods to retrieve the tenant creation date. It seemed like fun to try some of these methods against my tenant. Here’s what I found.

Using Exchange Online Data

If you’ve used Exchange Online from the start, you can check the creation date of the Exchange organization configuration object, created when an administrator enables Exchange Online for the first time.

(Get-OrganizationConfig).WhenCreated

Monday 27 January 2014 20:28:45

It’s an interesting result. Exchange Online reports its initiation in January 2014 while Teams is quite sure that the tenant existed in April 2011. I’ve used Exchange Online for email ever since I had a tenant, so the disconnect between Exchange Online and the tenant creation date is interesting.

Another way of checking Exchange data is to look at the creation dates for mailboxes. This PowerShell snippet finds all user mailboxes and sorts them by creation date. The first mailbox in the sorted array is the oldest, so we can report its creation date:

[array]$Mbx = Get-ExoMailbox -ResultSize Unlimited -Properties WhenCreated -RecipientTypeDetail UserMailbox | Sort {$_.WhenCreated -as [datetime]} 
Write-Host ("The oldest mailbox found in this tenant is {0} created on {1}" -f $Mbx[0].DisplayName, $Mbx[0].WhenCreated)

The oldest mailbox found in this tenant is Tony Redmond created on 27/01/2014 20:36:38

(Dates shown are in Ireland local format. The equivalent U.S. format date is 01/27/2014).

Grabbing all mailboxes to check their creation date will not be a fast operation. Even using the REST-based Get-ExoMailbox cmdlet from the Exchange Online management module, it will take time to retrieve all the user mailboxes in even a medium size tenant.

As it turns out, the oldest mailbox is my own, created about eight minutes after the initiation of Exchange Online. However, we’re still in 2014 when the tenant proclaims its creation in 2011, so what happened?

A search through old notes revealed that Microsoft upgraded my original Office 365 tenant created in 2011 to an enterprise version in 2014. It seems that during the tenant upgrade, Microsoft recreated the instance of Exchange Online. That explanation seems plausible.

Administrator Accounts

Another method is to examine the creation dates of administrator accounts to find the oldest account. This is usually the administrator account created during tenant setup. In other words, when you create a new tenant, you’re asked to provide the name for an account which becomes the first global administrator. If we look at the administrator accounts in the tenant and find the oldest, it should be close to the tenant creation date shown in the Teams admin center. That is, unless someone deleted the original administrator account.

Azure AD is the directory of record for every Microsoft 365 tenant, so we should check Azure AD for this information. The steps are:

• Find the set of accounts which currently hold the global administrator role. We omit the account returned with the object id 25cbf210-02e5-4a82-9f5c-f41befd2681a as this is a service principal used by Microsoft Rights Management services (you can confirm this by running Get-AzureADServicePrincipal -ObjectId 25cbf210-02e5-4a82-9f5c-f41befd2681a).
• Check each account to find the creation date. This is slightly complicated when using the Azure AD PowerShell module because the creation date is part of the extension properties. We therefore use the Get-AzureADUserExtension cmdlet to extract the date and then store it in the array used to hold details about tenant administrators.
• Sort the accounts by creation date and report the oldest.

Here’s the code I used:

# Find the identifier for the Azure AD Global Administrator role
$TenantAdminRole = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Global Administrator’} | Select ObjectId
# Get the set of accounts holding the global admin role. We omit the account used by
# the Microsoft Rights Management Service
$TenantAdmins = Get-AzureADDirectoryRoleMember -ObjectId $TenantAdminRole.ObjectId | ? {$_.ObjectId -ne "25cbf210-02e5-4a82-9f5c-f41befd2681a"} | Select-Object ObjectId, UserPrincipalName
# Get the creation date for each of the accounts
$TenantAdmins | ForEach-Object { $_ | Add-Member -MemberType NoteProperty -Name "Creation Date" -Value (Get-AzureADUserExtension -ObjectId $_.ObjectId ).Get_Item("createdDateTime") }
# Find the oldest account
$FirstAdmin = ($TenantAdmins | Sort-Object {$_."Creation Date" -as [datetime]} | Select -First 1)
Write-Host ("First administrative account created on {0}" -f $FirstAdmin."Creation Date")

The older Microsoft Online PowerShell module doesn’t require such a complicated approach to retrieve account creation data. Taking the code shown above and replacing the Get-AzureADUserExtension cmdlet with Get-MsOlUser, we get:

$TenantAdmins | ForEach-Object { $_ | Add-Member -MemberType NoteProperty -Name "Creation Date" -Value ((Get-MsOlUser -ObjectId $_.ObjectId ).WhenCreated) }

Using either cmdlet, the result is:

First administrative account created on 11/04/2011 17:35:11

The Teams admin center also reports April 11, 2011, so using administrator accounts might be a viable way to determine tenant age.

Use the Graph

Microsoft 365 stores information for each tenant in the Microsoft Graph, and it’s the Graph which is the source for the Teams admin center. We can retrieve the same information by running the https://graph.microsoft.com/V1.0/organization Graph query. The createdDateTime property returned in the organization settings is what we need.

Here’s the PowerShell code to run after obtaining the necessary access token for a registered app, which must have consent to use the Organization.Read.All Graph permission. Vasil used the beta endpoint when he showed how to fetch tenant organization settings using the Graph Explorer (which saves the need to write any code), but the V1.0 endpoint works too.

$Uri = "https://graph.microsoft.com/V1.0/organization"
$OrgData = Invoke-RESTMethod -Method GET -Uri $Uri -ContentType "application/json" -Headers $Headers
If ($OrgData) {
  Write-Host ("The {0} tenant was created on {1}" -f $Orgdata.Value.DisplayName, (Get-Date($Orgdata.Value.createdDateTime) -format g)) }

The Redmond & Associates tenant was created on 11/04/2011 18:35

The first administrator account appears to date from 17:35 while the tenant creation time is an hour later. This is easily explained because all dates stored in the Graph are in UTC whereas the dates extracted from Azure AD and reported by PowerShell reflect local time. In April 2011, local time in Ireland was an hour ahead of UTC.

An Old Tenant

After all the checks, it’s clear that I created my tenant in the early evening of April 11, 2011. Given that this was ahead of Microsoft’s formal launch of Office 365 in July 2011, I can claim to use an old tenant, for what that’s worth.

Important Microsoft 365 Workloads Respond to Critical Azure AD Events

Microsoft made a critical announcement on January 10 when they revealed that the base Office 365 workloads support continual access evaluation (CAE) for specific Azure AD events. What’s more, Microsoft has enabled this capability for all Microsoft 365 tenants.

Exchange Online, SharePoint Online, and Teams can now accept signals from Azure AD when an administrator:

• Deletes or disables an Azure AD user account.
• Changes or resets the password for a user account.
• Explicitly revokes all refresh tokens for a user account.
• Enables multi-factor authentication for a user account.

The top three actions correspond to highlighted options available at the top of the user account management card in the Microsoft 365 admin center (Figure 1). Multifactor enablement is at the bottom of the card.

In addition, Exchange Online can respond when Azure AD Identity Protection detects that higher risk of compromise exists for a user account.

Administrators can see details of sign-ins which use continuous access evaluation by applying a filter of (Is CAE Token = Yes) in the Azure AD admin portal. Figure 2 shows details of a CAE-enabled session.

Browsing the Azure AD sign-in log is enlightening in terms of understanding the degree of application support for CAE. Although currently limited to applications like OWA and the SharePoint Online browser interface, you’d anticipate that Microsoft will increase coverage over time.

Enlightened Applications

Continuous access evaluation means that the “enlightened” applications learn about changes in user accounts in almost real-time. For instance, if an administrator deletes a user account, the applications remove access immediately instead of waiting for the access token granted as the result of the last successful authentication by the account to expire.

Microsoft says that the use of continuous access evaluation means that “authentication session lifespan now depends on session integrity rather than on a predefined duration.” For example, if an event like a password change occurs to affect the integrity of a browser session where a user is connected to SharePoint Online, instead of waiting for the access token to expire, SharePoint Online will immediately demand that the user re-establishes session integrity by proving their credentials are still valid.

The effect is that users affected by these critical events must either reauthenticate (for instance, using a new password), or lose access to email, documents, calendar, and Teams. This makes it much easier to manage the possibility of data loss in cases like account compromise or the departure of disgruntled employees.

A benefit of continuous access evaluation is that in the case of outages, extended session lifetimes enabled by removing the dependency on the access token as the sole control over accounts mean that people can continue working without needing to revert to Azure AD (see this note about Microsoft’s Azure AD backup service).

Conditional Access Policy Support

While response to critical Azure AD events is available for all Microsoft 365 tenants, those with Azure AD Premium licenses can include continuous access evaluation in the criteria used by conditional access policies to decide to grant or deny user access to applications based on conditions like network location.

Zero Trust in Action

Microsoft talks about the Zero Trust model a lot. An action like enabling continuous access evaluation for critical events in all Microsoft 365 tenants is a practical and useful example of the Zero Trust initiative. Even if you don’t use conditional access policies (something I think all tenants should consider to improve their security posture), the fact that the base Microsoft 365 workloads now respond to critical Azure AD events almost in real time is a very welcome advance.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant. We cover continuous access evaluation in the chapter on Microsoft 365 identities.

Shared Mailboxes Aren’t Important, Are They?

First reported by MVP Jeff Guillet, the recent release of AAD Connect 2.0.88.0 includes a very nasty bug: it removes disabled Active Directory user accounts from Azure AD when it synchronizes information from the on-premises directory to the cloud. The issue here is that Exchange uses disabled user accounts for shared mailboxes. When synchronization occurs to remove the disabled user accounts, Exchange Online users can no longer access on-premises shared mailboxes because they’re not present in the GAL.

According to the release history for AAD Connect, on December 21, Microsoft acknowledged the problem and released version 2.0.89.0 for download. This version is unavailable for auto upgrade.

Roll Back to Previous Version

If you’ve already deployed 2.0.88.0, possibly to explore the (preview) ability to synchronize objects from a single Active Directory forest to multiple Microsoft 365 tenants, Jeff recommends that you roll back to version 2.0.28.0 instead (the software is available from his site). He knows more than I do about AAD Connect and it seems wise to revert to a stable version while Microsoft sorts out any issues which might still lurk in the new version.

A Lack of Testing

Given that the function of AAD Connect is to synchronize mail-enabled objects from on-premises directories to Microsoft 365 tenants, it’s both strange and troubling that Microsoft allowed this software to appear with such a fundamental flaw in place. Omitting shared mailboxes during synchronization cycles creates questions about the kind of testing regime Microsoft used. Perhaps the need to ship the software before Microsoft closed for the holidays meant that some shortcuts in testing crept in. For whatever reason, it’s not a good story.

Happy Holidays

Speaking of the holidays, this is likely the last post in the Office 365 for IT Pros blog for 2021. We’ll be back in 2022 to share information about Office 365 and the wider Microsoft 365 ecosystem in all its glory and occasional seedy bits. If you’re on vacation, enjoy the time off, and if you need to work to keep systems going, we hope you don’t have any major outages to deal with.

As for us, we need to get the January 2022 update done for the Office 365 for IT Pros eBook. That’s a train which keeps on chugging…

Licensing Report Has No Dates

I recently published a Practical365.com article explaining how to create a licensing report for an Office 365 tenant using cmdlets from the Microsoft Graph SDK for PowerShell.

A reader asked: “I am trying to determine when a specific license, in this case an E3 Security and Mobility license, was added for all users.”

No Dates for Licenses

It’s an interesting question. As written, my script generates a report based on the licenses and service plans assigned to user accounts. However, it doesn’t do anything to tell you when a license for a product like Enterprise Security and Mobility E3 (EMS E3) is assigned to a user. This is because Azure AD does not record assignment dates for the product license information held for user accounts. Instead, license information for an account is presented as a table of SKU identifiers with any disabled service plans in a SKU noted:

$User,AssignedLicenses

DisabledPlans                          SkuId
-------------                          -----
{bea4c11e-220a-4e6d-8eb8-8ea15d019f90} b05e124f-c7cc-45a0-a6aa-8cf78c946968
{}                                     8c4ce438-32a7-4ac5-91a6-e22ae08d9c8b
{}                                     4016f256-b063-4864-816e-d818aad600c9
{a23b959c-7ce8-4e57-9140-b90eb88a9e97} 6fd2c87f-b296-42f0-b197-1e91e994b900

However, date information is included in the service plan information for an account:

$User.AssignedPlans

AssignedDateTime    CapabilityStatus Service                       ServicePlanId
----------------    ---------------- -------                       -------------
09/11/2021 10:33:37 Enabled          AzureAdvancedThreatAnalytics  14ab5db5-e6c4-4b20-b4bc-13e36fd2227f
09/11/2021 10:33:37 Enabled          AADPremiumService             eec0eb4f-6444-4f95-aba0-50c24d67f998
09/11/2021 10:33:37 Enabled          RMSOnline                     5689bec4-755d-4753-8b61-40975025187c
09/11/2021 10:33:37 Enabled          SCO                           c1ec4a95-1f05-45b3-a911-aa3fa01094f5
09/11/2021 10:33:37 Enabled          AADPremiumService             41781fb2-bc02-4b7c-bd55-b576c07bb09d
09/11/2021 10:33:37 Enabled          MultiFactorService            8a256a2b-b617-496d-b51b-e76466e88db0
09/11/2021 10:33:37 Enabled          RMSOnline                     bea4c11e-220a-4e6d-8eb8-8ea15d019f90
09/11/2021 10:33:37 Enabled          RMSOnline                     6c57d4b6-3b23-47a5-9bc9-69f17b4947b3
09/11/2021 10:33:37 Enabled          Adallom                       2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2

Checking Dates for Service Plan Assignments

Given that date information is available for service plans, it should therefore be possible to check against the service plan information for user accounts to find assignments of a service plan belonging to a product (SKU). Looking at the Product names and service plan identifiers for licensing page , we find the list of service plans included in EMS E3 (SKU identifier efccb6f7-5641-4e0e-bd10-b4976e1bf68e). The set of service plans are:

• Azure Active Directory Premium P1: 41781fb2-bc02-4b7c-bd55-b576c07bb09d
• Azure Information Protection Premium P1: 6c57d4b6-3b23-47a5-9bc9-69f17b4947b3
• Cloud App Security Discovery: 932ad362-64a8-4783-9106-97849a1a30b9
• Exchange Foundation: 113feb6c-3fe4-4440-bddc-54d774bf0318
• Microsoft Azure Active Directory Rights: bea4c11e-220a-4e6d-8eb8-8ea15d019f90
• Microsoft Azure Multi-Factor Authentication: 8a256a2b-b617-496d-b51b-e76466e88db0
• Microsoft Intune: c1ec4a95-1f05-45b3-a911-aa3fa01094f5

The theory is that you should be able to check accounts assigned EMS E3 to retrieve information about one of the service plans in the SKU and retrieve and report the assigned date. I don’t have EMS E3 in my tenant, but I do have EMS E5. I therefore checked the theory by running this PowerShell code:

# Check the date when a service plan belonging to a product like EMS E3 is assigned to an account
$EMSE3 = "efccb6f7-5641-4e0e-bd10-b4976e1bf68e" # Product SKU identifier for Enterprise Mobility and Security E3
$EMSE5 = "b05e124f-c7cc-45a0-a6aa-8cf78c946968" # Product SKU identifier for Enterprise Mobility and Security E5
$TestSP = "41781fb2-bc02-4b7c-bd55-b576c07bb09d" # Azure Active Directory Premium P1
$Report = [System.Collections.Generic.List[Object]]::new()
# Find tenant accounts
Write-Host "Finding Azure AD accounts..."
[Array]$Users = Get-MgUser -Filter "UserType eq 'Member'" -All | Sort DisplayName
ForEach ($User in $Users) {
  ForEach ($SP in $User.AssignedPlans) {
   If (($User.AssignedLicenses.SkuId -contains $EMSE5) -and ($SP.ServicePlanId -eq $TestSP -and $SP.CapabilityStatus -eq "Enabled")) {
        $ReportLine = [PSCustomObject][Ordered]@{  
          User            = $User.DisplayName
          UPN             = $User.UserPrincipalName
          ServicePlan     = $SP.Service
          ServicePlanId   = $SP.ServicePlanId 
          Assigned        = Get-Date($SP.AssignedDateTime) -format g
         }
        $Report.Add($ReportLine)
    } #End if
  } #End ForEach Service plans
} #End ForEach Users

After defining some variables, the code calls the Get-MgUser cmdlet to find the Azure AD accounts in the tenant (I used the script described in this article as the basis; see this article for more information about the Microsoft Graph SDK for PowerShell). Make sure that you connect to the beta endpoint as license information is not available with the V1.0 endpoint (run Select-MgProfile beta after connecting to the Graph).

Next, the code checks the assigned plans and if the desired plan belongs to the right product and is enabled, we report it. Each line in the report is like this:

User          : Kim Akers
UPN           : Kim.Akers@office365itpros.com
ServicePlan   : AADPremiumService
ServicePlanId : 41781fb2-bc02-4b7c-bd55-b576c07bb09d
Assigned      : 11/11/2017 16:52

This is a quick and dirty answer to the problem of discovering when a product license is assigned to user accounts. It might serve to fill in while Microsoft improves matters.

As reported by Vasil Michev, Microsoft recently added a licenseAssignmentState resource to the Graph API. This isn’t yet available for PowerShell, but the date information can be retrieved using the Graph. In this snippet, we find user accounts and examine their assignment state for EMS E5 to discover when the license was assigned. The code assumes that you’ve already used a registered app to authenticate and fetch an access token to interact the Graph APIs. Remember that you might need to use pagination to fetch all the pages of user data available in the tenant. Anyway, here’s my quick and dirty code to prove the point:

# Use the Graph API to check license assignment states
Write-Host "Fetching user information from Azure AD..."
$Uri = "https://graph.microsoft.com/v1.0/users?&`$filter=userType eq 'Member'"
[Array]$Users = (Invoke-RestMethod -Uri $Uri -Headers $Headers -Method Get -ContentType "application/json")
$Users = $Users.Value

Write-Host “Processing users…”
ForEach ($User in $Users) {
    $Uri = "https://graph.microsoft.com/beta/users/" + $User.UserPrincipalName + "?`$select=licenseAssignmentStates"
    [Array]$Assignments = Get-GraphData -Uri $Uri -AccessToken $Token
    ForEach ($License in $Assignments.LicenseAssignmentStates) {
        $LicenseUpdateDate = $Null
        If ($License.SkuId -eq $EMSE5 -and $License.State -eq "Active") {
           If ([string]::IsNullOrWhiteSpace(($License.lastUpdatedDateTime)) -eq $False ) {
              $LicenseUpdateDate = Get-Date($License.lastUpdatedDateTime) -format g }
           Else {
              $LicenseUpdateDate = "Not set" }
           Write-Host ("Last update for EMS for {0} on {1}" -f $User.DisplayName, $LicenseUpdateDate) }
    } # End ForEach License
} # End ForEach User

Last update for EMS for Tony Redmond on 15/07/2021 15:28
Last update for EMS for Andy Ruth (Director) on Not set
Last update for EMS for Kim Akers on 26/10/2021 16:58
Last update for EMS for Jack Hones on Not set
Last update for EMS for Oisin Johnston on 03/10/2020 13:18

The dates retrieved using this method differ to the values you get from service plans because Microsoft is populating these values using the last licensing change made to the account. However, in the future, the dates will be more accurate and usable because they will capture changes, hopefully when PowerShell access is possible.

No Audit Data

In passing, I note that the Office 365 audit log captures a “Change user license” audit record when an administrator updates the licenses for an account. However, the audit record doesn’t include details of what licenses were added, changed, or removed. The Azure AD team could do a better job of capturing audit information about license updates. I’m sure they’ll be happy to hear that.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new development as they happen.

Microsoft 365 Tenants Need to Link their Entra ID 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 Office 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 engra ID P1 MAU costs $0.00325.

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.

Current Implementation Blocks Some but Not All Use of Reserved Aliases with Groups

SMTP email addresses are composed of an alias (otherwise called a mail nickname) and a domain. The alias is assigned to a mailbox or other mail-enabled object to allow it to receive email. User clients tend to generate aliases automatically when creating new groups. Administrative interfaces like the Microsoft 365 admin center or PowerShell allow more control over the alias given to new mail-enabled objects. And then we come to the question of reserved email aliases.

A reserved alias is a sensitive name that’s usually kept for specific purposes. Azure AD defines a set of reserved or highly-privileged aliases which it doesn’t allow for (some) mail-enabled groups. The purposes that these aliases often serve including being the contact address for an email system or web site. Obviously, you don’t want a common-or-garden group to hijack an email address which people might assume is used for a different purpose.

It is not unusual for email systems to ring-fence reserved aliases. Google Workspace does the same, explaining that “The following words can’t be used in the email addresses of groups that you create in groups.google.com:

• abuse
• admin
• administrator
• hostmaster
• majordomo
• postmaster
• root
• ssl-admin
• webmaster

Azure AD adds “secure” and “security” to the list.

Testing the Creation of Groups with Reserved Aliases

The Azure AD documentation says that an Azure AD global administrator can create groups with reserved aliases. This isn’t altogether true as it depends on the administrative interface used, which points to an inconsistency of implementation across Microsoft 365. Table 1 shows the results of some tests I did to see if I could create groups with reserved aliases.

I am a global tenant administrator, so finding five administrative endpoints where it’s possible to create a mail-enabled group with a reserved alias confirms that the documentation’s assertion that global administrators can create these groups is correct. A more exhaustive test might find more, especially in PowerShell cmdlets.

However, the problem is the five places where a global administrator couldn’t create groups with reserved aliases. Three of these are distribution lists, the others are mail-enabled security groups. That’s where the inconsistency exists. Microsoft’s documentation mentions “groups,” a term which covers a spectrum of different types of group objects and doesn’t focus on any specific kind of group. This raises the question of why are distribution lists and mail-enabled security groups treated differently?

Testing is simple. Select an administrative interface and see if you can create a group with a reserved alias (Figure 1).

When the Microsoft 365 admin center or Exchange Online admin center detect a problem creating a group with a reserved alias, it flags the error. The error text is by no means perfect. It starts off by pointing to a synchronization issue between Azure AD and Exchange Online before saying that the value for the alias is incorrect as it contains a blocked word.

Pointing to synchronization between Azure AD and Exchange Online is misleading. The two workloads use a dual-write process to make sure that the creation or update of a mail-enabled object occurs in both directories or not at all. Microsoft introduced the double-write some years ago to avoid synchronization issues between Azure AD (the directory of record for Microsoft 365) and Exchange Online (which has its own directory for mail-enabled objects). Reading the text, I assume that Exchange Online rejected the attempt to create the new group because of the reserved alias and Azure AD then declined the write.

PowerShell Inconsistencies Too

Other administrative interfaces give different errors. For instance, here we create a new security group with Azure AD PowerShell. Azure AD accepts the reserved alias because this group is not mail-enabled. If we try to mail-enable the group, we get an error.

New-AzureADGroup -Description "Abuse Group" -DisplayName "Abuse Group" -MailNickName Abuse -MailEnabled $False -SecurityEnabled $True

ObjectId                             DisplayName Description
--------                             ----------- -----------
d347eec5-62f1-4436-af41-e53fa18090be Abuse Group Abuse Group

Set-AzureADGroup -ObjectId d347eec5-62f1-4436-af41-e53fa18090be -MailEnabled $True
Set-AzureADGroup : Error occurred while executing SetGroup
Code: Request_BadRequest
Message: The service does not currently support writes of mail-enabled groups. Please ensure that the mail-enablement
property is unset and the security-enablement property is set.     

The Exchange Online cmdlets to work with Microsoft 365 groups are happy to accept reserved aliases:

New-UnifiedGroup -DisplayName "Majordomo Group" -Alias Majordomo -Members Tony.Redmond@office365itpros.com -Owner Tony.Redmond@office365itpros.com
Set-UnifiedGroup -Identity Majordomo -PrimarySmtpAddress Majordomo@office365itpros.com
Get-UnifiedGroup -Identity Majordomo | fl EmailAddresses

EmailAddresses : {SPO:SPO_720c5dd5-e387-4c93-836d-899466759f64@SPO_b662313f-14fc-43a2-9a7a-d2e27f4f3478, smtp:majordomo@office365itpros.onmicrosoft.com, SMTP:majordomo@office365itpros.com}

But the Exchange Online cmdlets for distribution lists are not so content to assign reserved aliases:

New-DistributionGroup -DisplayName "Secure" -Alias "Secure" -PrimarySmtpAddress Secure@Office365itpros.com -Name "Secure Group"
An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online.
However, it failed. Detailed error message:
        The value specified for property Alias is incorrect. Reason: ContainsBlockedWord RequestId :
514d14b4-cc5f-4581-b97a-9930dff98542
The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members
for more information.
    + CategoryInfo          : NotSpecified: (:) [New-DistributionGroup], UnableToWriteToAadException
    + FullyQualifiedErrorId : [Server=DB9PR04MB8445,RequestId=9f8a149c-dc90-4196-9274-7625148d6280,TimeStamp=25/08/202
   1 12:05:53] [FailureCategory=Cmdlet-UnableToWriteToAadException] AEC31773,Microsoft.Exchange.Management.RecipientTasks.NewDistributionGroup
    + PSComputerName        : outlook.office365.com

Moving along, we can assign a reserved alias to a dynamic distribution list.

Get-DynamicDistributionGroup "Secure DDL" | fl primarysmtpaddress

PrimarySmtpAddress : Secure@office365itpros.com

The Need for Consistency

One way of looking at this is to say that so many ways exist to create new mail-enabled groups within Microsoft 365 that it’s inevitable that some inconsistencies will creep in. However, the current situation shows all the signs of poor attention to detail. Global administrators usually know what they’re doing when they create groups. Users can create distribution lists and Microsoft 365 groups/teams (if allowed by policy), so user-driven creation is where an absolute block should exist on reserved aliases.

It would be nice if Microsoft either lived up to its assertion that global administrators aren’t subject to the block on using reserved aliases or documented exactly where they can and cannot create groups with reserved aliases. Knowing what to expect and where to do it is so much better than probing holes in documentation.

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

Applying Governance to Graph-Based Apps

Update (November 3): The App governance add-on is out of preview and generally available.

In mid-July, Microsoft introduced the preview of an app governance add-on for Microsoft Defender for Cloud Apps (MCAS), describing the new capability as a “security and policy management capability designed for OAuth-enabled apps that access Microsoft 365 data through Microsoft Graph APIs.”

There’s no doubt that tenants can accumulate a collection of Graph-enabled apps over time. The apps come from Microsoft, ISVs, and line of business apps. Indeed, any PowerShell script you write to interact with the Graph APIs gains its permissions through consent granted to an app registered with Azure AD. The net result is that you can end up with hundreds of registered apps, all with Graph permissions, some of which you might not know much about. App governance aims to deliver a structured management framework for those apps, leveraging information taken from Azure AD and MCAS.

Microsoft research clearly shows that attackers use illicit consent grants for Graph-based apps to extract and abuse data. Given the likelihood that organizations will have more Graph-based apps to manage over time, it’s important that administrators understand app usage in their tenant. Unfortunately, the need to review and analyze app usage often falls down task lists, which is the hole the app governance add-on attempts to close.

The Need for MCAS

MCAS isn’t included in any Office 365 plan. Office 365 E5 includes Office 365 Cloud App Security (OCAS), a cut-down version of the full-blown MCAS. Both operate on the same basis of data gathered from user and app activity, but MCAS delivers more functionality and covers more apps. For this pleasure, tenants need to pay more to license MCAS, unless they’ve already invested in Microsoft 365 E5, Enterprise Mobility and Security E5, or one of the other licenses which cover MCAS. You need MCAS to use the new add-on, which doesn’t work with OCAS.

Fortunately, Microsoft offers organizations the chance to run a 30-day trial for MCAS by signing up through the Purchase services section of the Microsoft 365 admin center. After starting the MCAS trial and assigning some licenses to accounts with suitable administrator roles, you can go ahead and start a trial of the add-on. Curiously, the add-on allows a 130-day trial, which might be due to its desire to capture and analyze usage data for apps over a reasonable period. Of course, if you sign up for both trials, MCAS expires after 30 days, and you won’t be able to use the add-on afterwards.

Using App Governance

App governance runs within the Microsoft 365 admin center. If your account isn’t licensed or doesn’t hold one of the necessary compliance roles, you’ll be told this unhappy news if you attempt to access the page. Licensed administrators see a preview of the app situation in the tenant (Figure 1).

I had recently been through an audit of apps based on grabbing app data from Azure AD and reviewing the data through Microsoft Lists, so there are fewer apps present in my tenant than existed previously. As I reviewed the data set, I found a couple of additional apps that I could disable or remove. You can disable an app by viewing its properties through App governance; to remove it, you need to use the Azure AD admin center. Disabling is a good first step to removing a potentially problematic app as you can easily enable the app if someone reports that a business case exists for its use.

In my tenant, app governance detected 33 high privileged apps and 13 overprivileged. Microsoft’s definitions for these categories are:

• High privilege: Consent has been granted to the app for Graph permissions that allow the app to access data or change key settings in the organization.
• Overprivileged: Consent has been granted to the app for Graph permissions the app doesn’t use.

To examine details of an app to understand why it falls into a certain category, click Apps, and peruse the list of apps to select and view the app properties (Figure 2).

As you can see, the portal includes several filters to limit the set of displayed apps. The set of available filters misses one to show disabled apps. This means that if you need to find a disabled app, perhaps to reenable it if the app had been disabled in error, you either need to know the name of the disabled app or do a lot of checking to find the right app.

Probing Permissions

Mmany apps fall into the high privilege category because they read user information. For example, the app used by Microsoft Ignite conference attendees to register has permission to see the user’s email and profile. Apps created by ISVs to read and report tenant data need access to the directory, and that is flagged as a high privilege permission because attacker apps also use the permission to find targets. Even Microsoft’s own Information Barriers app is flagged as high privilege because it has the Directory.Rewrite.All and Groups.Rewrite.All permissions. As always, understanding the context of what an app does is necessary to understand why it needs permissions.

App governance allows tenant administrators to automate checks by creating policies to monitor the creation of overprivileged or high privilege apps. This functionality works like the other alert policies available in the Microsoft 365 compliance center with the exception that the input data focuses on apps rather than actions. As you can see in Figure 1, policies quickly flag new apps which violate criteria. But as pointed out above, you then need to check the app to figure out if a problem really exists.

Permission Glitches

The add-on is a preview, so glitches are expected. For example, app governance flagged an app written to support adding organizational contacts to new user mailboxes as overprivileged. When I examined details of the app (Figure 3), the unused permission is Contacts.ReadWrite. This is odd because that’s the exact permission needed to write a new contact record into a mailbox.

Apart from app details and permissions, App Governance promises to show data about usage and users. Taking users first, I thought this information to be quite useless. The information shown on Figure 4 tells me that 237 consented users exist (Azure AD accounts with data the consents granted to the app covers). This figure includes both tenant and guest accounts and results because an administrator granted consent to the app for the entire organization (if consent is given for individual accounts, they are listed here). The five priority users are those marked as priority accounts. None of the priority accounts (including my own) had any trace of data uploaded or downloaded using the app. Given the app is Microsoft’s Graph Explorer, which I use to test Graph API queries almost daily, this was surprising.

After being disappointed with the data available for users, I didn’t hold out much hope for the Usage (beta) tab. And my expectations were met as precisely nothing showed up here. Instead, App governance informed me that no data was present. Oh well, it’s a preview.

DIY App Governance

As mentioned above, it is relatively simple to perform a DIY audit of Microsoft 365 Graph-enabled apps. Home-grown knowledge of apps used in a tenant is an advantage MCAS can’t deliver, but to exploit that knowledge, some work is necessary to acquire, refine, and understand the app inventory – and to keep on checking on a systematic basis.

App governance extends simple auditing by including policy-based management, categorizing apps based on the permissions they hold, and delivering some insights into app usage. Although still just a preview with all that implies, if your organization has MCAS, the add-on is a useful enhancement. If not, although the need to monitor the granting and usage of permissions in Graph-enabled apps is a real need, you might be able to construct your own method to achieve the goal.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Protect Most Confidential SharePoint Online Sites

Adding to their container management capabilities, a feature for sensitivity labels demonstrate how to use authentication contexts with Entra ID conditional access policies to ensure secure access to information in SharePoint Online sites.

An authentication context is a way to tag information which needs special attention. First introduced in March 2021, authentication contexts are additional information required by a service provider before it grants access to a resource. Microsoft positions authentication contexts as a method to “target policies for data and actions within an app.” Put another way, authentication contexts allow organizations to apply more granular control to targeted data.

As implemented for sensitivity labels, authentication contexts link conditional access policies to let applications like SharePoint Online know that users must provide some extra information before they can access information in labelled sites. Let’s work through an example.

Define an Authentication Context

The first thing to do is to define an authentication context. In the Security section of the Entra ID admin center, open the Protection section, select Conditional Access and choose Authentication context. I created a context called Require MFA (Figure 1). The name is what you’ll see in apps like sensitivity labels. The ID for the context shown towards the bottom of the screen (c1 in this case) is an internal value written into the settings of sensitivity labels which use authentication contexts.

The Publish to apps checkbox is set, meaning that this authentication context is visible to apps like sensitivity labels and can be used by conditional access policies.

Create a Conditional Access Policy

The next step is to create a conditional access policy to use the authentication context to force multi-factor authentication. Conditional access policies can range from very simple to very complex. To prove that everything works as expected, I created a simple policy which blocks access to resources tagged with the authentication context unless the user authenticates with MFA. The new thing here is that you select the authentication context instead of apps (Figure 2). The requirement to use MFA is selected in the Grant section (not shown here).

Another easy thing to include in a conditional access policy to protect sensitive data is to include a terms of use (TOU) check to force users to read and acknowledge conditions governing access before they gain access to a site.

Updating the Sensitivity Label

To protect SharePoint Online sites with the conditional access policy, we configure a sensitivity label with the authentication context. Figure 3 shows the UI for sensitivity labels where we’ve selected the authentication context.

Any attempt to access a site with the label causes SharePoint Online to look at the label settings to see if an authentication context is specified. If one is found, SharePoint Online queries Entra ID to find which conditional access policy is associated with the authentication context and invokes the policy. In our example, attempts to access the site succeed if the user authenticates with MFA and fail otherwise.

Using PowerShell to Assign Authentication Contexts to Sites

The value of Sensitivity labels is that they make it easy to assign a set of different controls to containers, including conditional access policy protection to SharePoint Online sites. However, if your tenant doesn’t use sensitivity labels (yet), you can update sites with PowerShell. After you assign a label with an authentication context to a site, SharePoint Online updates two site settings:

• ConditionAccessPolicy: Holds the name of the conditional access policy protecting the site. When using an authentication context, this value is “AuthenticationContext.”
• AuthenticationContextName: Holds the name of the selected authentication context. As per Figure 1, it is “Require MFA.”

Check the values by running the Get-SPOSite cmdlet:

Get-SPOSite -Identity https://office365itpros.sharepoint.com/sites/SuperConfidential | ft con*, aut*

ConditionalAccessPolicy AuthenticationContextName
----------------------- -------------------------
  AuthenticationContext Require MFA

Now we know the properties to update, we can update other sites using the Set-SPOSite cmdlet:

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/ProjectAjax -AuthenticationContextName "Require MFA" -ConditionalAccessPolicy "AuthenticationContext"

Testing the Block

To test that everything worked as expected, I used Teams. Many SharePoint sites created today are linked to Teams, so it seemed like a good test scenario. As expected, when I tried to access a site assigned the sensitivity label without using MFA, the Teams Files channel tab failed to connect and displayed an error (Figure 4).

Microsoft says that they are upgrading the Teams Files channel tab to prompt for MFA authentication when necessary. This will make access smoother and avoid users seeing the instant fail in the current experience.

When I tried to open the site using the SharePoint Online browser interface, it opened successfully. This puzzled me for a moment until I realized it was because the account had gone through a self-service password reset (SSPR) challenge and that the credentials gathered through that process satisfied the MFA requirement. This is because Microsoft now uses combined security information for MFA and SSPR (if your organization doesn’t use combined registration, you can enable it using these instructions). When I encountered the SSPR “your organization needs more information” challenge, it didn’t immediately make me think that MFA was involved, but it was!

To confirm that Entra ID enforces the conditional access policy for the site, you can check the Entra ID sign-in logs. Figure 5 shows that Entra ID invoked the policy because a user covered by the policy signed into SharePoint Online. The sign-in record doesn’t capture details of the site, but if only one sensitivity label uses the conditional access policy and you know who signed in, you can put two and two together to know what happened.

Increasing Control

Linking sensitivity labels with conditional access policies increases the granularity of control a label can exercise over SharePoint Online sites and increases the usefulness of sensitivity labels for container management. Multiple conditional access policies can use a context, which opens a bunch of different possibilities about how to control access in different circumstances.

Given the amount of confidential information stored in SharePoint Online, it’s nice to be able control conditional access so easily and a good example of how Microsoft is steadily building up the container management capabilities for sensitivity labels. Make sure that you have the necessary licenses before you use the feature!

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Microsoft Graph PowerShell SDK is the Future

For anyone who’s ever used the Azure AD or Microsoft Online Services (MSOL) PowerShell modules to write PowerShell code to automate some aspect of tenant administration, Microsoft’s June 2 announcement about their future direction for Azure AD PowerShell was big news. In a nutshell, Microsoft is focusing on the Graph APIs for identity management. As a consequence, any software which leverages the Azure AD Graph API, like the Azure AD module, is on the runway to deprecation.

Important Points for the Next Year

Last year, Microsoft announced that they would no longer support or provide security updates for the Azure AD Graph API after 30 June 2022. Now they are being more specific about what this end of support decision means for customers. The following points are important:

• Microsoft’s future investments for identity management are focused on the Microsoft Graph SDK for PowerShell. This is a wrapper around the Graph APIs and is already in use for purposes like setting tenant privacy options for the Insights API.
• The Azure AD and MSOL modules will not be supported for PowerShell 7.
• New identity APIs will be available through the Microsoft Graph PowerShell SDK (Figure 1).
• Microsoft’s investments will center on user, group, and application management, plus role-based access control (RBAC), which is important in terms of making sure that administrators don’t need all-powerful permissions to get work done. Microsoft 365 uses an increasing number of role groups to assign administrative work to different accounts.
• Microsoft also says that they will invest in usability for the Microsoft Graph PowerShell SDK, which is a good thing because the SDK cmdlets aren’t quite as approachable as those in other modules. The documentation is not in good shape either. See my articles covering basic Azure AD user account management and group management for details.

Microsoft says that their goal is that “every Azure AD feature has an API in Microsoft Graph so you can administer Azure AD through the Microsoft Graph API or Microsoft Graph SDK for PowerShell.” They don’t say that every feature will be accessible through the Microsoft Graph PowerShell SDK. In some cases, you’ll need to run pure Graph API calls, but that’s easily done using PowerShell (for an example, see this article on accessing Azure AD access reviews from PowerShell.

Update August 1, 2022: Microsoft has pushed out the previously announced retirement date for the license management cmdlets in the Azure AD and MSOL modules (August 26, 2022) to March 31, 2023. They have delayed the retirement of the Azure AD Graph API until the end of 2022 to give customers extra time to adjust.

It’s Different With the Graph

The net takeaway is that tenants need to review any PowerShell scripts which use the Azure AD or MSOL modules to prepare plans to upgrade scripts to use the Microsoft Graph PowerShell SDK or Graph API calls in the future. Given the number of Office 365 tenants, the pervasive use of PowerShell to automate operations, and the core position of Azure AD in those operations, it’s likely that millions of scripts will need upgrades. I know that I have a bunch of scripts to review and will discuss how the upgrade process proceeds in future articles. Already, I know it won’t be simply a case of replacing all occurrences of Azure AD cmdlets with equivalent Graph SDK calls, like replacing Get-AzureADUser with Get-MgUser. Parameters and output are likely to be different and code will need to be adjusted to cope.

While upgrading scripts is a big job, each script is a one-time activity. Interactive access is another issue. Today, it’s easy to run Connect-AzureAD to connect to Azure AD and then run whatever cmdlets you need to interrogate the directory. The equivalent actions with the SDK are:

First, you connect to the Graph and set the scope (permissions) needed to interact with Azure AD. Unless a suitable access token is available, this starts a device authentication sequence.

Connect-MgGraph -Scopes "User.Read.All","Group.ReadWrite.All"
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code D7DPGD3WL to authenticate.

Opening a web page and inputting the code causes another dialog to appear to confirm consent for the operation (Figure 2).

After consent is granted, you can then go ahead and issue commands. For example, here’s how to fetch a list of guest accounts:

$Guests = Get-MgUser -Filter "UserType eq 'Guest'"

Like most Graph commands, the amount of data returned is constrained to 100 items, so if you want more, you need to specify the All parameter.

The bottom line is that some more up-front thought is needed (to set permissions) before connecting to the Graph SDK and that the authentication flow is not as seamless as it is when running Connect-AzureAD. No doubt this is an area where Microsoft might look at to remove some rough edges.

Time to Prepare Upgrades

Losing support for the Azure AD and MSOL modules sometime in 2022 is a concern, but we’ve seen other instances when Microsoft has extended support to allow customers extra time to get work done, and anyway, losing support doesn’t mean that code will suddenly stop working. Scripts will continue to run. You just won’t be able to ask Microsoft to fix bugs.

One thing you can guarantee in the cloud is that change happens. This is just another example of how that change occurs.

The Office 365 for IT Pros team will document our learning with upgrading PowerShell scripts from the Azure AD module to use the Microsoft Graph PowerShell SDK in the months ago. It should be fun… Subscribe now to make sure that you stay abreast of developments.

Change Made without Warning for Security Reasons

Without any warning, Microsoft seems to have introduced a restriction to the Set-User cmdlet in the Exchange Online management PowerShell module. The change happens when you connect a new PowerShell session to Exchange Online and the cmdlets are downloaded into a session.

Security Problems Updating Work or Mobile Numbers

Any attempt to update a user’s business or mobile phone numbers with Set-User now generates an error saying that for security reasons these properties cannot be updated through Exchange Online. Instead, administrators are forced to update the properties through the Azure AD admin center or by using the Azure AD PowerShell module.

Set-User -id $User -Phone "+1 454 146 1412"
Phone and Mobile Phone for users with Recipient Type Details "UserMailbox" cannot be updated in Exchange Online for security reason. Please do it in Azure Active Directory.
    + CategoryInfo          : NotSpecified: (Jessica.Chen@office365itpros.com:UserIdParameter) [Set-User], ShouldNotUpdate...eInExoException
    + FullyQualifiedErrorId : [Server=AM4PR0401MB2289,RequestId=39d0dbcb-05d1-42e6-b8ea-4bc78fc58816,TimeStamp=10/05/2
   021 22:22:12] [FailureCategory=Cmdlet-ShouldNotUpdatePhoneMobilePhoneInExoException] 1D58FC00,Microsoft.Exchange.Management.RecipientTasks.SetUser
    + PSComputerName        : outlook.office365.com

Set-user -id $User -MobilePhone "+1 464 147 4433"
Phone and Mobile Phone for users with Recipient Type Details "UserMailbox" cannot be updated in Exchange Online for
security reason. Please do it in Azure Active Directory.
    + CategoryInfo          : NotSpecified: (Jessica.Chen@office365itpros.com:UserIdParameter) [Set-User], ShouldNotUpdate...eInExoException
    + FullyQualifiedErrorId : [Server=AM4PR0401MB2289,RequestId=4cffcdc2-5bc0-4d17-83bf-a4d7bb67d2a5,TimeStamp=10/05/2
   021 22:22:21] [FailureCategory=Cmdlet-ShouldNotUpdatePhoneMobilePhoneInExoException] 1D58FC00,Microsoft.Exchange.Management.RecipientTasks.SetUser
    + PSComputerName        : outlook.office365.com

Oddly, Set-User is still able to update other phone numbers such as a user’s phone or alternative number. You can also update someone’s pager number (if they still use one) and their fax number. The fax number also appears as a property for an Azure AD account, so if Microsoft decided to block the business and mobile numbers, it’s strange that they left the fax number alone.

Disruption to Scripts

Set-User has been part of Exchange PowerShell since Exchange 2007. The cmdlet is a method to update account properties stored in Active Directory and Azure Active Directory which are important to Exchange (because they appear in address lists). Changing behavior without warning is disruptive to organizations because it might impact scripts used for production purposes, such as taking a feed from a HR system and updating user accounts.

Microsoft’s error message implies that the change happened for security reasons, but as they haven’t explained any detail about why it is a security problem to allow Set-User to update phone numbers, it’s hard to assess what’s going on here. If it’s a problem for Set-User to update telephone numbers, why is it OK for Set-AzureADUser to do the same?

Set-AzureADUser -ObjectId Jessica.Chen@office365itpros.com -TelephoneNumber "+1 550 771 1314" -Mobile "+1 466 146 1453"

Roles and Permissions

Accounts need different permissions to run the two cmdlets. Accounts holding the Exchange administrator role can update mailbox properties (some of which synchronize with Azure AD) but can’t do so using Azure AD interfaces like the Azure AD PowerShell module. It could be that Microsoft wants to tighten the ability of users with workload-specific roles to update Azure AD.

Although I can’t prove this, I suspect that the tightening is at the heart of problems reported with the Set-CsUser cmdlet since the release of V2.3.0 of the Microsoft Teams PowerShell module last month (see this Microsoft Technical Community post for some details of user issues).

Communications Failure

Microsoft is much better at communicating change within Office 365 today than they used to be, notably through the Microsoft 365 roadmap and the notifications posted to the Microsoft 365 admin center. This change came out of the blue and landed without warning. People don’t like surprises and always react better if the logic behind an update is clearly explained. Everyone will get behind a change which helps to improve security – unless they find out when their scripts stop working.

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.

Self-Service Photo Updates

It’s easy for tenant administrators to add photos for guest accounts using the Azure AD portal. They can also run the Set-AzureADUserThumbnailPhoto cmdlet to do the same job. The difference is that apps can display Azure AD guest photos where otherwise they’d show the default initials (Figure 1).

What isn’t easy is for people who have guest accounts in other Microsoft 365 tenants to update their photo without administrator intervention. Microsoft blocks guest users from the features built into apps like Teams to allow users to update their photos, probably because guest accounts are not subject to the OWA mailbox policies which control this feature for tenant accounts.

Then MVP Yannick Reekmans published a blog to explain how he used the Azure AD portal to update a guest account in another tenant. The article explains how to find the GUID of the guest account in the target tenant and how to use the GUID to update the account. The method certainly works, but it’s a tad overcomplicated for my taste.

PowerShell makes the task very easy. Here’s how to do the job in three steps.

Sign into the Target Tenant

The key to this method is to use cmdlets in the Azure AD or Azure AD Preview modules. Make sure to download and install one of these modules on your workstation. Then, run the Connect-AzureAD cmdlet to connect to the service domain of the target tenant.

The service domain is the sub-domain in onmicrosoft.com used by the tenant. For example, to connect to the Office365ITPros.com tenant, we’d use the command:

Connect-AzureAD -Tenant Office365ITPros.onmicrosoft.com

Azure AD prompts you to authenticate. Use your normal account and sign in with its password (and MFA, if required by the tenant). Your normal account connects to the guest account, so when you authenticate, you use the guest account to access the target tenant. If you don’t know the service domain for the target tenant, use the What’s My Tenant ID site to find tenant GUID and use it to sign in. For example:

Connect-AzureAD -Tenant 72f988bf-86f1-41af-91ab-2d7cdxab647

Then run the Get-AzureADTenantDetail cmdlet and examine the VerifiedDomains property to find the service domain.

(Get-AzureADTenantDetail | Select-Object -ExpandProperty VerifiedDomains | Where-Object {$_.name -match "onmicrosoft"}).Name

Figure Out the User Principal Name

You can reference Azure AD accounts with the GUID (object identifier) or user principal name (UPN). The UPN is usually easier to figure out because it follows a set format. For instance, the guest account for the account with UPN Tony.Redmond@office365itpros.com is:

tony.redmond_office365itpros.com#EXT#@xxxxx.onmicrosoft.com

Where “xxxxx” is the name of the target tenant.

To make things easier, we put the UPN into a variable:

$UPN = "tony.redmond_office365itpros.com#EXT#@xxxxx.onmicrosoft.com"

Update the Photo for the Guest Account

Azure AD needs a suitable photo file (JPEG or PNG) to update a user’s image. Unlike Exchange Online, which stores a higher resolution form of photo data for use by Microsoft 365 apps, Azure AD stores only small thumbnail images. These images are acceptable for the small photos seen in Teams conversations or in browser menu bars, but not for attendee cards used in Teams meetings, so they do not appear everywhere within Microsoft 365.

The maximum size of the input file is 100 KB. I’ve had good results with square photos measuring 500 x 500 pixels. You might have to play with a photo editor to create a good photo of the right size, but once you have one, you can write it into Azure AD using the Set-AzureADUserThumbnailPhoto cmdlet:

Set-AzureADUserThumbNailPhoto -ObjectId $UPN -FilePath c:\temp\MyPhoto.jpg

If you don’t see an error, you know Azure AD is happy with the photo. To check, you can run the Get-AzureADUserThumbnailPhoto cmdlet. Any response is good:

Get-AzureADUserThumbnailPhoto -ObjectId $UPN

Tag                  :
PhysicalDimension    : {Width=500, Height=500}
Size                 : {Width=500, Height=500}
Width                : 500
Height               : 500
HorizontalResolution : 95.9866
VerticalResolution   : 95.9866
Flags                : 77842
RawFormat            : [ImageFormat: b96b3caf-0728-11d3-9d7b-0000f81ef32e]
PixelFormat          : Format32bppArgb
Palette              : System.Drawing.Imaging.ColorPalette
FrameDimensionsList  : {7462dc86-6180-4c7e-8e3f-ee7333a7a483}
PropertyIdList       : {769, 305, 20752, 20753...}
PropertyItems        : {769, 305, 20752, 20753...}

Like any operation involving photo manipulation for Azure AD accounts, it takes some time for applications to refresh their caches and pick up new photos. You should expect that this will happen within a day. And once it does, you’ll see your bright smiling face in places where only your initials were before (Figure 2).

And then all you need to do is to rinse and repeat the process for every tenant where you have a guest account (possibly some of which you have forgotten). For whatever reason, some tenants always seem to be slower than others to respect photo updates. I have no idea why this happens. Stay patient and the photos should turn up eventually.

Not Too Much for Administrators to Worry About

It’s good when guest accounts have photos. People like to know with whom they collaborate, and a photo is a much better reminder of a person than their initials can ever be. Tenant administrators might be concerned that guest users can sign into their tenant to update their photos. It’s true that guests could exploit this technique to display an inappropriate image. If they do, I’m sure that action will follow quickly, just like it would if a tenant user selected a distasteful photo. Another concern might be that guests might be able to update other account properties, like the display name. Much as I would like to do this, I haven’t been able to in any of the tenants where I tried. Azure AD allows me to update my photo but stops me doing anything else to my guest account. Which is how it should be.

Need to know more about managing guest accounts in an Office 365 tenant? The Office 365 for IT Pros eBook is packed full of advice and guidance on this and many other topics.

Azure AD Managers and Direct Reports Rely on Directory Accuracy

Last November, I wrote about why it’s important to have an accurate tenant directory (Azure AD). That article includes a script to check accounts for missing properties, one of which being the Manager. If that property isn’t populated, it means that an account is not listed as a direct report of another account (the manager), which makes it difficult for features like the Teams organizational view or Microsoft 365 profile card to work properly.

The Need to Avoid a Decaying Azure AD

Unless Azure AD receives updates from a HR system, it’s quite unsurprising when the directory loses track of manager-direct report relationships over time. And if no one checks, the directory will gradually decay to a point where its view of the organization’s structure is worthless. All of which means that we should check what’s in the directory periodically.

I have no idea about how individual companies record management structures, so I can’t help by telling you how to link systems with Azure AD. What I can do is show how easy it is to generate a report of what’s in Azure AD which can be used to identify potential issues to fix.

Some Azure AD Cmdlets Might Help

The idea is to find all the accounts in the tenant which have direct reports. It’s easy enough to do this for a single user. The Get-AzureADUserDirectReport cmdlet exists for this purpose. Once you know the object identifier for an Azure AD account, you can run:

Get-AzureADUserDirectReport -ObjectId eff4cd58-1bb8-4899-94de-795f656b4a18 | ft displayname

DisplayName
-----------
Kim Akers
Jeff Guillet
Ben Owens (Business Director)
Ståle Hansen (Office 365 for IT Pros)
James Ryan
Vasil Michev (Technical Guru)

The Get-AzureADUserManager cmdlet finds the manager of an account.

Get-AzureADUserManager -ObjectId cad05ccf-a359-4ac7-89e0-1e33bf37579e | ft DisplayName

DisplayName
-----------
Tony Redmond

It’s therefore possible to loop down through each user to find out who is their manager with code like this:

$Users = Get-AzureADUser -All:$true
# Now get rid of all the accounts created for room and resource mailboxes, service accounts etc.
$Users = $Users |?{($_.UserType -eq "Member" -and $_.AssignedLicenses -ne $Null)}

ForEach ($User in $Users) {
   $Manager = Get-AzureADUserManager -ObjectId $User.ObjectId
   If ($Manager) {
      Write-Host $User.DisplayName "manager is" $Manager.DisplayName }
   Else {
      Write-Host "No manager found for" $User.DisplayName }
}

Although this approach works, it means that we must find all users and then figure out who their manager is before reporting. A more logical approach is to find the managers in the organization and then work out their direct reports. There’s no straightforward way to do that with the Azure AD cmdlets without using intermediate arrays to store and then analyze who reports to who, but an easier way exists using the Exchange Get-User cmdlet.

Using Get-User to Retrieve Manager and Direct Reports

The Get-User cmdlet (part of the Exchange Online Management module) retrieves information about an account. The trick is that it can run a server-side filter to retrieve the direct reports of a manager. Better again, the cmdlet can also tell us which accounts have direct reports (the managers), including those who have no current direct reports.

To find the managers, we can run:

[array]$Managers = Get-User -Filter {DirectReports -ne $null} | Select DisplayName, UserPrincipalName, ExternalDirectoryObjectId, DistinguishedName

Once we know the managers, it’s simple to loop through each account to find their direct reports. The trick here is to filter using the distinguished name attribute for a manager’s account. It’s the same technique as used when Get-Recipient finds the set of groups a user belongs to. The technique is exploited in this article about generating a report of membership of Teams and Microsoft 365 Groups. Here’s how to find the set of direct reports for a manager:

[array]$Reports = Get-User -Filter "Manager -eq '$Dn'"

Once we know how to find managers and their direct reports, it’s easy to turn the data into a report, which is what I’ve done in a PowerShell script, which you can download from GitHub. Figure 1 shows the HTML report created by the script. Feel free to customize the report to your heart’s content.

PowerShell tip: We declare variables used to receive query results as arrays to make sure that we get an accurate count if only one item is returned. If you leave PowerShell to decide, when a single item is found by a query, the result is that item. You won’t be able to find the count for the item because it’s not an array or list. But if you explicitly declare the variable as an array, PowerShell respects your choice and you’ll be able to get a count even if only one item is in the array.

The Office 365 for IT Pros eBook is packed full of useful information, tips, and suggestions. That’s why the book is over 1,250 pages long… So much knowledge, so little time to read it all!

Avoiding the Need to Remove and Recreate Guest Accounts

Microsoft 365 applications like Microsoft 365 Groups, Teams, SharePoint Online, and Planner use Entra ID B2B Collaboration to enable guest user access to their resources. The result is that many tenants have a proliferation of guest accounts to manage. I’ve written quite a few tools to help, including a report of guest accounts and their membership of Microsoft 365 Groups and a comprehensive report of tenant and guest members in Groups and Teams. Management can even be a challenge for guests who want to renounce their membership of a tenant.

In any case, the details of some guest accounts change over their lifetime. On March 2, Microsoft issued documentation for Reset redemption status for a guest user. This doesn’t sound very exciting, but it’s really very interesting because the feature allows tenant administrators to adjust how a guest account is signed into without using the previous technique of removing and recreating an account. The downside of that approach is that access is lost to all the resources available to the guest account like Teams, SharePoint sites, shares to individual documents, and so on. After recreating the account, access must then be regranted for each resource. This process is tedious, especially when the guest features in multiple groups.

Microsoft anticipates that the reset feature will be used in scenarios such as:

• The user wants to sign in using a different email and identity provider. In other words, they now have a different account. For instance, the user might have moved companies and wishes to continue working with your company (a common scenario for professionals like IT consultants and lawyers).
• The account for the user in their home tenant has been deleted and recreated. Entra ID won’t recognize the link between the guest account and the user’s new account.
• The user’s responsibilities have been passed along to another user and they want to assign access to the resources which supported those responsibilities to that user.

Part of the change is performed using the Entra ID admin center. The rest is done with PowerShell cmdlets from the AzureAD Preview module, which you can download from the PowerShell Gallery.

Change the Email (Sign-in) Address for a Guest Account

Unlike tenant accounts, guest users don’t use their user principal name to sign in. Instead, they use their email address. To work, the reset feature changes the sign-in name for the guest account and nothing else. The mail user object created in Exchange Online to allow guest users to receive email is also updated.

In this example, I have a guest account for Jacko Winters. The original email address for this account is Flayosc@outlook.com. The guest is a member of multiple teams and shares some SharePoint documents. I want to reassign access to all these resources to another account called Flayosc@yandex.com. It’s an example of the first scenario described above.

The first step is to update the Mail attribute (Email address) for the guest account with the email address you want to use. Do this through the Entra ID admin center (Figure 1). The new email address cannot belong to any other mail-enabled object in the tenant, such as another guest account. If it does, Entra ID won’t allow you to update the account.

Moving to PowerShell, connect to AzureAD and get the Entra ID account identifier for the guest account you want to replace.

Connect-AzureAD
$ObjectId = (Get-AzureADUser -SearchString “Jacko Winters”).ObjectId
$ObjectId
558d8cbb-a5a2-4ea1-b950-0d0748ca5634

Now create a new User object and populate it with the object identifier for the account.

$OldUser = New-Object Microsoft.Open.MSGraph.Model.User -ArgumentList $ObjectId
$OldUser

Id                                   OdataType
--                                   ---------
558d8cbb-a5a2-4ea1-b950-0d0748ca5634

Issuing a New Invitation

The next thing to do is check that the values returned from the two commands match. If they do, use the New-AzureADMSInvitation cmdlet to reissue an invitation to the new email address. The identifier for the guest user account is passed in the InvitedUser parameter. The myapps.microsoft.com landing page is a default site showing apps available to a user. Here’s the command I ran:

New-AzureADMSInvitation -InvitedUserEmailAddress Flayosc@yandex.com -SendInvitationMessage $True -InviteRedirectUrl "http://myapps.microsoft.com" -InvitedUser $OldUser -ResetRedemption $True

Update: Given the deprecation of the AzureAD module in March 2024 (and the disappearance of the ResetRedemption parameter from the New-AzureADMSInvitation cmdlet), you should switch to the Microsoft Graph PowerShell SDK. This code is the equivalent using the Get-MgInvitation cmdlet:

$User = Get-MgUser -Filter "startsWith(mail, 'Flayosc@yandex.com')"
New-MgInvitation `
    -InvitedUserEmailAddress 'Flayosc@yandex.com' `
    -InviteRedirectUrl "http://myapps.microsoft.com" `
    -ResetRedemption `
    -SendInvitationMessage `
    -InvitedUser $User

See this documentation for more information.

Entra ID creates a new invitation to access the resources currently available to the guest account and sends it to the new email address. You’ll see a response like this:

Id                      : 129c1c12-da99-4879-b258-d14b34601d46
InvitedUserDisplayName  :
InvitedUserEmailAddress : Flayosc@yandex.com
SendInvitationMessage   : True
InviteRedeemUrl         : https://login.microsoftonline.com/redeem?rd=https%3a%2f%2finvitations.microsoft.com%2fredeem%
2f%3ftenant%3db662313f-14fc-43a2-9a7a-d2e27f4f3478%26user%3d129c1c12-da99-4879-b258-d14b34601
d46%26ticket%3dLStZd8uAONAIbLNIZyfaUZ91VsRczLbzqbFOeHsonSE%253d%26ver%3d2.0
InviteRedirectUrl       : http://myapps.microsoft.com/
InvitedUser             : class User {Id: 558d8cbb-a5a2-4ea1-b950-0d0748ca5634
OdataType: }

InvitedUserMessageInfo  : class InvitedUserMessageInfo {
                            CcRecipients: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.Recipient]
                            CustomizedMessageBody:
                            MessageLanguage:
                          }

InvitedUserType         : Guest
Status                  : PendingAcceptance
ResetRedemption         : True

Accepting the Reissued Invitation

The invitation arrives at the email address (Figure 2) and the user can accept the invitation to confirm their credentials (set a password) and create an OAuth consent to allow the tenant to read details of the user’s account (Figure 3).

Once the user consents to the permissions, the user account is updated to set the UserState property to Accepted and write the date of the redemption in UserStateChangedOn. We now have a fully functional guest account again. The important point is that the object identifier and user principal name for the account do not change. The only thing which changes is the mail address associated with the account.

The Entra ID audit log contains details of the issue (Figure 4) and redemption of the invitation. While the activity tab confirms the target address for the invitation, the target tab confirms the guest account.

Accessing Resources

In this instance, the guest account has access to several teams and some SharePoint documents. SharePoint access is immediate, including the sites used by Teams. Guest access to Planner also works properly.

After testing that access worked for SharePoint and Planner, I turned to Teams. I expected access to the Teams app to take longer because of the need to complete the process which synchronizes Entra ID with the membership roster used to control access to individual teams. Until this happens, the user is refused access to Teams (Figure 5) and the old email address assigned to the guest account remains visible in Teams (Figure 6). [Note that the display name of the guest account has reverted to Flayosc instead of Jacko Winters]

Unsurprisingly, because the account information in Teams is now outdated, any attempt to add the guest account as a new member of a team also generates an error (Figure 7).

To try to force synchronization, I updated the display name and several other attributes of the account. This had no effect, so I added a couple of new users to the group using Teams to force Teams to refresh its membership roster. The updates flowed through to Entra ID, but nothing happened in Teams.

Get-AzureADGroupMember -ObjectId b647d5ff-3bda-4333-b768-7990084569b6

ObjectId                             DisplayName                   UserPrincipalName
--------                             -----------                   -----------------
cff4cd58-1bb8-4899-94de-795f656b4a18 Tony Redmond                  Tony.Redmond@office365itpros.com
b3eeaea5-409f-4b89-b039-1bb68276e97d Ben Owens (Business Director) Ben.Owens@office365itpros.com
a6bfb216-e88c-4f1f-86d7-04747e5fc686 Ben James                     Ben.James@Office365itpros.com
9ba20686-f869-46e8-85a2-00ec8a035e48 James Joyce                   James.Joyce@office365itpros.com
acb778e8-f587-45de-ae3a-e76007e043b2 Paul Howett                   Paul.Howett@office365itpros.com
98dda855-5dc3-4fdc-8458-cbc494a5a774 Sean Landy                    Sean.Landy@office365itpros.com
6b52fba5-349e-4624-88cd-d790883fe4c4 Ken Bowers                    Ken.Bowers@office365itpros.com
558d8cbb-a5a2-4ea1-b950-0d0748ca5634 Jacko Winters                 flayosc_outlook.com#EXT#@office365itpro

Get-AzureADuser -ObjectId 558d8cbb-a5a2-4ea1-b950-0d0748ca5634 | ft mail, displayname, objectid

Mail               DisplayName   ObjectId
----               -----------   --------
flayosc@yandex.com Jacko Winters 558d8cbb-a5a2-4ea1-b950-0d0748ca5634

The Original email address can’t be used to sign into Teams either. Eventually, after a couple of days, Teams synchronized with Entra ID and the updated account details became visible in Teams. However, the updated account could not sign into Teams.

Come Home to Teams

Working with the Entra ID development group, the problem was diagnosed to due to the way Teams tries its best to bring a user to their home tenant. In the case of guest users, Teams uses the sign in address to locate the tenant and headed off to the wrong place. When using an explicit redirect to the tenant identifier, like https://teams.microsoft.com/?tenantId=c662313f-14fc-43a2-9a7a-d2e27f4f3478, the user can connect.

Obviously, there’s some work for Teams to do to cope when administrators assign new email addresses to guest accounts, but at least the problem is known, and Microsoft will no doubt fix the issue soon.

All this work for a few lines in Chapter 13 of the Office 365 for IT Pros eBook. It just goes to prove how much work and effort the writing team puts in to keeping content accurate, refreshed, and updated. Subscribe now to receive monthly updates of goodness.

App Consent Events Amongst Thousands of Audit Events Generated Across Microsoft 365

Following the publication of the article describing how to report the use of sensitivity labels by using audit events, a reader asked what’s the best way to discover if a feature generates an audit event. At the time of writing, Microsoft 365 workloads store more than 1,600 different events in the audit log, so understanding every auditable operation is a massive task, especially if you’re looking for something specific, like app consent events. New audit events show up in the audit log on an ongoing basis as Microsoft introduces new features, hopefully with an accompanying audit event, or backfills by updating features so that they generate audit events.

Looking for New Audit Records like an App Consent Event

Our method to discover new audit events is simple. It depends on the fact that every audit event notes an operation, or action performed to generate the event. You can filter audit records by specifying the type of operations to see. For instance, to see who send email on behalf of a shared mailbox, you can look for audit events with the SendAs operation. Here’s what we do to find if a new feature is captured in an audit event.

• First, use the new feature. Ideally, perform actions several times with different accounts.
• Second, wait for at least an hour to allow the ingestion of audit events from the source workload and appear in the audit log.
• Next, run a search to find all audit events for the current day and group and sort the results by operation. Make sure to specify the user principal name of the account which performed the accounts in the UserIds parameter.

[array]$Records = Search-UnifiedAuditLog -StartDate (Get-date).AddDays(-1) -EndDate (Get-Date).AddDays(1) -ResultSize 2000 -Formatted -UserIds James.Ryan@office365itpros.com -SessionCommand ReturnLargeSet

$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [datettime]}
$Records | Group Operations | Sort Count -Descending | Format-Table Count, Name

You should now be able to browse the sorted list of operations to find unfamiliar actions, such as Set-LabelPolicy (logged when someone updates a sensitivity label policy). You can take the same approach with the Audit search feature in the Compliance Center, but not all audit events show up there.

Investigating a New Audit Event

Typically, the new events appear at the end of the list. For instance, looking at a recent set, we see an event called Consent to application. This hadn’t come to our attention before:

    1 Consent to application.
    1 Get-DlpSiDetectionsReport
    1 New-Mailbox
    1 Set-TenantObjectVersion
    1 Set-AdminAuditLogConfig
    1 Get-ComplianceTag
    1 Send
    1 SoftDelete

Checking the event, we found that the event originated in Entra ID and relates to granting OAuth consent (permission to access data) to an application. Due to recent problems like the SolarWinds attack, there’s been heightened sensitivity to the need to understand what access to data has been granted within an organization. If you don’t know who can access data, you can’t detect and remediate illicit consents which might have been secured by attackers.

While other tools like the PowerShell script created by Microsoft (see this article) are better at enumerating and reporting consent grants for review, it’s interesting to find that Entra ID captures app consent events, In this case, an examination of the event data revealed that the consent was for the Microsoft Events app used for purposes like registering for the Microsoft Ignite online conference.

Checking the app registration in the Entra admin center, you can find the permissions assigned to the app. In this case, the app reads Entra ID to fetch details of people who register using their user account.

You can confirm that you’re looking at the same app by checking the application ID in Entra ID (e462442e-6682-465b-a31f-652a88bfbe51) with the details captured in the audit record:

{
                     "ID": "e462442e-6682-465b-a31f-652a88bfbe51;https://microsoft.onmicrosoft.com/aef17311-1f14-4e06-939b-42c0bcff5520",
                     "Type": 4
}

This example illustrates the value of checking for new audit events periodically. Now that we know that app consent events are available to track new consents, it’s easy to create a script to report consent grants over the last 90 days (the time audit events are kept for E3 accounts). You can grab an example script from the Office 365 IT Pros GitHub repository. See the Cloud Architect GitHub page for more information about resisting consent grant attacks.

If you want to distribute the report in other ways, you could:

• Format the content in HTML and send it via email (see this article for details).
• Create the report in a SharePoint document library (the basics of how to do this is explained here; the scenario is a script running in a Azure Automation runbook but the technique of using PnP cmdlets is the same in “regular” PowerShell).
• Post the report to a Teams channel or post a link to it in a message card created in a Teams channel using the inbound webhook connector. See this article for more information.

Microsoft Datacenter Operations

Searching the audit log to find new events also uncovers audit events logged when Microsoft updates tenant settings as part of their normal datacenter operations. For instance, Microsoft often updates OWA mailbox policies to introduce a control for a new OWA feature. When this happens, you’ll find audit events logged for a user called NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost) for the policy updates.

You can do nothing about Microsoft configuration updates, but at least you can discover when they happen by poking around in the audit log.

Chapter 21 of the Office 365 for IT Pros eBook goes into how auditing works in great detail and describes several examples of how audit data answers important questions. If you’re running a tenant, you need to have this information!

Build Filters Against Multiple Entra ID User Account Properties

A post in the Microsoft Technical Community looked for help building a dynamic distribution list based on multiple Entra ID properties. Our esteemed technical editor, Vasil Michev, stepped in to help and involved me. I pointed out that this topic is covered in the Groups chapter of the Office 365 for IT Pros eBook (easy to miss in 1,350 pages) but admitted that the question was interesting.

Dynamic distribution lists are an undervalued part of Exchange Online. The functionality has existed since Exchange 2003 introduced the query-based distribution group, or QDG. The current implementation arrived in Exchange 2007. In both cases, a query is resolved against the directory to identify the set of recipients for a message. The list is dynamic because the set of recipients will change based on the contents of the directory. Exchange Online calculates the list membership behind the scenes (the “modern” implementation), but the concept of membership depending on a filter run against the directory still holds.

Precanned and Custom Recipient Filters

The Exchange admin center (EAC) GUI is designed to make it easy for administrators to create the queries for dynamic distribution lists. It does this by limiting the set of properties available for queries, like department and city. The queries generated by the EAC are called precanned queries. after generation, Exchange stores the recipient filter as a property of the dynamic distribution list.

Custom queries can use a much wider set of properties. The downside is that you must build the recipient filters by hand and update dynamic distribution lists with PowerShell. That might seem hard, but it’s really not.

Excluding Some Mailboxes

In this instance, the need is to have a dynamic distribution list to address mailboxes owned by people with a specific job title but exclude any user accounts that Entra ID currently blocks for sign-in. Figure 1 shows the account of architect Ben James. The account is blocked.

When a user account is blocked, Exchange Online synchronizes the status and updates the ExchangeUserAccountControl mailbox property. To find the set of recipients who have architect in their job title and can still sign in, we can build a recipient filter which checks the Title and ExchangeUserAccountControl properties. Because people might have prefixes to indicate the seniority of their architect status, we need to include some variants of the job title. Exchange Online only supports wildcards for filters at the end of a string (“architect*”) instead of the start (“*architect”), which would be more useful in this case.

Building and Testing a Recipient Filter with PowerShell

Here’s what a custom filter to check for a job title and account blocked status looks like:

$Filter = "((Title -eq 'Architect') -or (Title -eq 'Senior Architect') -or (Title -eq 'Principal Architect') -and (ExchangeUserAccountControl -ne 'AccountDisabled'))"

To know if the filter works, we can use the Get-Recipient cmdlet. Get-Recipient accepts the filter defined in the $Filter variable and returns what it finds in the directory. This is exactly what will be returned as the set of recipients when the Exchange transport service resolves the query stored in the dynamic distribution list.

Get-Recipient -RecipientPreviewFilter $Filter | ft displayname, title

DisplayName                   Title
-----------                   -----
Ben James                     Architect
Eoin Redmond (Ireland)        Architect
James Joyce                   Principal Architect
Tony Redmond                  Principal Architect
Vasil Michev (Technical Guru) Senior Architect

It’s important to test a recipient filter before using it with a dynamic distribution list. If the query generated by the filter fails to resolve and return any recipients, any message sent to the list goes into a black hole. Exchange won’t generate a non-delivery notification because the address used for the message is valid (the list); the problem lies with what happens when the query is run against the directory.

Creating a Dynamic Distribution List with PowerShell

After you’re sure that the filter returns the correct set of recipients, you can create a dynamic distribution list using the filter. For example:

New-DynamicDistributionGroup -Name "Architects" -DisplayName "System and Engineering Architects" -Alias AllArchitects -PrimarySmtpAddress Architects@Office365itpros.com -RecipientFilter $Filter
Set-DynamicDistributionGroup -Identity AllArchitects -ManagedBy Tony.Redmond -MailTip "Distribution List for anyone with Architect in the job title"

The second command is to add an owner for the dynamic distribution list and to assign a mail tip for clients like Outlook to display when people address email to the list.

EAC Blocks Edits of Custom Recipient Filters

Any further adjustments to the recipient filter can only be made with PowerShell. If you look at a custom recipient filter with the Exchange admin center, it’s blocked for edit (Figure 2).

As for Ben James, when his user account is reenabled for sign-in, he’ll start to receive messages sent to the dynamic distribution list again, which is exactly what we want.

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.

Cherish the Accuracy of Entra ID Account Properties

Every Microsoft 365 tenant uses Azure Active Directory to store information about the tenant configuration, accounts, and groups. Maintaining accurate Entra ID user account properties is important. Whether data comes from an external source like a HR feed or is maintained manually, people depend on directory information to find others, or even understand how the organization works. If the data in your directory is inaccurate, some features won’t work properly or at all. For example:

• The people card (which makes the Intelligent Search of Microsoft 365 rather stupid)
• Teams organization tab (Figure 1) because reporting relationships won’t be correct.
• Dynamic distribution lists and dynamic Microsoft 365 groups because the right people won’t be found by the queries underpinning dynamic lists and groups.

It’s always been important to maintain an accurate directory. Perhaps it was less so in the on-premises world where fewer application features are built with an expectation that directory data is accurate, but it’s obvious that Microsoft 365 just works better with a solid directory.

Setting Goals for a Healthy Directory

You can invest in a product like Hyperfish to help analyze and maintain your Entra ID data, but before you rush into acquiring a sticking plaster to cure your directory woes, it’s a good idea to set down some threshold for directory quality. For example, you could say that your baseline measurement for a healthy directory is that all the properties displayed on the people card should be fully populated for every user account. Separate guidelines might be defined for guest accounts and groups.

Figure 2 shows a customized people card. Being able to customize the people card using Microsoft Graph commands allows tenants to expose the information they consider essential in the card, and it’s important to consider customization when setting your threshold.

Checking Entra ID Account Properties with PowerShell

Setting an aspirational goal is nice, achieving that goal is even better. We need to understand how healthy our directory is in terms of missing properties that show up in the people card. Fortunately, this is easy to create a PowerShell script to:

• Find mailbox-enabled user accounts in Entra ID.
• Check accounts for missing properties (like not having values in the Office or Title properties).
• Report what needs to be done in terms of account updates.

I’ve written a quick and dirty script which you can download from GitHub. It uses the Get-User cmdlet from the Exchange Online Management module to fetch account information. The Get-MgUser cmdlet from the Microsoft Graph PowerShell SDK could also be used, but it’s easier to filter out mailbox-enabled accounts with Get-User, which exposes the Entra ID user properties we want to check. Remember that you’ll need to modify the script to suit the circumstances in your organization. For instance, if you place particular importance on a specific property, you might want to amend the script to include that property in the checks.

Figure 3 shows how the script reports the problems it finds with missing properties in user accounts. The results shown here are from a small test tenant so it’s unsurprising to discover that so many accounts have missing properties. It’s reasonable to expect better results in a production tenant.

To make it easy for administrators to track down and fix missing properties. a CSV file is also generated with details of the accounts which need adjustment (Figure 4).

Although it can be a boring task, maintaining the accuracy of Entra ID user data can be boring. It’s much more interesting to read the Office 365 for IT Pros eBook and learn about changes in Office 365 through the updates we release every month.

Teams Creates Many Guest Accounts

Propelled by the success of Teams, guest accounts are becoming more popular across the Microsoft 365 ecosystem. There’s goodness and badness here. The good comes from being able to share and collaborate through the Microsoft 365 group membership model and Azure B2B collaboration. The bad is that it’s easy to accumulate a large set of guest accounts from different tenants (organizations) over time. For instance, Teams is used by many conferences to deliver online events, so I now have guest accounts in five organizations used for just that purpose.

Because Teams makes users switch focus to a different tenant to access resources there, guest accounts are more obvious in Teams than in any other Office 365 application. It can become distracting when you have a long list of tenants to choose from when the time comes to switch. Should I just dip into that tenant to see what’s going on there? Or which tenant has that information I’m looking from.

By comparison, guests access SharePoint Online and OneDrive for Business documents and folders via URLs and sharing invitations which look like those used for content stored in the tenant. And guests participating in Outlook group conversations do so via email, just like they’d send messages to any other distribution list.

Tenant administrators have their own challenges to manage guest accounts in the tenant’s Azure AD instance. Last July, I wrote about the lack of visibility tenant administrators have about the other Microsoft 365 tenants where people have guest account. And it can be hard to figure out when guest accounts are past their best-by date and should be removed because they are unused (but here’s one approach).

Removing Your Guest Account from a Tenant

The simple fact is that tenant administrators are busy people and tend to leave guest accounts alone, even those which aren’t in active use. If you want to clean up the list of organizations you belong to, you can do so as follows. The first step is to open the Organizations section in your My account page to view the set of Azure AD tenants where you have a guest account (Figure 1). Microsoft has done a lot of work to improve the My account page recently to add features like the ability to see your account sign-in activity (My sign-ins). Overall, the page is easier to use and more informative, which is a good reason to check it out and highlight the page’s existence within your organization.

Select the organization you want to remove your account from and click Leave organization. If you are not already signed into that tenant, you’ll be asked to do so to authenticate your ownership of the account and right to remove it. I use a private browser session when cleaning up guest accounts because I have encountered some problems with the sign-in process in the past. Once connected to the target organization, you’ll be asked to confirm the decision to leave (Figure 2).

Clicking Leave starts the process of removing the guest account from the target organization. Once Azure AD has removed the account, you’ll receive an email confirmation that the deed is done (Figure 3). Removing the account has the effect of removing membership to all groups and teams and nullifying any sharing links to documents or folders in the tenant. In short, you’re now a nobody in the eyes of that tenant.

Caching means that it takes a little longer before all traces of your membership of a now-left tenant disappear. For instance, the list of organizations you belong to won’t update immediately and it can take up to a day or so before Teams desktop and mobile clients refresh their local cache and pick up the new organization list. Because it works online, the Teams browser client is much faster at detecting changes in the set of organizations (Figure 4).

If You Need to Rejoin

If you leave a tenant and then find that you need to rejoin to access some resource, someone (an administrator or team/group owner) must extend another invitation to join. This will create a new guest account. After you accept the invitation, you’ll be able to access any resource in the tenant available to the account – but not resources you previously could access until that access is regranted.

For this reason, it’s unwise to leave a tenant until you know that you don’t need anything stored there.

Need to know more about how Office 365 tenants use Azure AD? Look no further than the words of wisdom you’ll find in the Office 365 for IT Pros eBook. Some of the words even make sense!

Exploiting Security Groups

Dan Stephenson, one of the Teams program managers, posted an interesting script to synchronize the membership of an AAD security group with an Office 365 group (now called Microsoft 365 Groups). The idea is that you might have invested in security groups to control access to different resources and now want to extend that investment and use the same group membership for collaboration with Teams.

PowerShell is Flexible

One of the wonders of PowerShell is the way that you can come up with different answers to the same problem. Everyone has their own way to attack a problem and code a solution. Here’s the script we include in Chapter 14 of Office 365 for IT Pros, where we deal with the many joys of managing Office 365 Groups and Teams with PowerShell.

The script synchronizes the membership of a security group called eDiscovery Admins with an Microsoft 365 Group called eDiscovery Administrators. The security group is the master, meaning that its membership is what we want to see synchronized to the Office 365 Group. Any members found in the Microsoft 365 Group membership that are not in the security group are removed. You need to connect your PowerShell session to Azure AD and Exchange Online (use the Exchange Online Management module) to access the cmdlets used in the script.

Synchronizing Group Memberships

First, we fetch details of the two groups we want to synchronize.

$M365Group = (Get-UnifiedGroup -Identity "eDiscovery Administrators")
$SecurityGroup = (Get-AzureADGroup -SearchString "eDiscovery Admins").ObjectId
# Grab list of security group members
$SecurityGroupMembers = (Get-AzureADGroupMember -ObjectId $SecurityGroup -All $True | Select UserPrincipalName, UserType)

Now we update the membership of the Office 365 Group based on the members of the security group.

ForEach ($i in $SecurityGroupMembers) {
If ($i.UserType -eq "Member") {
        Add-UnifiedGroupLinks -Identity $M365Group.ExternalDirectoryObjectId -LinkType Member -Links $i.UserPrincipalName }
}

The next step is to check the membership of the two groups and remove any member found in the Microsoft 365 Group who doesn’t exist in the security group.

$GroupMembers = (Get-UnifiedGroupLinks -Identity $M365Group.ExternalDirectoryObjectId -LinkType Member)
ForEach ($i in $GroupMembers) {
 $Member = (Get-Mailbox -Identity $i.Name)
 If ($SecurityGroupMembers -Match $Member.UserPrincipalName)
      { Write-Host $Member.DisplayName "is in security group" }
    Else
      { Write-Host "Removing" $Member.DisplayName "from Office 365 group because they are not in the security group" -ForeGroundColor Red
      Remove-UnifiedGroupLinks -Identity $M365Group.ExternalDirectoryObjectId -Links $Member.Alias -LinkType Member -Confirm:$False}
}
Write-Host "Current Membership of" $M365Group.DisplayName
Get-UnifiedGroupLinks -Identity $M365Group.ExternalDirectoryObjectId -LinkType Member | Select DisplayName

The next step for the budding PowerShell maestro to improve matters is to deal with nested groups (an exercise for the reader), improve error handling, and  come up with a way to run the script every day or so to ensure that the two group memberships remain synchronized.

We have a complete chapter (13) on using PowerShell in the Office 365 for IT Pros eBook. Not that you experts need to read it, but it is nice to know that the chapter is there.