Новые пользователи MS Entra MFA с AD FS неправильно обходят требование MFA для первоначального ProofUp.

Я готовлюсь к подключению новой группы пользователей для аутентификации MFA с помощью Entra/AD FS и сталкиваюсь с некоторыми проблемами (к счастью, это всё ещё на стадии тестирования!)

Среда — это локальный сервер AD/AD FS (2019 года), синхронизирующийся с Entra с использованием P1 для поддержки MFA. Это работает для большинства пользователей. Когда пользователи активируют новую учетную запись, они перенаправляются на процесс “ProofUp” от Microsoft на сайте mysignins.microsoft.com/security-info согласно документации и могут завершить регистрацию/аутентификацию. Это позволяет им изначально обойти требование MFA для доступа к странице “mysignins.microsoft.com/security-info”, пока не будут предоставлены дополнительные факторы, как и должно быть.

Однако у нас есть группа пользователей, которые уже имеют приложение Microsoft Authenticator и уже вошли в него с использованием нашей “Рабочей или Учебной учетной записи”, но ещё не завершили регистрацию приложения для MFA в нашем арендателе Azure/Entra. Примечательно, что приложение СОВСЕМ не отображается в разделе Методы аутентификации для пользователя в консоли администратора Entra. Это студенты (мы университет), которые использовали приложение для MFA с внешним сервисом до того, как мы ввели требование MFA для студентов, и теперь мы больше не используем этот сервис.

Эти пользователи НЕ могут загрузить страницу ProofUp на mysignins.microsoft.com/security-info и вместо этого попадают в цикл перенаправления, где они постоянно возвращаются на наш сайт AD FS с сообщением о необходимости завершить регистрацию MFA.

Ключевой момент в том, что пользователь никогда не видит фактического сообщения об ошибке. Они просто не могут пройти мимо страницы AD FS, на которой им предлагают зарегистрировать токены MFA. Всё, что они делают, чтобы продвинуться вперёд, перенаправляет их обратно к этому пункту. Кроме того, журналы входа для этих пользователей в Entra показывают только результаты “Успех”, если они не вводят неверный пароль, и даже эти записи сделаны до того, как мы включили требование MFA для пользователя (или после того, как мы освободили их из-за ошибки).

ОБНОВЛЕНИЕ:

Теперь я могу воспроизвести это для нового тестового пользователя по запросу с помощью следующих шагов:

1. Создайте пользователя в локальном Active Directory
2. Убедитесь, что от пользователя ещё не требуется MFA, и дайте ему синхронизироваться с Azure AD/Entra
3. Возьмите тестовое мобильное устройство, которое ещё не зарегистрировано в Entra
4. Установите приложение MS Authenticator заново на устройстве (полностью удалите его сначала, а затем переустановите, если оно уже было, чтобы удалить все локальные данные от предыдущих тестов)
5. Войдите в приложение Authenticator под учетной записью работника/учебной учетной записью с учетными данными пользователя, созданного на шаге 1
6. Закройте и выйдите из приложения.
7. Установите для пользователя требование MFA для одной из наших сторон, использующих AD FS (мы делаем это, добавляя членство группы в AD)
8. Пусть пользователь попробует получить доступ к защищенному приложению

Важно, чтобы шаги 5 и 6 произошли до шага 7.

AD FS теперь правильно определяет, что пользователю нужно завершить MFA; они увидят сообщение согласно документации, а затем попытается перенаправить их на страницу Entra ProofUp через 5 секунд. Но страница ProofUp не позволит получить доступ и немедленно перенаправит их обратно на AD FS, чтобы повторить цикл. Пользователь не может завершить процесс ProofUp.

Использование кнопки “Требовать повторную регистрацию многофакторной аутентификации”, показанной ниже для пользователя в консоли администратора, не помогает решить эту проблему.

На данный момент у меня есть два способа, как я могу продвинуть этих пользователей вперед:

1. Ввести дополнительный фактор вручную для них (например, номер мобильного телефона). Вскоре мы будем привлекать несколько сотен дополнительных пользователей таким способом, и я не обязательно имею эти номера мобильных телефонов. Мне нужно что-то лучшее.
2. Изменить политику контроля доступа для приложения Office 365 так, чтобы не требовать MFA. Это не так плохо, как кажется на первый взгляд, поскольку мы используем Google Workspace для электронной почты и большинства документов, но это, очевидно, тоже нехорошо и не то, с чем я хочу мириться в долгосрочной перспективе.

Как я могу очистить незавершенную регистрацию приложения Authenticator для этих пользователей или каким-либо образом позволить им продвинуться вперёд с регистрацией MFA?

Я не могу быть первым человеком, столкнувшимся с этой проблемой, потому что это может произойти с любым, кто пропускает шаг в обычном процессе и пытается добавить приложение Authenticator слишком рано.

Перейдите в Azure Active Directory > Пользователи > Все пользователи > Выберите пользователя, над которым хотите выполнить действие > выберите Методы аутентификации > Требовать повторную регистрацию MFA
https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userdevicesettings#next-steps

Обновление:
Вот скрипт, который также использует поддержка Microsoft для анализа журналов adfs. Может быть полезно
https://github.com/CSS-Identity/ADFS-Diag/

Вот как мы собираемся обойти эту проблему:

Я добавил дополнительную группу в AD для управления MFA, названную MFA_ProofUpBypass.
Затем я создал новую политику контроля доступа в AD FS с тремя критериями:

1. Разрешить всем, кроме группы MFA_Required
2. Разрешить пользователям из группы MFA_Required и требовать многофакторную аутентификацию, кроме группы MFA_ProofUpBypass
3. Разрешить пользователям из группы MFA_ProofUpBypass

После успешного тестирования политики, я применил ее к нашей стороней Microsoft 365 (и только этой стороне) в AD FS.

Теперь, когда мы добавляем новых пользователей из этой группы (пакетами по около 30 в неделю, потому что у нас всего две человек в команде поддержки, которые также должны обрабатывать обычные запросы), мы изначально добавим пользователей в обе группы MFA_Required и MFA_ProofUpBypass одновременно.

Таким образом, эти пользователи смогут завершить процесс регистрации MFA, а существующие пользователи MFA не потеряют защиту учетной записи для сервиса Microsoft 365.

Затем, когда мы увидим, что каждая группа успешно завершила регистрацию, мы можем удалить их из группы MFA_ProofUpBypass, чтобы они также получили защиту MFA для сервиса Microsoft 365.

В дальнейшем, когда у нас будет обычная смена пользователей и возникнут проблемы, мы сможем продолжать использовать группу MFA_ProofUpBypass, чтобы помогать пользователям с подобными вопросами, а также с такими вещами, как переход на новый телефон.

Я всё ещё хотел бы полностью решить эту проблему, но у меня нет времени (вроде как – мы не начинаем до следующего семестра, но мне нужно, чтобы руководство утвердило план миграции на этой неделе до праздников).

Убедитесь, что ваши пользователи также имеют назначенные лицензии P1.