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

Статья
01/04/2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если пользователь обновляется в идентификаторе 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 P2 или Управление идентификацией Microsoft Entra
- Лицензия Enterprise Mobility + Security E5.
Вам потребуется соответствующая административная роль. Если вы впервые выполняете эти действия, вам потребуется роль глобального администратора для авторизации использования Microsoft Graph PowerShell в арендаторе.
Приложению требуется по крайней мере один субъект-служба в клиенте:
- Если приложение использует каталог LDAP, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в каталоги LDAP с помощью раздела для скачивания, установки и настройки пакета агента подготовки Microsoft Entra Connect.
- Если приложение использует базу данных SQL, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей к приложениям на основе SQL с помощью раздела для скачивания, установки и настройки пакета агента подготовки Microsoft Entra Connect.
- Если приложение использует службы SAP Cloud Identity Services или является облачным приложением, поддерживающим протокол SCIM, и приложение еще не настроено в клиенте, то далее в этом руководстве вы зарегистрируете приложение из коллекции приложений.
- Если приложение находится в локальной среде и поддерживает протокол SCIM, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей к локальным приложениям на основе SCIM.

Сбор существующих пользователей из приложения

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

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

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

В этом разделе описываются четыре подхода, которые показано, как получить список пользователей в файле с разделием запятыми (CSV-файл):

Из каталога LDAP
Из базы данных SQL Server
Из другой базы данных на основе SQL
Из облачных удостоверений SAP

Сбор существующих пользователей из приложения, использующего каталог LDAP

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

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

Например, эта команда создаст CSV-файл в текущем каталоге файловой системы с userPrincipalName атрибутом каждого человека в каталоге LDAP:
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
При необходимости перенесите CSV-файл со списком пользователей в систему, где установлены командлеты Microsoft Graph PowerShell.
Продолжайте чтение на странице подтверждения идентификатора Microsoft Entra, где пользователи соответствуют пользователям из раздела приложения далее в этой статье.

Сбор существующих пользователей из таблицы базы данных приложения с помощью мастера SQL Server

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

Для начала получите список пользователей из таблиц. Большинство баз данных позволяют экспортировать содержимое таблиц в файлы стандартных форматов, например в CSV-файл. Если приложение использует базу данных SQL Server, можно применить мастер импорта и экспорта SQL Server для экспорта частей базы данных. Если у вас нет служебной программы для используемой базы данных, можно применять драйвер ODBC с PowerShell, как описано в следующем разделе.

Войдите в систему, в которой установлен SQL Server.
Запустите мастер импорта и экспорта для SQL Server 2019 (64-разрядную версию) или эквивалент для используемой базы данных.
Выберите существующую базу данных в качестве источника.
Выберите Назначение "Неструктурированный файл". Укажите имя файла и для параметра Кодовая страница укажите значение 65001 (UTF-8).
Завершите работу мастера и выберите немедленный запуск.
Подождите, пока завершится выполнение.
При необходимости перенесите CSV-файл со списком пользователей в систему, где установлены командлеты Microsoft Graph PowerShell.
Продолжайте чтение на странице подтверждения идентификатора Microsoft Entra, где пользователи соответствуют пользователям из раздела приложения далее в этой статье.

Сбор существующих пользователей из таблицы базы данных приложения с помощью PowerShell

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

Войдите в систему, в которой установлен или будет установлен агент подготовки.
Откройте средство PowerShell.
Создайте строку подключения для подключения к системе базы данных.

Компоненты строки подключения будут разными в зависимости от требований базы данных. Если вы используете SQL Server, просмотрите список ключевых слов и атрибутов для строки подключения и имени DSN.

Если вы используете другую базу данных, необходимо добавить обязательные ключевые слова для подключения к этой базе данных. Например, если в базе данных используется полный путь к файлу имени DSN, идентификатор пользователя и пароль, создайте строку подключения с помощью следующих команд:
```
$filedsn = "c:\users\administrator\documents\db.dsn"
$db_cs = "filedsn=" + $filedsn + ";uid=p;pwd=secret"
```
Откройте подключение к базе данных, используя следующие команды и передав в них строку подключения:
```
$db_conn = New-Object data.odbc.OdbcConnection
$db_conn.ConnectionString = $db_cs
$db_conn.Open()
```
Создайте SQL-запрос для получения пользователей из таблицы базы данных. Обязательно включите столбцы, которые будут использоваться для сопоставления пользователей в базе данных приложения с этими пользователями в идентификаторе Microsoft Entra. Столбцы могут содержать идентификатор сотрудника, имя учетной записи или адрес электронной почты.

Если пользователи находятся в таблице базы данных с именем USERS и содержат столбцы name и email, введите следующую команду:
```
$db_query = "SELECT name,email from USERS"
```
Отправьте этот запрос в базу данных через подключение:
```
$result = (new-object data.odbc.OdbcCommand($db_query,$db_conn)).ExecuteReader()
$table = new-object System.Data.DataTable
$table.Load($result)
```
Результатом является список строк, представляющих пользователей, полученных из запроса.

Запишите результат в CSV-файл:

$out_filename = ".\users.csv"
$table.Rows | Export-Csv -Path $out_filename -NoTypeInformation -Encoding UTF8

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

Сбор существующих пользователей из облачных служб удостоверений SAP

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

Войдите в консоль https://<tenantID>.accounts.ondemand.com/admin администрирования sap Cloud Identity Services или https://<tenantID>.trial-accounts.ondemand.com/admin пробную версию.
Перейдите к разделу "Пользователи и авторизация экспортируют пользователей>".
Выберите все атрибуты, необходимые для сопоставления пользователей Microsoft Entra с пользователями в SAP. К ним относятся SCIM IDи emailsuserNameдругие атрибуты, которые вы можете использовать в системах SAP.
Выберите "Экспорт " и дождитесь скачивания CSV-файла в браузере.
Если у этой системы нет установленных командлетов Microsoft Graph PowerShell или нет подключения к идентификатору Microsoft Entra, перенесите CSV-файл, содержащий список пользователей, в систему с установленными командлетами Microsoft Graph PowerShell.

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

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

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

Получение идентификаторов пользователей в идентификаторе Microsoft Entra

В этом разделе показано, как взаимодействовать с идентификатором Microsoft Entra с помощью командлетов Microsoft Graph PowerShell .

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

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

Откройте средство PowerShell.
Если у вас еще нет установленных модулей Microsoft Graph PowerShell, установите модуль Microsoft.Graph.Users и другие модули с помощью следующей команды:
```
Install-Module Microsoft.Graph
```
Если у вас уже установлены модули, убедитесь, что используете последнюю версию:
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Подключитесь к идентификатору Microsoft Entra:

$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

Если вы впервые использовали эту команду, может потребоваться согласие на предоставление этим разрешениям инструментам командной строки Microsoft Graph.
Считайте список пользователей, полученный из хранилища данных приложения, в сеанс PowerShell. Если список пользователей ранее хранился в CSV-файле, вы можете использовать этот командлет PowerShell Import-Csv, предоставив в качестве аргумента имя файла из предыдущего раздела.

Например, если файл, полученный из облачных служб удостоверений SAP, называется Users-exported-from-sap.csv и находится в текущем каталоге, введите следующую команду.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Для другого примера, если вы используете базу данных или каталог, если файл называется users.csv и расположен в текущем каталоге, введите следующую команду:
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Выберите столбец файла users.csv , который будет соответствовать атрибуту пользователя в идентификаторе Microsoft Entra.

Если вы используете службы SAP Cloud Identity Services, то сопоставление по умолчанию — это атрибут userName SAP SCIM с атрибутом userPrincipalNameидентификатора Microsoft Entra ID:
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
В другом примере, если вы используете базу данных или каталог, у вас могут быть пользователи в базе данных, где значение в столбце с именем EMail совпадает со значением атрибута userPrincipalNameMicrosoft Entra:
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```
Получите идентификаторы этих пользователей в идентификаторе Microsoft Entra ID.

В следующем скрипте PowerShell используются значения $dbusers, $db_match_column_name и $azuread_match_attr_name, указанные ранее. Он запрашивает идентификатор Microsoft Entra, чтобы найти пользователя с атрибутом с соответствующим значением для каждой записи в исходном файле. Если в файле есть много пользователей, полученных из исходной облачной службы идентификации SAP, базы данных или каталога, этот сценарий может занять несколько минут. Если у вас нет атрибута в идентификаторе Microsoft Entra, который имеет значение, и необходимо использовать contains или другое выражение фильтра, вам потребуется настроить этот скрипт и в шаге 11 ниже, чтобы использовать другое выражение фильтра.
```
$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}
```

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

Следующий скрипт PowerShell отображает количество записей, которые не удалось найти:

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

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

Например, адрес электронной почты пользователя и userPrincipalName могут быть изменены в идентификаторе Microsoft Entra без mail соответствующего свойства, обновляемого в источнике данных приложения. Также есть вариант, что пользователь уже покинул организацию, но сведения о нем сохранились в источнике данных приложения. Или может быть учетная запись поставщика или суперадминистратор в источнике данных приложения, который не соответствует любому конкретному лицу в идентификаторе Microsoft Entra.
Если пользователи не могли находиться в идентификаторе Microsoft Entra ID или не были активными и не смогли войти, но вы хотите проверить доступ или обновить их атрибуты в SAP Cloud Identity Services, базе данных или каталоге, вам потребуется обновить приложение, соответствующее правило или обновить или создать пользователей Microsoft Entra для них. Дополнительные сведения об изменениях см. в статье об управлении сопоставлениями и учетными записями пользователей в приложениях, которые не совпадают с пользователями в идентификаторе Microsoft Entra.

Если выбрать вариант создания пользователей в идентификаторе Microsoft Entra, вы можете создать пользователей в массовом режиме с помощью одного из следующих вариантов:
- CSV-файл, как описано в разделе массового создания пользователей в Центре администрирования Microsoft Entra
- командлета New-MgUser.
Убедитесь, что эти новые пользователи заполняются атрибутами, необходимыми для идентификатора Microsoft Entra, чтобы позже сопоставить их с существующими пользователями в приложении, а также атрибуты, необходимые идентификатору Microsoft Entra, включая userPrincipalNamemailNickname и displayName. Он userPrincipalName должен быть уникальным среди всех пользователей в каталоге.

Например, у вас могут быть пользователи в базе данных, где значение в столбце с именем EMail является значением, которое вы хотите использовать в качестве имени участника-пользователя Microsoft Entra, значение в столбце Alias содержит псевдоним электронной почты Microsoft Entra ID, а значение в столбце Full name содержит отображаемое имя пользователя:
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
Затем этот скрипт можно использовать для создания пользователей Microsoft Entra для пользователей в sap Cloud Identity Services, в базе данных или каталоге, который не совпадает с пользователями в идентификаторе Microsoft Entra. Обратите внимание, что может потребоваться изменить этот скрипт, чтобы добавить дополнительные атрибуты Microsoft Entra, необходимые в вашей организации, или если это $azuread_match_attr_name не mailNickname userPrincipalNameтак, чтобы предоставить этот атрибут Microsoft Entra.
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

После добавления отсутствующих пользователей в идентификатор Microsoft Entra запустите сценарий из шага 7 еще раз. Затем запустите скрипт из шага 8. Убедитесь, что сообщения об ошибках отсутствуют.

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

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

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

Если приложение использует каталог LDAP, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в каталоги LDAP, чтобы создать новую регистрацию для локального приложения ECMA в идентификаторе Microsoft Entra.
Если приложение использует базу данных SQL, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в приложениях на основе SQL, чтобы создать новую регистрацию для локального приложения ECMA в Идентификаторе Microsoft Entra.
Если вы используете службы SAP Cloud Identity Services, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в облачные службы удостоверений SAP.
Если это облачное приложение, поддерживающее протокол SCIM, можно добавить приложение из коллекции приложений.
Если приложение находится в локальной среде и поддерживает протокол SCIM, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей к локальным приложениям на основе SCIM.

Проверка пользователей, которые еще не назначены приложению

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

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

Например, если корпоративное приложение называется CORPDB1, введите следующие команды:
```
$azuread_app_name = "CORPDB1"
$azuread_sp_filter = "displayName eq '" + ($azuread_app_name -replace "'","''") + "'"
$azuread_sp = Get-MgServicePrincipal -Filter $azuread_sp_filter -All
```
Получите пользователей, которые в настоящее время имеют назначения приложению в идентификаторе Microsoft Entra.

Это создается на основе переменной, заданной $azuread_sp в предыдущей команде.
```
$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```
Сравните список идентификаторов пользователей из предыдущего раздела с теми пользователями, которые сейчас назначены приложению:
```
$azuread_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_not_in_role_list += $id }
}
$azuread_not_in_role_count = $azuread_not_in_role_list.Count
Write-Output "$azuread_not_in_role_count users in the application's data store are not assigned to the application roles."
```
Если число пользователей, не назначенных ролям приложения, равно 0, значит, всем пользователям назначены роли приложения и перед выполнением проверки доступа не требуются дополнительные изменения.

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

У приложения может быть несколько ролей, а субъект-служба может иметь дополнительные роли. Используйте эту команду для перечисления доступных ролей субъекта-службы:
```
$azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User"} | ft DisplayName,Id
```
Выберите из списка соответствующую роль и получите идентификатор этой роли. Например, если роль имеет имя Admin, укажите это значение в следующих командах PowerShell:
```
$azuread_app_role_name = "Admin"
$azuread_app_role_id = ($azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User" -and $_.DisplayName -eq $azuread_app_role_name}).Id
if ($null -eq $azuread_app_role_id) { write-error "role $azuread_app_role_name not located in application manifest"}
```

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

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

Убедитесь, что в настройках приложения для всех пользователей требуется наличие назначений ролей приложения, только выбранные пользователи были подготовлены в приложении.
Если подготовка для приложения не была настроена ранее, настройте ее сейчас (но пока не запускайте):
- Если приложение использует каталог LDAP, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в каталоги LDAP.
- Если приложение использует базу данных SQL, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в приложениях на основе SQL.
- Если приложение использует службы SAP Cloud Identity Services, следуйте инструкциям по настройке идентификатора Microsoft Entra для подготовки пользователей в sap Cloud Identity Services.
- Для других приложений выполните шаги 1–3, чтобы настроить подготовку с помощью API Graph.
Перейдите на вкладку "Свойства " для приложения. Убедитесь, что требуется назначение пользователя? Для параметра "Да" задано значение "Да". При выборе значения Нет все пользователи в каталоге, включая пользователей с внешними удостоверениями, смогут получать доступ к приложению, и выполнить проверку доступа для приложения будет невозможно.
Проверьте сопоставления атрибутов для подготовки к работе с этим приложением. Убедитесь, что для атрибута Microsoft Entra и столбца, используемого в предыдущих разделах для сопоставления, заданы объекты match с помощью этого атрибута .

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

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

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

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

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

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

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

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

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

foreach ($u in $azuread_not_in_role_list) {
   $res = New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -AppRoleId $azuread_app_role_id -PrincipalId $u -ResourceId $azuread_sp.Id 
}

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

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

Запрос идентификатора Microsoft Entra, чтобы получить обновленный список назначений ролей:
```
$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```

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

$azuread_still_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_still_not_in_role_list += $id }
}
$azuread_still_not_in_role_count = $azuread_still_not_in_role_list.Count
if ($azuread_still_not_in_role_count -gt 0) {
   Write-Output "$azuread_still_not_in_role_count users in the application's data store are not assigned to the application roles."
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Поделиться через