Microsoft Entra topics

Verifying domain name issue

I-Leadership — Tue, 28 Jul 2026 11:34:53 GMT

We're trying to verify our custom domain in Entra ID, but it turns out the domain is already claimed on another tenant that we have no access to (unknown account, no admin credentials). Because of that, verification on our own tenant fails.

Normally the fix for a claimed-domain conflict is to open a support request so Microsoft can help release it. The problem: doing that requires a support plan, and purchasing one doesn't work for us. "payment" always succeeds and we dont get an error, but we don't get charged and the account status doesn't change, we have nothing more to go on.

So we're stuck in a loop: we need support to release the domain, but we can't buy the support plan needed to reach support.

Has anyone dealt with a domain claimed on an inaccessible tenant? And is there another route to Microsoft support when the support plan purchase itself fails?

Best practices: Open OneDrive/SharePoint sharing but restrict Teams guest access by domain

Bejhan — Fri, 24 Jul 2026 05:49:11 GMT

Hi all,

Since SharePoint Online and OneDrive moved fully to Microsoft Entra B2B for external sharing, we've run into a policy conflict and would like to hear how others are handling it.

Our requirements

Enable OneDrive and SharePoint file sharing with external users, regardless of their email domain.
Restrict Microsoft Teams guest access to a predefined list of approved partner domains.
Continue allowing Teams external access (federated chat and meetings) for all domains.

The problem:

Teams guests, SharePoint guests, and OneDrive guests are now governed by the same Microsoft Entra B2B invitation framework and the single Collaboration restrictions allow/deny list under:
External Identities → External collaboration settings
As a result, restricting guest invitations by domain also restricts OneDrive and SharePoint sharing for domains not on the allowlist.
According to Microsoft's response in the following Q&A, this behavior is currently by design: OneDrive external sharing no longer working with "Allow invitations only to the specified domains" - Microsoft Q&A

Questions to the community

Has anyone implemented a solution where OneDrive/SharePoint sharing remains open to all domains while Teams guest access is restricted to approved domains only?
Are there recommended approaches using Entitlement Management, Access Packages, Connected Organizations, or other Entra capabilities?
Is there any roadmap item for workload-specific collaboration restrictions (e.g., separate policies for Teams guest invitations and SharePoint/OneDrive sharing)?

Any real-world experience or best practices would be greatly appreciated.

Thanks,

Bejhan

Is system-preferred first factor overriding Single Sign-On?

RyanSteele-CoV — Fri, 17 Jul 2026 23:02:31 GMT

My colleagues and I have noticed that we've started being prompted to perform a Windows Hello for Business authentication when we use Edge to access web resources that are authenticated with Entra. Previously, this authentication occurred silently through Single Sign-On with the PRT, per Understanding Primary Refresh Token (PRT) in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn.

While investigating what might have caused this change in behavior, I found MC1411574 in the M365 Message Center, which talks about a change to system-preferred authentication that started rolling out in late June 2026, whereby it now applies to the first factor as well as multi-factor authentication. I excluded myself from system-preferred authentication and sure enough, that seems to have restored the previous behavior.

Is it intended that this change to system-preferred authentication will disable SSO, or do we have something misconfigured?

Looking for an on-prem MFA solution for Active Directory and RDP

Grey_ai1 — Wed, 15 Jul 2026 18:07:23 GMT

Hi everyone,

We're reviewing options for adding MFA to our on-premises Active Directory environment.

Most of our users authenticate with Active Directory, while administrators also use RDP for managing Windows servers.

Because part of our infrastructure is isolated from the Internet, we'd prefer an on-premises MFA solution instead of relying on a cloud-only service.

Has anyone implemented something similar recently?

I'm interested in hearing:

Which solution did you choose?
How difficult was the deployment?
Did you run into any compatibility or performance issues?
Is there anything you'd do differently if you were deploying it again?

Any real-world experience or recommendations would be greatly appreciated.

Thanks!

Can the built-in "No account? Create one" link redirect to a custom sign-up page?

Lipikasree — Mon, 13 Jul 2026 10:13:42 GMT

I'm using Microsoft Entra External ID with a built-in sign-in/sign-up user flow.

On the Microsoft-hosted sign-in page, the "No account? Create one" link always redirects users to the default Entra sign-up page.

I already have a custom registration page and would like this built-in link to redirect to my custom URL instead.

Is there any supported way to customize the destination of this link in a built-in user flow? If not, could someone confirm whether this behavior is fixed by design?

Thanks!

Using Cloud sync to sync AD to existing Entra Accounts

tjcooper2 — Thu, 09 Jul 2026 22:32:31 GMT

I want to sync in premise AD accounts with existing Entra accounts. The email on both accounts is the same, and I added the Entra/o365 suffix to the domain and set the UPN to that suffix, making both UPN(s) the same. It did not sync. It created a NEW Entra account. I thought I covered all my bases.

How can I get on premise AD and existing Entra accounts to sync?

thank you

Group-Based Licensing (E3 → Business Premium): MutuallyExclusiveViolation – Months Unresolved

DanielZieb — Wed, 08 Jul 2026 06:32:59 GMT

We operate a Microsoft 365 environment with Entra ID, Intune, and Exchange Online. For months, we have been dealing with a critical issue that remains unresolved to this day — despite an active Microsoft Support ticket.

The Technical Problem:

During the migration of approximately 87 user accounts from Microsoft 365 E3 to Business Premium (SPB) via group-based licensing in Entra ID, all affected accounts receive a MutuallyExclusiveViolation error. Microsoft's backend treats E3 and Business Premium as mutually exclusive, blocking the SPB assignment — despite sufficient licenses being available.

A sequential approach (removing E3 first, then assigning Business Premium) is not an acceptable solution: a test run proved that this causes a complete loss of Exchange Online access. For a rollout across 87 productive user accounts, this is not viable. What is required is a seamless, atomic license swap at the backend level — exclusively via group-based licensing.

The Support Problem:

Two support engineers assigned — zero technical progress.
Instead of a substantive solution, we received standard documentation steps that do not address the actual problem.
A false resolution notice was issued — the issue had demonstrably not been resolved. Our own PowerShell tests (Get-MgUser, Get-MgSubscribedSku) and CSV exports from the Entra ID portal disproved this conclusively.
Committed updates from the Engineering Team were not delivered.
Instead, automatically generated follow-up emails were sent with no substantive relation to the ongoing case.
An additional unexplained behavior: a test user appears in the error report of a license group they were never added to — a further backend inconsistency that has not been investigated.

Current Status:

The ticket has been open for months. 87 user accounts cannot be migrated to Business Premium. An escalation to the Team Manager has been initiated. No resolution is in sight.

My Question to the Community:

Has anyone experienced a similar issue with MutuallyExclusiveViolation in group-based licensing (E3 → Business Premium)? Is there a known workaround or an official Microsoft statement on this?

Ticket Reference: #2604241410000669

Made a self-hosted Entra ID governance portal for app/identity sprawl (open source)

AzAutomationEngineer — Fri, 03 Jul 2026 08:46:42 GMT

Our tenant ended up with hundreds of app registrations and enterprise apps, and the native portal makes you dig through a separate blade for every basic question. Who owns this app? Which secrets die next month? What hasn't been signed into in a year? Which ones have scary Graph permissions? There's no single view for any of it, and half the ownership info was missing anyway.

Entra ID Governance, access reviews, PIM all exist, but they felt heavy (and licensed) for what I actually wanted, which was just a fast list I could scan for routine cleanup.

So I built one. Lightweight portal that runs entirely in your own subscription:

One grid for App Registrations, Enterprise Apps, Managed Identities and Privileged Users
Risk flags per identity: expiring/expired creds, high-risk permissions, no owner, stale sign-in, no CA coverage
Ownership tracking, review and owner-change workflow, CSV export
Tenant health score and a consent posture dashboard
Optional expiry email notifications (needs a SendGrid key)
Reads Graph through a managed identity, so no app secrets for data access and nothing leaves your tenant

Runs about $26-30/month (one B2 App Service plan). B1 is also supported, but it's noticeably slower.

It's not a replacement for Entra ID Governance or PIM, more of a cheap everyday hygiene thing.

Full disclosure, I used AI building this and writing this up. I designed the architecture and functionality, tested it and ran it against my own tenant. It's open source and deployable with Azure DevOps or an Azure CLI script. Data never leaves your own tenant.

Repo (screenshots + setup): Github Repository

Would love feedback, especially what you'd want it to flag that it doesn't, or where the risk scoring feels off. Been building it on and off for a few months with a lot of iteration. Hopefully this could be useful for others as well.

EntraID integration with Biostar 2

SancroNelly — Fri, 26 Jun 2026 12:05:16 GMT

Hi all, I have issue integrate entra ID with biostar. The sync keep fail, anyone have done the integration before? Need advise on the integration steps. Thank you.

Best approach to detect multiple user accounts signing in from the same physical device

RaedSalah — Wed, 01 Jul 2026 09:10:12 GMT

Hi Everyone,

Working on environment: D365 Finance & Operations (cloud).

Goal:
I need to detect when more than one Dynamics user account is being used
from the same physical device, and ideally count how many distinct users
are active on that device. The business reason is this is not permissible to login with more than one account in the same device.

For example:
User X has device D1, User Y has device D2.
User X logged in with his account using Device D2 (which is user's Y device).

I want to know if this happened, cause it's not permissible behavior in the organization.

For more illustration some users have blank devices id when I see Microsoft Entra.

Or if I could find out when a user logs in and integrate it with D365 F&O to store the device the user logged into in a custom log table or anything that tells me that this user account is opened on more than one device or this device has more than one logged-in user account.

Registering user becomes local admin on Joined Devices

gokhantatar — Thu, 25 Jun 2026 20:16:24 GMT

This setting works exactly as named, but the confusion is understandable because the privilege is invisible in the places people normally look.

Per Microsoft's official docs (assign-local-admin): at the moment of Microsoft Entra join, two principals get added to the local administrators group — the Microsoft Entra Joined Device Local Administrator role and the user performing the join. This happens only during the join operation itself. It's not a directory role assignment, so it won't show up in role assignments, audit logs, or under "Device Administrators" — that's by design.

Critically: users aren't directly listed in the local admin group; the privilege is delivered through the Primary Refresh Token (PRT) at sign-in. So:

To validate on the device itself, sign in as the user and run whoami /groups — you should see the device-local Administrators SID.
If you just changed the setting and want to force re-evaluation, run dsregcmd /refreshprt, then sign out and back in (lock/unlock won't trigger it — you need a fresh PRT, which can take up to ~4 hours to propagate otherwise).
This setting only applies to joined devices, not registered (workplace-joined) ones — so your distinction there is correct.

The "Manage Additional local administrators on all Microsoft Entra joined devices" link is a separate, tenant-wide mechanism (the same Device Administrator role) — it can't be scoped to specific devices, which is also worth knowing if you're trying to limit blast radius.

If you want to stop this going forward for new joins without ripping out existing admins, set "Registering user is added as local administrator" to None, and consider a Windows Autopilot profile or Intune Local Users and Groups policy to manage membership going forward — existing devices won't be retroactively changed.

PHS staged rollout works for existing users but not new synced users

mdoraz — Thu, 25 Jun 2026 00:01:42 GMT

We are troubleshooting an Entra ID PHS staged rollout issue with a federated domain using a third-party WS-Fed IdP.

The intended behavior is that normal federated users redirect to the IdP, while users in the PHS staged rollout group receive the Microsoft/Entra password prompt instead.

Existing users in the staged rollout group continue to work correctly. They enter their UPN and receive the Microsoft password prompt. One known-good test user is not provisioned in the third-party IdP and still signs in successfully through the Entra password prompt, so the working path does not require the user to exist in the IdP.

The issue is only with newly created AD-synced users. Newly synced users in the same staged rollout group are still being routed to the federated IdP at HRD instead of receiving the Entra password prompt.

We’ve verified the staged rollout policy and group membership from Graph, confirmed the affected users are properly AD-synced with clean immutableID/sourceAnchor, and confirmed PHS is working. Federation metadata and HRD policies also look clean. Seamless SSO/AZUREADSSOACC was checked and remediated, but the behavior did not change.

For failed attempts, there is no Entra sign-in log entry, including tenant-wide interactive and non-interactive logs. However, the federated IdP logs show a WS-Fed inbound request from login.microsoftonline.com for the affected user. That makes it look like Entra HRD is routing the user to federation before sign-in logging or token issuance.

The issue started around an Entra Connect AD connector/DC-path change. We have since reverted the connector to the previous known-good configuration. After reverting, we created a clean-room test user with the correct UPN set before first sync, confirmed sync/PHS/sourceAnchor, added the user directly to the staged rollout group, and waited 60+ minutes. The clean-room user still redirected to the federated IdP instead of getting the Entra password prompt.

So the current behavior is that established staged-rollout users still get the Entra password prompt, but newly created synced staged-rollout users are sent to the federated IdP by HRD.

Has anyone seen staged rollout get into this state, where existing users work but new synced users remain on the federated HRD path despite valid rollout policy, group membership, synced password hash, and clean immutableID/sourceAnchor? Is there any known backend cache/state reset or escalation path for HRD/staged rollout routing?

TAP requires step-up MFA when user already has a passkey registered — expected behavior?

ivofernandes — Wed, 17 Jun 2026 10:24:00 GMT

Environment

Microsoft 365 Business Premium (Entra ID P1)
Cloud-only tenant
Authentication methods enabled: FIDO2/Passkey only + TAP
All other methods disabled (no Authenticator push, no TOTP, no SMS)

CA Policy configuration

CA001 — Protect Security Info Registration

Target: User action — Register security information
Grant: Custom authentication strength "Bootstrap and Recovery" (TAP one-time + TAP multi-use + Passkey/FIDO2 + WHfB/Platform credential)
Status: On

CA002 — Require Phishing-Resistant Authentication

Target: All cloud apps (excluding Azure Credential Configuration Endpoint and tested also excluding Microsoft App Access Panel)
Grant: Built-in Phishing-resistant MFA
Status: On

What was tested

Scenario 1 — User with no registered methods (only with Platform credential):

Admin issues TAP (multi-use, 4 hours)
User navigates to aka.ms/mysecurityinfo
User authenticates with TAP
Result: Access granted — user can register passkey without any step-up, even in a flow authenticating directly to a resource (such as Microsoft Teams in browser)

Scenario 2 — User with an existing portable passkey already registered (in MS Authenticator):

Admin issues TAP (multi-use, 4 hours)
User navigates to aka.ms/mysecurityinfo
User authenticates with TAP
Result: Entra requests a second factor — specifically the existing passkey — before allowing access to My Security Info. Seems the system enforces CA002 or a platform-level step-up requirement.

The TAP is accepted as a first factor, but the platform then requires the existing passkey as a second factor before proceeding.

Sign-in log analysis: The behavior does not appear in the Conditional Access tab of the sign-in logs as a CA policy failure — it appears to be enforced at the platform level, not by any configured CA policy.

Questions

Is it by design that when a user already has a registered MFA-capable method (passkey), the platform enforces step-up authentication before allowing access to My Security Info — even when the user authenticates with a valid TAP?
If so, does the correct recovery procedure require the admin to first remove all existing authentication methods before issuing a TAP — so the user has no registered methods and the TAP is accepted without step-up?
Is there any way to allow TAP to bypass this step-up requirement for recovery scenarios, without removing existing methods first?

Any pointers to official documentation or confirmed behavior would be appreciated.

Entra ID Governance vs Saviynt for SAP IGA Use Cases

carltonflewis — Wed, 27 May 2026 17:28:07 GMT

Hi everyone,

We are currently evaluating Microsoft Entra ID Governance as a potential replacement for Saviynt for SAP-focused IGA requirements across a mixed SAP landscape, including:

SAP SuccessFactors
SAP Concur
SAP S/4HANA Private Cloud
Other SAP SaaS and enterprise applications

I wanted to get insights from anyone who has implemented or worked extensively with Entra Governance in SAP-centric environments, specifically around the following areas:

1. Birthright RBAC Provisioning

Can Entra Governance provision a single composite/business role (similar to Saviynt Enterprise Roles) through HR-driven JML events?

For example:

HR event triggers provisioning
User automatically receives bundled SAP access/business roles
Role assignment follows birthright/access package logic

How mature/scalable is this approach in Entra compared to Saviynt?

2. SoD (Segregation of Duties) Capabilities

Saviynt supports preventative SoD checks directly during request submission, including SAP-specific SoD analysis.

Questions:

Does Entra Governance support preventative SoD evaluation at request time?
Can conflicts be surfaced before approval/provisioning?
Is there native SAP SoD support or dependency on external tooling (for example SAP GRC/IAG)?

Additionally, Saviynt supports granular SAP authorization object analysis down to field-level min/max values within SAP Private Cloud environments.

Does Entra provide similar depth for SAP authorization analysis?

3. SAP Integrations / Connectors

While Entra provides OOTB Enterprise Applications and provisioning connectors for SAP applications:

What differences or limitations have you observed compared to Saviynt’s SAP connectors?
How well does Entra handle SAP role imports, entitlement hierarchy, and provisioning workflows?
Any known gaps for SAP Private Cloud integrations?

Would appreciate any implementation experiences, architecture guidance, lessons learned, or recommendations from teams who have evaluated or deployed Entra Governance in SAP-heavy environments.

Thanks in advance.

ssoSilent() not working across Next.js apps — timed_out or account picker on localhost

CilansSystem — Thu, 21 May 2026 07:08:45 GMT

Hi everyone,

I've been stuck on this for a few days and would really appreciate some guidance from anyone who has dealt with cross-app silent SSO using MSAL.js v5.

Here's the setup. We have 3 separate Next.js applications all belonging to the same organisation, all registered under a single Azure Entra ID App Registration with the same clientId and tenantId. In production they all live under the same parent domain — app1.contoso.com, app2.contoso.com, app3.contoso.com — so localStorage is shared between them. On localhost we run them on ports 3000, 3001, and 3002.

The goal is simple: if a user is already signed into App 1, opening App 2 in a new tab should silently authenticate them without any popup, redirect, or account picker. Just seamless SSO.

Here is how I've set up the msalConfig:

export const msalConfig: Configuration = {

auth: {

clientId: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',

authority: 'https://login.microsoftonline.com/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy',

redirectUri: 'http://localhost:3001/',

postLogoutRedirectUri: '/login',

cache: {

cacheLocation: 'localStorage',

storeAuthStateInCookie: true,

};

export const loginRequest = {

scopes: ['openid', 'profile', 'email', 'User.Read'],

};

Inside a component called SsoInitializer that sits inside MsalProvider, I scan localStorage for a sibling app's MSAL account on mount. I check both msal.2.account.keys (MSAL v5 format) and msal.account.keys (older format), extract the username/email as a loginHint, and then call ssoSilent(). If no loginHint is found — which is always the case on localhost since different ports are different origins — I still call ssoSilent() without a hint, expecting it to fall back to the Entra session cookie that was set when the user logged into port 3000.

instance.ssoSilent({

...loginRequest,

...(loginHint ? { loginHint } : {}),

redirectUri: `${window.location.origin}/silent-callback.html`,

})

The silent-callback.html in /public is just a blank HTML page with no scripts, which I believe is the correct approach based on the docs since MSAL v5 uses postMessage to communicate with the iframe.

The Azure app registration has the SPA platform selected, all redirect URIs including the /silent-callback.html variants are registered for all three localhost ports, ID tokens are enabled, and User.Read has admin consent.

Now here is the problem.

When App 1 is logged in on localhost:3000 and I open App 2 on localhost:3001, ssoSilent() fires but one of two things happens:

The first failure is a timed_out error — BrowserAuthError: timed_out from BrowserUtils.ts. The server-telemetry key in localStorage shows redirect_bridge_timeout repeated multiple times with cacheHits of 0. This started happening when I had a CDN import of MSAL inside silent-callback.html trying to call handleRedirectPromise(). The CDN download was too slow for the iframe timeout window, so I removed it.

The second failure happens after switching to the blank HTML silent-callback page. The timed_out goes away but now ssoSilent() seems to fall through entirely and the Microsoft "Pick an account" full-page redirect opens — which completely defeats the purpose.

I've also tried passing prompt: 'none' explicitly in the ssoSilent request. No change.

One important observation from DevTools: the Entra session cookie IS present in the browser. The user is fully signed in on port 3000. Based on my understanding of the docs, ssoSilent() without a loginHint should detect this session cookie and authenticate silently. But it's either timing out or showing the account picker.

I have a few specific questions I'm hoping someone can help with:

First, is ssoSilent() actually supposed to work without a loginHint using only the Entra session cookie? Or does it require a hint and will always show the account picker if multiple accounts are signed in to the browser?

Second, what is the correct content of silent-callback.html for MSAL v5 specifically? The blank page causes redirect_bridge_timeout, but adding MSAL scripts causes a different timeout because they load too slowly. Has the iframe handshake mechanism changed between v1/v2 and v5?

Third, is there an officially recommended pattern for cross-app silent SSO when developing on localhost with different ports? In production the same-domain setup handles localStorage sharing fine, but on localhost the browser's same-origin policy makes each port completely isolated, so the sibling token scan always returns null.

Fourth, does the redirectUri passed to ssoSilent() need to point to a page that actively runs MSAL code, or is a blank page genuinely sufficient for the iframe to complete its handshake in v5?

Using azure/msal-browser 5.6.1, azure/msal-react 3.0.20, Next.js 14 App Router, Chrome on Windows 11, single tenant.

Any help or a working example from someone who has done this in MSAL v5 would be hugely appreciated. Thanks in advance.

"Access package assignment manager" role with "Restricted access to Microsoft Entra admin center"

PawelKowalczyk — Thu, 14 May 2026 11:49:27 GMT

Hi,

How can I allow a user with the "Access package assignment manager" role assigned only to a single catalog to manage access package assignments when "Restricted access to Microsoft Entra admin center" is set to Yes?

I do not see any option to manage assignments through the MyAccess portal, so it seems this must be done through the Entra Admin Center. However, the user cannot access the Entra Admin Center because they do not have any Entra administrative roles.

I do not have an Entra ID Governance license, so the option to use on-behalf-of access package assignment requests is not available.

How can this scenario be solved?

Thanks.

'Registering user becomes local admin on Joined Devices' - WHAT

underQualifried — Wed, 22 Apr 2026 20:22:52 GMT

Stumbled on a tenant with 'JOIN' available for all users. Haven't worked with this much - most tenants I see only have registration. But then I noticed the horrifying 'Registering user is added as local administrator on the device during Microsoft Entra join' option was ALSO set to ALL.

This is a tenant we just took on, but I've never seen that control before. This is terrifying, considering AFAIK, there is no real way for a registering user to know if they're registering or joining. Beneath it is an option to 'Manage Additional local administrators on all Microsoft Entra joined devices', which leads to the Role page for Device Administrators, which is empty.

Under Description, this describes what APPEARS to be to be the same thing mentioned in the previous control - 'Users with this role become local machine administrators on all Windows 10 devices that are joined to Microsoft Entra'. But no one is assigned this.

Conveniently, on my own tenant, I happened to let someone JOIN yesterday. We have this limited to 2 (now 3) people - most just register... But this user Joined, and the 'Joining user becomes local admin' option was on ALL. But I can't validate that the user ever become local admin. They don't have the role, their device shows as joined, but there's no additional roles. The audit logs don't look weird. They're not in that 'Device Administrators' group, which describes itself as 'Users with this role become local machine administrators on all Windows 10 devices that are joined to Microsoft Entra'.

Thoughts? Freaking out, honestly. We have a mix of DC and Cloud users. I've inherited them all, and had the understanding that Join was essentially registration but with Org ownership. I've tried to get some input from Copilot, but he has basically waffled between 'No, this setting is just badly named' and 'no, actually it's this other setting' and 'no, you know what, it all makes sense somehow'.

1. Does that option actually set the joining user as global admin? Is that really the default setting?

2. can you validate this ANYWHERE in Entra? Or does it just disappear?

3. what is that Device Admin group? A separate group, independent of these two settings, that gives local admin?

4. Is there a graph endpoint that can be used to set this?

Thanks

MFA Options for Employees without Phones

FabianUni — Wed, 15 Apr 2026 12:00:35 GMT

Hello everbody,

we're currently trying to implement MFA in our company, but approximately 1/10 of our employees have a workphone and are not allowed to use their personal phone.

Since we also recently introduced Intune, the idea was to just use Windows Hello for Business, but when trying to provision it, we realized that you need to have MFA active for an account to be able to even activate it? Which kinda defeats the purpose.

So my question is, is there some way to circumvent the MFA requirement for WHfB? Or what other options do we realistically have?

Thanks in Advance!

Advice required for temp / agency staff

StuartK73 — Mon, 13 Apr 2026 15:05:38 GMT

Hi All

I hope you are well.

Anyway, I'm hoping someone can point me in the right direction.

We have Android devices in Entra Shared Device Mode (Multi App) which any of our employees with a valid UPN can logon to.

All good there.

What we need is a solution for temporary or agency staff. This would be staff that could be called on at very short notice and may not stay around for long.

For security and audit reasons, we'd rather not create "userless" accounts.

Is there anything in Entra / Entra Shared Device Mode that can achieve this?

Info greatly appreciated.

Understand Why a Service Principal Was Created in Your Entra Tenant

milgo — Thu, 09 Apr 2026 08:22:36 GMT

Are you a tenant admin or member of a security team in your organization and find yourself asking “Why was this service principal created in our tenant?”

Historically, answering this required correlating audit logs with Microsoft Graph queries or going through long investigations. Microsoft Entra now introduces enhanced audit log properties that make it significantly easier to understand the origin and intent behind newly created service principals directly from tenant audit logs. These new improvements surface additional insights within the Add service principal activity under the ApplicationManagement category—helping administrators determine whether a service principal was provisioned automatically by Microsoft services, triggered by a purchased subscription, or explicitly created by user or application activity.

What’s in it for me as an Admins or member of the Security Team
When a service principal is created, new metadata is now captured within Microsoft Entra audit logs that enables faster root‑cause analysis. These properties help distinguish between Microsoft‑driven provisioning processes and tenant‑initiated actions, allowing teams to quickly assess whether an event is expected platform behavior or something requiring deeper investigation.

For example, administrators can now:

Identify provisioning initiated by Microsoft services versus internal users or automation.
Determine which tenant subscription or service plan enabled just‑in‑time provisioning.
Recognize provisioning linked to Azure resource onboarding or managed identities.
Investigate service principal creation without relying on additional Graph lookups.

By leveraging these enriched audit logs, security teams can streamline investigations into newly created enterprise applications and reduce manual dependency on downstream data sources. This ultimately improves visibility into application onboarding events and supports faster decision‑making when assessing potential risk or unexpected provisioning activity within the tenant.

Learn more here- Understand why a service principal was created in your tenant - Microsoft Entra ID | Microsoft Learn