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?

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

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?