Исправление авторизации в Office365/ExchangeOnline

Назначение

Решить проблему, когда Outlook/Office 365 при входе в почту уходит в логин-луп, не открывает окно входа или зависает на «Pick an account». Обход: отключить использование Web Account Manager (WAM) в Office, включив реестрный ключ DisableAADWAM. При необходимости дополнить ключом DisableADALatopWAMOverride.

Почему возникает проблема с авторизацией (WAM, MSAL, AAD) и почему помогает DisableAADWAM

Что здесь вообще происходит

• Современная авторизация Office/Outlook использует MSAL и брокер Windows — Web Account Manager (WAM).
• WAM — это системный «токен-брокер» Windows 10/11: хранит и обновляет токены в общем кэше, обеспечивает SSO между приложениями Microsoft (Outlook/Teams/OneDrive/Edge) и привязку к состоянию устройства (PRT, Workplace/Azure AD Join).
• Когда Outlook запускает вход, он просит у WAM «сеанс» для нужного тенанта/приложения. Дальше управление уходит брокеру (WAM + WebView2), который показывает окно входа, применяет MFA/Conditional Access и возвращает токены приложению.

Почему ломается («логин-луп», «Pick an account» без прогресса, пустое окно входа)

• Битый/рассинхронизированный кэш WAM: устаревшие токены/учётки в «Учетные записи рабочих/учебных» → бесконечные запросы выбора аккаунта, окно закрывается без выдачи токена.
• Конфликт нескольких учёток/тенантов в общем кэше WAM (личный + рабочий, старый тенант, гостевой доступ B2B) → брокер пытается «переиспользовать» не тот сеанс.
• Неполная/проблемная регистрация устройства в Entra ID (PRT/Workplace Join, сбитое состояние dsreg) → CA/MFA не проходит, окно крутится.
• RDS/VDI/профиль-виртуализация (FSLogix/UPD): кэш/артефакты WAM и WebView2 плохо «кочуют» между сессиями → токены теряются или становятся невалидными.
• Системные зависимости: поломанная/устаревшая WebView2, антивирус/EDR блокирует брокер, прокси/SSL-инспекция ломает интерактивный флоу, баги конкретной версии Office/Windows.
• Политики организации/CA: требование «совместимого устройства» или device bound токенов, а на данном ПК статус устройства некорректен → WAM не может выдать приложению валидный набор токенов.

Почему помогает DisableAADWAM

• Ключ DisableAADWAM отключает брокерскую авторизацию через WAM для Office и заставляет Outlook/Office использовать «встроенный» интерактивный флоу MSAL/ADAL без системного брокера.
• Эффект:
  • Приложение получает собственный изолированный кэш токенов, не зависящий от глобального кэша WAM (уходит причина конфликтов между учётками/тенантами).
  • Обходятся проблемы сломанной WebView2/WAM и багов конкретной ветки Windows.
  • На RDS/VDI токены «живут» в пользовательском профиле приложения, а не в общесистемном брокере, что лучше переносится профильно.
• Это обходной путь: первопричина (WAM/PRT/политики/прокси/регистрация устройства) остаётся; просто исключается проблемный компонент из цепочки.

Какие побочные эффекты и риски

• Теряется часть «сквозного» SSO и фич брокера: интеграция с Windows Hello for Business, broker-assisted MFA, device compliance в некоторых сценариях CA. Может чаще спрашивать пароль/MFA.
• Возможны расхождения поведения между приложениями (Teams/OneDrive могут продолжать использовать WAM, если их отдельно не перевести на аналогичный режим).
• После починки первопричины WAM лучше включить обратно — это штатный и поддерживаемый путь.

Когда лучше чинить «по-взрослому», а не оставлять обход

• Разрушен статус устройства/PRT → проверить dsregcmd /status, пере-join к Entra ID/Workplace Join.
• Проблемы с WebView2/WAM → обновить WebView2 Runtime, Office, Windows; проверить политики, убрать блокировки в EDR/прокси, отключить SSL-инспекцию для Microsoft endpoints.
• Конфликт аккаунтов → почистить «Учетные записи рабочих/учебных», Credential Manager (Generic: MicrosoftOffice16_…), выйти/войти в Office.
• RDS/VDI → убедиться, что профили (FSLogix) стабильно сохраняют кэш приложений; при возможности использовать per-user контейнеры для токенов.

Пошаговая инструкция

Вариант A — Быстро для текущего пользователя (PowerShell)

1. Закройте Outlook и все приложения Office.
2. Выполните от имени пользователя:
   Disable WAM for Office (HKCU)

   $base = 'HKCU:\Software\Microsoft\Office\16.0\Common\Identity'
   New-Item -Path $base -Force | Out-Null
   New-ItemProperty -Path $base -Name 'DisableAADWAM' -PropertyType DWord -Value 1 -Force | Out-Null
   New-ItemProperty -Path $base -Name 'DisableADALatopWAMOverride' -PropertyType DWord -Value 1 -Force | Out-Null
   Write-Host "WAM disabled for Office (HKCU)."
   

3. Откройте Outlook и повторите вход.

Вариант B — Через reg.exe (скрипт входа пользователя/GPP)

reg add "HKCU\Software\Microsoft\Office\16.0\Common\Identity" /v DisableAADWAM /t REG_DWORD /d 1 /f
reg add "HKCU\Software\Microsoft\Office\16.0\Common\Identity" /v DisableADALatopWAMOverride /t REG_DWORD /d 1 /f

Вариант C — Массово через GPO (User Configuration → Preferences → Windows Settings → Registry)

1. Создайте/отредактируйте GPO, привязанную к нужным пользователям/OU.
2. В разделе User Configuration → Preferences → Windows Settings → Registry добавьте:

• Action: Update
• Hive: HKEY_CURRENT_USER
• Key Path: Software\Microsoft\Office\16.0\Common\Identity
• Value name: DisableAADWAM
• Value type: REG_DWORD
• Value data: 1

1. Добавьте второй параметр аналогично: DisableADALatopWAMOverride (DWORD=1).
2. Обновите политику: gpupdate /force (или релогин пользователя).

Проверка результата

1. Перезапустите Outlook.
   1. Если была проблема "Требуется пароль", то более вероятно окошко авторизации появится без проблем. В некоторых случаях, если окошко не появляется и "Требуется пароль" всё ещё висит, то поможет пересоздание профиля почты (через "Панель управления")
   2. Если была проблема именно в окошке авторизации, то то теперь авторизация должна пройти без проблем.
2. Очистите кэш учётных данных (по ситуации):
   Reset credentials (optional)

   rundll32.exe keymgr.dll,KRShowKeyMgr   :: вручную удалить устаревшие записи
   control.exe /name Microsoft.CredentialManager
   

3. В RDS/VDI проверьте повторный вход после логаута сессии.

Траблшутинг

• Окно входа не появляется вовсе.
  Проверьте, что оба ключа созданы в HKCU именно у проблемного пользователя и равны 1. Перелогиньтесь в систему.
• Всё ещё логин-луп.
  Очистите Credential Manager (Generic: MicrosoftOffice16_Data…), выйдите из аккаунта в любом приложении Office → войдите заново.
• Teams/OneNote тоже запрашивают пароль.
  Эти приложения также используют WAM. После применения ключей выполните выход/вход в аккаунт и перезапуск приложений.
• Нужно вернуть поведение по умолчанию.
  Установите DisableAADWAM/DisableADALatopWAMOverride в 0, или вообще удалите их, затем перезапустите приложения/релогин.

Частые вопросы (FAQ)

• Где именно создавать ключи?
  HKCU\Software\Microsoft\Office\16.0\Common\Identity у конкретного пользователя.
• Нужно ли перезагружать ПК?
  Обычно достаточно перезапуска Outlook. В RDS — завершить сессию целиком.
• Это безопасно?
  Вполне. Бомбанёт? Ну не должно.