ADSS TSync vs Entra Cross-Tenant Sync: A Comprehensive Comparison
When managing identities across multiple tenants, organizations often face a crucial decision: should they choose ADSS (Active Directory Synchronization Service) Tenant Sync or Entra Native Cross-Tenant Sync to enable collaboration across tenants? The ADSS Tenant Sync service for Tenant-to-Tenant Synchronization is designed to maintain a single unified global address list between tenants. It synchronizes and provisions users or contacts between tenants and provisions guest accounts for Azure B2B sharing of applications and resources. Cross-Tenant synchronization automates creating, updating, and deleting Microsoft Entra B2B collaboration users across tenants in an organization. It enables users to access applications and collaborate across tenants, while still allowing the organization to evolve. Both solutions aim to streamline identity management, but they differ significantly in terms of architecture, control, security, and overall functionality. Hereâs a closer look at each solution, presented with relatable examples to help you make an informed decision based on your organizationâs needs. Architecture and Core Functionality Imagine you are in charge of a large organization with multiple subsidiaries, each operating under its own Azure AD tenant. You need a solution to synchronize all these identities, but you're unsure where to start. ADSS Tenant Sync is a managed service provided by Microsoft Consulting - IMS team, utilizing a pull-push model. Here, synchronization rules are configured by Microsoft Consulting, and the ADSS server manages identity synchronization. This model is often preferred for larger, complex organizations, as it centralizes control and often includes expert support. Itâs akin to outsourcing a specific task to a trusted third-party expert who sets up and manages the solution for you. Entra Cross-Tenant Sync, in contrast, is a native feature of Entra ID (formerly Azure AD) that follows a push-based model using SCIM (System for Cross-domain Identity Management). Synchronization happens directly from your source tenant, offering greater control and integration within your existing Microsoft ecosystem. Itâs like managing your internal processes with a powerful tool thatâs built into your existing systemâno need for third-party involvement. Control, Authentication, and Security The level of control and the security measures between these solutions differ, particularly when it comes to permissions and access management. ADSS Tenant Sync requires permissions through Microsoft Graph and Exchange Online, demanding specific admin rights, like Exchange Recipient Admin rights and Write permissions for each object type you want to sync. This can feel like managing a series of security checkpoints where each part of the system requires specific access credentials to function properly. Entra Cross-Tenant Sync, on the other hand, simplifies authentication by allowing synchronization policies to be configured directly within both the source and target tenants. This reduces complexity and can be managed more easily, especially in organizations that prioritize ease of access and streamlined workflows. Itâs more like having a universal access pass for various departments within a company, eliminating the need for multiple levels of clearance. Data Management, Synchronization, and Filtering When it comes to data handling, there are key differences in how each solution approaches storage and filtering. ADSS Tenant Sync utilizes a centralized identity store within Microsoft-owned Azure subscriptions before synchronizing data to target tenants. This approach allows for complex attribute filtering and customization, such as syncing users as guests or contacts with desired attribute flows and even supports distribution list synchronization as contacts. Itâs like having a centralized warehouse where all the data is stored and categorized, allowing for flexibility when choosing what data to sync and how to manage it. In contrast, Entra Cross-Tenant Sync ensures that identities remain within their respective tenants, with no external storage of sensitive identity data. This model is beneficial for organizations concerned about data privacy, as the identities are kept within their home base. Additionally, Entra Cross-Tenant Sync supports syncing users as either external members or guests, depending on configuration. However, it does not support distribution list or contacts synchronization. Itâs like keeping all documents in their respective departments to ensure that sensitive information stays within the correct boundaries. Both solutions support object filtering and attribute-based scoping, but ADSS offers more customization in terms of attribute management, making it more flexible for organizations with intricate requirements. Cost, API Support, and Suitable Use Cases Cost and extensibility are crucial factors when considering which solution to adopt. ADSS Tenant Sync operates as a third-party managed service through Microsoft, with a monthly fee attached. Itâs ideal for businesses requiring extensive customization, external guest management, and broader synchronization capabilities. The use of Microsoft Graph and PowerShell APIs for extensibility also makes ADSS suitable for organizations that need advanced integrations and a highly tailored solution. Entra Cross-Tenant Sync, on the other hand, is natively integrated into the Microsoft ecosystem. It requires a P1 license for each synchronized user, but the overall cost can be lower compared to ADSS, especially for organizations that do not need extensive customization. The solution uses proprietary APIs managed by the Microsoft Entra Product team, offering a more straightforward, integrated experience. Entra Cross-Tenant Sync is typically more suitable for organizations that prefer an easy-to-manage, cost-effective synchronization solution, without requiring the advanced features of ADSS. Choosing the Right Solution Both ADSS Tenant Sync and Entra Native Cross-Tenant Sync have distinct advantages, and the decision between them depends on your organizationâs specific needs. ADSS Tenant Sync is a solid choice for businesses that need advanced features, such as the ability to customize attributes, manage external guests, and support complex synchronization requirements, even if it comes with an additional cost. Itâs more suitable for multi-tenant organizations or those working with business partners that require a more tailored solution. Entra Cross-Tenant Sync is a cost-effective, native option that seamlessly integrates into your existing Microsoft environment. It's ideal for enterprises looking for a simpler, more integrated way to manage multi-tenant synchronization without needing complex customization. This solution works well for organizations that prioritize streamlined workflows and less technical overhead. In conclusion, whether you choose ADSS Tenant Sync or Entra Native Cross-Tenant Sync depends on your organizationâs goals, the level of customization required, and budget considerations. Both solutions offer effective ways to synchronize identities across tenants, and understanding these differences will help you select the one that aligns best with your infrastructure and long-term identity management goals. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blogs page Watch related videos on our YouTube channel for a seamless, hassle-free migration experience. If you would like to discuss in person, reach out to us at imssales@microsoft.com. Our team will connect with you.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.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.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).Power Up Your ASP.NET Application with External ID Integration in Visual Studio
Microsoft Entra External ID is a comprehensive identity management solution tailored to streamline a vital component of application development; authentication. By integrating External ID, developers can leverage advanced, built-in security features that reduce the risk of vulnerabilities and ensure compliance with industry standards. This approach not only expedites the development process but also supports scalability and enhances the user experience by providing seamless and secure access. Ultimately, it empowers developers to deliver high-quality, secure applications with greater efficiency. In this blog, we walk you through the process of creating an ASP.Net application with External ID using Visual Studio. Currently the template on Visual Studio supports ASP.Net only. If youâd like to explore External ID on other samples (JavaScript, React, Angular, Node.js (Express), ASP.NET Core, Python Django, Python Flask, Java Servlet etc.), please check out the Microsoft Entra External ID extension for Visual Studio Code or the Microsoft Entra admin center wizard guide. Setting up and running your application Prerequisites Install the recommended Visual Studio version (17.11.3), along with ASP.NET and the web development workload. An external tenant on Microsoft Entra Admin Center. If you donât have one, you can create one using our 30-day free trial orâŻcreate an external tenantâŻwith an Azure subscription. If you have one continue reading. Ensure you have the application administrator role on Microsoft Entra. After meeting the above prerequisites, you can dive into the video where we show you how to integrate Microsoft Entra External ID in your app on Visual Studio or jump straight into the guide. Create your project Open Visual Studio and create a new project.⯠o From the templates, select âASP.NET Core Web App (Razor Pages)â and click Next. o Provide a Project Name, e.g. âASP-Applicationâ and a Location (where you want to create the project) and click Next. o In the Framework selection, use â.NET 8.0 (Long Term Support)â and under Authentication Type, select âMicrosoft identity platformâ. Then click on Create. The following diagram shows the Microsoft identity platform at a high level, including the application registration experience, SDKs, endpoints, and supported identities or account types. Install components Install the required component, dotnet msidentity tool, and click Next.⯠Configure External ID Sign in to External ID with a user that has permission to create an application registration. Select your trial or external tenant from the Tenants drop down. Click Create new and give your application a name, like âvisual-studio-asp-appâ. This will create an application in Microsoft Entra External ID including a linked user flow, fully defining the sign-in and sign-up experience for your users. Then click Register. The app registration process collects and assigns these values for your app: An Application (client) ID that uniquely identifies your app. A Redirect URI that you can use to direct responses back to your app. A few other scenario-specific values such as supported account types. Next, select the application youâve just registered then click Next. Skip the âAdditional settingsâ step shown below as it does not work with External tenant. Review the Summary of changes and click Finish. The dependency configuration process starts as shown below. Once done, click Close. Run and test the application To run your application, navigate to Debug> Start Without Debugging. Once your build is complete, a new browser window will open at https://localhost:7124. Complete the sign-up and sign-in process on the screen shown below: process On successful sign in, you will be able to see the demo page, as shown below: Youâve successfully configured Microsoft Entra External ID on an ASP.NET core Web App and signed in your first user. Next steps Continue exploring Microsoft Entra External ID samples by checking out the Microsoft Entra External ID extension for Visual Studio Code or the Microsoft Entra admin center wizard guide. Share your feedback and tell us what you think,âŻor suggest new features. Also, please join our research panel to receive occasional invites to participate in customer research. 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.Implement authentication on mobile apps with Native Authentication for Microsoft Entra External ID
Native authentication empowers you to take complete control over the design of the sign-in experience of your mobile applications. It allows you to craft stunning, pixel-perfect brand-aligned authentication user flows (including design elements, logo placement, and layout) that are seamlessly integrated into your mobile apps, rather than relying on browser-based solutions. While at the same time, ensuring that sign-in and sign-up processes remain secure and frictionless. This balance of customization and security drives better onboarding, retention, and, ultimately, user trust. Authentication on Mobile: Native authentication vs Browser-delegated When it comes to implementing authentication for mobile apps on External ID, you have two options: Fully custom SDK based native authentication. Microsoft-hosted browser-delegated authentication. In the browser-delegated mobile app sign-in process, users often experience a disruptive jump during authentication. Theyâre taken to a browser for authentication and then redirected back to the app when the sign-in is complete. This leads to a diluted experience and branding can be compromised. While browser-delegated methods can reduce attack vectors and support single sign-on (SSO), they suffer from limited UI customization and poor user experience. Whether you choose native authentication or browser-delegated authentication, Microsoft Entra External ID supports both of them. Refer to this documentation to understand when to use native authentication and when to use browser-delegated authentication. Native authentication gives you full control over the user interface and experience. Available authentication methods Native authentication currently supports local identity provider for two sign-in methods: Email with one-time passcode (OTP) sign-in. Email and password sign-in with support for self-service password reset (SSPR). How to enable native authentication 1. Register application in the external tenant To enable your application to sign in users with Microsoft Entra, Microsoft Entra External ID must be made aware of the application you create. The app registration establishes a trust relationship between the app and Microsoft Entra. When you register an application, External ID generates a unique identifier known as an Application (client) ID, a value used to identify your app when creating authentication requests. For Native Authentication, we use external tenant, not workforce tenant. You need to have an external tenant. If you donât already have one, sign up for a free trial. The following steps show you how to register your app in the Microsoft Entra admin center: Sign In Microsoft Entra admin center as at least an Application Developer. If you have access to multiple tenants, use the Settings icon in the top menu to switch to your external tenant from the Directories + subscriptions menu. Browse to Identity >Applications > App registrations. Select + New registration. In the Register an application page that appears; Enter a meaningful application Name that is displayed to users of the app, for example ciam-client-app. Under Supported account types, select Accounts in this organizational directory only. Select Register. The application's Overview pane displays upon successful registration. Record the Application (client) ID to be used in your application source code. 2. Enable public client and native authentication flows. Enable native authentication in the Microsoft Entra admin center: In Microsoft Entra admin center, browse to Applications> App registrations and select your app. Navigate to Authentication and select the Settings tab. Select the Allow native authentication and the Allow public client flow field. 3. Grant admin consent Once you register your application, it gets assigned the User.Read permission. However, since the tenant is an external tenant, the customer users themselves can't consent to this permission. You as the admin must consent to this permission on behalf of all the users in the tenant: From the App registrations page, select the application that you created (such as ciam-client-app) to open its Overview page. Under Manage, select API permissions. a) Select Grant admin consent for <your tenant name>, then select Yes. b) Select Refresh, then verify that Granted for <your tenant name>appears under Status for the permission. 4. Create user flow in the external tenant. Follow these steps to create a user flow. Sign in to the Microsoft Entra admin center as at least an Application Developer. If you have access to multiple tenants, make sure you use the directory that contains your external tenant: a) Select the Directories + subscriptions icon in the toolbar. b) On the Portal settings | Directories + subscriptions page, find your external tenant directory in the Directory name list, and then select Switch. 3. On the sidebar menu, select Identity. 4. Select External Identities > User flows. 5. Select + New user flow. 6. On the Create page: a) Enter a Name for the user flow, such as SignInSignUpSample. b) In the Identity providers list, select Email Accounts. This identity provider allows users to sign-in or sign-up using their email address. c) Under Email accounts, you can select one of the two options. For this tutorial, select Email one-time passcode. Email with password: Allows new users to sign up and sign in using an email address as the sign-in name and a password as their first factor credential. Email one-time passcode: Allows new users to sign up and sign in using an email address as the sign-in name and email one-time passcode as their first factor credential. For this option to be available at the user flow level, make sure you enable email one-time passcode (OTP) at the tenant level (select All Identity Providers, and then for Email One-time passcode select Configured, select the Yes option, and then select Save). d) Under User attributes, you can choose the attributes you want to collect from the user upon sign-up. For this guide, select Country/Region and City. 7. Select Create. The new user flow appears in the User flows list. 5. Associate the application with the user flow For the customer users to see the sign-up or sign-in experience when they use your app, you need to associate your app with a user flow. Although many applications can be associated with your user flow, a single application can only be associated with one user flow. On the sidebar menu, select Identity. Select External Identities, then User flows. In the User flows page, select the User flow name you created earlier, for example, SignInSignUpSample. Under Use, select Applications. Select Add application. Select the application from the list such as ciam-client-app or use the search box to find the application, and then select it. Choose Select. 6. Update your configuration code You can build apps that use native authentication by using our native authentication APIs or the Microsoft Authentication Library (MSAL) SDK for Android and iOS/macOS. Below are the supported languages and frameworks: Android (Kotlin, Java) iOS/macOS (Swift, Objective-C) For other languages and platforms, you can use our native authentication API. Whenever possible, we recommend using MSAL to add native authentication to your apps. The next step is to update your applicationâs configuration code to support native authentication flows for Android or iOS/macOS. To do so, you need to add the challenge type field to your configuration. Challenge types are a list of values that the app uses to notify Microsoft Entra about the authentication method it supports. We have the below code samples for Android and iOS/macOS. Clone the code sample for the language or platform of your choice. Find the place holders Enter_the_Application_Id_Here and Enter_the_Tenant_Subdomain in the configuration file highlighted in the table below and replace with the Application (client) ID and Directory (tenant) subdomain. These details can be found from Microsoft Entra admin center > Applications > App registrations then select your app. Language/ Platform Clone Code sample Code sample configuration file to be edited Android (Kotlin) https://github.com/Azure-Samples/ms-identity-ciam-native-auth-android-sample app/src/main/res/raw/native_auth_sample_app_config.json (Open on Android Studio) iOS (Swift) https://github.com/Azure-Samples/ms-identity-ciam-native-auth-ios-sample.git NativeAuthSampleApp/Configuration.swift (Open on Xcode) macOS (Swift) https://github.com/Azure-Samples/ms-identity-ciam-native-auth-macos-sample.git NativeAuthSampleAppMacOS/Configuration.swift (Open on Xcode) 7. Run and test the sample Android mobile application - To build and run your app, follow these steps: In Android Studio toolbar, select your app from the run configurations menu. In the target device menu, select the device that you want to run your app on. If you don't have any devices configured, you need to either create an Android Virtual Device to use the Android Emulator or connect a physical Android device. 3. Select the Run button. The app opens the Email & OTP screen. iOS/macOS application - To build and run your code, select Run from the Product menu in Xcode. After a successful build, Xcode will launch the sample app in the Simulator. Kudos, youâve successfully configured Microsoft Entra External ID native authentication on an android or iOS/macOS app. Next steps Continue exploring Microsoft Entra External ID Native Authentication by checking out the documentation. 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.Start learning how Copilot can help you by watching Microsoft Copilot for Security Flight School
Where traditional approaches to enterprise security can isolate security professionals from each other and business functions across highly fragmented environments, Microsoft Copilot for Security helps by redefining what security is and how security gets done. Thatâs why weâre thrilled to introduce Microsoft Copilot for Security Flight School! Building on the foundational learning in Learn Live: Get started with Microsoft Copilot for Security, host Ryan Munsch, Principal Tech Specialist at Microsoft, explores several intermediate technical topics (L200+) in our flight school videosâranging from what Microsoft Copilot for Security is (and what it isnât) to key capabilities, experiences, and how to extend Copilot to your ecosystem. Each topical video is 10 mins or less, aligning to relevant learning modules on Microsoft Learn. This can prove valuable for IT pros looking to enhance their ability to process security signals and protect at the speed and scale of AI. Training topics include: What is Microsoft Copilot for Security?â AI orchestration â Standalone and embedded experiences Copilot in Entra, Intune, and Purview Manage your plugins Prompting âCopilot Prompt engineering â Using promptbooks Logic appsâ Extending Copilot to your ecosystem Check out Microsoft Copilot for Security Flight School today.
