Отключение обычной проверки подлинности в exchange online

Фильтрация учетных записей пользователей Active Directory, синхронизированных с Exchange Online

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

В этом примере мы будем использовать атрибут Department, так как это распространенные атрибуты, которые идентифицируют пользователей на основе их отдела и роли. Чтобы увидеть все расширенные свойства пользователя Active Directory, перейдите в Active Directory: Get-ADUser поумолчанию и расширенные свойства.

Получить участников группы Active Directory

Эти действия требуют модуля Active Directory для Windows PowerShell. Чтобы установить этот модуль на компьютере, необходимо скачать и установить средства администрирования удаленного сервера (RSAT).

Запустите следующую команду в Active Directory PowerShell, чтобы вернуть все группы в Active Directory:

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

В этом примере возвращается значение атрибута objectGuid для членов группы с именем Developers.

Настройка фильтруемого атрибута пользователя

После определения группы Active Directory, которая содержит пользователей, необходимо установить значение атрибута, которое будет синхронизировано с Exchange Online для фильтрации пользователей (и в конечном итоге отключит для них проверку подлинности Basic).

Используйте следующий синтаксис в Active Directory PowerShell, чтобы настроить значение атрибута для участников группы, которую вы идентифицировали на предыдущем шаге. Первая команда определяет участников группы на основе значения атрибута objectGuid. Вторая команда назначает атрибуту Department значение для участников группы.

В этом примере атрибут Department задает значение «Developer» для пользователей, принадлежащих к группе с именем «Developers».

Используйте следующий синтаксис в Active Directory PowerShell, чтобы убедиться, что атрибут был применен к учетным записям пользователей (сейчас или в прошлом):

В этом примере возвращаются все учетные записи пользователей со значением «Developer» для атрибута Department.

Шаг 2. Отключение устаревшей проверки подлинности в Exchange Online

Примечание

Значения атрибутов для локального пользователя синхронизируются с Exchange Online только для пользователей, у Exchange Online лицензии. Дополнительные сведения см. в добавлении пользователей по отдельности или оптом.

Синтаксис Exchange Online PowerShell использует следующие команды (две для идентификации учетных записей пользователей, а другая — для применения политики к этим пользователям):

В этом примере политика с именем Block Basic Auth назначается всем синхронизированным учетным записям пользователей, атрибут отдела которых содержит значение «Developer».

Если вы подключите Exchange Online PowerShell в сеансе Active Directory PowerShell, вы можете использовать следующий синтаксис для применения политики для всех членов группы Active Directory.

В этом примере создается новая политика проверки подлинности с именем Marketing Policy, которая отключает базовую проверку подлинности для членов группы Active Directory с именем Marketing Department for ActiveSync, POP3, authenticated SMTP и клиентов IMAP4.

Примечание

Известное ограничение в Active Directory PowerShell не позволяет комлету Get-AdGroupMember возвращать более 5000 результатов. Поэтому в следующем примере работают только группы Active Directory с менее чем 5000 участниками.

Настройка политик проверки подлинности с помощью оснастки «Управление AD FS»

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

в AD FS в Windows Server 2012 R2 можно указать политику проверки подлинности в глобальной области, применимую ко всем приложениям и службам, защищенным AD FS. Можно также задать политики проверки подлинности для конкретных приложений и служб, которые используют отношения доверия сторон и защищены с помощью AD FS. Указание политики проверки подлинности для конкретного приложения на отношение доверия с проверяющей стороной не переопределяет глобальную политику проверки подлинности. Если для глобальной или для каждой политики проверки подлинности доверия с проверяющей стороной требуется MFA, MFA активируется, когда пользователь пытается пройти проверку подлинности для этого отношения доверия с проверяющей стороной. Глобальная политика проверки подлинности — это резервная стратегия для отношений доверия проверяющей стороны для приложений и служб, которые не имеют определенной настроенной политики аутентификации.

Outlook Modern Authentication

To use Modern Authentication with older versions of Outlook you may need to change some settings on the client-side. New versions of Outlook, 2019 and Outlook for Microsoft 365 do support it out of the box.

What you need to configure depends on the Outlook version that you are using:

	Modern Auth Supported	EnableADAL reg key required	Force Modern Auth required	MAPI/HTTP required
Outlook 2010	No	–	–	–
Outlook 2013	Yes	Yes	Yes	Yes
Outlook 2016	Yes	No	Yes	Yes

Outlook 2010 doesn’t not support Modern Authentication. Your only option is to upgrade Outlook.

Outlook 2013 Modern Authentication

If your organization is using Outlook 2013, then you will have to enable Modern Authentication manually. Outlook 2013 will keep using the basic authentication method by default. But we can force it to use Modern Authentication by setting a couple of registry keys on the clients.

# Change EnableADAL to 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL

# Change Version to 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version

Outlook will now try to use modern authentication first, but if you want to force, so it won’t fallback to basic authentication then you will have change the following key to 1 as well:

HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover

If the keys don’t exists then you can simply create them. They are all DWORD values.

Outlook 2016 Modern Authentication

Modern Authentication is enable by default in Outlook 2016. But Microsoft recommends to force Outlook to use Modern Authentication.

We can do this by setting the following registery key to 1:

HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover

Skype for Business Modern Authentication

If you are still using Skype for Business then you will need to enable Modern Authencation for Skype as well. Just like with Outlook we can set a couple of registry keys to enable it:

# Change AllowAdalForNonLyncIndependentOfLync to 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync\ AllowAdalForNonLyncIndependentOfLync

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Lync\ AllowAdalForNonLyncIndependentOfLync

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

Если в домене отсутствуют традиционные записи SPF, DKIM и DMARC, проверка записей не передает достаточно сведений о состоянии проверки подлинности. Поэтому корпорация Майкрософт разработала алгоритм неявной проверки подлинности электронной почты. Этот алгоритм объединяет несколько сигналов в одно значение, которое называется многофакторной аутентификацией, или сокращенно . Значение добавляется в заголовок Authentication-Results в заголовках сообщений.

Эти значения описываются в разделе .

Изучив заголовки сообщений, администраторы и даже пользователи могут увидеть, каким образом Microsoft 365 определил, что отправитель поддельный.

Использование проверки подлинности электронной почты для предотвращения спуфинга

DMARC предотвращает спуфинг, анализируя адрес отправителя в сообщениях. Адрес отправителя — это адрес электронной почты отправителя, который пользователи видят в почтовом клиенте. Организации электронной почты, являющиеся получателями, также могут убедиться, что домен электронной почты прошел проверку SPF или DKIM. Иначе говоря, если домен прошел проверку подлинности, адрес электронной почты отправителя не является поддельным.

Однако записи DNS для SPF, DKIM и DMARC (совместно именуемых «политики проверки подлинности электронной почты») являются необязательными. Домены с надежными политиками проверки подлинности электронной почты, такими как microsoft.com и skype.com, защищены от спуфинга. Но домены, имеющие менее надежные политики проверки подлинности электронной почты или не имеющие вообще никакой политики, являются основной целью спуфинга.

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

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

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

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

Общее извещение корпорации Майкрософт см. в статье Море фишинга, часть 2 — Улучшенные средства борьбы со спуфингом в Microsoft 365.

Настройка основной проверки подлинности для отношения доверия с проверяющей стороной

В диспетчере сервера щелкните Средства и выберите Управление AD FS.
В оснастке AD FS щелкните политики проверки подлинностидля отношения доверия с проверяющей стороной, а затем выберите отношение доверия с проверяющей стороной, для которого необходимо настроить политики проверки подлинности.
Либо щелкните правой кнопкой мыши отношение доверия с проверяющей стороной, для которого требуется настроить политики проверки подлинности, а затем выберите изменить пользовательскую основную проверку подлинностиили в области действия выберите изменить настраиваемую основную проверку подлинности.
В окне изменение политики проверки подлинности для > Relying_party_trust_name в разделе > вкладка можно настроить следующий параметр в рамках политики проверки подлинности с отношением доверия с проверяющей стороной :

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

Справочники

Этот параметр политики определяет, какой протокол проверки подлинности вызовов или ответов используется для сетевых логотипов. Lan Manager (LM) включает клиентский компьютер и серверное программное обеспечение корпорации Майкрософт, которое позволяет пользователям связывать личные устройства в одной сети. Возможности сети включают прозрачный обмен файлами и печатью, функции безопасности пользователей и средства администрирования сети. В доменах Active Directory протокол Kerberos — это протокол проверки подлинности по умолчанию. Однако если протокол Kerberos по каким-либо причинам не согласован, Active Directory использует LM, NTLM или версию NTLM 2 (NTLMv2).

Проверка подлинности LAN Manager включает варианты LM, NTLM и NTLMv2, и это протокол, используемый для проверки подлинности всех клиентских устройств, работающих в операционной системе Windows при выполнении следующих операций:

Регистрация домена
Проверка подлинности между лесами Active Directory
Проверка подлинности доменов на основе более ранних версий Windows операционной системы
Проверка подлинности на компьютерах, не Windows операционных системах, начиная с Windows 2000 г.
Проверка подлинности на компьютерах, которые не находятся в домене

Возможные значения

Отправка ответов & NTLM
Отправка LM & NTLM — используйте безопасность сеанса NTLMv2 при согласовании
Отправка только ответов NTLM
Отправка только ответов NTLMv2
Отправка только ответов NTLMv2. Отказ от LM
Отправка только ответов NTLMv2. Отказ от LM & NTLM
Не определено

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

Параметр	Описание	Уровень безопасности реестра
Отправка ответов & NTLM LM	Клиентские устройства используют проверку подлинности LM и NTLM и никогда не используют безопасность сеансов NTLMv2. Контроллеры домена принимают проверку подлинности LM, NTLM и NTLMv2.
Отправка & NTLM LM — используйте безопасность сеансов NTLMv2 при согласовании	Клиентские устройства используют проверку подлинности LM и NTLM и используют безопасность сеансов NTLMv2, если сервер поддерживает ее. Контроллеры домена принимают проверку подлинности LM, NTLM и NTLMv2.	1
Отправка только ответа NTLM	Клиентские устройства используют проверку подлинности NTLMv1 и используют безопасность сеансов NTLMv2, если сервер поддерживает ее. Контроллеры домена принимают проверку подлинности LM, NTLM и NTLMv2.	2
Отправка только ответа NTLMv2	Клиентские устройства используют проверку подлинности NTLMv2 и используют безопасность сеансов NTLMv2, если сервер поддерживает ее. Контроллеры домена принимают проверку подлинности LM, NTLM и NTLMv2.	3
Отправьте только ответ NTLMv2. Отказ от LM	Клиентские устройства используют проверку подлинности NTLMv2 и используют безопасность сеансов NTLMv2, если сервер поддерживает ее. Контроллеры домена отказываются принимать проверку подлинности LM, и они принимают только проверку подлинности NTLM и NTLMv2.	4
Отправьте только ответ NTLMv2. Отказ от & NTLM	Клиентские устройства используют проверку подлинности NTLMv2 и используют безопасность сеансов NTLMv2, если сервер поддерживает ее. Контроллеры домена отказываются принимать проверку подлинности LM и NTLM, и они будут принимать только проверку подлинности NTLMv2.	5

Значения по умолчанию

В следующей таблице перечислены фактические и эффективные значения по умолчанию для этой политики. Значения по умолчанию также можно найти на странице свойств политики.

Тип сервера или объект групповой политики	Значение по умолчанию
Default Domain Policy	Не определено
Политика контроллера домена по умолчанию	Не определено
Параметры по умолчанию для автономного сервера	Отправка только ответа NTLMv2
Dc Effective Default Параметры	Отправка только ответа NTLMv2
Действующие параметры по умолчанию для рядового сервера	Отправка только ответа NTLMv2
Действующие параметры по умолчанию для клиентского компьютера	Не определено

Дополнительная информация

Пользователи не могут войти, если Office 365 использует AD FS и проверка подлинности на основе форм отключена на сервере AD FS. В этой ситуации пользователи получают следующее сообщение об ошибке:

В определенных конфигурациях AD FS администратор может не включить проверку подлинности на основе форм на сервере AD FS. Это предотвращает Windows, которые работают Office, войти в систему по мере необходимости процесса проверки подлинности.

Чтобы устранить эту проблему, установите AD FS для использования проверки подлинности на основе форм в качестве вторичной формы проверки подлинности. Для этого выполните соответствующие действия для используемой версии.

Примечание

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

При использовании AD FS 2.0

Включить проверку подлинности на основе форм с помощью действий в AD FS 2.0. Какизменить локальный тип проверки подлинности.

Если вы используете AD FS в Windows Server 2012 R2

Выполните приведенные ниже действия.

В диспетчере серверов на сервере AD FS 3.0 щелкните Инструменты и нажмите кнопку Управление AD FS.
В оснастке AD FS щелкните Политики проверки подлинности.
В разделе Основная проверка подлинности нажмите кнопку Изменить рядом с глобальными Параметры.
В диалоговом окне Изменить глобальную политику проверки подлинности щелкните вкладку Primary.
В разделах Extranet и Intranet выберите поле проверки подлинности форм.

Проблема: сбой единого входного компьютера (SSO) с AD FS

Настольный SSO — это процесс, используемый для получения бесшовного входного Office 365 ресурсов с помощью AD FS с компьютера, подключитого к домену, который находится в сети компании. При сбой SSO на рабочем столе пользователи могут не активировать Приложения Microsoft 365 для предприятий или пользователям может быть предложено использовать логотип на основе форм, даже если они используют присоединились к доменным компьютерам из сети компании.

Современная проверка подлинности (ADAL) с помощью AD FS требует включения конечной точки /adfs/services/trust/13/windowstransport.

Чтобы включить конечную точку, запустите следующую команду Windows PowerShell на сервере AD FS:

настройка основной проверки подлинности глобально в Windows Server 2012 R2

В диспетчере сервера щелкните Средства и выберите Управление AD FS.
В AD FS оснастке щелкните политики проверки подлинности.
в разделе основная проверка подлинности щелкните изменить рядом с параметром глобальный Параметры. Можно также щелкнуть правой кнопкой мыши политики проверки подлинностии выбрать пункт изменить глобальную основную проверку подлинностиили в области действия выберите изменить глобальную основную проверку подлинности.
В окне изменение политики глобальной проверки подлинности на главной вкладке можно настроить следующие параметры в рамках глобальной политики проверки подлинности.
- Методы проверки подлинности, используемые для основной проверки подлинности. В экстрасети и интрасетиможно выбрать доступные методы проверки подлинности.
- Проверка подлинности устройства с помощью флажка включить проверку подлинности устройства . Дополнительные сведения см. в разделе Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

Современная проверка подлинности

Современная проверка подлинности — это общий термин для сочетания методов проверки подлинности и авторизации, которые включают:

Методы проверки подлинности: многофакторная проверка подлинности; Проверка подлинности на основе сертификата клиента.
Методы авторизации: реализация Microsoft open Authorization (OAuth).

Современная проверка подлинности включена с помощью библиотеки проверки подлинности Active Directory (ADAL). Проверка подлинности на основе ADAL — это то, Outlook для iOS и Android используется для доступа Exchange Online почтовых ящиков в Microsoft 365 или Office 365. Проверка подлинности ADAL, используемая приложениями Office на настольных и мобильных устройствах, включает вход пользователей непосредственно в Azure Active Directory, который является поставщиком удостоверений для Microsoft 365 и Office 365, вместо предоставления учетных данных Outlook.

Проверка подлинности на основе ADAL использует OAuth для современных учетных записей с поддержкой проверки подлинности (Microsoft 365 или Office 365 учетных записей или учетных записей локального использования гибридной современной проверки подлинности). Он также обеспечивает безопасный механизм доступа Outlook для iOS и Android для доступа к электронной почте, не требуя доступа к учетным данным пользователей. При входе пользователь сдает проверку подлинности непосредственно с помощью Azure Active Directory и получает взамен пару маркеров доступа и обновления. Маркер доступа предоставляет Outlook для iOS и Android доступ к соответствующим ресурсам Microsoft 365 или Office 365 (например, к почтовому ящику пользователя). Маркер обновления используется для получения нового доступа или обновления пары маркеров по истечении срока действия текущего маркера доступа. OAuth предоставляет Outlook с защищенным механизмом доступа к Microsoft 365 или Office 365 без необходимости или хранения учетных данных пользователя. Дополнительные сведения см. в записи в блоге Office Новые параметры доступа и безопасности для Outlook для iOS и Android.

Сведения о сроках служб маркеров см. в платформа удостоверений Майкрософт. Значения срока службы маркера могут быть скорректированы; Дополнительные сведения см. в ссылке Настройка управления сеансом проверки подлинности с условным доступом. Если вы решите сократить срок службы маркеров, вы также можете снизить производительность Outlook для iOS и Android, так как меньший срок службы увеличивает количество раз, когда приложение должно приобрести новый маркер доступа.

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

Для федераированной модели удостоверений локальному поставщику удостоверений необходимо отправить утверждения об истечении срока действия пароля в Azure Active Directory, в противном случае Azure Active Directory не сможет действовать по истечении срока действия пароля. Дополнительные сведения см. в дополнительных сведениях: Настройка AD FS для отправкиутверждений об истечении срока действия пароля.
Синхронизация хэша паролей не поддерживает истечение срока действия пароля. Этот сценарий означает, что приложения, которые ранее получили пару маркеров доступа и обновления, будут работать до превышения срока службы пары маркеров или изменения пароля пользователем. Дополнительные сведения см. в
Для сквозной проверки подлинности требуется включить возвращение пароля в AAD Подключение. Дополнительные сведения см. в Azure Active Directory сквозной проверки

По истечении срока действия маркера клиент попробует получить новый маркер доступа с помощью маркера обновления, но так как пароль пользователя был изменен, маркер обновления станет недействительным (предполагается, что выполнялась синхронизация службы каталогов между локальной средой и Azure Active Directory). Недействительный маркер обновления заставит пользователя повторно действовать, чтобы получить новый маркер доступа и обновить пару маркеров.

Общие сведения

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

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

Уникальный идентификатор (имя пользователя или идентификатор локального сервера Многофакторной идентификации).
Имя и фамилия (необязательно).
Адрес электронной почты (необязательно)
Номер телефона (при аутентификации посредством голосового вызова или SMS).
Маркер устройства (при аутентификации с помощью мобильного приложения).
Режим проверки подлинности
Результат проверки подлинности
Имя сервера Многофакторной идентификации
IP-адрес сервера Многофакторной идентификации.
IP-адрес клиента (если он доступен).

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

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

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

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

В США мы используем следующие короткие коды SMS:

97671
69829
51789
99399

В Канаде мы используем следующие короткие коды SMS:

759731
673801

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

Короткие коды стран и регионов не поддерживаются помимо США и Канады.