Создание устойчивой стратегии управления доступом с помощью идентификатора Microsoft Entra

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

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

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

Основное руководство

В этом документе четыре основных вывода:

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

Перед сбоем

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

Зачем вам нужно устойчивое управление доступом?

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

• Блокировка администратора: администраторы не могут управлять клиентом или службами.
• Блокировка пользователя: у пользователей нет доступа к приложениям и ресурсам.

Непредвиденный случай блокировки администратора

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

Уменьшение риска блокировки пользователя

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

Рекомендации корпорации Майкрософт

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

• Подготовьте несколько методов проверки подлинности для каждого пользователя, который использует различные каналы связи, например приложение Microsoft Authenticator (интернет-интерфейс), токен OATH (созданный на устройстве) и SMS (телефония).
• Разверните Windows Hello для бизнеса на устройствах Windows 10, чтобы соответствовать требованиям MFA непосредственно после входа в систему.
• Используйте доверенные устройства с помощью гибридного соединения Microsoft Entra или Microsoft Intune. Доверенные устройства улучшают взаимодействие с пользователем, так как само доверенное устройство может удовлетворить строгие требования к проверке подлинности политики без вызова MFA пользователю. Тогда MFA потребуется при регистрации нового устройства и при доступе к приложениям или ресурсам с ненадежных устройств.
• Используйте Защита идентификации Microsoft Entra политики на основе рисков, которые препятствуют доступу, если пользователь или вход подвергаются риску вместо фиксированных политик MFA.
• Если вы защищаете VPN-доступ с помощью расширения NPS многофакторной проверки подлинности Microsoft Entra, рассмотрите возможность федеративного VPN-решения в качестве приложения SAML и определите категорию приложений , как показано ниже.

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

Набор политик устранения рисков условного доступа:

• Политика 1. Блокировка доступа к пользователям за пределами целевых групп
  • Пользователи и группы: включает всех пользователей. исключает AppUsers, CoreAdmins и EmergencyAccess
  • Облачные приложения: включает все приложения
  • Условия: нет.
  • Предоставление управления: блокировка
• Политика 2: предоставление доступа к AppUsers, требующее MFA ИЛИ доверенное устройство.
  • Пользователи и группы: включает AppUsers. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: включает все приложения
  • Условия: нет.
  • Управление предоставлением: предоставление доступа, требование многофакторной проверки подлинности, требование соответствия устройства. Для нескольких элементов управления: требуется один из выбранных элементов управления.

Непредвиденные случаи для блокировки пользователя

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

Распознавание вашего воздействия во время сбоя помогает снизить риск и является критически важной частью вашего процесса планирования. Чтобы создать план на непредвиденные случаи, сначала определите следующие бизнес-требования вашей организации:

1. Заранее определите критически важные приложения: к каким приложениям необходимо предоставить доступ, даже с более низким состоянием риска или безопасности? Составьте список этих приложений и убедитесь, что все другие заинтересованные лица (бизнес, безопасность, юристы, руководство) согласны с тем, что если все управление доступом исчезнет, эти приложения все равно должны продолжать работу. Скорее всего, вы собираетесь в конечном итоге с категориями:
   • Категория 1 критически важных приложений, которые не могут быть недоступны в течение более чем нескольких минут, например приложения , которые напрямую влияют на доход организации.
   • Категория 2 — важные приложения, которые должны быть доступны бизнесу в течение нескольких часов.
   • Категория 3 — приложения с низким приоритетом, которые могут выдержать сбой на несколько дней.
2. Для приложений категории 1 и 2 корпорация Майкрософт рекомендует предварительно спланировать тип доступа, который требуется разрешить:
   • Хотите ли вы разрешить полный доступ или ограниченный сеанс, например ограничение загрузок?
   • Хотите ли вы разрешить доступ к части приложения, но не ко всему приложению?
   • Хотите ли вы разрешить доступ информационному работнику и заблокировать доступ администратора, пока контроль доступа не будет восстановлен?
3. Для этих приложений Корпорация Майкрософт также рекомендует спланировать способы доступа, которые вы намеренно откроете и какие из них вы закроете:
   • Хотите ли вы разрешить лишь браузеру получать доступ и блокировать клиентов с расширенными возможностями, которые могут сохранять автономные данные?
   • Хотите ли вы разрешить доступ только для внутренних пользователей корпоративной сети и заблокировать внешних пользователей?
   • Хотите ли вы разрешить доступ из определенных стран или регионов только во время сбоев?
   • Хотите ли вы использовать политики на случай непредвиденных ситуаций, особенно для критически важных приложений, для сбоя или успеха, если альтернативный контроль доступа недоступен?

Рекомендации корпорации Майкрософт

Политика условного доступа на случай непредвиденных обстоятельств — это политика резервного копирования, которая исключает многофакторную проверку подлинности Microsoft Entra, сторонние средства MFA, элементы управления на основе рисков или устройств. Чтобы свести к минимуму непредвиденное прерывание при включенной политике на случай непредвиденных обстоятельств, когда политика не используется она должна оставаться в режиме только отчета. Администраторы могут отслеживать потенциальное воздействие политик на непредвиденные случаи с помощью книги условного доступа. Затем, когда в организации решат активировать план на непредвиденные случаи, администраторы могут включить эту политику и отключить обычные политики на основе контроля.

• Настройте набор резервных политик, если нарушение доступа к одному типу учетных данных или одному механизму контроля доступа влияет на доступ к вашим приложениям. Настройте политику в режиме только отчетов, которая требует присоединения к домену в качестве элемента управления, в качестве резервной копии для активной политики, для которой требуется сторонний поставщик MFA.
• Уменьшите риск угадывание паролей плохих субъектов, если MFA не требуется, следуя рекомендациям в техническом документе руководства по паролям.
• Разверните microsoft Entra Self-Service Password Reset (SSPR) и Microsoft Entra Password Protection , чтобы убедиться, что пользователи не используют общий пароль и условия, которые вы решили запретить.
• Используйте политики, ограничивающие доступ в приложениях, если определенный уровень проверки подлинности не достигнут, а не просто вернуться к полному доступу. Например:
  • Настройте политику резервного копирования, которая отправляет утверждение ограниченного сеанса в Exchange и SharePoint.
  • Если ваша организация использует Microsoft Defender for Cloud Apps, попробуйте вернуться к политике, которая применяет этот брокер, а затем разрешите доступ только для чтения, но не для отправки.
• Присвойте политикам имя, чтобы легко найти их во время сбоя. Включите следующие элементы в имя политики:
  • Номер метки для политики.
  • Текст для отображения этой политики только в аварийном режиме. Пример. ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ
  • Нарушение, к которому оно относится. Пример. Во время нарушения работы MFA.
  • Порядковый номер для отображения порядка активации политик.
  • Приложения, к которым он применяется.
  • Элементы управления, которые будут применены.
  • Требуемые условия.

Этот стандарт именования для политик на случай непредвиденных обстоятельств выглядит следующим образом:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

Следующий пример. Пример A — политика условного доступа на случай непредвиденных обстоятельств для восстановления доступа к критически важным приложениям для совместной работы является обычным корпоративным непредвиденным случаем. В этом сценарии организации обычно требуется многофакторная проверка подлинности для всех доступа Exchange Online и SharePoint Online, а нарушение в этом случае — поставщик MFA для клиента имеет сбой (будь то многофакторная проверка подлинности Microsoft Entra, локальный поставщик MFA или сторонний MFA). Эта политика устраняет этот сбой, позволяя конкретным целевым пользователям получать доступ к этим приложениям с доверенных устройств Windows только при доступе к приложению из доверенной корпоративной сети. Она также исключит из этих ограничений учетные записи для экстренных ситуаций и основных администраторов. Затем целевые пользователи получат доступ к Exchange Online и SharePoint Online, тогда как другие пользователи по-прежнему не будут иметь доступ к приложениям из-за сбоя. В этом примере требуется именованное сетевое расположение CorpNetwork и группа безопасности EmergencyyAccess с целевыми пользователями, группа с именем Core Администратор с основными администраторами и группа с именем EmergencyAccess с учетными записями аварийного доступа. На случай непредвиденных обстоятельств для обеспечения желаемого доступа необходимы четыре политики.

Пример A — политики условного доступа на случай непредвиденных обстоятельств для восстановления доступа к критически важным приложениям для совместной работы:

• Политика 1. Требовать присоединенные к домену устройства для Exchange и SharePoint
  • Имя: EM001 — ВКЛЮЧЕНИЕ В ЧРЕЗВЫЧАЙНОЙ СИТУАЦИИ: нарушение MFA[1/4] — Exchange SharePoint — требуется гибридное соединение Microsoft Entra
  • Пользователи и группы: включает доступ на случай непредвиденных обстоятельств. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: Exchange Online и SharePoint Online
  • Условия: любые
  • Предоставление контроля: требуется присоединение к домену
  • Состояние: только отчет
• Политика 2. Блокировка платформ, отличных от Windows
  • Имя: EM002 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: прерывание MFA [2/4] — Exchange SharePoint — блокирование доступа, кроме Windows.
  • Пользователи и группы: включает всех пользователей. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: Exchange Online и SharePoint Online
  • Условия: платформа устройства включает все платформы, кроме Windows
  • Предоставление управления: блокировка
  • Состояние: только отчет
• Политика 3. Блокировка сетей, отличных от CorpNetwork
  • Имя: EM003 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: нарушение MFA [3/4] — Exchange SharePoint — блокировка доступа, кроме корпоративной сети
  • Пользователи и группы: включает всех пользователей. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: Exchange Online и SharePoint Online
  • Условия: расположения включают любое расположение, кроме CorpNetwork
  • Предоставление управления: блокировка
  • Состояние: только отчет
• Политика 4. Явно блокировать EAS
  • Имя: EM004 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: прерывание MFA [4/4]-Exchange- блокирование EAS для всех пользователей
  • Пользователи и группы: включает всех пользователей
  • Облачные приложения: включает Exchange Online
  • Условия: клиентские приложения: Exchange Active Sync
  • Предоставление управления: блокировка
  • Состояние: только отчет

Порядок активации:

1. Исключите ContingencyAccess, CoreAdmins и EmergencyAccess из существующей политики MFA. Убедитесь в том, что пользователь в ContingencyAccess может получить доступ к SharePoint Online и Exchange Online.
2. Включение политики 1. Проверка пользователей на устройствах, присоединенных к домену, которые не входят в группы исключений, могут получить доступ к Exchange Online и SharePoint Online. Убедитесь в том, что пользователи группы "Исключить" могут получить доступ к SharePoint Online и Exchange с любого устройства.
3. Включение политики 2. Проверка пользователей, которые не входят в группу исключений, не могут попасть в SharePoint Online и Exchange Online с мобильных устройств. Убедитесь в том, что пользователи группы "Исключить" могут получить доступ к SharePoint и Exchange с любого устройства (Windows/iOS/Android).
4. Включение политики 3. Проверка пользователей, которые не входят в группы исключений, не могут получить доступ к SharePoint и Exchange из корпоративной сети, даже с присоединенным к домену компьютером. Убедитесь в том, что пользователи группы "Исключить" могут получить доступ к SharePoint и Exchange с любой сети.
5. Включение политики 4. Убедитесь, что все пользователи не могут получать Exchange Online из собственных почтовых приложений на мобильных устройствах.
6. Отключите существующую политику MFA для SharePoint Online и Exchange Online.

В этом примере пример В — политики условного доступа на случай непредвиденных обстоятельств, которые разрешают мобильный доступ к Salesforce, восстанавливается доступ бизнес-приложения. В этом сценарии клиенту обычно требуется доступ к sales employees to Salesforce (настроенный для единого входа с помощью Идентификатора Microsoft Entra) с мобильных устройств, чтобы разрешить доступ только с соответствующих устройств. Нарушение в этом случае заключается в том, что существует проблема с оценкой соответствия устройств и сбой происходит в конфиденциальное время, когда команда продаж нуждается в доступе к Salesforce для закрытия сделок. Эти политики непредвиденных обстоятельств предоставляют критически важный доступ пользователей к Salesforce с мобильного устройства, чтобы они могли продолжать закрывать сделки и не нарушать бизнес. В этом примере SalesforceContingency содержит всех сотрудников отдела продаж, которым необходимо сохранить доступ, а SalesAdmins — необходимых администраторов Salesforce.

Пример B — политики условного доступа на случай непредвиденных обстоятельств:

• Политика 1. Блокировать всех не в команде SalesContingency
  • Имя: EM001 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: нарушение соответствия устройства [1/2] — Salesforce — блокировка всех пользователей, кроме SalesforceContingency
  • Пользователи и группы: включает всех пользователей. исключает SalesAdmins и SalesforceContingency
  • Облачные приложения: Salesforce
  • Условия: Нет
  • Предоставление управления: блокировка
  • Состояние: только отчет
• Политика 2. Блокировать группу продаж от любой платформы, отличной от мобильных устройств (чтобы уменьшить область атаки)
  • Имя: EM002 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ — нарушение соответствия устройства [2/2] — Salesforce — блокировка всех платформ, за исключением iOS и Android
  • Пользователи и группы: включает SalesforceContingency. исключает SalesAdmins
  • Облачные приложения: Salesforce
  • Условия: платформа устройства включает все платформы, кроме iOS и Android
  • Предоставление управления: блокировка
  • Состояние: только отчет

Порядок активации:

1. Исключите SalesAdmins и SalesforceContingency из существующей политики соответствия устройств для Salesforce. Убедитесь в том, что пользователь группы SalesforceContingency имеет доступ к Salesforce.
2. Включение политики 1. Проверка пользователей за пределами SalesContingency не может получить доступ к Salesforce. Убедитесь в том, что пользователи SalesAdmins и SalesforceContingency могут получить доступ к Salesforce.
3. Включение политики 2. Проверка пользователей в группе SalesContingency не может получить доступ к Salesforce с ноутбуков Windows или Mac, но по-прежнему может получить доступ с мобильных устройств. Убедитесь в том, что SalesAdmin может получить доступ к Salesforce с любого устройства.
4. Отключите существующую политику соответствия устройств для Salesforce.

Непредвиденные ситуации для блокировки пользователей из локальных ресурсов (расширение NPS)

Если вы защищаете VPN-доступ с помощью расширения NPS многофакторной проверки подлинности Microsoft Entra, рассмотрите возможность федеративного VPN-решения в качестве приложения SAML и определите категорию приложений , как показано ниже.

Если вы развернули расширение NPS многофакторной проверки подлинности Microsoft Entra для защиты локальных ресурсов, таких как VPN и шлюз удаленных рабочих столов, с MFA, необходимо заранее рассмотреть, если вы готовы отключить MFA в случае чрезвычайной ситуации.

В этом случае можно отключить расширение NPS, в результате сервер NPS будет проверять только первичную проверку подлинности и не будет применять MFA для пользователей.

Отключить расширение NPS:

• Экспортируйте раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters в качестве резервной копии.
• Удалите значения реестра для AuthorizationDLLs и ExtensionDLLs, но не для ключа параметров.
• Перезапустите службу сетевой политики (IAS), чтобы изменения вступили в силу.
• Определите, успешно ли выполнена основная проверка подлинности для VPN.

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

• Импортируйте раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters из резервной копии.
• Перезапустите службу сетевой политики (IAS), чтобы изменения вступили в силу.
• Определите, успешно ли выполнена первичная проверка подлинности и дополнительная проверка подлинности для VPN.
• Проверьте NPS-сервер и журнал VPN, чтобы определить, какие пользователи зарегистрировались в системе во время аварийного окна.

Развертывание синхронизации хэша паролей, даже если вы федеративны или используете сквозную проверку подлинности

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

• Ваша организация использует гибридное решение для идентификации со сквозной проверкой подлинности или федерацией.
• Ваши локальные системы идентификации (например, Active Directory, AD FS или зависимый компонент) недоступны.

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

Рекомендации корпорации Майкрософт

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

Во время сбоя

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

1. Включите ваши политики на случай непредвиденных обстоятельств, которые предоставляют целевым пользователям доступ к определенным приложениям из определенных сетей.
2. Отключите свои обычные политики на основе контроля.

Рекомендации корпорации Майкрософт

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

1. Документировать каждое изменение и предыдущее состояние (как часть вашей стратегии управления изменениями), чтобы иметь возможность откатывать любые непредвиденные обстоятельства, которые вы внедрили, как только управление доступом будет полностью рабочим.
2. Предполагать, что злоумышленники будут пытаться собрать пароли с помощью атаки путем распыления пароля или фишинговых атак, пока отключена MFA. Кроме того, у плохих субъектов уже могут быть пароли, которые ранее не предоставили доступ к любому ресурсу, который можно попытаться выполнить во время этого окна. Для критически важных пользователей, таких как руководители, вы можете частично снизить этот риск, сбросив перед отключением MFA их пароли.
3. Архивировать все действия по входу в систему, чтобы определить, кто к чему имеет доступ при отключенной MFA.
4. Рассмотрите все сообщения об обнаружении рисков, пока открыто это окно.

После сбоя

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

1. Включите обычные политики.
2. Отключите политики на непредвиденные случаи и вернитесь обратно в режим "только отчеты".
3. Откатите любые другие изменения, которые вы сделали и задокументировали во время сбоя.
4. Если вы использовали учетную запись для аварийного доступа, не забудьте повторно создать учетные данные и физически защитить детали новых учетных данных как часть процедур учетной записи для аварийного доступа.
5. Продолжайте рассматривать все сообщения об обнаружении рисков после прерывания работы службы на предмет подозрительной активности.
6. Отмените все маркеры обновления, выданные для целевого набора пользователей. Отмена всех токенов обновления важна для привилегированных учетных записей, используемых во время сбоя. Это заставит их повторно пройти проверку подлинности и получить контроль над восстановленными политиками.

Параметры аварийного режима

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

• Если у вас есть исходящий IP-адрес корпоративной сети, вы можете добавить его в качестве доверенных IP-адресов, чтобы включить проверку подлинности только в корпоративной сети.
• Если у вас нет перечня исходящих IP-адресов или вам нужно включить доступ внутри и за пределами корпоративной сети, вы можете добавить все адресное пространство IPv4 в качестве доверенных IP-адресов, указав 0.0.0.0/1 и 128.0.0.0/1.

Подробнее

• Документация по проверке подлинности Microsoft Entra
• Управление учетными записями администратора аварийного доступа в идентификаторе Microsoft Entra
• Настройка именованных расположений в идентификаторе Microsoft Entra
  • Set-MsolDomainFederationSettings
• Настройка гибридных устройств, присоединенных к Microsoft Entra
• Руководство по развертыванию Windows Hello для бизнеса
  • Password Guidance - Microsoft Research (Руководство о паролях — Microsoft Research)
• Каковы условия условного доступа Microsoft Entra?
• Что такое элементы управления доступом в условном доступе Microsoft Entra?
• Режим условного доступа "только отчет"