что такое mfa код

Принцип работы: Многофакторная проверка подлинности Azure AD

Многофакторная идентификация — это процесс, при котором пользователю для входа в систему предлагается дополнительная форма идентификации, например ввод кода с мобильного телефона или сканирование отпечатков пальцев.

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

Многофакторная идентификация Azure AD требует использовать два или несколько методов проверки подлинности:

Многофакторная идентификация Azure AD также может усилить защиту от сброса пароля. Когда пользователи регистрируются в службе Многофакторной идентификации Azure AD, они также могут зарегистрироваться для самостоятельного сброса пароля, выполнив один шаг. Администраторы могут выбрать формы дополнительной проверки подлинности и настроить запросы для MFA в зависимости от принятых решений по настройке.

Не требуется изменять приложения или службы для использования Многофакторной идентификации Azure AD. Запросы на проверку являются частью события входа в Azure AD, которое при необходимости автоматически запрашивает и обрабатывает запрос MFA.

Доступные методы проверки

Когда пользователь входит в приложение или службу и получает запрос MFA, он может выбрать одну из зарегистрированных форм дополнительной проверки. Пользователи могут перейти на страницу Мой профиль, чтобы изменить или добавить методы проверки.

С Многофакторной проверкой подлинности Azure AD могут использоваться следующие дополнительные формы проверки.

Включение и использование многофакторной проверки подлинности Azure AD

Для всех арендаторов Azure AD доступны параметры безопасности по умолчанию, чтобы быстро разрешить использование приложения Microsoft Authenticator для всех пользователей. Многофакторную проверку подлинности Azure AD можно включить для пользователей и группы, чтобы запрашивать дополнительную проверку во время события входа.

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

Дальнейшие действия

Дополнительные сведения о различных способах проверки подлинности и методах проверки см. в разделе Методы проверки подлинности в Azure Active Directory.

Чтобы увидеть MFA в действии, включите Многофакторную проверку подлинности Azure AD для набора тестовых пользователей в следующем учебнике:

Источник

Часто задаваемые вопросы о многофакторной идентификации Azure

В этой статье приведены ответы на часто задаваемые вопросы о многофакторной идентификации Azure AD и использовании службы MFA. Здесь рассматриваются вопросы о службе в целом, моделях выставления счетов, пользовательских интерфейсах и устранении неполадок.

По состоянию на 1 июля 2019 года корпорация Майкрософт больше не предлагает приложение «Сервер MFA» для новых развертываний. Клиентам, которым нужно, чтобы пользователям поступал запрос на многофакторную проверку подлинности, следует использовать облачную службу «Многофакторная идентификация Azure AD». Существующие клиенты, которые активировали приложение «Сервер MFA» до 1 июля, смогут скачать последнюю версию, будущие обновления и создавать учетные данные для активации обычным образом.

Следующие сведения о сервере многофакторной идентификации Azure применимы только для пользователей, у которых уже запущен сервер MFA.

Лицензирование на основе потребления уже недоступно для новых клиентов, начиная с 1 сентября 2018 г. С 1 сентября 2018 года создавать новые поставщики аутентификации невозможно. Существующие поставщики аутентификации можно продолжать использовать и обновлять. Многофакторная аутентификация по-прежнему будет предоставляться как функция в лицензиях Azure AD Premium.

Общее

Каким образом сервер Многофакторной идентификации Azure обрабатывает данные пользователей?

При использовании сервера многофакторной идентификации данные пользователей хранятся только на локальных серверах. В облаке данные пользователя постоянно не хранятся. Когда пользователь выполняет двухфакторную проверку подлинности, сервер Многофакторной идентификации отправляет данные в облачную службу Многофакторной идентификации Azure AD для проверки подлинности. Для обмена данными между сервером Многофакторной идентификации и облачной службой Многофакторной идентификации используются протокол SSL или TLS и исходящие подключения через порт 443.

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

Необязательные поля можно настроить на сервере Многофакторной идентификации.

В данных о проверке подлинности хранятся результаты этой операции (выполнена или нет), а также указана причина отказа в соответствующем случае. Эти сведения доступны в отчетах о проверке подлинности и использовании.

Какие короткие коды SMS используются для отправки SMS моим пользователям?

В США корпорация Майкрософт использует следующие короткие коды SMS:

В Канаде корпорация Майкрософт использует следующие короткие коды SMS:

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

Майкрософт не поддерживает короткие коды для каких-либо других стран, кроме США и Канады.

Выставление счетов

Взимается ли с организации плата за телефонные звонки или текстовые сообщения, используемые для проверки подлинности?

Нет. С организаций не взимается плата за отдельные телефонные звонки или текстовые сообщения, отправленные пользователям через службу Многофакторной идентификации Azure AD. Если используется поставщик MFA с оплатой за событие проверки подлинности, счет выставляется за каждую проверку подлинности, а не за используемый метод.

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

При использовании модели выставления счетов «на пользователя», плата взымается за всех включенных пользователей или только за пользователей, выполняющих двухфакторную проверку подлинности?

При выставлении счетов учитывается количество пользователей, для которых настроено использование Многофакторной идентификации, не зависимо от того, выполняли ли они двухфакторную проверку подлинности в этом месяце.

Как выставляются счета за Многофакторную идентификацию?

При создании поставщика MFA «на пользователя» или «на проверку подлинности» счета выставляются ежемесячно по мере использования в подписке Azure вашей организации. Точно так же Azure выставляет счета за использование виртуальных машин и веб-приложений.

При покупке подписки на Многофакторную идентификацию Azure AD организация оплачивает только годовой лицензионный сбор за каждого пользователя. Таким образом оплачиваются лицензии MFA и пакеты Microsoft 365, Azure AD Premium и Microsoft Enterprise Mobility + Security.

Существует ли бесплатная версия службы многофакторной идентификации Azure AD?

Параметры безопасности по умолчанию можно включить на уровне Azure AD Free. Если используются параметры безопасности по умолчанию, для всех пользователей включена многофакторная идентификация с помощью приложения Microsoft Authenticator. Нельзя использовать текстовые сообщения или проверку по телефону с использованием параметров безопасности по умолчанию — только приложение Microsoft Authenticator.

Может ли моя организация переключаться между моделями выставления счетов «по пользователям» и «по аутентификации»?

Если организация приобретает MFA как автономную службу с оплатой по мере использования, модель выставления счетов можно выбрать при создании поставщика MFA. После его создания изменить модель выставления счетов невозможно.

Если поставщик MFA не связан с клиентом Azure AD или новый поставщик MFA связан с другим клиентом Azure AD, пользовательские настройки и параметры конфигурации не будут применяться. Кроме того, вам потребуется повторно активировать имеющиеся серверы Azure MFA с помощью учетных данных активации, созданных с помощью нового поставщика многофакторной идентификации. Повторная активация серверов MFA для их связи с новым поставщиком MFA не влияет на проверку подлинности с помощью телефонного звонка и текстового сообщения в отличие от уведомлений мобильных приложений, которые перестанут работать, пока пользователи повторно не активируют мобильные приложения.

Может ли моя организация в любой момент переключаться между моделью выставления счетов по мере использования и подписками (моделью на основе лицензий)?

В некоторых случаях это возможно.

Если в каталоге уже есть поставщик Многофакторной идентификации Azure с оплатой на пользователя, вы можете добавить лицензии MFA. Пользователи, имеющие лицензии, не будут учитываться при выставлении счетов по мере использования с оплатой «на пользователя». Для пользователей без лицензий можно по-прежнему включить MFA с помощью поставщика MFA. Если приобрести и назначить лицензии всем пользователям, для которых настроено использование Многофакторной идентификации, вы сможете удалить поставщик Многофакторной идентификации Azure. Если в будущем количество пользователей превысит число лицензий, вы можете всегда создать другой поставщик MFA с оплатой «на пользователя».

Если в каталоге уже есть поставщик Многофакторной идентификации Azure с оплатой за событие проверки подлинности, счета всегда будут выставляться за каждую операцию проверки подлинности до тех пор, пока поставщик MFA связан с вашей подпиской. Вы можете назначить лицензии MFA пользователям, но плата по-прежнему будет взиматься за каждый запрос на двухфакторную проверку подлинности даже от пользователей с лицензиями MFA.

Должна ли моя организация использовать и синхронизировать удостоверения для использования Многофакторной идентификации Azure AD?

Когда организация использует модель выставления счетов с оплатой по мере использования, то применять Azure Active Directory необязательно. Если поставщик MFA не привязан к клиенту Azure AD, то вы сможете развернуть сервер Многофакторной идентификации Azure только в локальной среде.

При использовании любой модели лицензирования применять Azure Active Directory обязательно, так как лицензии, приобретенные и назначенные клиенту Azure AD, добавляются в этот каталог.

Управление учетными записями пользователей и их поддержка

Что делать пользователю, если он не получил ответ на свой звонок?

Попросите пользователей раз в 5 минут принять телефонный звонок или SMS до пяти раз, чтобы пройти проверку подлинности. Корпорация Майкрософт использует несколько провайдеров для доставки звонков и SMS-сообщений. Если этот метод не работает, для решения проблемы создайте обращение в службу поддержки.

Сторонние приложения безопасности также могут блокировать текстовое сообщение или телефонный звонок с проверочным кодом. Если вы используете стороннее приложение безопасности, попробуйте отключить защиту, а затем запросите другой проверочный код MFA.

Если указанные выше действия не работают, проверьте, не настроено ли для пользователей несколько методов проверки. Попробуйте выполнить вход еще раз, но при этом выбрать другой метод проверки на странице входа.

Что делать, если один из пользователей не может получить доступ к своей учетной записи?

Вы можете сбросить настройки учетной записи, попросив пользователя снова пройти процесс регистрации. Узнайте больше об управлении параметрами пользователей и устройств в облаке с помощью Многофакторной идентификации Azure AD.

Что делать в случае утери телефона пользователя, использующего пароли приложений?

Чтобы предотвратить несанкционированный доступ, удалите все пароли приложений пользователя. После получения нового устройства пользователь сможет создать их заново. Узнайте больше об управлении параметрами пользователей и устройств в облаке с помощью Многофакторной идентификации Azure AD.

Что если пользователь не может войти в приложения, не относящиеся к браузеру?

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

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

Современная аутентификация для клиентов Office 2013

Пароли необходимы только для тех приложений, которые не поддерживают современные методы проверки подлинности. Клиенты Office 2013 поддерживают современные протоколы проверки подлинности, но их необходимо настроить. Современная проверка подлинности доступна для любого клиента, на котором установлено обновление для Office 2013,выпущенное в марте 2015 г. или позднее. Дополнительные сведения приведены в публикации блога Обновленная современная аутентификация Office 365.

Что делать пользователю, если текстовое сообщение не приходит или истекает время ожидания проверки?

Мы не можем гарантировать доставку SMS-сообщений, так как надежность этой услуги зависит от неконтролируемых факторов. К таким факторам относится страна или регион назначения, оператор мобильной связи и сетевое покрытие.

Сторонние приложения безопасности также могут блокировать текстовое сообщение или телефонный звонок с проверочным кодом. Если вы используете стороннее приложение безопасности, попробуйте отключить защиту, а затем запросите другой проверочный код MFA.

Пользователям, которые испытывают трудности с получением текстовых сообщений, мы советуем использовать приложение Microsoft Authenticator или телефонные звонки. Приложение Microsoft Authenticator может получать уведомления как по сотовой сети, так и через Wi-Fi. Кроме того, мобильное приложение может создать код подтверждения даже при полном отсутствии связи. Приложение Microsoft Authenticator доступно для Android, iOS и Windows Phone.

Можно ли изменить время, в течение которого пользователи должны ввести код проверки из текстового сообщения до истечения времени ожидания?

В некоторых случаях — да.

Для односторонних SMS с сервером Azure MFA версии 7.0 или более поздней можно настроить параметр времени ожидания, задав раздел реестра. После того как облачная служба MFA отправит текстовое сообщение, на сервер MFA вернется код проверки (или одноразовый секретный код). По умолчанию сервер MFA хранит код в памяти 300 секунд. Если пользователь вводит свой код по истечении 300 секунд, ему будет отказано в доступе. Чтобы изменить значение времени ожидания по умолчанию, выполните следующие действия:

При наличии нескольких серверов MFA код проверки, который был отправлен пользователю, знает только тот, который обработал исходный запрос идентификации. Когда пользователь вводит код, запрос проверки подлинности для его подтверждения должен быть отправлен на тот же сервер. Если проверка кода отправляется на другой сервер, в проверке подлинности будет отказано.

Если пользователь не ответит на текстовое сообщение в течение определенного времени ожидания, в проверке подлинности будет отказано.

Для односторонних SMS с Azure AD MFA в облаке (включая адаптер AD FS и расширение сервера политики сети) нельзя настроить параметр времени ожидания. Azure AD хранит код проверки в течение 180 секунд.

Могу ли я использовать аппаратные ключи с сервером Многофакторной идентификации Azure?

При использовании сервера Многофакторной идентификации Azure вы можете импортировать сторонние маркеры OATH TOTP (одноразовые пароли с ограниченным сроком действия), чтобы применять их для двухфакторной проверки подлинности.

Токены ActiveIdentity формата OATH TOTP можно использовать, если вы поместите секретный ключ в CSV-файл и импортируете его на сервер Многофакторной идентификации Azure. OATH-токены можно использовать со службами федерации Active Directory (AD FS), протоколом RADIUS (до тех пор, пока клиентская система может принимать пользовательский ввод) или при проверке подлинности на основе форм IIS.

Сторонние токены OATH TOTP можно импортировать в следующих форматах.

Могу ли я использовать сервер Многофакторной идентификации Azure для защиты служб терминалов?

Да, но если вы используете Windows Server 2012 R2 или более позднюю версию, то обеспечить безопасность служб терминалов можно только с помощью шлюза удаленных рабочих столов.

Изменения системы безопасности в Windows Server 2012 R2 изменили способ подключения сервера Многофакторной идентификации Azure к пакету безопасности локальной системы безопасности, используемый в Windows Server 2012 и более ранних версиях. Для версий служб терминалов, используемых в Windows Server 2012 и более ранних версий, можно защитить приложение с помощью проверки подлинности Windows. Если вы используете Windows Server 2012 R2, необходим шлюз удаленных рабочих столов.

Почему пользователь получает вызовы Многофакторной идентификации от анонимного абонента после настройки идентификатора звонящего на сервере MFA?

Когда вызовы для многофакторной проверки подлинности осуществляются по телефонной сети общего пользования, иногда они передаются через оператора, который не поддерживает идентификацию вызывающего абонента. Учитывая такое поведение оператора, идентификация вызывающего абонента не гарантируется, хотя система Многофакторной идентификации всегда отправляет соответствующий идентификатор.

Почему пользователи получают предложение зарегистрировать свои сведения о безопасности?

Существует несколько причин, почему пользователи могут получать такой запрос:

ошибки

Что делать пользователю, если при использовании уведомлений через мобильное приложение он видит сообщение об ошибке приблизительно следующего содержания: «Запрос на проверку подлинности не предназначен для активированной учетной записи»?

Попросите пользователя выполнить следующую процедуру, чтобы удалить учетную запись из Microsoft Authenticator, а затем снова добавить ее:

Что делать пользователю, если при входе в приложение без использования браузера он видит сообщение об ошибке 0x800434D4L?

При попытке войти в установленное на локальном компьютере приложение, не использующее браузер, которое не работает с учетной записью, требующей двухфакторную проверку, возникает ошибка 0x800434D4L.

Для устранения этой ошибки нужно использовать отдельные учетные записи пользователя для операций администрирования и для операций, не связанных с администрированием. Позже вы сможете связать почтовые ящики с этими учетными записями, чтобы иметь возможность входить в Outlook с помощью учетной записи без привилегий администратора. Чтобы больше узнать об этом решении, ознакомьтесь с предоставлением администратору возможности открывать и просматривать содержимое почтового ящика пользователя.

Вероятная причина этой ошибки: если введенные первичные учетные данные верны, возможно, существует несоответствие между поддерживаемой версией NTLM на сервере MFA и контроллере домена. Сервер MFA поддерживает только NTLMv1 (LmCompatabilityLevel=1 thru 4) и не поддерживает NTLMv2 (LmCompatabilityLevel=5).

Следующие шаги

Если вы не нашли здесь ответ на свой вопрос, можно также использовать следующие варианты поддержки:

Источник

Многофакторная аутентификация и Office 365

Пора взять систему MFA на вооружение

Прочитав на сайте Wired.com опубликованную еще в 2012 году статью Kill the Password: A String of Characters Won’t Protect You (http://www.wired.com/2012/11/ff-mat-honan-password-hacker/), я пересмотрел свое отношение к паролям. Никому сегодня не нужно объяснять, сколь важно ограждать информацию от посягательств злоумышленников, и я уже давно защищаю свои данные с помощью сложных паролей, которые к тому же часто меняю. Но, когда я прочел эту статью, мне стало буквально не по себе: с какой же легкостью злоумышленники взламывают защищенные паролями учетные записи!

Теперь везде, где только возможно, я защищаю свои данные с помощью средств многофакторной аутентификации Multi-Factor Authentication (MFA). И не могу понять, почему пользователи платформы Office 365 до сих пор удовлетворяются средствами парольной защиты. Должен признаться: у меня нет точных сведений относительно того, какой процент пользователей Office 365 применяет средства MFA. Но неофициальное исследование, проведенное мною среди знакомых, показывает, что использование средств MFA не является нормой. Возможно, все дело в опасениях, что необходимость выполнения дополнительных аутентификационных процедур будет раздражать пользователей и сбивать их с толку. Мой опыт показывает, что на практике дела обстоят иначе, однако я вполне понимаю тех, кто придерживается такой точки зрения. Но как бы то ни было, теперь, когда средства аутентификации на базе OAuth (иногда именуемые средствами современной аутентификации) реализованы как в последней версии Office 2013, так и в Office 2016, надо полагать, что для администраторов наступило самое время рассмотреть вопрос о том, смогут ли средства MFA обеспечить защиту пользовательских данных.

Знакомство со средствами MFA платформы Office 365

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

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

Вспомогательные методы аутентификации, реализованные в пакете Azure Active Directory, многообразны и включают в себя телефонный звонок, текстовое сообщение, оповещение средствами мобильного приложения, код верификации и маркеры OATH от независимых поставщиков (это не опечатка — между стандартом OAuth и маркерами OATH существует определенное различие). Более подробные сведения о средствах MFA, реализованных в пакете Azure Active Directory, можно найти на сайте разработчика.

Azure Active Directory — это служба подтверждения полномочий Office 365. Чтобы подтвердить свои права доступа к службам с помощью пакета OAuth 2.0, приложения, разработанные для взаимодействия с MFA, используют библиотеку Active Directory Authentication Library (ADAL). OAuth — это открытый стандарт предоставления прав доступа, поддерживаемый многими другими поставщиками. Используя библиотеку ADAL, клиентские приложения, такие как Outlook или Outlook Web App, получают доступ к данным пользователей с помощью маркеров доступа, выдаваемых в процессе аутентификации. Применение маркеров доступа обеспечивает приложениям возможность продолжать обращаться к данным, не расходуя ресурсы на хранение или предоставление учетной информации пользователей.

Применяется два типа маркеров. Маркер refresh token выдается после успешного подтверждения аутентичности пользователя. Это главный маркер, служащий для получения маркеров, которые необходимы для обращения к данным пользователя. Так, при первом подключении клиента Outlook к системе Office 365 и подтверждении прав доступа к ней маркер refresh token предоставляется службой Azure Active Directory. После этого Outlook может использовать данный маркер для получения маркеров доступа, действительных для системы Exchange. Тот же refresh token действителен на всем пространстве Office 365, так что, если у программ Word или Excel возникает необходимость обращения к данным SharePoint или OneDrive for Business, клиентские приложения могут запросить маркер доступа, действительный для упомянутых серверных приложений. На данную ситуацию можно взглянуть и под другим углом: маркер доступа всегда задается ресурсом — будь то Exchange, SharePoint или какая-либо другая программа.

Если маркер refresh token не используется, срок его действия составляет две недели. Однако, если этот маркер применяется для генерирования маркеров доступа, он обновляется средствами Azure Active Directory. Разумеется, если вы выйдете из системы на срок свыше двух недель и не будете обращаться к Office 365 на протяжении этого времени, срок действия refresh token истечет, и вам придется вновь создавать его в процессе аутентификации.

Активация MFA для учетных записей Office 365

Активация MFA для учетных записей Office 365 осуществляется без каких-либо затруднений. Зарегистрируйтесь в центре администрирования Office 365 Admin Center, перейдите на вкладку Users и щелкните ссылку Setup рядом со строкой Set multi-factor authentication requirements. Теперь вы сможете активировать средства MFA для целой группы учетных записей или для отдельных учетных записей по своему выбору. Запустите процесс, щелкнув на пункте Enable, а затем укажите учетные записи, для которых должны быть активированы средства MFA.

В процессе следующей регистрации пользователей под активированными сейчас учетными записями каждому пользователю будет предложено дополнить процесс активации средства MFA указанием второго метода проверки подлинности личности. Как вы можете убедиться, взглянув на экран 1, я выбрал метод отправки текстового сообщения на мобильный телефон. На указанный номер телефона направляется SMS-сообщение, содержащее шестизначный код, и получатель для завершения процесса должен ввести это число в браузер.

Экран 1. Выбор методов верификации для средств MFA

Разработчики Azure Active Directory объединили указываемый пользователем номер мобильного телефона с соответствующей учетной записью. Когда для той или иной записи требуется дополнительная проверка подлинности, служба Azure Active Directory направляет по заданному номеру код верификации, и пользователь может ввести данный код в ответ на запрос. Этот метод с успехом применяется в браузерных приложениях и в современных мобильных приложениях, которые используют библиотеку ADAL, например в приложении Office 365 Groups. Кроме того, телефоны могут использоваться в процессе аутентификации посредством реакции на звонок. В этом случае пользователь принимает телефонный вызов и завершает процесс подтверждения подлинности нажатием на экране набора номера значка «решетка» (#).

Альтернативные методы аутентификации

Разработчики службы Azure Active Directory предусмотрели возможность применения методов многофакторной аутентификации в таких, например, случаях, когда пользователи перепутали свои смартфоны. Разумеется, никто из пользователей не предполагает, что ему придется прибегнуть к альтернативному методу, пока не возникнет критическая ситуация, но здесь у администраторов есть прекрасный повод принять решение о том, следует ли реализовать подобные методы в организации.

Иногда телефонные звонки и текстовые сообщения не могут быть применены в качестве механизмов проверки подлинности пользователей. Так, работающие с соединениями WiFi пассажиры авиалайнеров не имеют возможности завершить процесс аутентификации с помощью телефонного звонка или текстового сообщения. Но при наличии WiFi-соединения вы можете получать извещающие уведомления (push notifications) с помощью приложения Azure Authenticator (существуют версии для iOS, Android и Windows Phone). Это приложение, кстати, можно применять и в автономном режиме для генерации кодов, которые могут использоваться в процессе аутентификации. Понятно, что пользователям, не располагающим ни приложением Authenticator, ни доступом к сетевому соединению, придется довольствоваться теми вариантами автономного доступа, которые обеспечивают их клиенты.

Прежде чем воспользоваться средством аутентификации, вам придется из своей учетной записи Office 365 активировать его в качестве механизма верификации. Делается это так. Перейдите в раздел Office 365 Settings, выберите вкладку Additional security verification и щелкните на пункте Update your phone numbers used for account security. После этого вы сможете добавить приложение Azure Authenticator к списку программ, поддерживаемых вашей учетной записью, и завершить процесс настройки (см. экран 2).

Экран 2. Настройка приложения authenticator

Пароли приложений

Перечисленные выше методы верификации реализованы не во всех приложениях, и именно по этой причине существует такой механизм, как «пароль приложения». Пароль приложения, создаваемый на финальной стадии активации средств MFA (см. экран 3), представляет собой сложную текстовую строку, которую можно ввести для завершения процесса аутентификации. Пароли приложений были созданы для того, чтобы обеспечить приложениям, не оснащенным средствами аутентификации на основе стандарта OAuth, возможность создания действительных маркеров доступа, открывающих путь к данным Office 365.

Экран 3. Просмотр пароля приложения

Получив пароль приложения, пользователь должен обеспечить его неприкосновенность, поскольку этот пароль потребуется для проверки прав доступа средствами некоторых приложений, включая мобильные телефоны, оснащенные технологией ActiveSync. Освоить эту часть процесса труднее всего, поскольку, хотя у вас может быть несколько паролей приложений (скажем, по одному на каждое приложение или по одному на устройство), все эти пароли генерируются автоматически и, похоже, выдаются нам с гарантией: их ни за что не вспомнишь в тот момент, когда это потребуется. Средства MFA никак не проявляют себя сразу после активации: на данный момент у пользователей могут быть задействованы существующие соединения, срок действия которых должен истечь или которые должны быть разорваны перед тем, как новый режим аутентификации вступит в силу. Обычно первыми требуют использования средств MFA браузерные соединения (включая соединения с SharePoint и с OneDrive при открытии файлов, хранящихся в этих репозиториях). За ними следуют другие приложения, такие как Outlook 2016. После завершения проверки подлинности ее результаты остаются действительными в течение 14 дней.

Использование средств MFA

На то, чтобы привыкнуть к работе со средствами MFA, уходит некоторое время, но скоро эти навыки становятся вашей «второй натурой». Система не предлагает вам вводить свои учетные данные чаще, чем раньше, однако, когда это происходит, процесс проверки подлинности складывается из двух этапов. В большинстве случаев получение текстового сообщения с верификационным кодом (см. экран 4) никаких сложностей не вызывает. Единственная проблема, с которой мне приходилось сталкиваться при работе за пределами моей страны проживания, состояла в том, что иногда имела место некоторая задержка с передачей сигнала. Это телекоммуникационные компании прикидывали, как донести сообщение SMS с кодом верификации до моего мобильника. Что ж, таковы особенности роуминга. Пожалуй, в подобных случаях удобнее пользоваться приложением Azure Authenticator.

Экран 4. Введение одноразового кода, полученного через SMS

MFA и пакет PowerShell

Самая серьезная проблема, с которой мне довелось столкнуться, заключалась в отсутствии средств работы с многофакторной аутентификацией в среде 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 (см. экран 5). Я работал под управлением новейшей версии Windows 10 (10586, или редакция Threshold 2); при этом, в отличие от IE, как Edge, так и Chrome работали с MFA без каких-либо нареканий. Я сделал все, что полагается в таких случаях: очистил кэш браузера и навел в Интернете справки по коду ошибки 50012, но оптимального решения так и не нашел. Проблема сохранялась в течение недели или чуть больше. В конце концов я решил деактивировать средства MFA для своей учетной записи и посмотреть, как на это отреагирует IE. Браузер работал после деактивации средств MFA и продолжал исправно функционировать и после ее повторного включения. Таким образом я получил еще одно подтверждение тому, что отключение функции с ее последующей активацией часто позволяет решить проблему.

Экран 5. Ошибка в работе IE

Не забывайте о том, что, если вы деактивируете средства MFA и затем вновь активируете их для той или иной учетной записи, пользователь будет вынужден вновь пройти через процесс настройки методов верификации.

Вопрос планирования

Разумеется, реализация средств MFA — это не такой шаг, на который вы решаетесь просто потому, что вам очень захотелось. Здесь я не рассматриваю тот случай, когда кто-то хочет сокрушить справочную службу, обрушив на нее лавину звонков от возмущенных пользователей, желающих обратиться к своим почтовым ящикам. В таких делах требуется предварительная подготовка, и в первую очередь — уведомление пользователей. Все они должны иметь представление о том, что именно происходит и как нужно реагировать на приглашение к проведению дополнительной верификации. Кроме того, целесообразно удостовериться в том, что приложения нормально функционируют с активированными средствами MFA, и составить список ответов на часто задаваемые вопросы (возможно, по образцу списка, подготовленного по данной теме специалистами Microsoft, https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-end-user-manage-settings/). Ознакомившись с этим списком, пользователи будут знать, чего им следует ожидать в процессе выполнения процедуры аутентификации.

Хотя специалисты Microsoft реализовали средства MFA во всей платформе Office 365, рассматриваемая функция не ограничена «облачной» службой. Механизм многофакторной аутентификации Azure Active Directory можно настроить и для обслуживания почтовых ящиков, размещенных на локальном оборудовании. Обладатель статуса Microsoft MVP Брайан Рийд раскрывает эту тему в своем журнале по адресу http://www.c7solutions.com/2015/01/exchange-owa-and-multi-factor-authentication. Кроме того, дополнительную информацию по реализации MFA в локальных приложениях, а также по планированию развертывания гибридных систем можно получить в Microsoft (https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server/и https://support.office.com/en-us/article/Plan-for-multi-factor-authentication-for-Office-365-Deployments-043807b2-21db-4d5c-b430-c8a6dee0e6ba).

Ну и, разумеется, если вы не работаете с Office 365, но хотите защитить системы Exchange с помощью средств MFA, к вашим услугам множество решений, предлагаемых независимыми поставщиками; в этом вы сможете убедиться сами, выполнив простую процедуру поиска в Интернете.

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

С течением времени функции многофакторной аутентификации реализуются во все большем числе приложений, и в конечном итоге их применение станет нормой. Для иллюстрации этой мысли отмечу, что недавно специалисты Microsoft оснастили функциями MFA средства защиты управления правами Windows Rights Management (http://blogs.technet.com/b/rms/archive/2015/10/14/fall-update-document-tracking-ga-multi-factor-authentication-outlook-android-support-and-public-preview-for-rms-sharing-app-for-non-admin-users.aspx) для целого ряда клиентов, включая приложения Office 2016. Это полезное решение, подчеркивающее уязвимость информации в представлении получателей, которые могут получить доступ к тому или иному защищенному файлу, только идентифицировав себя с помощью механизма MFA.

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

Источник