Многофакторная аутентификация и Office 365: использование средств MFA
Содержание:
1. Знакомство со средствами MFA платформы Office 365;
2. Активация MFA для учетных записей Office 365;
3. Альтернативные методы аутентификации;
4. Использование средств MFA (Вы читаете данный раздел);
5. Вопрос планирования.
На то, чтобы привыкнуть к работе со средствами MFA, уходит некоторое время, но скоро эти навыки становятся вашей «второй натурой». Система не предлагает вам вводить свои учетные данные чаще, чем раньше, однако, когда это происходит, процесс проверки подлинности складывается из двух этапов. В большинстве случаев получение текстового сообщения с верификационным кодом (см. скриншот ниже) никаких сложностей не вызывает.
Единственная проблема, с которой мне приходилось сталкиваться при работе за пределами моей страны проживания, состояла в том, что иногда имела место некоторая задержка с передачей сигнала. Это телекоммуникационные компании прикидывали, как донести сообщение SMS с кодом верификации до моего мобильника. Что ж, таковы особенности роуминга. Пожалуй, в подобных случаях удобнее пользоваться приложением Azure Authenticator. Плюско всему, такая система будет малопригодна, когда вам приходится работать с обширными базами заявок, поступающих от клиентов.
Самая серьезная проблема, с которой мне довелось столкнуться, заключалась в отсутствии средств работы с многофакторной аутентификацией в среде PowerShell. Когда пользователь начинает сеанс удаленной работы с PowerShell с помощью подключения через Office 365, он может идентифицировать себя, только предоставив свое имя пользователя и пароль, так как механизм для передачи второго фактора аутентификации, включая пароли приложений, в этом случае не предусмотрен. Единственное решение — создать отдельную учетную запись для работы с PowerShell. Само по себе это несложно, к тому же отделение административных действий (которые вы будете выполнять с использованием PowerShell) от рутинных процедур взаимодействия с Office 365 отвечает требованиям безопасности. Кстати, специалисты Microsoft сейчас работают над оснащением PowerShell средствами MFA, так что в будущем вы сможете использовать различные методы верификации. Учтите, что, возможно, на первых порах модули PowerShell для различных приложений, включая Exchange, не будут поддерживать работу средств MFA. Но даже если такая поддержка и будет реализована, я все равно рекомендовал бы рассмотреть возможность использования отдельной учетной записи для работы с PowerShell.
Определение альтернативного метода аутентификации
Среда PowerShell может использоваться для просмотра учетных записей, настроенных для применения средств MFA. Как разъясняется в статье, подготовленной обладателем статуса Microsoft MVP Мишелем де Руиж, публикуемый выше код вы можете использовать для определения учетных записей Office 365, применяющих средства многофакторной аутентификации, а также для выявления методов, используемых для дополнительной проверки подлинности. Приведенные ниже данные показывают, что обе учетные записи настроены для использования аутентификации с помощью SMS (OneWaySMS), а также звонков по мобильному телефону (TwoWayVoiceMobile). Помимо прочего, вы можете использовать PowerShell для управления настройками MFA для учетных записей, хотя большинство пользователей устроит обращение в центр администрирования Office 365 Admin Center.
Более занятная проблема возникла в связи с тем, что Internet Explorer внезапно стал отказывать мне в соединении с использованием средств MFA (см. скриншот выше). Я работал под управлением новейшей версии Windows 10 (10586, или редакция Threshold 2); при этом, в отличие от IE, как Edge, так и Chrome работали с MFA без каких-либо нареканий. Я сделал все, что полагается в таких случаях: очистил кэш браузера и навел в Интернете справки по коду ошибки 50012, но оптимального решения так и не нашел. Проблема сохранялась в течение недели или чуть больше. В конце концов я решил деактивировать средства MFA для своей учетной записи и посмотреть, как на это отреагирует IE. Браузер работал после деактивации средств MFA и продолжал исправно функционировать и после ее повторного включения. Таким образом я получил еше одно подтверждение тому, что отключение функции с ее последующей активацией часто позволяет решить проблему.
Не забывайте о том, что, если вы деактивируете средства MFA и затем вновь активируете их для той или иной учетной записи, пользователь будет вынужден вновь пройти через процесс настройки методов верификации.
1. Знакомство со средствами MFA платформы Office 365;
2. Активация MFA для учетных записей Office 365;
3. Альтернативные методы аутентификации;
4.
5. Вопрос планирования.
На то, чтобы привыкнуть к работе со средствами MFA, уходит некоторое время, но скоро эти навыки становятся вашей «второй натурой». Система не предлагает вам вводить свои учетные данные чаще, чем раньше, однако, когда это происходит, процесс проверки подлинности складывается из двух этапов. В большинстве случаев получение текстового сообщения с верификационным кодом (см. скриншот ниже) никаких сложностей не вызывает.
Единственная проблема, с которой мне приходилось сталкиваться при работе за пределами моей страны проживания, состояла в том, что иногда имела место некоторая задержка с передачей сигнала. Это телекоммуникационные компании прикидывали, как донести сообщение SMS с кодом верификации до моего мобильника. Что ж, таковы особенности роуминга. Пожалуй, в подобных случаях удобнее пользоваться приложением Azure Authenticator. Плюско всему, такая система будет малопригодна, когда вам приходится работать с обширными базами заявок, поступающих от клиентов.
MFA и пакет PowerShell
Самая серьезная проблема, с которой мне довелось столкнуться, заключалась в отсутствии средств работы с многофакторной аутентификацией в среде PowerShell. Когда пользователь начинает сеанс удаленной работы с PowerShell с помощью подключения через Office 365, он может идентифицировать себя, только предоставив свое имя пользователя и пароль, так как механизм для передачи второго фактора аутентификации, включая пароли приложений, в этом случае не предусмотрен. Единственное решение — создать отдельную учетную запись для работы с PowerShell. Само по себе это несложно, к тому же отделение административных действий (которые вы будете выполнять с использованием PowerShell) от рутинных процедур взаимодействия с Office 365 отвечает требованиям безопасности. Кстати, специалисты Microsoft сейчас работают над оснащением PowerShell средствами MFA, так что в будущем вы сможете использовать различные методы верификации. Учтите, что, возможно, на первых порах модули PowerShell для различных приложений, включая Exchange, не будут поддерживать работу средств MFA. Но даже если такая поддержка и будет реализована, я все равно рекомендовал бы рассмотреть возможность использования отдельной учетной записи для работы с PowerShell.
Get-MsOlUser | Where {$_.StrongAuthenticationRequirements} | Select UserPrincipalName, @{n="MFA"; e={$_.StrongAuthenticationRequirements.State}}, @{n="Methods"; e={($_.StrongAuthenticationMethods).MethodType}}
UserPrincipalName MFA Methods
----------------- --- -------
John.Smith@Office365ExchangeBook.com Enforced {OneWaySMS, TwoWayVoiceMobile}
Ed.Banti@office365exchangebook.com Enforced {OneWaySMS, TwoWayVoiceMobile}Определение альтернативного метода аутентификации
Среда PowerShell может использоваться для просмотра учетных записей, настроенных для применения средств MFA. Как разъясняется в статье, подготовленной обладателем статуса Microsoft MVP Мишелем де Руиж, публикуемый выше код вы можете использовать для определения учетных записей Office 365, применяющих средства многофакторной аутентификации, а также для выявления методов, используемых для дополнительной проверки подлинности. Приведенные ниже данные показывают, что обе учетные записи настроены для использования аутентификации с помощью SMS (OneWaySMS), а также звонков по мобильному телефону (TwoWayVoiceMobile). Помимо прочего, вы можете использовать PowerShell для управления настройками MFA для учетных записей, хотя большинство пользователей устроит обращение в центр администрирования Office 365 Admin Center.
Казус с привередливым браузером
Более занятная проблема возникла в связи с тем, что Internet Explorer внезапно стал отказывать мне в соединении с использованием средств MFA (см. скриншот выше). Я работал под управлением новейшей версии Windows 10 (10586, или редакция Threshold 2); при этом, в отличие от IE, как Edge, так и Chrome работали с MFA без каких-либо нареканий. Я сделал все, что полагается в таких случаях: очистил кэш браузера и навел в Интернете справки по коду ошибки 50012, но оптимального решения так и не нашел. Проблема сохранялась в течение недели или чуть больше. В конце концов я решил деактивировать средства MFA для своей учетной записи и посмотреть, как на это отреагирует IE. Браузер работал после деактивации средств MFA и продолжал исправно функционировать и после ее повторного включения. Таким образом я получил еше одно подтверждение тому, что отключение функции с ее последующей активацией часто позволяет решить проблему.
Не забывайте о том, что, если вы деактивируете средства MFA и затем вновь активируете их для той или иной учетной записи, пользователь будет вынужден вновь пройти через процесс настройки методов верификации.