# AADSTS9002341: User must allow Windows single sign-on (fix)

Canonical: https://brambrinkmeier.com/entra/aadsts/9002341/
By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/9002341.json

**Short answer:** AADSTS9002341 means the user hasn't given permission for an app to use their Windows sign-in for single sign-on. Microsoft links it to the Windows SSO change in the European Economic Area, where Windows asks before reusing the Windows account in other apps. It has low attack value. Users accept the prompt; admins can auto-accept it on managed Windows 11 devices.

**Fix:** User: when Windows asks to use your Windows account, choose to continue. Developer: catch it on the silent call and start an interactive sign-in. Admin: on managed Windows 11 24H2/25H2 devices, set `AutoAcceptSsoPermission` (DWORD) to `1` under `HKLM\SOFTWARE\Policies\Microsoft\Windows\AAD`.

| Field | Value |
|---|---|
| Code | AADSTS9002341 |
| Category | Consent and app permissions |
| Type | Interrupt (an expected extra step, not a failure) |
| Attack signal | Low: usually configuration or user error |
| Where to look | `SigninLogs`, `AADNonInteractiveUserSignInLogs` |
| In Microsoft's error reference | Yes |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS9002341 mean?

Microsoft's description:

> V2Error: `invalid_grant` - The user is required to permit single sign-On (SSO). This error occurs when the user has not granted the necessary permissions for the application to perform SSO. The user should be redirected to the consent screen to grant the necessary permissions. Refer to [this announcement](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/upcoming-changes-to-windows-single-sign-on/ba-p/4008151) for more information.

The app tried to sign the user in with the credentials from their Windows sign-in. The user hadn't said yes to that, so the request failed with `invalid_grant`.

The announcement Microsoft links to is the December 2023 Windows IT Pro post *Upcoming changes to Windows single sign-on*. It opens: *"Microsoft has been working to ensure compliance with the Digital Markets Act (DMA) in the European Economic Area (EEA)."*

Microsoft's current Learn page on the change describes the behaviour. In the EEA, users *"are not automatically signed in to other Microsoft applications and services after signing in to Windows. Instead, Windows asks users whether they want to use the same credentials to sign in to additional apps or services."* The notice *"appears the first time a user uses an app that enables sign-in with a personal Microsoft account, or work or school Entra ID, after signing in to Windows. If the user chooses to use the same credentials they used to sign in to Windows, this notice will not appear again."*

This is not the app consent you know from [65001](https://brambrinkmeier.com/entra/aadsts/65001/). Nobody grants API permissions here. The question is whether Windows may reuse the Windows account for single sign-on in this app.

## Is it an attack?

No. It is a permission prompt on the user's own device, and the failure means no token was issued. There is no documented attack pattern.

| Pattern | Likely meaning |
|---|---|
| 9002341 for users in the EEA on Windows, often the first time they open an app | The Windows SSO prompt hasn't been accepted yet. Benign. |
| 9002341 followed by a success for the same user and app | The user accepted the prompt, or signed in another way. Working as designed. |
| 9002341 repeating for one user and app, with no success | Our reading: the user declined the prompt (the screenshot on Microsoft's page shows a *Don't sign in* button) or the app doesn't send them to it. |
| A drop in 9002341 after you deploy the admin setting | The auto-accept setting is in effect on those devices. |

Exclude it from failure-rate dashboards and spray detections.

## How do I find it in my logs (KQL)?

Microsoft doesn't document which sign-in table 9002341 is logged in. Check where it lands:

```kusto
union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "9002341"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable
```

Which apps and operating systems hit it. `DeviceDetail` is `dynamic` in `SigninLogs` and `string` in `AADNonInteractiveUserSignInLogs`, so normalise it first:

```kusto
union
    (SigninLogs | extend Dev = todynamic(DeviceDetail)),
    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))
| where TimeGenerated > ago(7d)
| where ResultType == "9002341"
| extend OS = tostring(Dev.operatingSystem)
| summarize Rows = count(), Users = dcount(UserPrincipalName) by AppDisplayName, OS
| sort by Users desc
```

Users who keep hitting it on the same app and don't succeed there after their first failure that day. These are the people to contact, or the devices to cover with the admin setting:

```kusto
let prompts =
    union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "9002341"
    | summarize Fails = count(), FirstFail = min(TimeGenerated) by UserPrincipalName, AppId, AppDisplayName;
let successes =
    union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "0"
    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;
prompts
| join kind=leftouter successes on UserPrincipalName, AppId
| where isnull(LastSuccess) or LastSuccess < FirstFail
| project UserPrincipalName, AppDisplayName, Fails, FirstFail
| sort by Fails desc
```

The threshold is up to you; start with users who have more than a handful of `Fails`. `ResultType` is a **string** column, so compare it with `"9002341"`, not `9002341`.

## How do I fix AADSTS9002341?

**For the user:** when Windows asks whether to use your Windows account to sign in to the app, choose to continue. Microsoft says the notice then *"will not appear again"* for that app.

**For developers:** Microsoft's description says *"The user should be redirected to the consent screen to grant the necessary permissions."* Treat 9002341 like other interaction-required errors: catch it on the silent call and start an interactive sign-in, so the user sees the prompt.

**For admins:**
1. On managed Windows devices you can accept the prompt for your users. Microsoft documents a registry policy: path `HKLM\SOFTWARE\Policies\Microsoft\Windows\AAD`, value `AutoAcceptSsoPermission` (DWORD) = `1`.
2. Requirements, per Microsoft: Windows 11, version 24H2 or 25H2, with the July 2026 security update (KB5101650) or later. It *"Applies only to Windows managed enterprise devices with Microsoft Entra ID accounts."*
3. Deploy it with Group Policy, Intune or another MDM, Configuration Manager, or *"Any management tool that supports registry policy deployment."*
4. Personal Microsoft accounts and unmanaged devices have no admin control. Those users still see the prompt.
5. Run the third query again after the rollout and check that the remaining users are on unmanaged or older devices.

## Evidence

Not reproduced in the lab yet; the page is based on Microsoft's documentation.

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes)
2. [Admin control for SSO prompts in Windows](https://learn.microsoft.com/en-us/entra/identity/devices/sso-admin-control)
3. [Upcoming changes to Windows single sign-on (Windows IT Pro Blog)](https://techcommunity.microsoft.com/blog/windows-itpro-blog/upcoming-changes-to-windows-single-sign-on/4008151)
4. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
5. [AADNonInteractiveUserSignInLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadnoninteractiveusersigninlogs)

## Related codes

[AADSTS65001](https://brambrinkmeier.com/entra/aadsts/65001/), [AADSTS50058](https://brambrinkmeier.com/entra/aadsts/50058/)

## License and citation

CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change.

Cite as: Bram Brinkmeier, "AADSTS9002341: User must allow Windows single sign-on (fix)", https://brambrinkmeier.com/entra/aadsts/9002341/ (CC BY 4.0), last updated 2026-10-30.