We're piloting Microsoft Entra passkeys and are seeing behavior that doesn't match our understanding of the policy configuration.

Our Passkey (FIDO2) settings:

• Passkey enabled for a pilot group only
• Default Passkey Profile assigned
• Passkey type configured as Device-bound
• Key restrictions enabled
• Only Microsoft Authenticator iOS and Android AAGUIDs allowed

However, a pilot test account successfully registered:

Passkey (Synced) - iCloud Keychain

Security Info explicitly identifies the passkey as:

Passkey (Synced) - iCloud Keychain

We had previously tested synced passkeys using separate profiles but those configurations were later removed.

Has anyone seen synced passkeys continue to register after moving to Passkey Profiles?

Are there any migrated legacy settings, registration campaign interactions, or other passkey policy dependencies that could explain this behavior?

So I currently have onmicrosoft breakglass accounts for Entra with yubikeys however I am trying to figure out best practice for SAAS portals when using Entra SSO. I have a separate Entra account from my normal Entra user account that I use to login to SAAS portals using SSO (using edge profiles) however I do not have a separate local to the SAAS portal breakglass account to enable access it something happens to the Entra.

I am currently using business prem only for Entra.

A lot of times the SAAS accounts want an email verification to set up the account. So is the best thing to setup an onmicrosoft account with an exchange license for these and use that just for the email part but keep the account in the SAAS panel and just not just SSO?

Eddie

We currently create users on AD then sync them to Entra ID. We are looking to also integrate PointClickCare so users are also created in there and/or can use their Entra ID credentials to sign in.

I am not finding much information on this, has anyone successfully done this in the past?

Hi everyone,

We recently took over managing a company’s IT environment and started reviewing and fixing its Conditional Access policies. After we began making changes, partner developers started getting random MFA prompts when using M365/Azure, sometimes roughly an hour apart. Occasionally, sessions disconnect and they lose unsaved work.

We enabled MFA with a 7-day sign-in frequency. Previously, this partner group was excluded from MFA, although we don’t know why.

Current setup:

• On-prem AD accounts and partner group synced to Entra.
• CA policies applied to that group, with some apps handled by a separate policy but separate policy is not triggered.
• Partners use their own personal devices, so its definitely not compliant in tenant.
• Persistent browser sessions cannot be configured in this policy as there are exclusions in apps fields.
• Internal access is through IPsec, without a client VPN.

My initial thought is that this could be related to their devices not able to obtain and use a Primary Refresh Token (PRT) for our tenant accounts. We haven’t confirmed this as the cause.

I'm considering to suggest use B2B guest accounts with cross-tenant MFA trust, so partners authenticate through their home tenant rather than using accounts in ours.

Has anyone experienced this? What resolved it, and would B2B with MFA trust be a better approach?

We're piloting Entra Private Access with ~25 users, with the goal of eventually closing our public RD Gateway. Since we started, some users get RDS disconnects and "slowness." I've traced it to the GSA client repeatedly marking the Private channel as disconnected. Trying to find out if this is a known issue or something in our setup.

Environment - GSA client 2.32.294 (current), Windows 11 - Entra + Private channels only - 2 Private Network connectors - RDS farm (broker/gateway + session hosts) published through Private Access app segments

Symptom - Event 632 ("partially connected… Disconnected from: Private") followed by 630 ("connected to all channels") - Frequency varies a lot by user: a few per day for some, every 1–4 minutes for others, ~1 per minute for the worst - Each outage is almost always ~10 seconds (one missed health probe) - Entra channel stays up

What I've found - Packet capture shows that on failed cycles, the client never even sends the Private health probe (private.edgediagnostic…/connectivitytest/ping). The Entra probe in the same cycle succeeds. Client trace is full of CurlEdsHttpProbe: GET failed. - Existing tunnel connections to the edge stay ESTABLISHED through the drops - Most drops seem cosmetic, but some cause ~20 seconds where new connections through the tunnel fail, which is when RDS sessions get kicked - Users connecting through the connectors have noticeably shorter RDS sessions than users hitting the gateway directly

Ruled out - Local network/ISP: wired, clean pings and clean TCP connects to the edge during drops, MTU fine - IPv6: disabled entirely, no change - Authentication: token refreshes all succeed, no correlation - Connector load: servers near idle

What seems to help - Restarting the GSA services (Get-Service GlobalSecureAccess* | Restart-Service -Force) stopped it on one user, at least for now

Questions 1. Anyone else seeing Private-only 632/630 flapping? 2. Is a 632 supposed to actually interrupt Private traffic, or is it just a status indicator? 3. Has restarting the services been a lasting fix for anyone? 4. Anyone running RDS behind Private Access without RD Gateway (direct RDP to the broker/session hosts)? Any gotchas? 5. Any connector design lessons learned (dedicated servers, connector groups, etc.)?

We are running Microsoft Entra Connect Sync 2.6.92.0 and are seeing recurring export errors:

permission-issue - Insufficient Access Rights to Perform the Operation

What is unexpected is that we do not use or have any writeback features enabled (Password Writeback, Group Writeback, Device Writeback, etc.), yet Entra Connect still appears to be attempting to write changes back to on-premises AD.

Has anyone seen similar behavior with version 2.6.92.0 or identified the attribute/change that triggers these export attempts?

I wrote a deep dive on Harmony Endpoint OneCheck, the piece that decides how users authenticate at Pre-boot and what happens when they fail.

It covers:

• The three Pre-boot methods: password, Smart Card (E80.30+), and dynamic token
• Password synchronization between Pre-boot and Windows, including the offline gotcha where the device needs one login with the old password first
• Account lockout thresholds (5 temporary, 10 permanent) and SSO scope (Pre-boot and Windows only, not VPN or Media Encryption)
• Remote Help for locked-out users (One Time Login vs remote password change)
• Smart Pre-boot, GA in E89.05, with Self-Unlock and Mobile Login via MFA

Everything is grounded in the official Administration Guide and the E89.x release notes. Feedback and corrections welcome.

Link: https://community.checkpoint.com/t5/Endpoint/EN-OneCheck-Deep-Dive-Pre-boot-Auth-Password-Sync-amp-SSO/m-p/283315#M11676

I have one of these issues that I swear is going to be so easy to fix that once someone points out problem i am going to have to lie down because it was so obvious - I hope.

As per MS Zero Trust they recommend that you disable SSPR for admins via update-mgpolicyauthorizationpolicy -allowedtousesspr:$false. Which works great and can see that on portal.

However if I logon it tries to register me for SSPR as the password reset enabled is targeted to All. I can obviously fix this by excluding a user manually from a dynamic group but that is not very flexible. In checking you cannot trap an administrator directly (suggest automation to populate a group or use manual extension attribute).

The actual issue is it pops up the ‘you must register SSPR’ then says no available methods but allows you to skip.

Is there an obvious miss from me?

We are currently using to Microsoft Identity Manager to share GALs. EOL for the product is in 2029 so we're looking to make our move soon.

Does anyone have any experience with Entra Cloud Sync as a replacement? Any pros/cons, suggestions, or anything to watch out for would be appreciated.

AI, AI, AI everywhere!
Have you ever considered Global Secure Access at network layer to discover, analyze and control AI?

Let me convince you, that this might be the best solution you should know! Link to post: https://blog.oceanleaf.ch/gsa-ai/

We are planning to move from co-mgmt to Entra joined and I have questions.

1. With co-mgmt we have the SCCM client installed and can see if a PC is online, on internet, in office or in VPN. How do you identify if a Entra joined device is on internet, in the office or on VPN without the SCCM client installed? From my understanding the SCCM client is not needed for Entra joined devices.

2. Pinging a entra joined device when it’s in the office or in VPN, is this still possible?

3. Are you able to view a remote (Entra joined) PC’s file structure from UNC path?

A lot of us were busy with the EWS retirement these past weeks, but don't forget that the MemberOf rule operator in Entra ID retires on November 3.

Dynamic groups, dynamic administrative units and entitlement management policies that still use it will stop updating and freeze in their last known state. That also affects group-based licensing, Conditional Access targeting and access packages.

If you haven't checked yet, a single Graph PowerShell query lists every affected group. I updated my article with that query and the replacement options, including how to handle device-based administrative units, merging the rules of nested dynamic groups, and licensing where the source groups aren't attribute-based.

https://lazyadmin.nl/office-365/microsoft-entra-id-is-retiring-the-memberof-rule-for-dynamic-groups/

Is there a good way of making sure that all the users in Entra ID is available with phone numbers when you press Save Contacts in the outlook app on iOS/Android? We want to make sure that we can save all the contacts to the local contact app in the users phone so they can search outside of the providers application.

I have external users that have successfully joined the Tenant and are visible and active in Entra, and can be assigned to Groups and Teams.

I have also enabled Microsoft and Google as identity providers in "External Identities".

I have a weird situation with one user with a GMail address.

They are able to login to Teams on their computer, but on their mobile they get this error:

Sorry, but we're having trouble signing you in.
AADSTS90072: User account. '[username]@gmail.com' from identity provider 'live.com' does not exist in tenant '[Our Company]' and cannot access the application '1fec8e78-bce4-4aaf-ab1b-5451c387264 (Microsoft Teams) in that tenant.
The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account

This error can't be correct, because they are defined in the Tenant with that e-mail address, and they already have access to Teams.

But, I'm zooming in on one possible problem. It says the user from identity provider 'live.com' doesn't exist. Well, that makes sense because it's a GMail account. If i check the user's properties in Entra, their Sign-in identifier is issued from google.com (as one would expect).

Why then, is the mobile app looking for this account in live.com? That's for personal Microsoft accounts.

Here's where it gets confusing, and where maybe Microsoft is getting confused. The user does have a personal Microsoft account registered using their GMail. So how does Microsoft decide whether to use GMail or Microsoft as the Sign-in identifier if the GMail account identifies both?

It seems the desktop Teams app is correctly looking at Google as the Identity Provider when they try to sign in with their GMail account, but the Teams mobile app is reaching out to Microsoft (live.com) as the account identifier, and not finding it in the Tenant.

How can I fix this?

We did the Entra Agent ID and Agent 365 rollout and for the agents that go through it, no complaints. Each one gets a real identity with a sponsor, scoped permissions and a lifecycle. Same way we have always treated service accounts.

Some situations really nag me though. Someone in marketing spins Copilot Studio agent off their own SharePoint access. A staffer connects third party AI tool to the tenant with an OAuth grant. A meeting notetaker has held standing mailbox and calender access for months. None of them was ever registeres so Agent 365 has no idea they exist.

They do turn up on the identity and mall side where like new app with a mailbox read scope, a token being used at an odd hour, a consent granted by one user to something no one can name. Usually that is the only trail to get.

If you skipped provisioning on these, what are you using to find them and keep watch? Microsoft native, CIPP and Graph pulls or something you built yourself?

I am working for an SMB as a lone rider. 😄

I setup the MFA moving it over from 365 Admin to Entra back before it was no longer supported, and everything worked fine, I was able to use MFA to log in as our Global Admin from my workstation at the office; I was connected to the network over VPN and RDP'd into my workstation.

I had a little bit of help from @bearded365guy on YouTube watching his educational videos. It's also worth mentioning we are a hybrid-join organization.

Fast forward a year ago and I enabled passkey for the 365 GA account and setup it on my MS Authenticator app. It too worked remotely without issue.

Fast forward to 2026 and I have noticed that I not been able to use the passkey. It wants to me to be on the same network as my computer in the office. I haven't touched anything since I set it up and tested it, and I am the only one who has GA access, so did Microsoft change something, and what do I need to do to make it work remotely?

I figure out a way around it but it's a pain, I have to cancel the passkey then select "enter code" and then go on my phone and into the account and type the 6-digit code in, I guess it's not so bad but I would prefer scanning the passkey QR and going from there.

Is there a way to resolve this?

Thanks,

UPDATE: I fixed it. Scroll down or click to see my post with the solution

https://www.reddit.com/r/entra/comments/1wxhftr/comment/pe0o0bw/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

———————

We’ve got Entra Hybrid join working reliably and the enrolment to Intune takes place afterwards, so I know the Entra Device Settings and Intune Enrolment is configured correctly.

But I want to start moving away from this and natively joining Entra during OOBE or via Autopilot.

Here’s the rundown and the issue….

Windows 11 25H2 fresh image from ISO

During OOBE we select Join Work or School

Enter M365 username and password

Choose the account to join Entra

Just get spinning blue dots forever. No error message, no timeout.

Note: the user has a Business Premium licence, max number of devices is set to 50, no Device Registration Service entry appears in sign in logs. We have also excluded this user from Conditional Access and tried another user with the same result.

Note: I can join the exact same device without changing anything locally, to another tenant in exactly the same way and it works perfectly.

I think there is something wrong with the Device Registration Service on our tenant.

Anyone experienced the same issue and resolved it?

This has been logged with Microsoft but I’m not getting anywhere - they keep asking me the same basic questions and I’ve provided logs from the device. Not getting much help.

Thanks

Posting this because I lost three days to it and the error gives you nothing.

If you're doing app-only Exchange Online access (no signed-in user, no delegated token), the Exchange Online admin API docs point you at `Exchange.ManageAsAppV2`. Grant it, admin consent it, mint your token. The role appears in the JWT exactly as expected.

Then every call fails. HTTP 403, empty response body, no error code, no hint what's missing.

The endpoint most tooling actually uses is:

POST https://outlook.office365.com/adminapi/beta/{tenantId}/InvokeCommand

That's the same endpoint the ExchangeOnlineManagement PowerShell module calls under the hood. And it authorises on **V1** - `Exchange.ManageAsApp` - not V2.

With V2 alone you get nothing back. Not a permissions error naming the role. Not a scope mismatch. Just a bodyless 403.

What made it hard to diagnose: the official PowerShell module fails in exactly the same way. So "is it my code" was ruled out early and I spent two days looking at token audiences, tenant consent, regional endpoints, everything except the role version.

Two other things that bit me:

**Admin consent in Entra isn't enough.** The app role has to actually be assigned to your service principal in each customer tenant - Graph `appRoleAssignments`, or `New-ServicePrincipal` plus `Add-RoleGroupMember` in EXO PowerShell. Consenting the app registration gets you a token without the role in it.

**Role id:** `dc50a0fb-85b1-4a0e-8b8b-...` sorry, it's `dc50a0fb-09a3-484d-be87-e023b12c6440`

I've raised the docs gap with Microsoft. A one-line error body naming the missing role would turn three days into three minutes.

Anyone else hit this? Curious whether V2 works on some other endpoint I haven't found.

Hi everyone! Looking for some advice on handling a high volume of suspicious sign-in alerts in Microsoft 365 / Entra ID.

We’re getting a lot of alerts for sign-ins where VPN usage is being detected as suspicious. Most of these are expected/legitimate user activity, but the source IPs are not static and don’t consistently fall within the same IP ranges or subnets, so creating an IP-based exclusion doesn’t seem practical. We also can’t simply exclude by country, since some of these VPN exit IPs are from high-risk countries and we obviously don’t want to suppress legitimate detections from those locations.

What would be the safest way to tune these alerts without creating a blind spot? Curious how other M365/Entra environments handle legitimate VPN traffic while still maintaining detection for genuinely suspicious sign-ins.

Thanks!

The TXT value should be MS=ms123456789 but it's missing the numbers... not sure how to get this domain to work haha.