Teams External Collaboration Administrator Role Arrives
Microsoft is introducing a new Entra ID role. The Teams External Collaboration administrator role allows users to manage external collaboration settings. Quite how often Microsoft 365 tenants need to manage these settings is unknown, but it’s a useful prompt to review the current set of roles used and users who are members of those roles. Time for an annual clean-up. https://office365itpros.com/2026/01/14/new-entra-id-role/Entra ID Rationalizes Session Revocation for User Accounts
Microsoft is rationalizing the options to revoke sessions for a user account in the Entra admin center by removing an old revoke MFA sessions button. That seems like a perfectly reasonable thing to do. When administrators want to revoke sessions for an account, the best way is to create a PowerShell script to perform the necessary steps. That way you don’t need to worry about buttons. https://office365itpros.com/2026/01/09/revoke-sessions-button/
Android Teams login fails during ADFS federation with SSL error
Hello Android mobile users cannot sign in to Microsoft Teams The login fails during the ADFS federation step due to an SSL error Environment Android OS versions 10 to 14 Microsoft Teams mobile app Entra ID federated with on premises ADFS ADFS service URL is masked Public certificate issued by Sectigo Issue description After entering the account in Teams the sign in process redirects to ADFS The page does not load correctly and shows infinite loading or a blank screen The same account works normally on PC browser PC Teams and Outlook Web The issue occurs only on Android mobile apps that use WebView Android log summary OAuth2 WebView client received SSL error Primary error SSL untrusted Wildcard certificate for masked domain Certificate issued by Sectigo Public Server Authentication CA Troubleshooting performed Device date and time verified Teams app cache cleared and app reinstalled Issue reproduced on multiple Android versions and devices PC authentication works with the same certificate Questions Can Android WebView or Microsoft mobile authentication fail with SSL untrusted when the ADFS server does not provide a complete certificate chain Is full chain certificate configuration required on ADFS IIS for mobile authentication Can SSL inspection or proxy interception cause this issue only on Android apps while PC browsers work normally Are there official Microsoft recommendations for certificate configuration when using ADFS federation with Android mobile apps Additional information The same behavior occurs in other Microsoft mobile apps The suspected causes are incomplete certificate chain or network SSL inspection Thank youMoving Exchange Account Source Account
I have a very complex environment I'm hoping someone might jump start my search. We have two domains syncing to Entra ID. One domain is a resource forest where our Exchange environment sits. That domain contains disabled stub accounts synced to our primary domain where the actual user accounts sit. The source for all EXO mailboxes are the stubs in the resource forest. Those accounts are kept in sync using FIM 2008. We're wanting to decom that entire resource environment and move all of the attributes to the primary domain. The resource domain schema is the last version of Ex 2016. The primary domain schema is Ex 2010 SP1. I know my first step is to update the primary schema, however, has anyone encountered a situation like this? Any help would be greatly appreciated.
Graph http 449 throttled
We are experiencing a lot of Microsoft Graph trolling errors from some of our applications that are hosted in Azure Web App Services and other third party such as Front App to name one. I am trying to find an approach or strategy to figure out and narrow down what may be causing so many of these events. Whether I can narrow down by application or process, I am not sure yet. We enforce MFA on all our users, but of course, on Azure Enterprise Applications, we don't, which are used extensively in our ecosystem of apps. Any help is much appreciated here.Automating Microsoft 365 with PowerShell Second Edition
The Office 365 for IT Pros team are thrilled to announce the availability of Automating Microsoft 365 with PowerShell (2nd edition). This completely revised 350-page book delivers the most comprehensive coverage of how to use Microsoft Graph APIs and the Microsoft Graph PowerShell SDK with Microsoft 365 workloads (Entra ID, Exchange Online, SharePoint Online, Teams, Planner, and more). Existing subscribers can download the second edition now free of charge. https://office365itpros.com/2025/06/30/automating-microsoft-365-with-powershell2/
Microsoft Authenticator Passkeys for Entra ID on unmanaged devices
Hello, has anyone successfully registered passkeys on an unmanaged phone in an organisation with device compliance policies? Use case is to provide a phishing-resistant MFA option via Authenticator app for logging into apps on their desktop. Users already have authenticator app on their phone and do number matching MFA. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-register-passkey-authenticator?tabs=iOS When I select "Create a passkey" - I need to log into my account. However I'm blocked from successful authentication because I have conditional access policies to require compliant devices. As my mobile phone is not enrolled into Intune, I never get to the step where the passkey is created and registered. Based on the constraints - it seems like passkeys cannot be used for unmanaged/BYOD devices for organisations that have device compliance policies. It can only be used for users who have enrolled their mobile phone. Looking to see if anyone has tips or different experience using passkeys on unmanaged mobile phones to log into Entra?Empower Your Cloud Identity: How to Convert User SOA from AD to Entra ID
For years, hybrid identity has been the standard. We synchronize users from on-premises Active Directory (AD) to Microsoft Entra ID (formerly Azure AD), giving our people one set of credentials for both cloud and local resources. But this setup comes with a hidden limitation: Active Directory remains the Source of Authority (SOA). This traditional model limits your ability to leverage modern security, governance, and management tools available in the cloud. The good news? Microsoft has introduced the capability to shift the SOA for your users entirely to Entra ID. Here’s a deep dive into why this shift is essential, how simple the change is, and the critical implications you need to plan for. The Hybrid Dilemma: Why AD SOA is Limiting: In a typical hybrid setup, every synced user object in Entra ID has properties that are permanently locked down or "grayed out." This is because the object has an underlying attribute, isCloudManaged, set to false. This status means: Limited Lifecycle Management: You can’t fully leverage cloud-based identity governance or lifecycle features. HR Provisioning Complexity: If your Human Resources (HR) system is the true source of truth for new employees, updates must flow: HR → AD → Entra ID. This creates latency and points of failure. Increased Attack Surface: If you are primarily cloud-focused, maintaining an AD object for synchronization creates an unnecessary on-premises attack surface that you must continually protect. No Cloud Editing: You are forced to make all major attribute changes in AD, even if the user only interacts with cloud services. By making Entra ID the Source of Authority, you break this dependency and unlock a truly cloud-first identity posture. The Core Mechanism: A Single Attribute Flip: The actual technical process of changing the SOA is surprisingly simple, it boils down to flipping a single attribute. The change is made using the Microsoft Graph API (or PowerShell) with a PATCH command against the user's onPremisesSyncBehavior endpoint. Action Method Endpoint Body Change SOA PATCH /beta/users/{user-id}/onPremisesSyncBehavior { "isCloudManaged": true } Once this change is made, two immediate things happen: Synchronization Stops: Entra Connect or Cloud Sync immediately recognize the change and stop synchronizing any updates from the on-premises AD object to the Entra ID object. Properties Unlocked: The user's properties in the Entra ID portal are instantly un-grayed, allowing cloud administrators to manage the user's identity directly. Critical Warning: No Write-Back Before you perform this change, you must understand the most critical implication: There is no user write-back capability from Entra ID to AD today. Once you shift the SOA, the connection is unidirectional and then effectively severed. Changes made to the cloud object will not be reflected in the on-premises AD object. Post-Migration Scenarios: Planning the Cutover: After flipping the SOA, you must plan what happens to the on-premises AD object. There are two main scenarios: Scenario 1: Full Cloud Cutover (The Ideal) If your user no longer requires any legacy Kerberos or AD-dependent services: Action in AD: Disable the user account in Active Directory immediately. After a period of validation, the account can be safely deleted. Benefit: This achieves the goal of minimizing your AD footprint, reducing attack surface, and simplifying your HR flow to HR → Entra ID. Scenario 2: Maintaining On-Premises Kerberos Access Many organizations still rely on Kerberos for resources like file shares, legacy applications, or Remote Desktop (RDP) access. Fortunately, you can still access these resources with an Entra ID-managed user, but it requires a few key technical components: Keep the AD Object: You must keep the on-premises AD user account (though it should no longer be managed by AD tools). Passwordless Authentication: The user must utilize a modern passwordless method (like Windows Hello for Business or FIDO2 keys). Cloud Kerberos Trust: Your environment must be configured with a Cloud Kerberos Trust. How it works: The cloud-managed user authenticates with Entra ID using passwordless methods. Entra ID, acting as a pseudo Read-Only Domain Controller, issues a partial Kerberos Ticket Granting Ticket (TGT). This partial TGT is used with your domain controllers to acquire a full Kerberos service ticket, which then grants access to the on-premises resource (e.g., the file share). Final Planning Checklist: While the Graph API command is easy, the preparation is everything. Plan your deployment carefully: Step Action Why 1. Migrate Groups First Shift the SOA for all security groups the user belongs to before shifting the user's SOA. Groups are often a logical first step for moving access controls. 2. Retire Exchange Hybrid Ensure all user mailboxes have been moved to Exchange Online. Entra ID SOA users are incompatible with the on-premises Exchange Hybrid configuration. 3. Plan for HR Flow Update your HR provisioning to target Entra ID directly, bypassing AD, for the affected users. This ensures the user's identity lifecycle is entirely cloud-managed going forward. 4. Automate Write a robust PowerShell script to manage the process, allowing for staged rollouts based on Organizational Units (OUs) or security groups. Avoid making changes one-by-one in the portal for scale and consistency. Moving the Source of Authority to Microsoft Entra ID is a major step toward a modern, highly secure, and simplified identity environment. Understand the implications, plan your path for Kerberos access, and start unlocking the full potential of the cloud.Empower Your Cloud Identity: How to Convert User SOA from AD to Entra ID
For years, hybrid identity has been the standard. We synchronize users from on-premises Active Directory (AD) to Microsoft Entra ID (formerly Azure AD), giving our people one set of credentials for both cloud and local resources. But this setup comes with a hidden limitation: Active Directory remains the Source of Authority (SOA). This traditional model limits your ability to leverage modern security, governance, and management tools available in the cloud. The good news? Microsoft has introduced the capability to shift the SOA for your users entirely to Entra ID. Here’s a deep dive into why this shift is essential, how simple the change is, and the critical implications you need to plan for. The Hybrid Dilemma: Why AD SOA is Limiting: In a typical hybrid setup, every synced user object in Entra ID has properties that are permanently locked down or "grayed out." This is because the object has an underlying attribute, isCloudManaged, set to false. This status means: Limited Lifecycle Management: You can’t fully leverage cloud-based identity governance or lifecycle features. HR Provisioning Complexity: If your Human Resources (HR) system is the true source of truth for new employees, updates must flow: HR → AD → Entra ID. This creates latency and points of failure. Increased Attack Surface: If you are primarily cloud-focused, maintaining an AD object for synchronization creates an unnecessary on-premises attack surface that you must continually protect. No Cloud Editing: You are forced to make all major attribute changes in AD, even if the user only interacts with cloud services. By making Entra ID the Source of Authority, you break this dependency and unlock a truly cloud-first identity posture. The Core Mechanism: A Single Attribute Flip: The actual technical process of changing the SOA is surprisingly simple, it boils down to flipping a single attribute. The change is made using the Microsoft Graph API (or PowerShell) with a PATCH command against the user's onPremisesSyncBehavior endpoint. Action Method Endpoint Body Change SOA PATCH /beta/users/{user-id}/onPremisesSyncBehavior { "isCloudManaged": true } Once this change is made, two immediate things happen: Synchronization Stops: Entra Connect or Cloud Sync immediately recognize the change and stop synchronizing any updates from the on-premises AD object to the Entra ID object. Properties Unlocked: The user's properties in the Entra ID portal are instantly un-grayed, allowing cloud administrators to manage the user's identity directly. Critical Warning: No Write-Back Before you perform this change, you must understand the most critical implication: There is no user write-back capability from Entra ID to AD today. Once you shift the SOA, the connection is unidirectional and then effectively severed. Changes made to the cloud object will not be reflected in the on-premises AD object. Post-Migration Scenarios: Planning the Cutover: After flipping the SOA, you must plan what happens to the on-premises AD object. There are two main scenarios: Scenario 1: Full Cloud Cutover (The Ideal) If your user no longer requires any legacy Kerberos or AD-dependent services: Action in AD: Disable the user account in Active Directory immediately. After a period of validation, the account can be safely deleted. Benefit: This achieves the goal of minimizing your AD footprint, reducing attack surface, and simplifying your HR flow to HR → Entra ID. Scenario 2: Maintaining On-Premises Kerberos Access Many organizations still rely on Kerberos for resources like file shares, legacy applications, or Remote Desktop (RDP) access. Fortunately, you can still access these resources with an Entra ID-managed user, but it requires a few key technical components: Keep the AD Object: You must keep the on-premises AD user account (though it should no longer be managed by AD tools). Passwordless Authentication: The user must utilize a modern passwordless method (like Windows Hello for Business or FIDO2 keys). Cloud Kerberos Trust: Your environment must be configured with a Cloud Kerberos Trust. How it works: The cloud-managed user authenticates with Entra ID using passwordless methods. Entra ID, acting as a pseudo Read-Only Domain Controller, issues a partial Kerberos Ticket Granting Ticket (TGT). This partial TGT is used with your domain controllers to acquire a full Kerberos service ticket, which then grants access to the on-premises resource (e.g., the file share). Final Planning Checklist: While the Graph API command is easy, the preparation is everything. Plan your deployment carefully: Step Action Why 1. Migrate Groups First Shift the SOA for all security groups the user belongs to before shifting the user's SOA. Groups are often a logical first step for moving access controls. 2. Retire Exchange Hybrid Ensure all user mailboxes have been moved to Exchange Online. Entra ID SOA users are incompatible with the on-premises Exchange Hybrid configuration. 3. Plan for HR Flow Update your HR provisioning to target Entra ID directly, bypassing AD, for the affected users. This ensures the user's identity lifecycle is entirely cloud-managed going forward. 4. Automate Write a robust PowerShell script to manage the process, allowing for staged rollouts based on Organizational Units (OUs) or security groups. Avoid making changes one-by-one in the portal for scale and consistency. Moving the Source of Authority to Microsoft Entra ID is a major step toward a modern, highly secure, and simplified identity environment. Understand the implications, plan your path for Kerberos access, and start unlocking the full potential of the cloud.Checking Where Tenant Users Go as Guests
After all the fuss about Teams users inviting people to chat via email, tenant administrators realize that knowing where users are active as guest accounts is not as easy as it might seem. Part of the problem is that data about user activity is mostly controlled by host rather than home tenants. However, it’s possible to extract some information from audit sign-in logs to figure out where tenant users go as guests. https://office365itpros.com/2025/12/09/external-guest-activity/
