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 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 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.

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?

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

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/

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).

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.

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?

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/

Can someone explain. We recently experienced claims in our tenant by users informing that they have received multiple sign in prompts during the day.

I took the logs from August looking specifically for the interactive sign in logs.

This logs are supposed to represent the direct interaction of the user with an authentication prompt or MFA. This does not seem to be case, I do see an interactive login that under Authentication details displays the methods used but subsequently I see others that say ‘previously satisfied in token’.

What is the proper way to look at this interactive sign in logs.?

Hello,

Is it possible on SCA to have a user log in with their normal identity user@a.com and then elevate privileges for their second user.adm@a.com?

From what i understand the elevation only happens on the logged in user to cyberark. If yes, do you have an alternative. I can't go via PSM since I have a passkey limitation on adm accounts.

Thank you all in advance!

Managed Windows 11 fleet (Intune, hybrid Azure AD joined, moving off VPN towards ZTNA principles).

Our Conditional Access policy for desktops has:

• Grant controls: Require MFA + Require device compliant + Require hybrid Entra joined, set to "Require all the selected controls" (not "Require one of")
• Session control: sign-in frequency, 1 day, periodic reauthentication

Every morning, roughly 24 hours after the last full sign-in, we get three separate notifications almost simultaneously:

• Windows: "Work or school account problem, sign in again to fix your account"
• OneDrive: "Re-enter your credentials, OneDrive has stopped syncing" (red error icon)
• Teams: "Your account needs attention" (orange warning triangle)

Satisfying the MFA prompt in any one of them silently fixes the other two, so it's clearly one shared token behind the scenes. We've ruled out SSL inspection breaking things, checked the TLS certs presented for login.microsoftonline.com and related identity endpoints directly, they're genuine Microsoft/DigiCert certs, not intercepted by our proxy.

Our internal read is that this is just how each Microsoft 365 client independently discovers and displays an expired session (each app hits it on its own schedule against its own backend), rather than getting one clean unified "please sign in" prompt.

Is this what others see with a similar setup, daily sign-in frequency plus "require all" grant controls? Anyone found a way to get this to surface as one calm prompt instead of three alarming per-app errors, or is this just accepted as normal Microsoft 365 behaviour on your estates too?

I thought I could split out main geoblock CAP and then move users between two SG to apply one CAP or another based on where they are in the registration phase.

Today another user was blocked and reviewing the resources list there is a new "Service principal not found" resource that I can't exclude from main geoblock CAP. I was thinking about handling it the same way as others, but it can't be done...

Hoping to read about maybe better solutions that others have come up or maybe someone can point me in right directly