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.Navigating Mergers and Acquisitions: IT Consolidation Best Practices and Approach
In today’s business environment, mergers, divestitures, and acquisitions (M&A) are becoming increasingly common. However, with these business transformations come the challenges of consolidating multiple IT services and applications. Effective consolidation streamlines operations, enhances accessibility, provides a single pane of glass for management, security, and scalability, most importantly, reduces costs. At Microsoft, my team specializes in helping customers tackle these challenges by delivering top-notch solutions. In this article, I’ll Walk you through some key activities to consider when faced with IT consolidation during M&A. Step 1: Define the Scope of Consolidation The first critical step in any consolidation project is identifying the scope. Where is the consolidation happening, and what are the source and target environments? Once these are defined, the next step is to determine how to consolidate the apps, identities, and infrastructure across the two entities. Step 2: Data is Key When it comes to IT, everything revolves around data. In a consolidation scenario, the most valuable data typically comes from Configuration Items (CI’s), customer asset management systems, and server management teams. If the organization maintains robust documentation of these CIs, it can greatly simplify the process. However, what if documentation is sparse? In such cases, we rely on interviews with various teams, including application, server, and infrastructure teams, as well as vendors who support the current infrastructure and applications. These interviews help us gather the essential information needed for a smooth consolidation and migration. Step 3: Leverage Tools for Data Collection Even with comprehensive interviews, there may still be gaps in the available information. This is where tools like the MAP Toolkit, Connection Loggers, and Network traces come into play. The list of tools could be longer, but I have mentioned a few here just for reference. These tools help identify the applications running within the environment and provide details about them. Our team at Microsoft is well-versed in using these tools and can assist customers in creating an accurate inventory of applications hosted in their environment, which will ultimately help in defining the application scope for migrations. Step 4: Prioritize and Plan Migration Once we have a comprehensive list of the applications, servers, and identities involved, the next step is to prioritize and plan the migration. A thorough discussion with stakeholders will determine which elements should be migrated from one domain to another. For Active Directory (AD) users, groups and computer migrations, we leverage the expertise of our Microsoft IMS (Identity Migration Service.) team. For server / application migrations, the approach will depend on the methodologies we plan to follow. Approach to Consider for Users/Groups and Computer Migration: Prepare source and target domain readiness. Define the migration approach and tool selection. Migrate the users, groups, and computers to the target. Test the resources that have been migrated and confirm that users can log in to the target domain. Step 5: Server / Application Migration Scenarios In some cases, servers may already be tied or tagged to a specific domain. However, if users are available in the new domain and the required groups and other settings are configured (using Identity Migration Services team to migrate resources to the target domain), we can switch the server’s domain and reapply the necessary user and group-specific permissions. This is the easiest option when the application hosted on the server is simple and does not require any code changes or reprogramming. In more complex scenarios, switching the domain isn’t possible. In these cases, we may choose to clone the server and create a mirrored environment in the target Active Directory domain, or we may need to set up a parallel environment for the applications. From there, we can reconfigure the applications, endpoints, and any other settings necessary for the app to function properly. Some Common Approaches to Consider: Assessment of the current environment. Setting up migration goals. Creating a migration plan. Testing the migration plan in a lower environment. Migrate server and databases (If applicable). Consider taking sign-off from respective teams. Step 6: Good Rollback Plan You should always create a solid rollback plan for any migration activity. This is a key requirement for a successful migration, and it helps you prepare in case something goes wrong. A good rollback plan will act as a lifesaver, minimizing the impact and helping you recover quickly in case of failure. Step 7: Post-Migration Cleanup Cleanup is the most essential and important step in any migration or consolidation activity. We will need to clean up any resources left behind in the source domain. This includes the cleanup and removal of any Active Directory resources, such as Users, Groups, Group Policies, DNS entries, or trust relationships between the domains. Proven Success in IT Consolidation We have successfully guided numerous customers through consolidation projects, helping them achieve their goals efficiently and securely. If you're currently facing an M&A scenario and need assistance with your IT consolidation efforts, don’t hesitate to reach out to Microsoft. Our team is ready to help. Security First: Protecting Your Environment At Microsoft, security is always a top priority. As we help you consolidate and manage your IT infrastructure, we ensure that security remains at the forefront. We not only help with the technical aspects of consolidation but also with safeguarding your environment throughout the process.Introducing the Secure Future Initiative Tech Tips show!
Introducing the Secure Future Initiative: Tech Tips show! This show provides bite-sized technical tips from Microsoft security experts about how you can implement recommendations from one of the six engineering pillars of Microsoft's Secure Future Initiative in your own environment to uplift your security posture. Hosted by Sarah Young, Principal Security Advocate (_@sarahyo) and Michael Howard, Senior Director Microsoft Red Team (@michael_howard), the series interviews a range of Microsoft security experts giving you practical advice about how to implement SFI controls in your organization's environment. The first episode about phishing resistant creds is live on YouTube and MS Learn. Upcoming episodes include: Using managed identities Using secure vaults to store secrets Applying ingress and egress control Scanning for creds in code and push protection Enabling audit logs for cloud and develop threat detections Keep up to date with the latest Secure Future Initiative news at aka.ms/sfiMicrosoft 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?
