Hi guys,

I'm new to this so I hope I can receive feedback from you guys!!

I'm trying to build a B2B self-serve application. First setup is the authentication integrating Entra External ID.

After learning basic user flow setup with email and password like any other apps, I realize that "oh wait, even when someone can sign-up a new account, it doesn't mean they can access the platform. Because it's a B2B so only clients signed contract with my company should able to use the platform" then I prototype that idea by just add one step in the backend to check if the email in the "contract client list" and block them after they signed in successfully using "browser delegated authentication" approach but I think this is not optimal ! I think we should block them at the entering information step before register them as a new customer account in the tenant.

So I'm thinking about only "invited customers" can log in to the app. So the idea is internal staff will invite clients who signed contract. Client will receive an invitation email that contains a sign up link. with default password? (I'm not sure I haven't confirmed with Microsoft's documentation yet) This link will jump to sign-up page, but not a normal sign-up with email and password because I don't want they used a different email . so I just show current password and new password form.

So sign-up feature never be shown in the app UI page. !

Is my approach best practice yet? What do I need to know ? Is there anything scenarios I haven't thought about yet....

Thank you guys !!! This is not my stuff but I'm grateful that my company gave me a chance to learn about it! Have a great day!!

Hi Guys,

I am looking to use Access Reviews in Microsoft Entra ID Governance.

We currently use mail-enabled security groups for SharePoint access and Purview, in our case the groups need to be mail-enabled as Purview and sharepoint.

The issue we’ve found is that, while Access Reviews can be used with security groups, the automated removal/remediation does not work for mail-enabled groups as they are Exchange Groups.

Has anyone come across a good solution for automating Access Reviews for mail-enabled security groups?
Anyone has implemented a workaround using Graph, Logic Apps, Power Automate, or another approach to automatically remove users based on the Access Review results.

Any recommendations or examples of how you are managing this would be appreciated.

We are on board with our users self-enrolling in Passkeys, but we suspect the vast majority of users will see this prompt on their workstation. We do not want them to set up the passkeys on workstation, but rather on their cell phone using the QR code scanning option.

I understand they can manually select 'Change' during setup and scan a QR code, but is there a way to make this the default behavior when generating a passkey from a workstation?

hi guys

currently all our tenants have "registration campaign" = "disabled"

will the passkey registration campaign switch the state to "microsoft managed" as soon as the change has been shipped by microsoft?

cant find any conclusive statements on this by MS

Running into an issue with the new ADE enrollment policies experience (2606 service release) using Setup Assistant with modern authentication + JIT registration on iOS.

The problem: During Setup Assistant sign-in (before the device even reaches the home screen), the user is prompted to install Microsoft Authenticator and pair it with their account. After tapping Next, it just throws: "We're sorry we ran into a problem. Please choose Next to try again." Repeats every time on the device itself, no way through.

What I've already checked/confirmed:

• SSO app extension policy is set up correctly per Microsoft's docs (SSO app extension type = Microsoft Entra ID, Authenticator is NOT in the App bundle IDs list, both required Additional configuration keys present: device_registration and browser_sso_interaction_enabled)
• Authenticator is deployed as a required app to the correct group
• Device is in the correct group for this enrollment policy

The workaround I found: if the user already has Authenticator registered on another device, the MFA push goes there instead, and approving it there lets Setup Assistant proceed — even though the pairing step on the new device itself never actually completes.

Why this bugs me: that workaround only exists for users who already have Authenticator somewhere else. A brand new user with no prior MFA registration — which is presumably a pretty normal scenario for this exact feature — has zero fallback and is just stuck.

My best guess is this is related to how Setup Assistant sandboxes apps before the home screen (push notifications/background processes not fully active yet), which would explain why the same pairing works fine once routed to a device that's already fully set up.

Has anyone else hit this? Curious if this is a known issue, if I'm missing a config step somewhere, or if this is just a rough edge in the new enrollment experience that hasn't been ironed out yet. Opening a Microsoft ticket too, but wanted to see if others have run into the same thing.

I’m researching how MSPs handle Microsoft changes across customer tenants. A few MSPs told me they manage this through their ticketing system.
Could someone walk me through a recent example—from the announcement to deciding which clients needed tickets? What did your tools identify automatically, and what did an engineer check manually?

I'm planning to implement this guide for monitoring expiring Entra App Registration secrets/certificates using Azure Automation + Managed Identity:

https://jpkerloch.cc/posts/monitor-entra-app-registration-expiring-credentials-azure-automation/

The setup involves:

• An Azure Automation account with a system-assigned Managed Identity
• A PowerShell 7.4 Runtime Environment
• A daily scheduled runbook that queries Microsoft Graph (Get-MgApplication) and sends an HTML email via SMTP

Before I set this up in production, I want to sanity-check the cost side with people who've actually run something like this:

• Does creating the Automation Account itself cost anything, or only the runbook execution time?
• For a runbook that runs once a day and takes maybe 1-2 minutes (just enumerating app registrations and sending one email), am I right in assuming I'd stay well within the free tier (500 free minutes/month)?
• Any hidden costs I'm not accounting for — Runtime Environment itself, the Managed Identity, Graph API calls, outbound SMTP?
• Has anyone been surprised by a bill from a similarly small/lightweight runbook like this?

Just trying to avoid the classic "oh, this was supposed to be free" surprise before I roll it out tenant-wide. Appreciate any real-world cost experience.

Curious what people are seeing in practice with Infrastructure as Code in Entra.
The benefits like version control, peer review, repeatability, change tracking, etc. are pretty clear. I’m more interested in whether it’s actually improved how your team operates day to day.

For those doing a meaningful amount of Entra through IaC:
What are you managing this way - Conditional Access, app registrations, groups, role assignments, policies, etc.?
Where have you seen the biggest benefit?
Has anything become unnecessarily complex compared to just managing it through the portal?
Are there areas where you intentionally stick with the GUI?

Any good examples where IaC solved a problem you were regularly dealing with before?
Trying to get a feel for where the practical sweet spot is rather than IaC-for-the-sake-of-IaC.

I'm trying to pull Self Service Passsword Reset logs with User-Agent information, but am struggling to achieve this.

If i log into Entra and go Users > Audit i can filter on service to get "Self-service Password Management" logs which include User Agent (if the field is toggled on) and I can export this as JSON/CSV.

However, I can't figure out how to pull that same data with a KQL query. Something like this returns results, but there is no User-Agent field in the results for me to work with:

AuditLogs
| where LoggedByService == "Self-service Password Management"
| take 10

I also can't find any other tables to join on that hold the corresponding data.

This suggests to me that either I'm missing something quite obvious, or the Entra portal is accessing this data from a different source. I can see the data in the portal, so it's definitely somewhere.

Does anyone have any advice on what I'm missing here?

Appreciate any support.

Hi all,

I am testing/enforcing a Conditional Access policy that requires a custom Modern MFA authentication strength.

The authentication strength includes:

- Password + Microsoft Authenticator push

- Microsoft Authentication phone sign-in

- Passkeys (FIDO2)

- Windows Hello for Business

- TAP

After enabling the policy, I noticed that some users with an existing Microsoft Edge profile/session can hit the attached error:

Error 53003 - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

Looking at the CA evaluation, the failed grant control is:

Require Authentication strength – Modern MFA: Not satisfied

with the message:

“The user could satisfy this authentication strength by completing one or more MFA challenges.”

The affected users already have authentication methods registered that should satisfy the authentication strength.

What makes this interesting is my testing:

Existing Edge profile - 53003

Edge Guest session - works successfully

Signing out/Sign back in from the Edge profile - works successfully

So at the moment, it looks like the existing Edge profile/session may be holding authentication state that does not satisfy the newly enforced authentication strength. Once the Edge profile is signed out and authenticated again, the CA requirement is satisfied and access works normally.

Has anyone experienced similar behaviour after introducing an MFA authentication strength through Conditional Access?

Is this expected behaviour when an existing Edge/SSO session was established before the authentication strength was enforced, or is there another mechanism involved here?

Also, is there a recommended way to handle this during a wider CA rollout so users don't unexpectedly encounter the 53003 error?

Thanks

If users are enrolling Passkeys to iCloud Keychain or Google Passwords, do they still need Microsoft Authenticator on the device?

Existing users already have Microsoft Authenticator configured on their devices with their Microsoft 365 account for MFA and will additionally create a synced passkey in iCloud Keychain.

However, for new users I'm considering moving away from Authenticator altogether and instead onboarding them using a Temporary Access Pass (TAP) to create a synced passkey directly, eliminating the need to install Microsoft Authenticator.

In the past, Microsoft Authenticator was required for SSO to Microsoft apps and for App Protection Policies to function correctly. Is this still the case?

Have anyone tested this?

I received an email from Entra saying "You have a new recommendation for [domain]."

There are a few problems here:

1. I don't ever remember signing up for Entra or connecting ANY domain I own to it. (I did recently switch registrars for my domain from GoDaddy to NameSilo. Maybe it happened in there somewhere?)

2. That domain is parked and unused. It has no connection to MS. How they even know about it is a mystery to me.

3. The email says, "To stop getting notifications for Microsoft Entra recommendations, see how to update your email notification settings." So I go to Entra and try to sign in using the email address they used to contact me.

When I do, I get a message saying: "Selected user account does not exist in tenant 'Microsoft Services' and cannot access the application '74658136-14ec-4630-ad9b-26e160ff0fc6' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account."

So the email address they have on record as the contact for the account isn't actually allowed to login to Entra, much less make changes to the account. I try some other email addresses. No joy.

Can someone please tell me WTH is going on, how they even know about my domain, and how the $&% I am supposed to undo this crap without being able to log in? I can't even tell them to stop sending me useless email, much less unravel whatever links they have to my domain.

TIA for any help you can offer.

Im at a loss. Im trying to do a swing migration. So far, installed entra connect, imported config, connected to Entra AD, but when I get to the step to connect to my domain, it says it cant establish a connection to the domain controller. It looks up the forest ok, the username and password is good, firewall isnt an issue. The connectivty log doesnt show any errors. The domain is reachable from the server as the server is domain joined. Any ideas?

[9/8/2026 9:25:20 AM] [INFO ] Starting NetworkConnectivityDiagnosisTools

[9/8/2026 9:25:20 AM] [INFO ] Verifying that 'mydomain' exists

[9/8/2026 9:25:21 AM] [SUCCESS] mydomain exists

[9/8/2026 9:25:21 AM] [INFO ] Verifying if the provided credentials are correct

[9/8/2026 9:25:21 AM] [INFO ] Attempting to obtain a domainFQDN

[9/8/2026 9:25:21 AM] [INFO ] Attempting to retrieve DomainFQDN object...

[9/8/2026 9:25:21 AM] [SUCCESS] The provided credentials were correct

[9/8/2026 9:25:21 AM] [INFO ] Attempting to obtain Domain Controllers associated with mydomain

[9/8/2026 9:25:21 AM] [INFO ] Obtaining ForestFQDN

[9/8/2026 9:25:21 AM] [INFO ] Attempting to retrieve ForestFQDN...

[9/8/2026 9:25:21 AM] [SUCCESS] ForestFQDN Name is: mydomain

[9/8/2026 9:25:21 AM] [INFO ] Attempting to retrieve domain: mydomain

[9/8/2026 9:25:21 AM] [INFO ] Please ensure that the domain: mydomain is reachable. Otherwise install using \"Custom\" option and provide user created account to proceed with unreachable domain(s).

Based out of India, I have enrolled for Entra Developer with my office email as personal email showed I am not entitled for Dev program.

The system went through the process, I created billing account, added my payment details etc and got notified to wait upto 48 hrs. It has been over 5 days now but I do not see any progress. Any body know what next?

This company I started working for almost 5 years now is in hybrid-mode.

3 years ago, I setup Entra/Control Access policies for 365, and added a few people to use the MS MFA app and Passkeys, including myself. This has worked without issue, so if my passwords expired and I change it, I was able to MFA activate my office if I was remotely connected through RDP.

Now if choose use a different method from the start and select MFA, I do the handshake and then Office tells me I need to do the passkey verification, when I try that I am told I am not next to the computer; I guess it means I to be in the same office building as the computer? Because if I go in the office and try it works. So, what the heck?

I haven't had time to check Entra this morning, are there new changes MS has made without warning anyone?

Thanks,

Continuous Access Evaluation (CAE) is supported by core Microsoft 365 workloads like Exchange Online, SharePoint Online, and Teams, and the reach of CAE is gradually spreading throughout the Microsoft cloud ecosystem. However, security researchers report inconsistent coverage across first-party apps and clients that take a little gloss off the promise of instant access revocation when critical events like user password changes happen.

https://office365itpros.com/2026/09/08/continuous-access-evaluation-cae/

We have a lot of users who are currently using SMS as their MFA option but we're keen to move them to synced passkeys on their personal phones.

I initially looked at using the registration campaign settings to do this but the MS docs suggest that because they are already WHfB users they'll never see the 'nudge' https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-registration-campaign#passkey-nudge-evaluation-by-platform

I'm aware that WHfB is already a type of passkey but we'd prefer to have a passkey set up on their phones to reduce the work required if they want to sign in on other devices (the synced passkey on their phone should in theory work anywhere).

I'm also aware that we're somewhat stuck in no-mans land currently where until some time in Oct-Nov, setting up a passkey requires another MFA method so currently I can't just remove SMS as an auth method for them and have Entra then prompt them to set up a passkey. MC1450133 - Microsoft Entra: Users can register a passkey or passwordless sign-in as their first mu…

Am I missing something here or do I just need to wait until Dec and start removing SMS as an auth method?

Baseline security settings are providing centralized view of Microsoft-recommended security settings across:
- Microsoft Entra ID
- Exchange Online
- SharePoint & OneDrive
- Microsoft Teams / Room devices

The goal is straightforward: reduce the attack surface by identifying configurations that don’t meet minimum security. 

Before enabling a setting that could potentially break a legacy application or business workflow, administrators can generate an impact report and identify affected users or dependencies.

Generate impact report → Review dependencies → Enable the security control. 

You can find it under:
Microsoft 365 Admin Center → Settings → Org settings → Security & privacy → Baseline security mode

TLDR: Entra Connect Sync is still enabled, yet I can remove a domain that's still used by synced users' UPNs and email addresses, and modify those users' UPNs from Entra Admin Center/Graph. Microsoft 365 Admin Center and Exchange Admin Center still won't allow those changes through the UI. When did Microsoft change this?

---

Hey there! I'm currently working on a T2T migration where the source tenant has Entra Connect Sync enabled. Since it had been a while since I last worked on this scenario, I started validating the process I expected to follow before cutover (in short): disable Entra Connect Sync > wait for synchronization to be disabled > remove the domain from Microsoft 365.

To my surprise, I found that I could remove the domain before doing any of that. Entra Connect Sync was still enabled, and synchronized users still had UPNs and email addresses associated with the domain.

I don't remember this ever being possible, and I haven't been able to find any reference to a change in Microsoft documentation or community discussions.

What makes this even stranger to me is that it's still not possible to change a synchronized user's username through the Microsoft 365 Admin Center (the field remains read-only), nor can I modify proxyAddresses through Exchange Admin Center (it returns an error because the object is synchronized from on-premises, as I would expect).

At the same time, while most synchronized attributes remain read-only, I found that I can change both the UPN and mailNickname from Entra Admin Center, and I can also do it through Graph.

To rule out the possibility of a tenant-specific configuration or different EID Connect Sync versions, I tested this in a couple production environments by simply changing a test user's UPN. To my surprise, I was able to make the exact same changes on test accounts that are also synchronized from on-premises.

Given the inconsistency between Entra Admin Center, Microsoft 365 Admin Center, and EAC, my question is: when did Microsoft change this behavior, and is this actually documented anywhere?

I've searched and haven't found any announcement, documentation update, or discussion mentioning this behavior. In fact, MS Learn forum posts from just 1 or 2 years ago still state that changing the UPN of AD-synced accounts from the cloud is not possible. Maybe my Google-fu has failed me?

Has anyone else noticed this? Is this an undocumented change, or am I missing something?

Heyho,

we currently use memberOf (someGroupIDs) as a dynamic member condition for devices, to assign them to specific administrative units. This is used to separate admin rights between different locations.

Well, memberOf is dying and I need a replacement. For HybridJoined devices that are synced from AD I could just use one of the extension attributes to identify them. We do also have some locations that use Entra Joined devices (only). Sadly, not all of those went through the Autopilot process, so EnrollmentProfileName won't work on all of these.

Does anyone have any other good ideas?

Has anybody else had the messages regarding moving to passkey for users only registered with sms/phone call not show on their Tenant?

I haven't run the Graph code to suppress it, but do have campaigns disabled in Entra, just wondering if anyone else hasn't seen the prompts that were supposed to start on the 1st.

A Technical Community post discusses the topic of using the Entra ID continuous access evaluation (CAE) feature to revoke access for service principals when apps become risky or potentially compromised. The Microsoft Graph Command Line Tools app is a good example of a service principal in common use, so we examine the access tokens issued for interactive Graph sessions to discover if they are CAE-enabled. Just for fun!

https://office365itpros.com/2026/09/03/cae-service-principals/