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

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

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

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

2. Убедитесь, что каждое приложение интегрируется с Microsoft Entra. Если приложение указано как одно из sap Cloud Identity Services, подготавливающих целевые системы, например SAP S/4HANA, или использует SAP BTP, вы можете использовать SAP Cloud Identity Services в качестве по промежуточного слоя для моста единого входа и подготовки от Microsoft Entra к приложению. Если ваше приложение – это SAP ECC, вы можете интегрировать Microsoft Entra непосредственно с SAP NetWeaver для единого входа в систему и с BAPI SAP ECC для предоставления.

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

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

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

   Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примите решение о топологии предоставления и проверки подлинности

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

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

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

2. Определите, существуют ли пользователи или должны быть созданы в Windows Server AD в дополнение к Microsoft Entra ID. Возможно, у вас уже есть пользователи в 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; другие – в нескольких. Для получения дополнительной информации см. настройка назначения контейнеров OU в Active Directory.

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

6. Определите, нужно ли предоставить доступ пользователям в SAP ECC. Вы можете настроить пользователей из Microsoft Entra ID в 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 ID для автоматизации подключения, ваш клиент должен иметь как минимум столько же лицензий для Microsoft Entra ID P1, сколько имеется работников, поступающих из исходного HR-приложения, или обычных пользователей (не гостей), подключаемых в систему.

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

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

   Вы также можете использовать рабочие книги 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 ID, ознакомьтесь с рекомендациями по всем архитектурам изоляции.

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

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

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

Если вы используете SAP Cloud Identity Services для работы с SAP S/4HANA или другими приложениями SAP, убедитесь, что SAP Cloud Identity Services имеет сопоставления для отправки этих атрибутов из Microsoft Entra ID в эти приложения. Если вы не используете облачные службы удостоверений 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 ID, а другим процессом, ознакомьтесь с справочным материалом по атрибутам SAP SuccessFactors и схемой пользователей Windows Server или Microsoft Entra ID, чтобы определить, какие атрибуты в пользовательских объектах содержат уникальный идентификатор работника в SAP SuccessFactors.

   Этот атрибут должен присутствовать с уникальным значением для каждого пользователя, который соответствует рабочему, чтобы входящая подготовка Microsoft Entra могла определить, какие пользователи уже существуют для работников и избежать создания повторяющихся пользователей. Атрибут сопоставления по умолчанию основан на идентификаторе сотрудника. Перед импортом работников из источника кадров необходимо убедиться, что значение этого атрибута, например идентификатор сотрудника, заполнено в Microsoft Entra ID (для облачных пользователей) и 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 имеет максимальную длину строки. Если значение в поле HR, соответствующее атрибуту идентификатора Microsoft Entra ID, содержит больше символов, обновление атрибута может завершиться ошибкой. Одним из вариантов является проверка сопоставления атрибутов и проверка возможности усечения или обновления длинных строковых значений в системе кадров. Если это не вариант, можно либо использовать такие функции, как Mid, чтобы усечь длинные строки, либо использовать такие функции, как Switch для сопоставления длинных значений с более короткими значениями или сокращенными значениями.

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

Проверьте, что необходимые BAPI для 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 ID, для них необходимо заполнить поле, которое будет использоваться как уникальный идентификатор работника. Это поле должно присутствовать с уникальным значением на каждом пользователе, соответствующем работнику. Затем процесс подготовки Microsoft Entra может определить, какие пользователи уже существуют для работников, и избежать создания повторяющихся пользователей.

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

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

Документируйте поток атрибутов от начала до конца и преобразования

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

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

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

Этап	Рекомендации	Ссылки для получения дополнительных сведений
В самой системе записей	Управление жизненным циклом удостоверений Microsoft Entra может быть не единственным решением, которое может считывать данные из системы учетных записей. Выполнение нормализации данных перед предоставлением их в Microsoft Entra может также принести пользу другим решениям, которым требуются аналогичные данные.	См. документацию по системе учета.
В потоке подготовки входящего трафика из системы записей в Microsoft Entra или Windows Server AD	Вы можете написать настраиваемое значение в атрибут пользователя Windows Server AD или атрибут пользователя Идентификатора Microsoft Entra, основанный на одном или нескольких атрибутах SuccessFactors.	Выражение с функциями для настройки
При синхронизации с Windows Server AD в Microsoft Entra ID	Если у вас уже есть пользователи в Windows Server AD, вы можете преобразовать атрибуты этих пользователей по мере их ввода в идентификатор Microsoft Entra.	Настройка правила синхронизации в Microsoft Entra Connect и использование построителя выражений с помощью Microsoft Entra Cloud Sync
В потоке исходящего предоставления из Microsoft Entra ID в SAP Cloud Identity Services, SAP ECC или другие не-SAP приложения	При настройке подготовки приложения к использованию, одним из типов сопоставления атрибутов, которые можно указать, является сопоставление выражений одного или нескольких атрибутов в Microsoft Entra ID с атрибутом в целевом объекте.	Выражение с функциями для настройки
Исходящая федеративная аутентификация SSO	По умолчанию платформа удостоверений Майкрософт выдает токен SAML приложению, которое содержит утверждение со значением имени пользователя (также известного как основное имя пользователя), которое может однозначно идентифицировать пользователя. Маркер SAML также содержит другие утверждения, которые включают адрес электронной почты пользователя или отображаемое имя, и можно использовать функции преобразования утверждений.	Настройка утверждений токена SAML и утверждений веб-токена JSON клиента
В службах облачной идентификации SAP	В облачных службах удостоверений личности SAP каждая настроенная целевая система вносит изменения в модель данных источника для идентификационных данных, предоставленных службам удостоверения личности SAP, в соответствии с требованиями целевой системы. Возможно, вам потребуется изменить эти преобразования в облачных службах удостоверений SAP, чтобы соответствовать тому, как вы планируете моделировать удостоверение, особенно если у вас настроено несколько целевых систем. Этот подход может быть подходящим, если требование атрибута относится к одному или нескольким приложениям SAP, подключенным к облачным службам удостоверений SAP.	Службы облачных удостоверений SAP — управление преобразованием

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

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 ID, так и для новых сотрудников.

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

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

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

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

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

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

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

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

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

В этом разделе вы:

• Импортируйте пользователей в Microsoft Entra ID из достоверной исходной системы.

  

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

  

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

Если вы интегрируете пользователей в Windows Server AD и Microsoft Entra ID, убедитесь, что среда 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 контейнеры существуют до активации агента подготовки.

Обновить схему пользователя Microsoft Entra ID

Если вы используете Windows Server AD, вы уже расширили схему пользователя Microsoft Entra ID при настройке сопоставлений из 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 ID, которые соответствуют работникам. Затем эти пользователи должны иметь атрибут, значение которого уникально и соответствует свойству в авторитетной системе источника записей для этих работников.

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

1. Извлеките пользователей из Microsoft Entra ID. Убедитесь, что любой пользователь уже в Microsoft Entra ID, представляющий работника, имеет атрибут, чтобы его можно было сопоставить. Как правило, несколько пользователей в идентификаторе 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 ID, например, управление правами доступа Microsoft Entra или рабочие процессы жизненного цикла Microsoft Entra, разверните данные функции перед тем, как добавить работников в качестве пользователей в Microsoft Entra ID.

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

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

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

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

4. Создайте рабочий процесс ухода, который блокирует вход в систему. В Microsoft Entra Lifecycle Workflows настройте рабочий процесс ухода с задачей, которая блокирует вход пользователей в систему. Этот рабочий процесс может выполняться по запросу. Если вы не настроили входящее обеспечение из источников записей кадров для блокировки входа сотрудников после их запланированных дат ухода, настройте процесс увольнения, который будет запущен в их запланированные даты ухода.

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

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

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

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

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

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

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

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

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

   

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

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

6. Убедитесь, что пользователи были настроены в Microsoft Entra ID. На этом этапе пользователи должны присутствовать в идентификаторе Microsoft Entra с атрибутами, необходимыми для целевых приложений. Например, может потребоваться, чтобы пользователи имели атрибуты givenname, surname и 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 ID нет неожиданных несвязанных учетных записей. Как правило, несколько пользователей в Microsoft Entra ID не соотносятся с работниками в вашей авторитетной системе учета данных. Они включают учетную запись аварийного административного доступа, учетные записи ИТ-поставщиков и бизнес-гостей.

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

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

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

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

Предоставление пользователей в SAP Cloud Identity Services

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

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

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

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

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

3. Добавьте SAP Cloud Identity Services из галереи и настройте автоматическое предоставление пользователей в SAP Cloud Identity Services. Выполните действия, описанные в разделах «Добавление SAP Cloud Identity Services из галереи» и «Настройка автоматического предоставления пользователей в SAP Cloud Identity Services».

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

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

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

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

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

7. Дождитесь синхронизации от Microsoft Entra ID до 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 ID не совпали, так как состояние учетной записи пользователя было отключено.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Настройте федеративную единую аутентификацию из Microsoft Entra в SAP. Включите SSO (единую систему аутентификации) на основе 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 ID.

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

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

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

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

Если у вас есть приложения в SAP BTP, вы также можете назначать группы, управляемые с помощью Microsoft Entra, на роли этого приложения в SAP Cloud Identity Services.

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

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

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

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

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

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

На этом этапе все пользователи находятся в Microsoft Entra ID и обеспечены соответствующими приложениями 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 ID, распределите начальные учетные данные Microsoft Entra ID для вновь созданных пользователей. Список недавно созданных пользователей можно получить с помощью команды Get-MgAuditLogDirectoryAudit с такими параметрами, как 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 ID Governance

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

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

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

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

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