Can External ID (CIAM) federate to an Azure AD/Entra ID tenant using SAML?
What I'm trying to achieve I'm setting up SAML federation FROM my External ID tenant (CIAM) TO a partner's Entra ID tenant (regular organizational tenant) for a hybrid CIAM/B2B setup where: Business users authenticate via their corporate accounts (OIDC or SAML) Individual customers use username/password or social providers (OIDC) Tenant details / Terminology: CIAM tenant: External ID tenant for customer-facing applications IdP tenant: Example Partner's organizational Entra ID tenant with business accounts Custom domain: mycustomdomain.com (example domain for the IdP tenant) Configuration steps taken Step 1: IdP Tenant (Entra ID) - Created SAML App Set up Enterprise App with SAML SSO Entity ID: https://login.microsoftonline.com/<CIAM_TENANT_ID>/ Reply URL: https://<CIAM_TENANT_ID>.ciamlogin.com/login.srf NameID: Persistent format Claim mapping: emailaddress → user.mail Step 2: CIAM Tenant (External ID) - Added SAML IdP (Initially imported from the SAML metadata URL from the above setup) Federating domain: mycustomdomain.com Issuer URI: https://sts.windows.net/<IDP_TENANT_ID>/ Passive endpoint: https://login.microsoftonline.com/mycustomdomain.com/saml2 DNS TXT record added: DirectFedAuthUrl=https://login.microsoftonline.com/mycustomdomain.com/saml2 Step 3: Attached to User Flow Added SAML IdP to user flow under "Other identity providers" Saved configuration and waited for propagation The problem It doesn't work. When testing via "Run user flow": No SAML button appears (should display "Sign in with mycustomdomain") Entering email address removed for privacy reasons doesn't trigger federation The SAML provider appears configured but never shows up in the actual flow Also tried using the tenant GUID in the passive endpoint instead of the domain - same result My question Is SAML federation from External ID to regular Entra ID tenants actually possible? I know OIDC federation to Microsoft tenants is (currently, august 2025) explicitly blocked (microsoftonline.com domains are rejected). Is SAML similarly restricted? The portal lets me configure everything without throwing any errors, but it never actually works. Am I missing something in my configuration? The documentation for this use case is limited and I've had to piece together the setup from various sources. Or is this a fundamental limitation where External ID simply can't federate to ANY Microsoft tenant regardless of the protocol used?Securing the Modern Workplace: Transitioning from Legacy Authentication to Conditional Access
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction In today’s threat landscape, legacy authentication is one of the weakest links in enterprise security. Protocols like POP, IMAP, SMTP Basic, and MAPI are inherently vulnerable — they don’t support modern authentication methods like MFA and are frequently targeted in credential stuffing and password spray attacks. Despite the known risks, many organizations still allow legacy authentication to persist for “just one app” or “just a few users.” This article outlines a real-world, enterprise-tested strategy for eliminating legacy authentication and implementing a Zero Trust-aligned Conditional Access model using Microsoft Entra ID. Why Legacy Authentication Must Die No support for MFA: Enables attackers to bypass the most critical security control Password spray heaven: Common vector for brute-force and scripted login attempts Audit blind spots: Limited logging and correlation in modern SIEM tools Blocks Zero Trust progress: Hinders enforcement of identity- and device-based policies Removing legacy auth isn’t a nice-to-have — it’s a prerequisite for a modern security strategy. Phase 1: Auditing Your Environment A successful transition starts with visibility. Before blocking anything, I led an environment-wide audit to identify: All sign-ins using legacy protocols (POP, IMAP, SMTP AUTH, MAPI) App IDs and service principals requesting basic auth Users with outdated clients (Office 2010/2013) Devices and applications integrated via PowerShell, Azure Sign-In Logs, and Workbooks Tools used: Microsoft 365 Sign-In Logs Conditional Access insights workbook PowerShell (Get-SignInLogs, Get-CASMailbox, etc.) Phase 2: Policy Design and Strategy The goal is not just to block — it’s to transform authentication securely and gradually. My Conditional Access strategy included: Blocking legacy authentication protocols while allowing scoped exceptions Report-only mode to assess potential impact Role-based access rules (admins, execs, vendors, apps) Geo-aware policies and MFA enforcement Service account handling and migration to Graph or Modern Auth-compatible apps Key considerations: Apps that support legacy auth only Delegates and shared mailbox access scenarios BYOD and conditional registration enforcement Phase 3: Staged Rollout and Enforcement A phased approach reduced friction: Pilot group enforcement (IT, InfoSec, willing users) Report-only monitoring across business units Clear communications to stakeholders and impacted users User education campaigns on legacy app retirement Gradual enforcement by department, geography, or risk tier We used Microsoft Entra’s built-in messaging and Service Health alerts to notify users of policy triggers. Phase 4: Monitoring, Tuning, and Incident Readiness Once policies were in place: Monitored Sign-in logs for policy match rates and unexpected denials Used Microsoft Defender for Identity to correlate legacy sign-in attempts Created alerts and response playbooks for blocked sign-in anomalies Results: 100% of all user and app traffic transitioned to Modern Auth Drastic reduction in brute force traffic from foreign IPs Fewer support tickets around password lockouts and MFA prompts Lessons Learned Report-only mode is your best friend. Avoids surprise outages. Communication beats configuration. Even a perfect policy fails if users are caught off guard. Legacy mail clients still exist in vendor tools and old mobile apps. Service accounts can break silently. Replace or modernize them early. CA exclusions are dangerous. Every exception must be time-bound and documented. Conclusion Eliminating legacy authentication is not just a policy update — it’s a cultural shift toward Zero Trust. By combining deep visibility, staged enforcement, and a user-centric approach, organizations can securely modernize their identity perimeter. Microsoft Entra Conditional Access is more than a policy engine — it is the architectural pillar of enterprise-grade identity security. Author’s Note: This article is based on my real-world experience designing and enforcing Conditional Access strategies across global hybrid environments with Microsoft 365 and Azure AD/Entra ID. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.Display On-prem Password Policy on SSPR Page
Hi All We are beginning to rollout SSPR with on-prem writeback. So far so good. Is there a way we can display our on-prem password policy requirements on the SSPR screen? I have seen the MS docs, but can't really make any sense of them so any help would be greatly appreciated. SKPrimer: How to Use RBAC for Applications to Control App Use of the Mail.Send Permission
The temptation to use the Mail.Send application permission in scripts can lead PowerShell developers into trouble because the permission allows access to all mailboxes, including sensitive executive and financial mailboxes. Fortunately, RBAC for Applications allows tenants to control the access that apps have to mailboxes and other Exchange content. All explained here with an example script to test RBAC of Applications. https://office365itpros.com/2026/02/17/mail-send-rbac-for-applications/
Orphaned TPM-bound Entra Workplace Join device — no tenant access, backend deletion required
I have a personal Windows device that remains stuck in a TPM-protected Workplace Join to a former Microsoft Entra ID tenant. I no longer have tenant access and am not an admin. Local remediation completed: - dsregcmd /leave executed as SYSTEM - All MS-Organization / AAD certificates removed - Device still reports WorkplaceJoined : YES Azure Support ticket creation fails with: AADSTS160021 – interaction_required Application requested a user session which does not exist. Tenant inaccessible / user not present in tenant. This is an orphaned Entra ID device object. Requesting guidance or escalation for backend deletion. Tenant ID: 99f9b903-8447-4711-a2df-c5bd1ad1adf7 Device ID: f47987f4-a20b-4c34-a5f7-40ab0f593c6cEntra Enterprise apps and App registrations - Global Secure Access - Conditional Access Block
I am working on a rollout for Global Secure Access and ran into an issue with Entra Enterprise apps setup in the tenant. With Global Secure Access I have a Conditional Access Policy set to Block access to All Resources excluding some resources like Intune and Defender tap required for mobile setup. When I added an administrator account which had done some Enterprise application setup and authorization for various third-party applications, those third-party applications stopped working with failed logins indicating token access issues. Upon review I found the majority of applications to be using client secret authentication with this administrator account as the authorizer. My limited knowledge of Enterprise apps leads me to believe this client secret is an application password that the third-party uses to keep generating tokens based on the authorizing account. My questions surrounding this setup and further understanding are mainly in relation to how Enterprise apps and app registrations authenticate, as well as user authentication directly. 1. How does the token authorization work? Does the application just use the client secret to authenticate as the user who authorized it to generate an access token? Why does MFA requirements and changing passwords not affect this but specific Block policy does? 2. What are best practices in relation to authorizing third-party applications? My thoughts are a dedicated account to authorize applications when needed. 3. How will this work with applications regular users use? Say a user has a digital notebook that syncs with their OneNote or a calendar app that syncs calendars between Outlook and their website. Do these applications also use client secrets with the user's token and will break when added to the GSA setup I have? Is the only way around this to authorize with an admin account for token issuance? Thank you for your time reading this and any insight you may have for any of the questions or ideas mentioned.
External (guest) users can't access my registered application
We have a FileMaker application registered with Entra ID, using OAuth, for internal and external (guests) users in my organization. Since January 19th, external users have been encountering a different authentication process, which results in a 404 error (see images below). No changes were made to the Entra ID or the application configurations before this change in behaviour. It seems that logging in to a personal account results in an incorrect token for the redirect URL, which does not happen when logging in with organizational accounts.
Microsoft Feedback Portal account issue
I changed my Microsoft email a year ago, and it updated everywhere other than the Feedback Portal. As a result, I get an error when I try to login, or do anything on the page. Microsoft account support's suggestion was to login to the Feedback Portal which is insane given I'm having issues accessing it. How can I get this issue resolved? I've got three separate support tickets now and they keep asking me to wait 24 hours to get the issue resolved. Can someone from the Feedback Portal team please contact me to resolve this? This is what Microsoft Support have said: "understand your frustration, and yes—this is an account‑related issue because the Feedback Portal is still tied to your old alias, which causes login conflicts and forces you out. Your Microsoft account itself signs in correctly, but the Feedback Portal is pulling outdated identity data that you cannot update on your own. Since you cannot access the Portal to submit feedback, directing you back there is not a workable solution. What you need is for Support to escalate this to the internal Identity/Feedback Platform engineering team so they can manually correct the outdated alias mapping on the backend. In this situation, the Feedback Portal and Tech Community teams are the ones who manage and maintain that specific platform. Because the issue appears on the Feedback Portal side—even though your Microsoft account is working normally—only their dedicated team can make the necessary corrections on their end. That’s why we are guiding you to connect with them through the links provided: https://techcommunity.microsoft.com/ or https://feedbackportal.microsoft.com/feedback. They will be able to review the portal‑specific account data and assist you further. I understand why this is frustrating. Since you’re unable to stay signed in to the Feedback Portal, I completely see why posting there isn’t possible for you. However, I do need to be transparent: I’m not able to escalate this issue directly to the Feedback Portal team, as they don’t provide internal escalation channels for us and only accept requests through their own platform."
