Управление существующими пользователями приложения: Microsoft PowerShell

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

Требования к лицензиям

Для использования этой функции требуются лицензии Управление идентификацией Microsoft Entra или Microsoft Entra Suite. Чтобы найти подходящую лицензию для ваших требований, см. основы лицензирования управления идентификацией Microsoft Entra.

Приложение мигрировало на Microsoft Entra ID после использования собственного удостоверяющего поставщика.

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

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

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

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

Приложение, которое не использует Microsoft Entra ID в качестве единственного поставщика идентификационных данных

Во втором сценарии приложение не полагается только на Microsoft Entra ID как на своего поставщика идентификации.

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

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

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

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

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

Если пользователь обновляется в идентификаторе Microsoft Entra, изменения не будут отправлены приложению. И если назначения ролей приложения будут проверяться, пользователь не будет включён в проверку. Чтобы включить в проверку всех пользователей, необходимо создать назначения ролей в приложении для всех пользователей приложения.

Приложение не использует Microsoft Entra ID в качестве поставщика удостоверений и не поддерживает управление учётными записями.

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

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

Приложение использует Microsoft Entra ID в качестве поставщика удостоверений и имеет дополнительные права доступа для пользователей.

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

Затем можно запустить проверки доступа пользователей (UAR) как в ресурсах, подключенных к Microsoft Entra, так и в этих правах доступа. Рецензенты могут легко просматривать и сертифицировать доступ пользователей на портале "Мой доступ", обеспечивая согласованное управление, улучшенную видимость и соответствие всем ресурсам независимо от того, подключены ли они к Microsoft Entra.

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

Терминология

В этой статье показано, как управлять назначениями ролей для приложения с помощью командлетов Microsoft Graph PowerShell. Здесь используется указанная ниже терминология Microsoft Graph.

Диаграмма, на которой показана терминология Microsoft Graph.

В идентификаторе Microsoft Entra субъект-служба (ServicePrincipal) представляет приложение в каталоге конкретной организации. В ServicePrincipal есть свойство AppRoles со списком ролей, поддерживаемых приложением, таких как Marketing specialist. AppRoleAssignment сопоставляет пользователя с субъектом-службой и указывает роль, которую пользователь имеет в этом приложении. Приложение может иметь более одного основного компонента службы, если единый вход в приложение и развертывание приложения обрабатываются отдельно.

Вы также можете использовать пакеты управления правами Microsoft Entra, чтобы предоставить пользователям ограниченный доступ к приложению. В управлении правами AccessPackage содержит одну или несколько ролей ресурсов, потенциально из нескольких субъектов-служб. AccessPackage также имеет назначения (Assignment) для пользователей в пакете доступа.

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

Перед началом

Регистрация приложения

Если приложение уже зарегистрировано в идентификаторе Microsoft Entra, перейдите к следующему шагу.

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

Если приложение использует каталог LDAP, базу данных SQL, облачные службы удостоверений SAP или поддерживает SCIM, то перед созданием новых назначений настройте подготовку пользователей Microsoft Entra в приложении. Настройка подготовки перед созданием назначений позволит Microsoft Entra ID сопоставить пользователей в Microsoft Entra ID с назначениями ролей приложения, связанными с пользователями, уже имеющимися в хранилище данных приложения. Если у вашего приложения есть локальный каталог или база данных для предоставления, а также поддерживается федеративный единый вход, может потребоваться два служебных принципала для представления приложения в каталоге: один для предоставления и один для единого входа. Если ваше приложение не поддерживает автоматическую настройку, продолжайте чтение в следующем разделе.

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

  2. Если предоставление для приложения не настроено, настройте его сейчас (но пока не запускайте).

  3. Перейдите на вкладку "Свойства " для приложения. Убедитесь, что требуется назначение пользователя? Для параметра "Да" задано значение "Да". При выборе значения Нет все пользователи в каталоге, включая пользователей с внешними удостоверениями, смогут получать доступ к приложению, и выполнить проверку доступа для приложения будет невозможно.

  4. Проверьте сопоставления атрибутов для подготовки к работе с этим приложением. Убедитесь, что для атрибута Microsoft Entra и столбца, который вы использовали в предыдущих разделах для сопоставления, установлен параметр Сопоставление объектов по этому атрибуту.

  5. Убедитесь, что существует сопоставление атрибута isSoftDeleted с атрибутом приложения.

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

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

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

Теперь, когда вы предоставили сведения о подключении и соответствующий атрибут в рамках конфигурации подготовки, Microsoft Entra может обнаружить существующих пользователей в приложении. Нажмите кнопку идентификации на странице обзора подготовки. После создания отчета вы получите представление обо всех пользователях в вашем приложении: какие пользователи в приложении совпадают с пользователем Microsoft Entra ID, какие пользователи уже назначены корпоративному приложению в Microsoft Entra ID, и какие пользователи в приложении не совпадают с пользователем Microsoft Entra ID.

Создание назначений ролей приложения в идентификаторе Microsoft Entra

Чтобы Microsoft Entra ID сопоставлял пользователей в приложении с пользователями в Microsoft Entra ID, вам необходимо создать назначения ролей приложения в Microsoft Entra ID. Каждое назначение роли приложения связывает одного пользователя с одной ролью приложения одного субъекта-службы.

Когда назначение роли приложения создается в Microsoft Entra ID для пользователя к приложению, и приложение поддерживает провизирование, то:

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

Если приложение не поддерживает предоставление, то

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

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

  1. Скачайте файл CorrelatedUsers.ps1.

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

    .\Assign-CorrelatedUsers.ps1 -ServicePrincipalId "InputServicePrincipalIdHere" -DryRun

  3. Создайте назначения ролей приложения для всех пользователей, которые сейчас не имеют назначений ролей:

    .\Assign-CorrelatedUsers.ps1 -ServicePrincipalId "InputServicePrincipalIdHere"

  4. Подождите одну минуту, пока изменения будут распространяться в идентификаторе Microsoft Entra.

Убедитесь, что настройка Microsoft Entra соответствует существующим пользователям.

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

  2. Если основной объект службы приложения настроен для предоставления, и состояние предоставления для основного объекта службы выключено, включите его включено. Вы также можете начать подготовку с помощью API Graph.

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

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

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

  5. Проверьте лог подготовки через админцентр Microsoft Entra или Graph API. Отфильтруйте журнал по состоянию Сбой. Если возникают сбои с кодом ошибки DuplicateTargetEntries, это указывает на неоднозначность в правилах сопоставления управления ресурсами, и вам потребуется обновить пользователей Microsoft Entra или правила, используемые для сопоставления, чтобы каждый пользователь Microsoft Entra соответствовал одному пользователю в приложении. Затем отфильтруйте журнал по действию Создать и состоянию Пропущено. Если пользователи пропускались с кодом SkipReason NotEffectivelyEntitled, это может указывать на то, что учетные записи пользователей в идентификаторе Microsoft Entra не совпадали, так как состояние учетной записи пользователя было отключено.

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

Выбор подходящих рецензентов

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

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

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

Перед созданием обзоров убедитесь, что у арендатора достаточно модельных мест для Microsoft Entra ID P2 или Управление идентификацией модели SKU Microsoft Entra ID. Кроме того, убедитесь, что все рецензенты являются активными пользователями, имеющими адреса электронной почты. Когда начинаются проверки доступа, каждый из них проверяет электронное письмо от Microsoft Entra ID. Если у рецензента нет почтового ящика, он не получит сообщение электронной почты при начале проверки или напоминание по электронной почте. И если они заблокированы в аккаунт Microsoft Entra ID, они не смогут выполнить проверку.

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

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

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

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

Теперь, когда существующие пользователи назначены на роль в приложении, вы можете настроить Microsoft Entra ID, чтобы начать проверку этих назначений.

  1. На этом шаге вам потребуется быть в роли глобального администратора или администратора управления удостоверениями.

  2. Следуйте инструкциям в руководстве по созданию проверки доступа для групп и приложений, чтобы создать проверку назначений ролей приложения. Настройте проверку, чтобы применить результаты после завершения. Вы можете создать обзор доступа в PowerShell с помощью командлета New-MgIdentityGovernanceAccessReviewDefinition из модуля Microsoft Graph PowerShell для управления удостоверениями. Дополнительные сведения см. в примерах.

    Примечание.

    Если вы включите помощники по принятию решений для проверки при создании проверки доступа, рекомендации помощников по принятию решений основаны на 30-дневном интервале в зависимости от последней даты входа пользователя в приложение с помощью Microsoft Entra ID.

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

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

  5. Если автоматическое применение не было выбрано при создании проверки изначально, вам потребуется применить результаты проверки по её завершении.

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

  7. После применения результатов Microsoft Entra ID начнет отключать доступ запрещенным пользователям из приложения. На основе руководства о том, сколько времени потребуется для подготовки пользователей, дождитесь, когда в Microsoft Entra начнется деактивация запрещенных пользователей. Следите за состоянием предоставления через портал или API-интерфейсы Graph, чтобы убедиться, что все запрещенные пользователи были успешно удалены.

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

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

Управление доступом с помощью управления правами

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

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

  1. Для этого шага вам потребуется быть в роли глобального администратора или администратора управления удостоверениями, либо иметь делегацию на создание каталога и быть владельцем приложения.
  2. Если у вас еще нет каталога для сценария управления приложениями, создайте каталог в службе управления правами Microsoft Entra. Скрипт PowerShell можно использовать для создания каждогокаталога, как показано в создании каталога с помощью PowerShell.
  3. Заполните каталог необходимыми ресурсами, добавив приложение и все группы Microsoft Entra, которые приложение использует в качестве ресурсов в этом каталоге. Вы можете использовать скрипт PowerShell для добавления каждого ресурса в каталог, как показано на примере добавления приложения в виде ресурса в каталог.
  4. Для каждого из приложений и для каждой из их ролей или групп приложений создайте пакет доступа, который включает в себя роль или группу в качестве ресурса. На этом этапе настройки этих пакетов доступа настройте первую политику назначения пакетов доступа в каждом пакете, как политику для прямого назначения, чтобы только администраторы могли создавать назначения в этой политике, и задайте требования проверки доступа для существующих пользователей, если они имеются, чтобы они не сохраняли доступ на длительный срок. Если у вас много пакетов доступа, можно использовать сценарий PowerShell для создания каждого пакета доступа в каталоге, как показано на примере создания пакета доступа приложения с одной ролью.
  5. Для каждого пакета доступа назначьте существующих пользователей приложения, относящихся к соответствующей роли или состоящих в этой группе, в пакет доступа и его политику прямого назначения. Вы можете напрямую назначить пользователя пакету доступа, используя Центр администрирования Microsoft Entra, или же в массовом порядке с помощью Graph или PowerShell, как показано в разделе о добавлении назначений существующим пользователям.
  6. Если вы настроили проверки доступа в политиках назначения пакетов доступа, то при запуске проверки доступа попросите рецензентов предоставить входные данные. По умолчанию каждый из них получает сообщение электронной почты от Microsoft Entra ID со ссылкой на панель доступа для просмотра назначений пакетов доступа. Когда проверка завершится, следует ожидать, что пользователи, которым было отказано, если такие есть, потеряют свои назначения ролей в приложении в течение нескольких минут. Впоследствии Microsoft Entra ID начнет удалять запрещенных пользователей из приложения. На основе руководства о том, сколько времени потребуется для подготовки пользователей, дождитесь, когда в Microsoft Entra начнется деактивация запрещенных пользователей. Следите за состоянием предоставления через портал или API-интерфейсы Graph, чтобы убедиться, что все запрещенные пользователи были успешно удалены.
  7. Если у вас есть требования к разделению обязанностей, настройте несовместимые пакеты доступа или включите в пакеты для доступа уже существующие группы. Если в вашем сценарии требуется возможность обойти проверку разделения обязанностей, то можно также настроить дополнительные пакеты доступа для таких сценариев переопределения.
  8. Если вы хотите разрешить пользователям, у которых еще нет доступа, запрашивать доступ, создайте в каждом пакете доступа дополнительные политики назначения пакетов доступа, чтобы пользователи могли подавать запросы на доступ. Настройте требования к утверждению и требованиям к периодическому пересмотру доступа в этой политике.

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

  • Last updated on