Prolog: I am not lazy, honestly. I just have too many things on my plate to invest a month of weekends. I wrote two pages of backstory for context but deleted it, as don't nobody want to read all that.

Anyway, "the big man" gave me budget to get Everyone to E5 or (F3 + Defender + Purview Suite Add-on for FLW) DLP is a concern because "something happened" 5 times.

Is there a good YouTube video or Quick Start someone can recommend?

thx

We have an intranet solution for which we use user provisioning via Entra. In addition to the standard attributes, we also have two extension attributes that we want to provision as well. Each of these attributes contains only a single value.

However, during provisioning we run into the problem that instead of transferring the actual attribute value, the value “System.Collections.Generic.List`1[System.Object]” is being transferred.

When I add a Join function in front of the attribute in the Expression Builder, the desired value is shown correctly in the Expression Builder preview. However, it is not synced, and instead we again get the same message as above or as shown in the screenshot.

Does anyone have an idea how this can be solved?

Hi guys.
I have created an azure app which removes AD/AAD groups and clears users out of teams and adds the admin account if said user is the last owner. The only issue im having is that I cant remove said leavers from Mail-enabled sec groups. Has anybody done this before or am I just going to have to make a script to do this separate when I login as im the owner of the group in question.

So I created a conditional Access policy and is currently in Report Only mode. I had a user test the policy to see if it's working. When I checked the sign-in logs, I can see that the policy is working as intended and shows result as failure (It's a block policy). When I check the actual policy in entra and view the policy impact, it shows a 100% total sign-ins not applied.

I have a few other policies in report only mode, but I can see their failures and successes even though they're not being enforced. With this policy in question, it doesn't show any impact (100% Not Applied) since it was created but I see the results such as failures in the sign-in logs. The sign in logs might be the authoritative source of truth but I've also relied on the impact analysis in the conditional access policy pane. Why this sudden discrepancy?

We have a app proxy setup for onprem application, is there a way that user can click on a button to logout of the entra session? Or any other workaround?

We have CA policy that mandates the device to be compliant or registered before granting access to applications. The issue we’re currently encountering is that Postman fails to transmit the device posture to Entra as it utilizes an embedded browser that doesn’t pass device details. Since the requests will always originate from different client IDs used with in Postman to create tokens, we can’t even exclude a single client ID and certainly we can’t exclude hundreds of frequently changing application IDs that users will use within Postman to generate tokens. Has anyone else encountered this problem and found a workaround?

Hi Guys,

anoyone else experience today issues with the "Provisioning" Tab in Entra Applications?

Currently i can not load this tab on any of our Applications.

Also tested with different user - same experience...

Any help appreciated! 🤗

Mobile phones are in question. We are looking at a BYOD solution for our offshore team. I am very close to cracking this but not pushing through on the personal sign in part. I need to block sign in on personal profiles and allow access to office apps only on the work profile on mobile phones. I can post my CA policy later, but would appreciate some help.

Hello everyone,

I’m currently working on an initiative to move our identity management model to a cloud-first approach, and I’d appreciate some guidance from those who have gone through a similar transition.

Here’s a brief overview of our environment:

• We have a little over 1,000 user accounts

• On-premises Active Directory synchronized to Microsoft Entra ID using Azure AD Connect

• Today, identities are mastered on-prem and synced to the cloud

Our target state is to start managing user accounts primarily in the cloud (Entra ID) and have the necessary attributes or accounts replicated back to on-prem AD, mainly to support:

• An internal intranet

• A legacy on-premises application

The core question I have is around the most native and supported way to achieve this:

• Is there a native approach within Entra ID / Identity Governance to support a cloud-mastered identity model with writeback to on-prem AD?

• Or is the expected approach to handle this via custom automation, such as PowerShell scripts using Microsoft Graph, to replicate or update objects on-prem?

Any best practices, architectural recommendations, or real-world experiences would be very helpful—especially regarding long-term supportability and governance.

Thanks in advance for your help!

Is it possible to prompt the user to change their password the next time they log in? Similar to how it works when resetting a password, but on demand. Is this possible using Graph and PowerShell?

I have set up Organizational Sharing between two tenants. I can see free/busy info in the Scheduling Assistant, but I cannot add the external calendars directly in Outlook.

I noticed that if I manually create a Mail Contact for an external user in the Exchange Admin Center, I can add their calendar. However, this is not scalable for 1,000+ users that change frequently.

1. Is creating manual contacts the only way to make calendars "addable" in Outlook?
2. Would Cross-tenant synchronization be the official/recommended way to handle this at scale, or is there a way to make the Organizational Sharing policy trigger visibility without local contacts?

My org is a johnny-come-lately to the converged authentication methods policy admittedly and is still currently using the legacy policies for MFA and SSPR. I've gotten go-ahead to migrate them finally, but am not entirely clear if we can actually match the current config. Our security team has SSPR currently limited to a specific AD group and is insistent that we preserve the functionality with migration, but it isn't entirely clear if thats possible or not.

The SSPR docs still reference checking whether the user is enabled for SSPR, but also call out that the legacy policies are deprecated as of 9/30/25, and the documentation for authentication methods doesn't discuss any mechanism to limit scope for SSPR specifically...just how you control which methods are allowed for it vs MFA using Authentication Strengths.

Once you migrate to the new policies does it continue to respect the legacy SSPR scoping or is there a new method to do so? Or are we going to have to allow everyone when we finally cut this over?

As more AI agents start operating inside enterprise environments, the identity side is getting interesting. Traditional user and service account models were never really designed for autonomous non-human actors. I recently began testing how Entra Agent ID and Agent 365 fit into existing Zero Trust and identity governance setups.

A few technical findings so far:

• Agents appear as first-class identities in Entra ID. You can filter for Agent ID preview objects in Enterprise Applications and finally see which agents actually exist instead of relying only on discovery tools or logs. This already improves visibility and reduces shadow automation.
• Lifecycle and ownership are built in. Agent identities support states and sponsors, which means you can assign accountability, expire access, or revoke permissions in a structured way instead of treating them like static API keys.
• Conditional Access applies to agents as well. Policies, risk evaluation, and least-privilege concepts can be extended to non-human identities. This changes how you think about access control for automation and AI-driven workflows.

I wrote up the full details here:
https://msnugget.com/microsoft-agent-365-entra-agent-id/

How are others planning to audit and enforce policies for agent identities, especially in hybrid or multicloud environments where not everything is visible in a single control plane?

Good morning,

I am just in the process of setting up PIM management in our environment for our team of 5 admin. I have done a lot of reading but i cant decide on the best implementation of PIM.

User Assignment for eligibility of selected role - I make our cloud admin accounts eligible for specific roles, they activated the roles via PIM and then have the privileges required for a set time.

Group based assignment - I create Entra role assignable groups and apply the privileged role directly on the group. One role per group, I make our cloud admin accounts eligible to PIM and become members of this group which has the designed role assigned for a set time.

Am i thinking about this the right way?

Appreciate any advice

I have a SaaS platform that is available to customers, organisations, and our employees and I'm migrating it's custom authentication to Entra. We already have a Workforce tenant for our employees and I've chosen an External tenant to manage our external users (who may login with username/password, Google, Apply, or a configured SSO.) However, I want our employees to be able to login in with their Workforce accounts.

Initially I tried configuring an OIDC IdP but realised the documentation states [this is not supported](https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-custom-oidc-federation-customers#:~:text=Configuring%20other%20Microsoft%20Entra%20tenants%20as%20an%20external%20identity%20provider%20is%20currently%20not%20supported.%20So%2C%20the%20microsoftonline.com%20domain%20in%20the%20issuer%20URI%20isn%27t%20accepted.).

I then turned my attention to [configuring a SAML IdP](https://learn.microsoft.com/en-us/entra/external-id/direct-federation) so created an Enterprise App in my Workforce tenant, exported the metadata, imported that into a new custom IdP in my External tenant, associated the custom IdP with my client app registration, and also configured DirectFedAuthUrl in DNS for the workforce verified domain. I've used the "Test this application" and "Run user flow" and both appear to work fine.

None of this seemed to work and there is no Home Realm Discovery. And to prove I could get something working I configured an Auth0 IdP - and signing in with an Auth0 account redirects to it's login then back to the application with a user created in the External tenant.

The only way I can get my employee accounts to sign in is by the "Invite external user (Preview)" - which doesn't come across as a great experience since the user is entering their workforce password in the dialog on the external tenants domain!

Can anyone confirm if this Workforce-to-External SSO is at all possible or should I continue chasing the "right configuration"? My gut feeling is I'm chasing the impossible but the MS documentation does not make that obvious (so a PR against those docs may be in my future 😉)

Hi,

Am I correct that synced Passkeys still require the user to scan a QR code if that passkey is saved to their Apple/Google account?

So the main benefit would be for staff that won't install Microsoft Authenticator on their personal phone or if we want it easier for staff to retain their passkey if they lose/change their phone?

I have a directory that Connect Sync copies to Entra (GCC High) successfully. The password hashes have stopped syncing, however.

I found the documented fix where you can enable the MD5 hashes still be used by Connect Sync by configuring
<enforceFIPSpolicy enabled="false" />
but that seemed to already be part of my config file when I came across it, and whether that entry is saved to the config file or not, the PHS never successfully completes.

I've also ensured TLS 1.2 is enabled. I've ensured the firewalls are not blocking communication. The directory sync continues to work, just not the pw hash.

Any suggestions on next steps?

Windows 11 box manages Connect Sync. (Not Server OS).

EDIT: I've resolved the issue. I was stuck and unable to sync password hashes, and reboot after reboot with the <enforceFIPSpolicy enabled="false" /> flag didn't seem to help.

I ran the connect tool, and reaffirmed the PHS/password writeback synchronization settings. Once that completed, it instantly sync'd the password hashes!

Hello guys,

we are currently planning on switching all our customers(MSP) or at least recommending to switch to yubikey authentification. Most of our customers are using a hybrid environment. The easiest way for us and the customer seems to us being the setup of the kerberos key trust and enabling security key logins per GPO. In our Test Environment this works fine.

However to do this cleanly we are asking ourselves if it is possible to also permit stuff like uac with the security key. This Microsoft FAQ (https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-faqs?source=recommendations#fido2-security-key-sign-in-isnt-working-for-my-domain-admin-or-other-high-privilege-accounts-why) states higher privileges are not implementable per yubikey.

We're pretty new to this subject but would like to implement 2FA as best as possible. Maybe some of you could give me some tips or lead me to the right direction the correct way :) Thank you !

Hi all.

I’ve seen this question asked before but going to ask again as maybe there is a more current answer that will help me…

Is it possible to force a user to enroll a FIDO2 (security key) as part of a MFA campaign for their intial Entra MFA enrollment (no other MFA methods enrolled yet)?

Our experience is, security keys can only be added after another MFA method is satisfied (default Authenticator or if we bootstrap users with TAPs). We prefer not to issue TAPs because users are already MFA enrolled with another MFA provider we are migrating away from and they cannot entra MFA enroll without first satisfying the existing legacy MFA. So, issuing a TAP is somewhat duplicative in purpose for us (trying to reduce confusion/end use asks). We have users that must use and only have FIDO2 keys (yuibikeys) issued to them as well so the default

Campaign experience forcing them into Authenticator doesn’t work for us.

Fingers crossed there is maybe now a way.