Microsoft Security in Action: Deploying and Maximizing Advanced Identity Protection
As cyber threats grow in sophistication, identity remains the first line of defense. With credentials being a primary target for attackers, organizations must implement advanced identity protection to prevent unauthorized access, reduce the risk of breaches, and maintain regulatory compliance. This blog outlines a phased deployment approach to implement Microsoft’s identity solutions, helping ensure a strong Zero Trust foundation by enhancing security without compromising user experience. Phase 1: Deploy advanced identity protection Step 1: Build your hybrid identity foundation with synchronized identity Establishing a synchronized identity is foundational for seamless user experiences across on-premises and cloud environments. Microsoft Entra Connect synchronizes Active Directory identities with Microsoft Entra ID, enabling unified governance while enabling users to securely access resources across hybrid environments. To deploy, install Microsoft Entra Connect, configure synchronization settings to sync only necessary accounts, and monitor health through built-in tools to detect and resolve sync issues. A well-implemented hybrid identity enables consistent authentication, centralized management, and a frictionless user experience across all environments. Step 2: Enforce strong authentication with MFA and Conditional Access Multi-Factor Authentication (MFA) is the foundation of identity security. By requiring an additional verification step, MFA significantly reduces the risk of account compromise—even if credentials are stolen. Start by enforcing MFA for all users, prioritizing high-risk accounts such as administrators, finance teams, and executives. Microsoft recommends deploying passwordless authentication methods, such as Windows Hello, FIDO2 security keys, and Microsoft Authenticator, to further reduce phishing risks. Next, to balance security with usability, use Conditional Access policies to apply adaptive authentication requirements based on conditions such as user behavior, device health, and risk levels. For example, block sign-ins from non-compliant or unmanaged devices while allowing access from corporate-managed endpoints. Step 3: Automate threat detection with Identity Protection Implementing AI-driven risk detection is crucial to identifying compromised accounts before attackers can exploit them. Start by enabling Identity Protection to analyze user behavior and detect anomalies such as impossible travel logins, leaked credentials, and atypical access patterns. To reduce security risk, evolve your Conditional Access policies with risk signals that trigger automatic remediation actions. For low-risk sign-ins, require additional authentication (such as MFA), while high-risk sign-ins should be blocked entirely. By integrating Identity Protection with Conditional Access, security teams can enforce real-time access decisions based on risk intelligence, strengthening identity security across the enterprise. Step 4: Secure privileged accounts with Privileged Identity Management (PIM) Privileged accounts are prime targets for attackers, making Privileged Identity Management (PIM) essential for securing administrative access. PIM allows organizations to apply the principle of least privilege by granting Just-in-Time (JIT) access, meaning users only receive elevated permissions when needed—and only for a limited time. Start by identifying all privileged roles and moving them to PIM-managed access policies. Configure approval workflows for high-risk roles like Global Admin or Security Admin, requiring justification and multi-factor authentication before privilege escalation. Next, to maintain control, enable privileged access auditing, which logs all administrative activities and generates alerts for unusual role assignments or excessive privilege usage. Regular access reviews further enable only authorized users to retain elevated permissions. Step 5: Implement self-service and identity governance tools Start by deploying Self-Service Password Reset (SSPR). SSPR enables users to recover their accounts securely without help desk intervention. Also integrate SSPR with MFA, so that only authorized users regain access. Next, organizations should implement automated Access Reviews on all users, not just privileged accounts, to periodically validate role assignments and remove unnecessary permissions. This helps mitigate privilege creep, where users accumulate excessive permissions over time. Phase 2: Optimize identity security and automate response With core identity protection mechanisms deployed, the next step is to enhance security operations with automation, continuous monitoring, and policy refinement. Step1: Enhance visibility with centralized monitoring Start by Integrating Microsoft Entra logs with Microsoft Sentinel to gain real-time visibility into identity-based threats. By analyzing failed login attempts, suspicious sign-ins, and privilege escalations, security teams can detect and mitigate identity-based attacks before they escalate. Step 2: Apply advanced Conditional Access scenarios To further tighten access control, implement session-based Conditional Access policies. For example, allow read-only access to SharePoint Online from unmanaged devices and block data downloads entirely. By refining policies based on user roles, locations, and device health, organizations can strengthen security while ensuring seamless collaboration. Phase 3: Enable secure collaboration across teams Identity security is not just about protection—it also enables secure collaboration across employees, partners, and customers. Step 1: Secure external collaboration Collaboration with partners, vendors, and contractors requires secure, managed access without the complexity of managing external accounts. Microsoft Entra External Identities allows organizations to provide seamless authentication for external users while enforcing security policies like MFA and Conditional Access. By enabling lifecycle management policies, organizations can automate external user access reviews and expirations, ensuring least-privilege access at all times. Step 2: Automate identity governance with entitlement management To streamline access requests and approvals, Microsoft Entra Entitlement Management lets organizations create pre-configured access packages for both internal and external users. External guests can request access to pre-approved tools and resources without IT intervention. Automated access reviews and expiration policies enable users retain access only as long as needed. This reduces administrative overheads while enhancing security and compliance. Strengthening identity security for the future Deploying advanced identity protection in a structured, phased approach allows organizations to proactively defend against identity-based threats while maintaining secure, seamless access. Ready to take the next step? Explore these Microsoft identity security deployment resources: Microsoft Entra Identity Protection Documentation Conditional Access Deployment Guide Privileged Identity Management Configuration Guide The Microsoft Security in Action blog series is an evolving collection of posts that explores practical deployment strategies, real-world implementations, and best practices to help organizations secure their digital estate with Microsoft Security solutions. Stay tuned for our next blog on deploying and maximizing your investments in Microsoft Threat Protection solutions.Microsoft Security in Action: Zero Trust Deployment Essentials for Digital Security
The Zero Trust framework is widely regarded as a key security model and a commonly referenced standard in modern cybersecurity. Unlike legacy perimeter-based models, Zero Trust assumes that adversaries will sometimes get access to some assets in the organization, and you must build your security strategy, architecture, processes, and skills accordingly. Implementing this framework requires a deliberate approach to deployment, configuration, and integration of tools. What is Zero Trust? At its core, Zero Trust operates on three guiding principles: Assume Breach (Assume Compromise): Assume attackers can and will successfully attack anything (identity, network, device, app, infrastructure, etc.) and plan accordingly. Verify Explicitly: Protect assets against attacker control by explicitly validating that all trust and security decisions use all relevant available information and telemetry. Use Least Privileged Access: Limit access of a potentially compromised asset, typically with just-in-time and just-enough-access (JIT/JEA) and risk-based policies like adaptive access control. Implementing a Zero Trust architecture is essential for organizations to enhance security and mitigate risks. Microsoft's Zero Trust framework essentially focuses on six key technological pillars: Identity, Endpoints, Data, Applications, Infrastructure, & Networks. This blog provides a structured approach to deploying each pillar. 1. Identity: Secure Access Starts Here Ensure secure and authenticated access to resources by verifying and enforcing policies on all user and service identities. Here are some key deployment steps to get started: Implement Strong Authentication: Enforce Multi-Factor Authentication (MFA) for all users to add an extra layer of security. Adopt phishing-resistant methods, such as password less authentication with biometrics or hardware tokens, to reduce reliance on traditional passwords. Leverage Conditional Access Policies: Define policies that grant or deny access based on real-time risk assessments, user roles, and compliance requirements. Restrict access from non-compliant or unmanaged devices to protect sensitive resources. Monitor and Protect Identities: Use tools like Microsoft Entra ID Protection to detect and respond to identity-based threats. Regularly review and audit user access rights to ensure adherence to the principle of least privilege. Integrate threat signals from diverse security solutions to enhance detection and response capabilities. 2. Endpoints: Protect the Frontlines Endpoints are frequent attack targets. A robust endpoint strategy ensures secure, compliant devices across your ecosystem. Here are some key deployment steps to get started: Implement Device Enrollment: Deploy Microsoft Intune for comprehensive device management, including policy enforcement and compliance monitoring. Enable self-service registration for BYOD to maintain visibility. Enforce Device Compliance Policies: Set and enforce policies requiring devices to meet security standards, such as up-to-date antivirus software and OS patches. Block access from devices that do not comply with established security policies. Utilize and Integrate Endpoint Detection and Response (EDR): Deploy Microsoft Defender for Endpoint to detect, investigate, and respond to advanced threats on endpoints and integrate with Conditional Access. Enable automated remediation to quickly address identified issues. Apply Data Loss Prevention (DLP): Leverage DLP policies alongside Insider Risk Management (IRM) to restrict sensitive data movement, such as copying corporate data to external drives, and address potential insider threats with adaptive protection. 3. Data: Classify, Protect, and Govern Data security spans classification, access control, and lifecycle management. Here are some key deployment steps to get started: Classify and Label Data: Use Microsoft Purview Information Protection to discover and classify sensitive information based on predefined or custom policies. Apply sensitivity labels to data to dictate handling and protection requirements. Implement Data Loss Prevention (DLP): Configure DLP policies to prevent unauthorized sharing or transfer of sensitive data. Monitor and control data movement across endpoints, applications, and cloud services. Encrypt Data at Rest and in Transit: Ensure sensitive data is encrypted both when stored and during transmission. Use Microsoft Purview Information Protection for data security. 4. Applications: Manage and Secure Application Access Securing access to applications ensures that only authenticated and authorized users interact with enterprise resources. Here are some key deployment steps to get started: Implement Application Access Controls: Use Microsoft Entra ID to manage and secure access to applications, enforcing Conditional Access policies. Integrate SaaS and on-premises applications with Microsoft Entra ID for seamless authentication. Monitor Application Usage: Deploy Microsoft Defender for Cloud Apps to gain visibility into application usage and detect risky behaviors. Set up alerts for anomalous activities, such as unusual download patterns or access from unfamiliar locations. Ensure Application Compliance: Regularly assess applications for compliance with security policies and regulatory requirements. Implement measures such as Single Sign-On (SSO) and MFA for application access. 5. Infrastructure: Securing the Foundation It’s vital to protect the assets you have today providing business critical services your organization is creating each day. Cloud and on-premises infrastructure hosts crucial assets that are frequently targeted by attackers. Here are some key deployment steps to get started: Implement Security Baselines: Apply secure configurations to VMs, containers, and Azure services using Microsoft Defender for Cloud. Monitor and Protect Infrastructure: Deploy Microsoft Defender for Cloud to monitor infrastructure for vulnerabilities and threats. Segment workloads using Network Security Groups (NSGs). Enforce Least Privilege Access: Implement Just-In-Time (JIT) access and Privileged Identity Management (PIM). Just-in-time (JIT) mechanisms grant privileges on-demand when required. This technique helps by reducing the time exposure of privileges that are required for people, but are only rarely used. Regularly review access rights to align with current roles and responsibilities. 6. Networks: Safeguard Communication and Limit Lateral Movement Network segmentation and monitoring are critical to Zero Trust implementation. Here are some key deployment steps to get started: Implement Network Segmentation: Use Virtual Networks (VNets) and Network Security Groups (NSGs) to segment and control traffic flow. Secure Remote Access: Deploy Azure Virtual Network Gateway and Azure Bastion for secure remote access. Require device and user health verification for VPN access. Monitor Network Traffic: Use Microsoft Defender for Endpoint to analyze traffic and detect anomalies. Taking the First Step Toward Zero Trust Zero Trust isn’t just a security model—it’s a cultural shift. By implementing the six pillars comprehensively, organizations can potentially enhance their security posture while enabling seamless, secure access for users. Implementing Zero Trust can be complex and may require additional deployment approaches beyond those outlined here. Cybersecurity needs vary widely across organizations and deployment isn’t one-size-fits all, so these steps might not fully address your organization’s specific requirements. However, this guide is intended to provide a helpful starting point or checklist for planning your Zero Trust deployment. For a more detailed walkthrough and additional resources, visit Microsoft Zero Trust Implementation Guidance. The Microsoft Security in Action blog series is an evolving collection of posts that explores practical deployment strategies, real-world implementations, and best practices to help organizations secure their digital estate with Microsoft Security solutions. Stay tuned for our next blog on deploying and maximizing your investments in Microsoft Threat Protection solutions.Add authentication to your Azure App Service or Function app using Microsoft Entra External ID
Azure App Service and Function app offers built-in authentication and authorization features, allowing you to sign in users by writing minimal or no code in your web app, RESTful API, or mobile back end. It’s built directly into the platform and doesn’t require any particular language, library, security expertise, or even any code to use. The built-in authentication feature for App Service and Function app can save you time and effort by providing out-of-the-box authentication with federated identity providers, allowing you to focus on the rest of your application. This built-in authentication includes: Easy activation and configuration via the Azure portal and app settings. No need for SDKs, specific languages, or changes to your application code. Support for multiple identity providers: Microsoft GitHub Facebook Google Sign in with Apple X Any OpenID Connect provider When the authentication/authorization module is enabled, every incoming HTTP request is processed through it before reaching your app code. For more details, see Authentication and Authorization in Azure App Service. This blog shows you how to configure authentication for Azure App Service and Azure Functions so that your app signs in external users with the Microsoft identity platform (Microsoft Entra External ID) as the authentication provider. How to enable External ID on your Azure App Service or Function app Prerequisites An external tenant on Microsoft Entra Admin Center. If you don’t have one, create an external tenant with an Azure subscription. Ensure you have the Application Administrator role and External ID User Flow Administrator role on Microsoft Entra. A Contributor role on Azure to create Function apps. Have an existing Function app or Azure App Service. If you don’t have one, follow this guide to create your first function app or this training to host a web application with Azure App Service. 1. Choose a tenant for your applications and its users Now that you have your Function app or Azure App Service, let’s set up sign in for your users. Since we want our app to be available to consumers and business customers, we first need to register the app in an external tenant. Sign in to the Azure portal and navigate to your function app or Azure App Service. On your app's left menu, under Settings, select Authentication, and then select Add identity provider. In the Add an identity provider page, select Microsoft as the Identity provider to sign in Microsoft and Microsoft Entra identities. For Tenant type, select External configuration for consumers and business customers (external users). 2. Choose the app registration The Authentication feature can automatically create an app registration for you or you can use a registration that you or a directory admin created separately. To create a new app registration, select the Create new app registration option. Select an existing tenant to use from the drop-down, or select Create new to create a new external tenant. The second option is to use an existing app registration where we select Provide the details of an existing app registration then provide application (client) ID, Client secret and Issuer URL which you can find under App Registration> All applications > Select your app. The following situations are the most common cases to use an existing app registration: Your account doesn't have permissions to create app registrations in your Microsoft Entra tenant. You want to use an app registration from a different Microsoft Entra tenant than the one your app is in. The option to create a new registration isn't available for government clouds. 3. Configure external authentication Follow these steps to set up sign-in and customize branding. Select Configure to configure external authentication for the new tenant. The browser opens Configure external authentication. Select a user flow from the drop-down or select Create new. The user flow defines the sign-in methods your external users can use. Each app can only have one user flow, but you can reuse the same user flow for multiple apps then click Next. On the Customize Branding tab, add your logo and background color, and Center-align or Right-align your sign-in page and click Next. Review your configurations and click Configure. 4. Configure additional checks Configure Additional checks, which determine which requests are allowed to access your application. You can customize this behavior now or adjust these settings later from the main Authentication screen by choosing Edit next to Authentication settings. For Client application requirement, choose whether to: Allow requests only from this application itself Allow requests from specific client applications Allow requests from any application (Not recommended) For Identity requirement, choose whether to: Allow requests from any identity Allow requests from specific identities For Tenant requirement, choose whether to: Allow requests only from the issuer tenant Allow requests from specific tenants Use default restrictions based on issuer 5. Configure authentication settings These options determine how your application responds to unauthenticated requests, and the default selections will redirect all requests to sign in with this new provider. You can change customize this behavior now or adjust these settings later from the main Authentication screen by choosing Edit next to Authentication settings. To learn more about these options, see Authentication flow. For Restrict access, decide whether to: Require authentication. Allow unauthenticated access For Unauthenticated requests HTTP 302 Found redirect: recommended for websites HTTP 401 Unauthorized: recommended for APIs HTTP 403 Forbidden HTTP 404 Not found Select Token store (recommended). The token store collects, stores, and refreshes tokens for your application. You can disable this later if your app doesn't need tokens or you need to optimize performance. 6. Test your app After following the above steps, External ID should now be added as an identity provider for your app. To verify that this is now working, navigate to your Function App or Azure App Service. Click Overview > Browse. This will take you straight to the sign-in page. Follow the sign-up process for a new user. On successful sign-up, this should take you to your app as shown below. Next steps Continue exploring Microsoft Entra External ID on Azure App Service by checking out the documentation. We have a YouTube playlist on ‘Identity for developers’ that shows you other developer tools integrating External ID. You can also explore other features in the Microsoft Entra portfolio by visiting our: Developer center Identity blog YouTube for tutorials, deep dives, and the latest news.
User app registration - exploitable for BEC?
Hello. Recently dealt with a case of BEC. I'm not trained in forensics, but doing my best. Appears the hacker used an application called eM Client for their attack, getting access to a user's mailbox and hijacking a thread. I can see the login from two weeks ago (the incident was only noticed a couple days ago, however) - from a European country that SHOULD have been blocked by Conditional Access. Come to find out, the tenant conditional access was unassigned from everyone. We're not sure how - we re-enabled it, and audited changes, but the only change that appears was us re-enabling it. Which I thought indicates it was never configured right, except we've got a ticket documenting a change to Conditional Access a couple days after the hack that ALSO does not appear in the logs. So... it's likely it was changed, yet I have no record of that change (atleast, not through Entra > Monitoring > Auditing). If anyone knows any other ways of checking this, please advise - but I can't seem to even access our Diagnostic settings, the page tells me I need an Azure Active Directory subscription (I'm on Entra ID P1, which includes AAD.... this might be related to being global admin, and not Security Admin - we don't use that role in this relationship) ANYWAY, my amateur forensic skills have found that the attacker used an app called eM Client to get access. I'm not sure yet how they obtained the password, and got past MFA... But quick research shows this application (esp it's pro version) is known for use in BEC. The app was registered in Entra, and granted certain read permissions in Entra ID for shared mailboxes, presumably to find a decent thread to hijack. I'm not 100% sure yet there was any actual exploit done using this app, but it's popularity amongst hackers implies it does SOMETHING useful (i think remember that it authenticates using Exchange Web Services instead of Exchange Online, or something similar? Will update when I have the chance to check). We're in the process of improving our Secure Score, and this incident makes me think user's ability to register apps should be locked down. Checked Secure Score for this, and while there ARE recommendations around apps, disabling user app registration is NOT one of them. Just curious about people's thoughts. I just barely understand App Registration in Entra, but if this is a known attack vector, I would think disabling app registration would be a security recommendation?
Cannot login to Service Trust Portal
Hi, I'm trying to get some certificates from the service trust portal, but I keep getting "Service Trust Portal no longer support Microsoft Account (MSA) access." I'm using an account registered on Azure and I checked the Azure Active Directory, and the user exists (seeing it's the owner of the account). What am I missing here?Anomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon TüpkerMTO/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.NIST CSF 2.0 - Protect (PR) - Applications for Microsoft 365 (Part 1)
This blog and series will look to apply the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) 2.0 and, specifically, the Protect (PR) Function to Microsoft 365. Though the discussion will endeavor to focus primarily on Microsoft 365, topics may venture into Microsoft Azure topics periodically by the nature of each solution. Part 1 or any subsequent blogs in the series will not be an exhaustive review of all possible applications of NIST CSF 2.0, nor exhaustive of the technologies mentioned and their abilities to manage cybersecurity risks. Other applicable Functions or Categories found in NIST CSF 2.0 will be evoked throughout in the true spirit of the framework. PR as a function is intended to cover “safeguards to manage the organization’s cybersecurity risks” and contains five Categories. The prior CSF publication included six categories, but two were significantly edited and renamed. Let’s first dive into Identity Management, Authentication, and Access Control (PR.AA).
