Планирование развертывания Microsoft Entra для подготовки пользователей с помощью исходных и целевых приложений SAP

Ваша организация использует Microsoft для различных служб Azure или Microsoft 365. Программное обеспечение и службы SAP также могут предоставлять критически важные функции, такие как кадровые ресурсы (HR) и планирование корпоративных ресурсов (ERP) для вашей организации. Вы можете использовать Microsoft Entra для оркестрации удостоверений сотрудников, подрядчиков и других пользователей, а также их доступа к приложениям SAP и не sap.

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

• У вашей организации есть клиент Microsoft Entra в коммерческом облаке с лицензией по крайней мере microsoft Entra ID P1 в этом клиенте. (Некоторые шаги также иллюстрируют использование Управление идентификацией Microsoft Entra функций.)
• Вы являетесь администратором этого клиента.
• У вашей организации есть система источников записей рабочих ролей, которая является SAP SuccessFactors.
• У вашей организации есть компонент SAP ERP Central (ECC), SAP S/4HANA или другие приложения SAP, а также другие приложения, отличные от SAP.
• Вы используете SAP Cloud Identity Services для подготовки и единого входа (SSO) для любых приложений SAP, отличных от SAP ECC.

Обзор

В этом руководстве показано, как подключить Microsoft Entra к авторитетным источникам для списка работников в организации, например SAP SuccessFactors. В нем также показано, как использовать Microsoft Entra для настройки удостоверений для этих работников. Затем вы узнаете, как использовать Microsoft Entra для предоставления сотрудникам доступа к одному или нескольким приложениям SAP, таким как SAP ECC или SAP S/4HANA.

Отправка выполняется так:

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

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

На следующей схеме показана пример топологии, используемая в этом руководстве. В этой топологии рабочие роли представлены в SuccessFactors и должны иметь учетные записи в домене Windows Server Active Directory (Windows Server AD) в Microsoft Entra, SAP ECC и облачных приложениях SAP. В этом руководстве показана организация с доменом Windows Server AD. Однако для этого руководства не требуется Windows Server AD.

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

Планирование интеграции с источниками и целевыми объектами SAP

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

Если вы использовали SAP IDM, вы можете перенести сценарии управления удостоверениями из SAP IDM в Microsoft Entra. Дополнительные сведения см. в статье "Миграция сценариев управления удостоверениями" из SAP IDM в Microsoft Entra.

Определение последовательности подключения приложений и интеграции приложений с Microsoft Entra

Может быть, ваша организация уже интегрировала некоторые приложения с Microsoft Entra для подмножества доступных сценариев интеграции. Например, возможно, вы интегрировали службы sap Cloud Identity Services с Microsoft Entra для единого входа, чтобы получить преимущество условного доступа, но вы по-прежнему полагаетесь на подготовку вручную и отмену подготовки. Кроме того, у вас могут быть такие приложения, как SAP ECC в вашей организации, которые еще не интегрированы с Microsoft Entra.

1. Установите порядок приоритета для интеграции приложений с Microsoft Entra для единого входа и подготовки. Организации обычно начинают интеграцию с программным обеспечением как услуга (SaaS), поддерживающие современные протоколы. Для приложений SAP рекомендуется, чтобы организации, имеющие облачные приложения SAP, начали интеграцию с единым входом и подготовкой интеграции с SAP Cloud Identity Services в качестве по промежуточного слоя. Здесь подготовка пользователей и интеграция единого входа с Microsoft Entra может воспользоваться несколькими приложениями SAP.

2. Убедитесь, что каждое приложение интегрируется с Microsoft Entra. Если приложение указано в качестве одной из целевых систем подготовки облачных служб удостоверений SAP, таких как SAP S/4HANA, вы можете использовать SAP Cloud Identity Services в качестве по промежуточного слоя для мостов единого входа и подготовки от Microsoft Entra к приложению. Если приложение является SAP ECC, вы можете интегрировать Microsoft Entra непосредственно с SAP NetWeaver для единого входа и бизнес-интерфейсов программирования приложений (BAPIs) SAP ECC для подготовки.

   Для приложений, отличных от SAP, следуйте инструкциям в статье "Интеграция приложения с идентификатором Microsoft Entra ID ", чтобы определить поддерживаемые технологии интеграции для единого входа и подготовки для каждого приложения.

3. Соберите все роли и разрешения, которые предоставляет каждое приложение. Некоторые приложения имеют только одну роль. Например, службы SAP Cloud Identity Services имеют только одну роль, пользователь, который доступен для назначения. Облачные службы удостоверений SAP могут считывать группы из идентификатора Microsoft Entra для использования в назначении приложений. Другие приложения могут управлять несколькими ролями с помощью идентификатора Microsoft Entra. Эти роли приложений обычно делают широкие ограничения на доступ, который пользователь с этой ролью имеет в приложении.

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

   Примечание.

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

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

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

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

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

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

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

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

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

   Если у вас уже есть определение роли организации, можно перенести определения ролей организации в Управление идентификацией Microsoft Entra.

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

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

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

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

   Дополнительные сведения о том, как определить политику условного доступа, см. в разделе Планирование развертывания условного доступа.

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

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

Выбор топологии подготовки и проверки подлинности

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

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

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

2. Определите, существуют ли пользователи или должны быть подготовлены в Windows Server AD в дополнение к идентификатору Microsoft Entra. Возможно, у вас уже есть пользователи в Windows Server AD, которые соответствуют вашим сотрудникам в авторитетном источнике кадров. Или, возможно, вы настроили SAP ECC или другие приложения для использования Windows Server с помощью протокола LDAP или Kerberos. В таких ситуациях вы подготавливаете пользователей в Windows Server AD. Затем эти пользователи синхронизируются с идентификатором Microsoft Entra.

3. Проектирование топологии развертывания агента подготовки Microsoft Entra Connect. Если вы используете SuccessFactors и используете Windows Server AD, необходимо установить агент подготовки для подготовки пользователей в этих доменах. Топология развертывания агента подготовки Microsoft Entra Connect зависит от количества клиентов облачных приложений hr и дочерних доменов Active Directory, которые планируется интегрировать. Если у вас несколько доменов Active Directory, важно также учесть, связные они или несвязанные. Дополнительные сведения см. в статье "Проектирование топологии развертывания агента подготовки Microsoft Entra Connect".

4. Определите, будет ли вы использовать несколько контейнеров в Windows Server AD. Если вы используете SuccessFactors и используете Windows Server AD, в каждом домене необходимо определить, организованы ли пользователи, представляющие рабочие роли, в иерархию контейнеров. Некоторые организации могут создавать всех пользователей, представляющих сотрудников в одной organizationalUnitорганизации; в других организациях может быть несколько. Дополнительные сведения см. в статье о настройке назначения контейнеров подразделений Active Directory.

5. Решите, следует ли использовать идентификатор Microsoft Entra для подготовки к облачным службам удостоверений SAP или использования облачных удостоверений SAP для чтения из идентификатора Microsoft Entra. Дополнительные сведения о возможностях подготовки Microsoft Entra см. в статье "Автоматизация подготовки пользователей и отмена подготовки пользователей в облачные службы удостоверений SAP" с помощью идентификатора Microsoft Entra. Службы облачных удостоверений SAP также имеют собственный отдельный соединитель для чтения пользователей и групп из идентификатора Microsoft Entra. Дополнительные сведения см. в разделе SAP Cloud Identity Services — подготовка удостоверений — идентификатор Microsoft Entra в качестве исходной системы.

6. Определите, нужно ли подготовить пользователей в SAP ECC. Вы можете подготовить пользователей из идентификатора Microsoft Entra в SAP ECC (ранее SAP R/3) NetWeaver 7.0 или более поздней версии. Если вы используете другие версии SAP R/3, вы по-прежнему можете использовать руководства, указанные в соединителях для Microsoft Identity Manager 2016 , в качестве ссылки на создание собственного шаблона для подготовки.

Убедитесь, что предварительные требования организации выполнены перед настройкой идентификатора Microsoft Entra

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

1. Убедитесь, что идентификатор Microsoft Entra и среда Microsoft Online Services готовы к требованиям соответствия для приложений. Соответствие — это общая ответственность между корпорацией Майкрософт, поставщиками облачных служб и организациями.

2. Убедитесь, что клиент Идентификатора Microsoft Entra правильно лицензирован. Чтобы использовать идентификатор Microsoft Entra для автоматизации подготовки, клиент должен иметь как минимум столько лицензий для Microsoft Entra ID P1, сколько рабочих ролей, поступающих из исходного приложения HR или пользователей (не являющихся участниками), подготовленными.

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

3. Убедитесь, что идентификатор Microsoft Entra уже отправляет свой журнал аудита и при необходимости другие журналы в Azure Monitor. Azure Monitor является необязательным, но полезен для управления доступом к приложениям, так как Microsoft Entra хранит события аудита только в течение 30 дней в журнале аудита. Данные аудита можно хранить дольше, чем этот период хранения по умолчанию. Дополнительные сведения см. в статье о том, как долго хранилище отчетов microsoft Entra ID store?.

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

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

   Вы также должны просмотреть пользователей в ролях Azure в подписках, которые содержат Azure Monitor, Logic Apps и другие ресурсы, необходимые для работы конфигурации Microsoft Entra.

5. Убедитесь, что клиент имеет соответствующую изоляцию. Если ваша организация использует Локальную службу Active Directory и эти домены Active Directory подключены к идентификатору Microsoft Entra, необходимо убедиться, что высоко привилегированные административные операции для облачных служб изолированы от локальных учетных записей. Убедитесь, что вы настроили защиту облачной среды Microsoft 365 от локального компрометации.

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

7. Задокументируйте время существования маркера и параметры сеанса приложения. В конце этого руководства вы интегрируете приложения SAP ECC или SAP Cloud Identity Services с Microsoft Entra для единого входа. Как долго пользователь, которому запрещен доступ, может продолжать использовать федеративное приложение, зависит от времени существования сеанса приложения и времени существования маркера доступа. Время существования сеанса для приложения зависит от самого приложения. Дополнительные сведения об управлении временем существования маркеров доступа см. в статье о времени существования настраиваемых маркеров.

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

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

Если вы используете sap Cloud Identity Services для подготовки к SAP S/4HANA или другим приложениям SAP, убедитесь, что в этих приложениях есть сопоставления для отправки этих атрибутов из идентификатора Microsoft Entra ID через облачные службы удостоверений SAP. Если вы не используете облачные службы удостоверений SAP, перейдите к следующему разделу.

1. Убедитесь, что в каталоге SAP cloud есть схема пользователя, необходимая для облачных приложений SAP. В облачных службах удостоверений SAP каждая целевая система, настроенная, добавляет преобразования из модели данных источника для удостоверений, предоставленных облачным службам удостоверений SAP, в требования целевого объекта. Возможно, вам потребуется изменить эти преобразования в облачных службах удостоверений SAP, чтобы соответствовать тому, как вы планируете моделировать удостоверение, особенно если у вас настроено несколько целевых систем. Затем запишите необходимую схему для Microsoft Entra, чтобы предоставить облачным приложениям SAP через облачные службы SAP Cloud Identity Services.

Определение связи между рабочими записями в системе источников записей и пользователей в Microsoft Entra

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

1. Определите, как сопоставить изменения в системе источника записей для присоединения и выхода событий. Если вы хотите автоматизировать процессы для присоединения к рабочей роли и выхода, необходимо сопоставить сведения о состоянии рабочей роли с атрибутами в Microsoft Entra. Дополнительные сведения см. в разделе "Определение состояния учетной записи пользователя".

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

3. Запишите схему, используемую для корреляции между идентификатором Microsoft Entra и системами записей. Возможно, у вас есть пользователи в Windows Server AD или идентификаторе Microsoft Entra, соответствующие рабочим сотрудникам в SAP SuccessFactors. Если эти пользователи не были созданы идентификатором Microsoft Entra, но с помощью другого процесса, ознакомьтесь со ссылкой на атрибут SAP SuccessFactors и схему пользователя Windows Server или Microsoft Entra, чтобы выбрать, какие атрибуты на пользовательских объектах содержат уникальный идентификатор рабочей роли в SAP SuccessFactors.

   Этот атрибут должен присутствовать с уникальным значением для каждого пользователя, соответствующего рабочей роли, чтобы подготовка входящего трафика Microsoft Entra может определить, какие пользователи уже существуют для рабочих ролей и избегать создания повторяющихся пользователей. Атрибут сопоставления по умолчанию основан на идентификаторе сотрудника. Перед импортом рабочих ролей из источника кадров необходимо убедиться, что значение этого атрибута, например идентификатор сотрудника, заполняется идентификатором Microsoft Entra (для облачных пользователей) и Windows Server AD (для гибридных пользователей) перед началом полной синхронизации и его значение однозначно идентифицирует каждого пользователя. Дополнительные сведения см. в разделе "Определение соответствующих атрибутов " и создание уникального значения атрибута.

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

5. Запланируйте обработку специальных символов, которые могут сформировать новое имя пользователя. Это распространенная практика использования имени и фамилии рабочей роли для создания уникального userPrincipalName имени пользователя. В Windows Server AD и идентификаторе Microsoft Entra не допускаются символы акцента userPrincipalName , а разрешены A - Z, a - z, 0 - 9, ' . - _ ! # ^ ~только следующие символы. Используйте функцию NormalizeDiacritics для обработки символов акцента и создания соответствующих userPrincipalNameсимволов.

6. Планирование обработки длинных строк, возникающих в источнике кадров. Проверьте, имеют ли данные отдела кадров длинные строковые значения, связанные с полями кадров, которые будут использоваться для заполнения атрибутов Идентификатора Microsoft Entra и Windows Server AD. Каждый атрибут Идентификатора Microsoft Entra имеет максимальную длину строки. Если значение в поле кадров, сопоставленное с атрибутом идентификатора Microsoft Entra ID, содержит больше символов, обновление атрибута может завершиться ошибкой. Одним из вариантов является проверка сопоставления атрибутов и проверка возможности усечения или обновления длинных строковых значений в системе кадров. Если это не вариант, можно либо использовать такие функции, как Mid, чтобы усечь длинные строки, либо использовать такие функции, как Switch для сопоставления длинных значений с более короткими значениями или сокращенными значениями.

7. Адрес потенциально пустых значений для обязательных атрибутов. Это обязательно для заполнения определенных атрибутов, таких как firstName, CNlastNameили UPN при создании учетной записи в Идентификаторе Microsoft Entra или Windows Server AD. Если любое из соответствующих полей кадров, сопоставленных с такими атрибутами, равно null, операция создания пользователя завершается ошибкой. Например, если атрибут AD CN сопоставляется с отображаемым именем и если отображаемое имя не задано для всех пользователей, возникает ошибка. Одним из вариантов является проверка таких обязательных сопоставлений атрибутов и обеспечение заполнения соответствующих полей в hr. Можно также рассмотреть возможность проверки значений NULL в сопоставлении выражений. Например, если отображаемое имя является пустым, сцепляйте имя и фамилию или фамилию, чтобы сформировать отображаемое имя.

Убедитесь, что необходимые BAPIs для SAP ECC готовы к использованию Microsoft Entra

Агент подготовки Microsoft Entra и соединитель универсальных веб-служб обеспечивает подключение к локальным конечным точкам SOAP, включая SAP BAPIs.

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

1. Убедитесь, что BAPIs, необходимые для подготовки, публикуются. Предоставите необходимые API в SAP ECC NetWeaver 7.51 для создания, обновления и удаления пользователей. Соединители для файла Microsoft Identity Manager 2016 с именем Deploying SAP NetWeaver AS ABAP 7.pdf показано, как предоставить необходимые API.

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

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

3. Запишите необходимую схему для Microsoft Entra для предоставления SAP BAPIs. Например, вы можете использовать SAP BAPIBAPI_USER_CREATE1, для которого требуется ADDRESS,COMPANY,DEFAULTS,LOGONDATA,,SELF_REGISTERPASSWORD и USERNAME поля для создания пользователя. При настройке сопоставления из схемы пользователя Microsoft Entra ID с требованиями SAP ECC сопоставляйте атрибуты пользователя или константы идентификатора Майкрософт с каждым из этих полей.

Документируйте сквозный поток атрибутов и преобразования

Вы определили требования к схеме приложений и доступные рабочие поля из системы источников записей. Теперь задокументируйте пути к тому, как эти поля передаются через Microsoft Entra и, при необходимости, Windows Server AD и sap Cloud Identity Services в приложения.

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

Существует несколько этапов обработки, в которых можно применить преобразование.

Подготовка к выпуску новых учетных данных проверки подлинности

1. Если вы используете Windows Server AD, запланируйте выдачу учетных данных Windows Server AD для работников, которым требуется доступ к приложениям и не имели учетных записей пользователей Windows Server AD ранее. Исторически в некоторых организациях пользователи были подготовлены непосредственно в репозитории приложений. Рабочие пользователи получили учетные записи пользователей Windows Server AD только в том случае, если они нуждаются в почтовом ящике Microsoft Exchange или доступе к приложениям, интегрированным с Windows Server AD.

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

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

Если пользователям нужны пароли, можно развернуть возможность самостоятельного сброса пароля (SSPR) идентификатора Microsoft Entra ID. Вы можете подготовить атрибут мобильного номера из облачного приложения hr. После того как атрибут мобильного номера находится в идентификаторе Microsoft Entra, вы можете включить SSPR для учетной записи пользователя. Тогда новый пользователь сможет использовать зарегистрированный и проверенный номер мобильного телефона для проверки подлинности в первый день. Дополнительные сведения о том, как предварительно заполнить контактные данные проверки подлинности, см. в документации по SSPR.

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

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

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

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

Планирование пилотного проекта

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

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

Развертывание интеграции Microsoft Entra

В этом разделе выполняются следующие действия:

• Доведите пользователей в идентификатор Microsoft Entra из авторитетной исходной системы.

  

• Подготовьте этих пользователей к sap Cloud Identity Services или SAP ECC, чтобы разрешить им войти в приложения SAP.

  

Обновление схемы пользователя Windows Server AD

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

Если вы не используете Windows Server AD, перейдите к следующему разделу.

1. При необходимости расширьте схему Windows Server AD. Для каждого атрибута пользователя, требуемого Microsoft Entra и приложениями, которые еще не входят в схему пользователя Windows Server AD, необходимо выбрать встроенный атрибут расширения пользователя Windows Server AD. Или необходимо расширить схему Windows Server AD, чтобы иметь место для Windows Server AD для хранения этого атрибута. Это требование также включает атрибуты, используемые для автоматизации, например дату присоединения рабочей роли и дату выхода.

   Например, некоторые организации могут использовать атрибуты extensionAttribute1 и extensionAttribute2 хранить эти свойства. Если вы решили использовать встроенные атрибуты расширения, убедитесь, что эти атрибуты еще не используются другими приложениями на основе LDAP Windows Server AD или приложениями, интегрированными с идентификатором Microsoft Entra. Другие организации создают новые атрибуты Windows Server AD с именами, соответствующими их требованиям, например contosoWorkerId.

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

   Например, некоторые организации используют атрибут, например employeeId в Windows Server AD. Если у пользователей нет этого атрибута, они могут не рассматриваться во время последующей интеграции. Затем автоматическая подготовка приводит к дублированию пользователей, созданных в Windows Server AD. Когда пользователь покидает, исходные пользователи не обновляются или не удаляются. Вы можете использовать:

   • Конвейер PowerShell на присоединенном к домену компьютере с командой Get-ADUser , чтобы получить всех пользователей в контейнере Active Directory.
   • where-object Команда для фильтрации для пользователей, имеющих отсутствующий атрибут с фильтром, например{$_.employeeId -eq $null}.
   • Команда export-csv для экспорта результирующего пользователя в CSV-файл.

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

3. Расширьте схему идентификатора Microsoft Entra и настройте сопоставления из схемы Windows Server AD с схемой пользователя идентификатора Microsoft Entra ID. Если вы используете синхронизацию Microsoft Entra Connect, выполните действия в Microsoft Entra Connect Sync: расширения каталогов для расширения схемы пользователя Идентификатора Microsoft Entra ID с атрибутами. Настройте сопоставления синхронизации Microsoft Entra Connect для атрибутов Windows Server AD с этими атрибутами.

   Если вы используете Microsoft Entra Cloud Sync, выполните действия, описанные в расширениях каталогов Microsoft Entra Cloud Sync и сопоставлении настраиваемых атрибутов, чтобы расширить схему пользователя Идентификатора Microsoft Entra с любыми другими необходимыми атрибутами. Настройте сопоставления Microsoft Entra Cloud Sync для атрибутов Windows Server AD с этими атрибутами. Убедитесь, что вы синхронизируете атрибуты, необходимые для рабочих процессов жизненного цикла.

4. Дождитесь завершения синхронизации с Windows Server AD с идентификатором Microsoft Entra ID. Если вы внесли изменения в сопоставления для подготовки дополнительных атрибутов из Windows Server AD, подождите, пока эти изменения пользователи не внесли изменения из Windows Server AD в идентификатор Microsoft Entra ID, чтобы представление идентификатора Microsoft Entra id пользователей было полным набором атрибутов из Windows Server AD.

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

5. Создайте все необходимые контейнеры в Windows Server AD. Если вы будете подготавливать пользователей в подразделениях в домене, убедитесь, что эти organizationalUnit контейнеры существуют до включения агента подготовки.

Обновление схемы пользователя идентификатора записи Майкрософт

Если вы используете Windows Server AD, вы уже расширили схему пользователя Идентификатора Microsoft Entra в рамках настройки сопоставлений из Windows Server AD. Если этот шаг завершен, перейдите к следующему разделу.

Если вы не используете Windows Server AD, выполните действия, описанные в этом разделе, чтобы расширить схему пользователя идентификатора Microsoft Entra ID.

1. Создайте приложение для хранения расширений схемы Microsoft Entra. Для клиентов, которые не синхронизированы из Windows Server AD, расширения схемы должны быть частью нового приложения. Если вы еще этого не сделали, создайте приложение для представления расширений схемы. Этому приложению не назначены какие-либо пользователи.

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

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

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

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

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

Например, некоторые организации могут расширить схему пользователя Microsoft Entra ID, чтобы иметь новый атрибут для этой цели. Если у пользователей нет этого атрибута, они могут не рассматриваться во время последующей интеграции. Затем автоматическая подготовка приводит к дублированию пользователей, созданных в Windows Server AD. Когда пользователь покидает, исходные пользователи не обновляются или не удаляются.

1. Получите пользователей из идентификатора Microsoft Entra. Убедитесь, что любой пользователь уже в идентификаторе Microsoft Entra, представляющего рабочую роль, имеет атрибут, чтобы его можно было сопоставить. Как правило, несколько пользователей в идентификаторе Microsoft Entra не соответствуют сотрудникам в вашей авторитетной системе источника записей. Эти пользователи включают учетную запись аварийного административного доступа, учетные записи ИТ-поставщиков и бизнес-гостей. Остальные пользователи уже должны иметь атрибут с уникальным значением для корреляции.

   Если некоторые пользователи не коррелируются, они могут быть пропущены для обновлений и отмены подготовки. Microsoft Entra может даже создавать повторяющихся пользователей. Например, если требование заключается в том, что у всех пользователей-участников (помимо учетной записи разбиения) есть employeeid атрибут, можно определить этих пользователей с помощью конвейера команд PowerShell, аналогичного следующему скрипту:

   $u = get-mguser -all -property id,displayname,userprincipalname,usertype,employeeid | Where-Object {$_.UserType -ne 'Guest' -and $_.EmployeeId -eq $null}
   

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

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

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

2. При необходимости создайте каталог. По умолчанию при первом взаимодействии администратора с управлением правами Microsoft Entra автоматически создается каталог по умолчанию. Однако пакеты доступа для управляемых приложений должны находиться в указанном каталоге. Чтобы создать каталог в Центре администрирования Microsoft Entra, выполните действия, описанные в разделе "Создание каталога".

   Чтобы создать каталог с помощью PowerShell, выполните действия, описанные в разделах "Проверка подлинности в идентификаторе Microsoft Entra ID " и "Создание каталога".

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

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

5. Создайте рабочий процесс выхода для удаления учетных записей пользователей. При необходимости настройте рабочий процесс выхода с задачей для удаления пользователя. Запланируйте выполнение этого рабочего процесса в течение некоторого периода времени, например 30 или 90 дней после запланированной даты выхода рабочей роли.

Подключение пользователей в идентификаторе Microsoft Entra к рабочим записям из источника кадров

В этом разделе показано, как интегрировать идентификатор Microsoft Entra с SAP SuccessFactors в качестве исходной системы кадров.

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

2. Настройте входящие сопоставления из системы записей в Windows Server AD или Идентификатор Microsoft Entra. Если вы используете SAP SuccessFactors и подготавливаете пользователей в Windows Server AD и Идентификатор Microsoft Entra, выполните действия, описанные в разделе "Настройка подготовки пользователей из SuccessFactors в Active Directory".

   Если вы используете SAP SuccessFactors и не подготавливаете в Windows Server AD, выполните действия, описанные в разделе "Настройка подготовки пользователей из SuccessFactors в идентификатор Microsoft Entra".

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

3. Выполните начальную подготовку входящего трафика из системы записей. Если вы используете SAP SuccessFactors и подготавливаете пользователей в Windows Server AD и Идентификатор Microsoft Entra, выполните действия, описанные в разделе "Включение и запуск подготовки". Если вы используете SAP SuccessFactors и не подготавливаете в Windows Server AD, выполните действия, описанные в разделе "Включение и запуск подготовки". Для крупных клиентов облачных приложений отдела кадров (>30 000 пользователей) выполните начальный цикл на прогрессивных этапах, как описано в плане начального цикла.

4. Дождитесь завершения начальной синхронизации из системы записи. Если вы синхронизируете sap SuccessFactors с Windows Server AD или Идентификатором Microsoft Entra, после завершения начальной синхронизации с каталогом Microsoft Entra обновляет сводный отчет аудита на вкладке подготовки приложения SAP SuccessFactors в Центре администрирования Microsoft Entra.

   

5. Если вы подготавливаете в Windows Server AD, подождите, пока новые пользователи, созданные в Windows Server AD или обновленные в Windows Server AD, будут синхронизированы с Windows Server AD с идентификатором Microsoft Entra. Дождитесь внесения изменений пользователям в Windows Server AD в идентификатор Microsoft Entra ID, чтобы представление идентификатора Microsoft Entra пользователей было полным набором пользователей и их атрибутов из Windows Server AD.

   Если вы используете Microsoft Entra Cloud Sync, вы можете отслеживать steadyStateLastAchievedTime состояние синхронизации, извлекая задание синхронизации субъекта-службы, представляющего Microsoft Entra Cloud Sync. Если у вас нет идентификатора субъекта-службы, просмотрите схему синхронизации.

6. Убедитесь, что пользователи были подготовлены в идентификатор Microsoft Entra. На этом этапе пользователи должны присутствовать в идентификаторе Microsoft Entra с атрибутами, необходимыми для целевых приложений. Например, может потребоваться, чтобы пользователи имели givennamesurnameатрибуты , а employeeID также атрибуты. Чтобы отобразить количество пользователей с определенными атрибутами или отсутствующие атрибуты, можно использовать команды PowerShell, аналогичные следующему скрипту:

   $u = get-mguser -all -property id,displayname,userprincipalname,usertype,givenname,surname,employeeid
   $u2 = $u | where-object {$_.usertype -ne 'Guest' -and $_.employeeid -ne $null}
   $u2c = $u2.Count
   write-output "member users with employeeID attribute: $u2c"
   $u3 = $u| Where-Object {$_.UserType -ne 'Guest' -and ($_.EmployeeId -eq $null -or $_.GivenName -eq $null -or $_.Surname -eq $null)}
   $u3c = $u3.Count
   write-output "member users missing employeeID, givenname or surname attributes: $u3c"
   

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

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

8. Проверьте присоединение, обновление и выход действий в вышестоящей системе потока записей в Microsoft Entra. Дополнительные сведения см. в статье о тестировании планов.

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

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

Подготовка пользователей к облачным службам удостоверений SAP

Действия, описанные в этом разделе, настраивают подготовку из идентификатора Microsoft Entra в sap Cloud Identity Services. По умолчанию настройте идентификатор Microsoft Entra для автоматической подготовки и отмены подготовки пользователей в облачные службы удостоверений SAP. Затем эти пользователи могут пройти проверку подлинности в sap Cloud Identity Services и получить доступ к другим рабочим нагрузкам SAP, интегрированным с облачными службами удостоверений SAP. Облачные службы удостоверений SAP поддерживают подготовку из локального каталога удостоверений в другие приложения SAP в качестве целевых систем.

Кроме того, можно настроить sap Cloud Identity Services для чтения из идентификатора Microsoft Entra. Если вы используете sap Cloud Identity Services для чтения пользователей и необязательных групп из идентификатора Microsoft Entra ID, следуйте инструкциям SAP по настройке облачных удостоверений SAP. Затем перейдите к следующему разделу.

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

1. Убедитесь, что у вас есть клиент SAP Cloud Identity Services с учетной записью пользователя в sap Cloud Identity Services с разрешениями администратора.

2. Настройте облачные службы удостоверений SAP для подготовки. Войдите в консоль администрирования sap Cloud Identity Services и выполните действия, описанные в разделе "Настройка облачных служб удостоверений SAP для подготовки".

3. Добавьте облачные службы удостоверений SAP из коллекции и настройте автоматическую подготовку пользователей в sap Cloud Identity Services. Выполните действия, описанные в разделах "Добавление облачных удостоверений SAP" из коллекции и настройка автоматической подготовки пользователей в облачных службах удостоверений SAP.

4. Подготовьте тестового пользователя из идентификатора Microsoft Entra в sap Cloud Identity Services. Убедитесь, что интеграция подготовки готова, выполнив действия, описанные в разделе "Подготовка нового тестового пользователя из идентификатора Microsoft Entra в службы удостоверений SAP Cloud Identity Services".

5. Убедитесь, что существующие пользователи в Microsoft Entra и SAP Cloud Identity Services могут быть сопоставлены. Чтобы сравнить пользователей в идентификаторе Microsoft Entra с этими пользователями, уже имеющимися в sap Cloud Identity Services, выполните действия, описанные в следующих разделах:

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

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

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

7. Дождитесь синхронизации с идентификатором Microsoft Entra с SAP Cloud Identity Services. Дождитесь подготовки всех пользователей, назначенных приложению. Начальный цикл занимает от 20 минут до нескольких часов. Время зависит от размера каталога Microsoft Entra и количества пользователей в области подготовки. Вы можете отслеживать steadyStateLastAchievedTime свойство состояния синхронизации, извлекая задание синхронизации субъекта-службы, представляющего облачные службы SAP Cloud Identity Services.

8. Проверьте наличие ошибок подготовки. Проверьте журнал подготовки через Центр администрирования Microsoft Entra или API Graph. Отфильтруйте журнал по состоянию Сбой.

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

   Если пользователи пропускались с SkipReason кодом *NotEffectivelyEntitled, это событие журнала может указать, что учетные записи пользователей в идентификаторе Microsoft Entra не совпадают, так как состояние учетной записи пользователя отключено.

9. Сравните пользователей в облачных службах удостоверений SAP с пользователями в идентификаторе Microsoft Entra. Повторите действия в разделе "Убедитесь, что существующие пользователи облачных удостоверений SAP имеют необходимые атрибуты сопоставления для повторного экспорта пользователей из облачных удостоверений SAP". Затем убедитесь, что экспортированные пользователи имеют необходимые свойства для приложений SAP. С помощью команды PowerShell where-object можно отфильтровать список пользователей только для тех пользователей, у которых отсутствует атрибут, с фильтром, например {$_.employeeId -eq $null}.

10. Настройте федеративный единый вход из Microsoft Entra в sap Cloud Identity Services. Включите единый вход на основе SAML для служб облачных удостоверений SAP. Следуйте инструкциям, приведенным в руководстве по единому входу в SAP Cloud Identity Services.

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

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

12. Убедитесь, что тестовый пользователь может подключиться к приложениям SAP. Вы можете использовать Microsoft Мои приложения для тестирования единого входа приложения. Убедитесь, что тестовый пользователь был назначен приложению sap Cloud Identity Services и подготовлен из идентификатора Microsoft Entra в облачные службы удостоверений SAP. Затем войдите в Microsoft Entra как этот пользователь и перейдите к ней myapps.microsoft.com.

    При выборе плитки SAP Cloud Identity Services в Мои приложения, если вы настроили интеграцию в режиме поставщика услуг (SP), вы будете перенаправлены на страницу входа приложения для инициации потока входа. Если вы настроили в режиме поставщика удостоверений (IDP), вы автоматически войдете в sap Cloud Identity Services, для которого настроили единый вход.

Подготовка пользователей к SAP ECC

Теперь, когда у вас есть пользователи в идентификаторе Microsoft Entra, их можно подготовить в локальной среде SAP.

Если вы не используете SAP ECC, перейдите к следующему разделу.

1. Настройте подготовку. Следуйте инструкциям в статье Настройка идентификатора Microsoft Entra для подготовки пользователей в SAP ECC с помощью NetWeaver AS ABAP 7.0 или более поздней версии.

2. Дождитесь синхронизации с идентификатором Microsoft Entra с SAP ECC. Дождитесь подготовки всех пользователей, назначенных приложению SAP ECC. Начальный цикл занимает от 20 минут до нескольких часов. Время зависит от размера каталога Microsoft Entra и количества пользователей в области подготовки. Вы можете отслеживать steadyStateLastAchievedTime свойство состояния синхронизации, извлекая задание синхронизации субъекта-службы.

3. Проверьте наличие ошибок подготовки. Проверьте журнал подготовки через Центр администрирования Microsoft Entra или API Graph. Отфильтруйте журнал по состоянию Сбой.

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

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

4. Сравните пользователей в SAP ECC с пользователями в идентификаторе Microsoft Entra. На сервере Windows Server, где размещен агент подготовки для подготовки к SAP ECC, перезапустите Microsoft ECMA2Host службу Windows. При перезапуске службы выполняется полный импорт пользователей из SAP ECC.

5. Настройте федеративный единый вход из Microsoft Entra в SAP. Включите единый вход на основе SAML для приложений SAP. Если вы используете SAP NetWeaver, следуйте инструкциям, приведенным в руководстве по единому входу SAP NetWeaver.

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

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

7. Убедитесь, что тестовый пользователь может быть подготовлен и войдите в SAP NetWeaver. Следуйте инструкциям в разделе Test SSO , чтобы убедиться, что пользователи могут войти после настройки условного доступа.

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

Вы можете настроить Microsoft Entra для записи определенных атрибутов из идентификатора Microsoft Entra в SAP SuccessFactors Employee Central, включая рабочую электронную почту. Дополнительные сведения см. в разделе "Настройка обратной записи SAP SuccessFactors" в идентификаторе Microsoft Entra.

Microsoft Entra также может подготавливать многие другие приложения, включая те приложения, которые используют такие стандарты , как OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP и REST. Дополнительные сведения см. в разделе "Интеграция приложений с идентификатором Microsoft Entra".

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

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

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

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

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

2. Настройте процесс, чтобы обеспечить актуальность назначений ролей приложения. Если вы используете управление правами Microsoft Entra, см. статью "Создание пакета доступа в управлении правами для приложения с одной ролью с помощью PowerShell для настройки назначений для приложения, представляющего облачные службы удостоверений SAP или SAP ECC".

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

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

Распространение учетных данных для только что созданных пользователей Microsoft Entra или пользователей Windows Server AD

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

1. Если входящий трафик Microsoft Entra создает пользователей в Windows Server AD, распределите начальные учетные данные Windows Server AD для только что созданных пользователей. Список событий взаимодействия Microsoft Entra с Windows Server AD можно получить с помощью команды Get-MgAuditLogProvisioning .

   Вы можете использовать Set-ADAccountPassword команду с -Reset параметром на компьютере, присоединенном к домену, чтобы задать новый пароль Windows Server AD для пользователя. Затем используйте Set-ADUser команду с -ChangePasswordAtLogon параметром , чтобы пользователь должен выбрать новый пароль при следующем входе.

2. Если подготовка входящего трафика Microsoft Entra создает пользователей в идентификаторе Microsoft Entra, распределите исходные учетные данные идентификатора Microsoft Entra для вновь созданных пользователей. Список новых пользователей можно получить с помощью команды Get-MgAuditLogDirectoryAudoryAudit с такими параметрами, как Get-MgAuditLogDirectoryAudit -Filter "category eq 'UserManagement' and activityDisplayName eq 'Add user' and result eq 'success' and activityDateTime+ge+2024-05-01" -all.

   Чтобы создать временный проход доступа для пользователя, можно использовать команды New-MgUserAuthenticationTemporaryAccessPassMethod и Get-MgUserAuthenticationTemporaryAccessPassMethod, как показано в разделе "Создание временного прохода доступа".

3. Убедитесь, что пользователи зарегистрированы для MFA. Вы можете определить пользователей, которые не зарегистрированы для MFA, выполнив команды PowerShell в разделе отчетов PowerShell о пользователях, зарегистрированных для MFA.

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

Мониторинг потоков удостоверений

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

Мониторинг входящего подготовки

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

Мониторинг изменений в Windows Server AD

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

Мониторинг назначений ролей приложения

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

• Если вы используете управление правами Microsoft Entra, книга с именем Access Package Activity отображает каждое событие, связанное с определенным пакетом доступа.

  

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

  

Мониторинг исходящей подготовки

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

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

Мониторинг единого входа

Вы можете просмотреть последние 30 дней входа в приложение в отчете о входе в центре администрирования Microsoft Entra или через Microsoft Graph. Вы также можете отправить журналы входа в Azure Monitor в архив действий входа в течение двух лет.

Мониторинг назначений в Управление идентификацией Microsoft Entra

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

• Администратор или владелец каталога может получить список пользователей с назначениями пакетов доступа через Центр администрирования Microsoft Entra, Microsoft Graph или PowerShell.
• Вы также можете отправить журналы аудита в Azure Monitor и просмотреть журнал изменений пакета доступа в Центре администрирования Microsoft Entra или PowerShell.

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

Связанный контент

• Управление доступом к приложениям в вашей среде
• Управление доступом путем переноса модели ролей организации в Управление идентификацией Microsoft Entra
• Определение политик организации для управления доступом к другим приложениям в вашей среде
• Использование идентификатора Microsoft Entra для защиты доступа к платформам и приложениям SAP
• Ознакомьтесь с основами идентификации и управления для SAP в Azure