Вопрос или проблема
У меня очень интересная ситуация, которую я не могу объяснить. У меня есть два пользователя на двух устройствах. Оба пользователя и устройства настроены одинаково. Я буквально проверил все, и оба пользователя и устройства идентичны в рамках конфигурации и логов.
Тем не менее, первый пользователь (использующий тот же браузер, что и второй) получает предложение о методе WHFB в режиме инкогнито как опцию для прохождения валидации MS Entra ID MFA при входе на “office.com”. У второго пользователя этой опции вообще нет (он должен использовать обычные опции MS Entra ID MFA).
Microsoft говорит мне следующее: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/faq, что WHFB не может быть использован в режиме инкогнито. Из моего опыта это возможно, и мне интересно, что, черт возьми, здесь происходит.
Вот опции для прохождения MS Entra ID MFA в режиме инкогнито с методами WHFB, которые были настроены на первом устройстве:
Мы используем доверие Cloud Kerberos на устройствах с гибридным присоединением. Все настроено правильно. Каждый лог, результат и отладка в порядке.
Я выяснил, что второй пользователь может войти с WHFB в режиме инкогнито браузера, если я выберу опцию “Опции входа” на портале “login.microsoftonline.com” вместо того, чтобы вводить UPN пользователя. Когда я ввожу UPN, я перехожу на наш ADFS, и тогда мне нужно использовать MS Entra ID MFA (WHFB не является опцией в этом случае). Так что я не знаю, почему к первому пользователю запрашивают WHFB после прохождения ADFS, а ко второму пользователю не запрашивают WHFB при прохождении ADFS. Более того, важный факт состоит в том, что WHFB может быть использован в режиме инкогнито браузера в нашем случае. Я не понимаю, о чем говорит Microsoft в ссылке на FAQ WHFB, которую я здесь опубликовал.
Итак, я нашел ответ.
Дело в том, что даже когда у гибридного пользователя развернут, подготовлен и зарегистрирован WHFB, MS Entra ID все равно будет показывать классический метод MS Entra ID MFA в “Предпочитаемом методе многофакторной аутентификации системы”. Эта информация может быть найдена в MS Entra ID – {пользователь} – Методы аутентификации.
Это означает, что даже когда у вас зарегистрирован WHFB как метод аутентификации для пользователя, это не влияет на “Предпочитаемый метод многофакторной аутентификации системы” – по крайней мере, не из моего опыта.
Теперь ситуация начинает быть забавной.
Когда вы регистрируете аппаратный ключ FIDO2 для учетной записи пользователя, “Предпочитаемый метод многофакторной аутентификации системы” изменится с классического метода MS Entra ID MFA на FIDO2. Это изменение повлияет на процесс входа. Вам больше не будет предложено использовать классический метод MS Entra ID MFA, но вам будет предложено использовать ключ FIDO2 или метод WHFB. Таким образом, вы можете использовать WHFB как основной метод, чтобы пропустить классический метод MS Entra ID MFA. Однако, когда у вас нет зарегистрированного ключа FIDO2 в вашей учетной записи, использование WHFB как замены классическому методу MS Entra ID MFA невозможно – вам нужно использовать классический метод MS Entra ID MFA (WHFB здесь не является опцией).
Тем не менее, ваш WHFB активен, и вы все еще можете его использовать, но в “login.microsoftonline.com” вам нужно выбрать “Опции входа” вместо ввода вашего UPN (Электронная почта). Когда вы выбираете “Опции входа”, вы можете использовать WHFB для входа без пароля. Когда вы вводите UPN (Электронная почта), вы попадаете в сценарий с WHFB или без него (в зависимости от регистрации FIDO2), который я описал.
Я не знаю, является ли это временным сбоем, плохим дизайном или за этим стоит какая-то логика. Я не понимаю, почему, когда вы можете использовать WHFB для входа без пароля, вы не можете использовать WHFB как замену классическому методу MS Entra ID MFA. Ну, вы можете использовать его таким образом, но вам нужно зарегистрировать ключ FIDO2 в вашей учетной записи MS Entra ID.
Я надеюсь, что Microsoft вскоре исправит или изменит это поведение, потому что оно не имеет смысла. Когда вы читаете это, возможно, логика уже была изменена в Microsoft.
Ответ или решение
Почему Windows Hello for Business запускается в режиме инкогнито?
Вопрос о возможности использования Windows Hello for Business (WHFB) в режиме инкогнито вызывает много обсуждений, особенно в контексте облачных решений и многопользовательских систем. Ваш случай, когда два пользователя с одинаковыми настройками имеют разные результаты использования WHFB в браузере, демонстрирует сложность этого вопроса. Позвольте подробно рассмотреть детали проблемы.
1. Технические основы WHFB
Windows Hello for Business предоставляет пользователям возможность выполнять аутентификацию без паролей, используя такие методы, как биометрия или PIN-коды. Однако под капотом WHFB существует множество интеграций с другими компонентами идентификации, такими как Azure AD и ADFS.
2. Различия между пользователями
Вы упомянули, что вы проверили конфигурации обоих пользователей и устройств, и они идентичны. Однако в процессе локализации проблемы важно учитывать, что даже незначительные различия в учётных записях пользователей или в их настройках безопасности могут привести к различным сценариям аутентификации. Таким образом, даже если оба пользователя имеют WHFB, поведение различных экземпляров может изменяться на основе их индивидуальных настроек MFA (многофакторной аутентификации).
3. Ошибка или недоразумение?
Согласно информации от Microsoft, использование WHFB в режиме инкогнито не предусмотрено. Однако ваш опыт говорит об обратном. Это может быть связано с тем, как система интерпретирует запросы на аутентификацию. При регистрации ключа FIDO2 у пользователя система меняет "Предпочитаемый метод многофакторной аутентификации", включая WHFB в список доступных методов для аутентификации. В этом контексте WHFB становится более предпочтительным способом.
4. Сценарии аутентификации
Как вы отметили, при вводе UPN пользователя происходит переадресация через ADFS, что может отключать опцию WHFB. Важно понимать, что имя пользователя и пароль (UPN) могут привести к другой цепочке вызова аутентификации, которая может не поддерживать WHFB. Напротив, доступ через "Sign-in options" может предоставить возможность использования WHFB, но только если он уже зарегистрирован.
5. Проблема с логикой Microsoft
Ваши наблюдения о том, что WHFB может быть доступен только при определённых условиях, указывают на то, что существует логика, заключающаяся в предпочтениях методов аутентификации, которая может сбить с толку пользователей. Следствием этого может быть очевидная непоследовательность в логике предоставления аутентификационных методов, особенно в контексте безопасной аутентификации.
6. Потенциальные решения и рекомендации
- Регистрация FIDO2: Поощряйте пользователей регистрировать аппаратные ключи FIDO2. Это может упростить обмен методами аутентификации и устранить некоторые текущие несоответствия.
- Мониторинг и обратная связь: Обсудите с пользователями их опыт и соберите данные о дополнительных несоответствиях для передачи в техподдержку Microsoft.
- Проверка обновлений: Поддерживайте актуальность системных и облачных решений, поскольку Microsoft часто вносит изменения в свою политику, которая может повлиять на поведение WHFB.
Заключение
Ваш опыт подчеркивает сложности, связанные с WHFB в режиме инкогнито и многопользовательскими настройками. Разные сценарии аутентификации могут затруднить использование WHFB, и понимание того, как различные элементы взаимодействуют друг с другом, поможет в поиске оптимального решения. Если Microsoft не решит эту проблему, рекомендуется взаимодействовать с ними для получения разъяснений и возможных корректировок.
С пониманием данной проблемы, мы можем надеяться на улучшение и согласование методов аутентификации в будущем, что повысит безопасность пользователей и упростит процесс входа.