MTO/Cross Tenant Sync Identity Considerations
In the current Azure environment, a user from another tenant can be represented by various identity objects. Most users have a cloud guest account, while a subset also possesses Mail contacts, alongside their guest user status. Additionally, some users have licensed accounts. In this blog post, we will explore each of these representations and the process of merging/rationalizing these to ensure a single representation of the user in the resource tenant. This unified representation will be enabled for B2B collaboration with their home identity and mail-enabled for integration within Exchange. Existing B2B Users A user can have the following representations: Guest account with the Invitation State as Pending Acceptance. This is usually the case when the user was invited as a guest, but they never accepted the Invitation. Cross tenant sync will fail for such accounts. Cross-tenant synchronization uses an internal attribute called the alternativeSecurityIdentifier to uniquely match an internal user in the source tenant with an external / B2B user in the target tenant. But since the invitation was never redeemed, alternativeSecurityIdentifier property will not be populated for the user. Assuming that Automatic Redemption is enabled for both the tenant, you can reset the redemption/resend the invite to populate the alternativeSecurityIdentifier. Reference Article Reset guest redemption status - Microsoft Entra External ID | Microsoft Learn https://learn.microsoft.com/en-us/entra/external-id/b2b-quickstart-invite-powershell#send-an-invitation Note: You may want to supress the invitation message to avoid end user notifications. Multiple Guest account with the Invitation State as Pending Acceptance. This typically occurs when multiple accounts are created for a user in the Home Account. Both accounts may be invited, and subsequently, one account is deleted while the email address is transferred to the remaining account. Here in example: The user had the below account in Home tenant. o Display Name: Lidia Holloway o Email: Lidia.Holloway@contoso.com User was provided with another account for administration in Home tenant. o Display Name: Lidia Holloway (GA) o Email: Lidia.Holloway@fabrikam.com User was invited as a guest in the resource tenant with email address as Lidia.Holloway@contoso.com. The user never accepted the invitation. User was invited as a guest in the resource tenant with email address as Lidia.Holloway@fabrikam.com. The user never accepted the invitation in this case as well. Lidia Holloway (GA) account was removed from the Home Tenant and the email address Lidia.Holloway@fabrikam.com was added as an alias to the Lidia Holloway account. End State Home Tenant: o Display Name: Lidia Holloway o Email Addresses: SMTP: Lidia.Holloway@contoso.com; smtp:Lidia.Holloway@fabrikam.com Resource Tenant Account1 o Display Name: Lidia Holloway o Email Addresses: SMTP: Lidia.Holloway@contoso.com o Invitation State: Pending Acceptance Account2 o Display Name: Lidia Holloway o Email Addresses: SMTP: Lidia.Holloway@fabrikam.com o Invitation State: Pending Acceptance The recommendation here would be to retain the one that matches the PSMTP Address of the Home Account and delete the other one. Note: The account scheduled for deletion may have group memberships and email threads with other users. It is advisable to transition the Legacy Exchange Distinguished Name (DN) and group memberships to the account being retained. To achieve this, capture the Legacy Exchange DN and group memberships, delete the unnecessary account, and then transfer these attributes to the retained account. Multiple Guest account with the Invitation State as Accepted and Pending Acceptance. This is similar to the previous one, except that one of the invitations was accepted. It is advisable to retain the account that is in an accepted state, as it may have permissions across various M365 workloads. There may also be situations where the PSMTP address of the home account was changed; in such cases, CTS should update the mail attribute according to the CTS configuration. If it does not automatically update despite the configuration, ondemand provisioning can be used to force the update. Note: Just like the previous scenario, it is advisable to transition the Legacy Exchange Distinguished Name (DN) and group memberships to the account being retained. Existing Contact Object Contact Object A user may be added as a Contact in the resource tenant, often when GAL Sync Solution is configured between organizations. There can be both Sync and Cloud-only contacts. These contacts might hold memberships in various synced and non-synced groups. To achieve a single representation, it is recommended to capture the Legacy Exchange Distinguished Name (DN) and group memberships from the contact object and delete it. After this, perform the scoping and let the CTS create the B2B object. Finally, transition the Legacy Exchange Distinguished Name (DN) and group memberships to the B2B account. Contact & a B2B Object A user can be added as both a Contact Object and a B2B Object in the resource tenant, often occurring when invited as a guest with an existing contact object. Provisioning in EXO depends on the email address and creation order of these objects. The B2B object’s Invitation State can be either Pending Acceptance/Acceptance state. If the B2B object’s Invitation State is Pending Acceptance, then it’s advisable to first remediate that. To achieve a single representation, the recommendation again would be to delete the contact object and transition the Legacy Exchange Distinguished Name (DN) and group memberships to the B2B account. Contact + Multiple B2B Objects A user can have a contact along with Multiple B2B Objects. In such scenarios, it is recommended to first rationalize the B2B Objects and proceed with the contact rationalization. Internal /Dual Mailbox Users Finally, there may be instances where users are classified as Internal Users in both tenants. Dual mailbox users cannot be enabled for B2B collaboration because the assigned email addresses will conflict with those of their home accounts. These dual mailbox users should be excluded from identity rationalization processes and should coexist with corresponding cloud external member objects created via cross-tenant synchronization. This setup can result in the user appearing twice in people search across Microsoft 365 applications unless one of the entries is hidden; however, hiding one entry could lead to additional complications. A final note would be to perform the rationalization during off-business hours, preferably on weekends, to allow for rollback if needed. Also, consider nested groups when transitioning group membership.Automating and Streamlining Vulnerability Management for Your Clients
Learn how to enhance vulnerability management for your windows clients using Microsoft Defender for Endpoint, Intune, and Azure AD. Harness the potential of automation to simplify processes and minimize expenses. *Discover how automation transforms security by removing manual tasks, minimizing human error, and conserving time and resources. *Observe how Microsoft's tools deliver a complete vulnerability management solution for both on-site and remote devices. *Follow our detailed guide on setup, enrollment, strategic updates deployment, and monitoring progress through the Microsoft 365 Defender portal. Take charge of your vulnerability management and protect your organization. Don't miss our blog post, and keep an eye out for the upcoming entry on servers!Hardening Windows Clients with Microsoft Intune and Defender for Endpoint
Explore an approach at hardening clients in your organization by using Microsoft Intune and Defender for Endpoint to apply and mitigate some of the most common security misconfigurations. This blog unveils a centralized approach to automating asset management, deploying security baselines consistently, and minimizing the impact on end users. Learn valuable insights on planning, testing, and monitoring security policies, while discovering the power of attack surface reduction rules. Dive into this comprehensive guide and elevate your organization's security posture with streamlined solutions and proactive measures. Don't miss the chance to turn a major pain point into a significant win for your team!
Detection Engineering in Azure & Introducing AzDetectSuite
The AzDetectSuite is an open source project geared towards helping secure environments within Azure by utilizing KQL and Azure Monitor alerts. This heavily supplements the Azure Threat Research Matrix (ATRM) by supplying defensive content for the known techniques within Azure. This article will also cover what goes into a detection and how to develop a granular detection in a noisy environment.Building a Strong Foundation: Prioritizing Developer Security at Microsoft Build 2023
Join us at Microsoft Build 2023 as we shine a spotlight on Developer Security, an imperative in today's evolving threat landscape. Engage with our experts in informative sessions and discover how Azure's industry-leading defense in depth approach and the Secure Supply Chain Consumption Framework empower developers to build resilient applications. Don't miss this opportunity to enhance your knowledge, network with industry leaders, and elevate your understanding of secure software development. Register now for Microsoft Build and be part of the conversation.Improving Server Vulnerability Management Efforts
Discover a new way to transform vulnerability management with Microsoft Defender for Servers, Azure Automation Services, and Azure Arc. This blog post will guide you through moving pass the traditional vulnerability management approach toward implementing an automated and streamlined process for your servers on-premises and the cloud. Seamlessly integrate various tools in a 5-step solution that will make you rethink server vulnerability management. Don't miss the opportunity to add a new weapon to your cyber security strategy that aims at removing inefficiencies.Introducing the Azure Threat Research Matrix
When performing a security assessment, it’s common to find the assessment team attribute their actions to the MITRE ATT&CK knowledge base so that high-level stakeholders can visually see what techniques were successful and defenders can understand the techniques that were performed. However, the commonly utilized MITRE knowledge base lacks formal documentation of Azure or AzureAD-related tactics, techniques, or procedures (TTPs) that assessment teams can attribute to. Over the past year, Microsoft has worked with some of the top Azure security researchers to create the Azure Threat Research Matrix (ATRM), a matrix that provides details around the tactics & techniques a potential adversary may use to compromise an Azure Resource or Azure Active Directory.
