사용자를 LDAP 디렉터리로 프로비전하도록 Microsoft Entra ID 구성

아티클
02/13/2024

다음 설명서에서는 Microsoft Entra ID에서 LDAP 디렉터리로 사용자를 프로비전하는 방법을 보여주는 구성 및 자습서 정보를 제공합니다.

이 문서에서는 사용자를 Microsoft Entra ID에서 LDAP 디렉터리에 자동으로 프로비전 및 프로비전 해제하기 위해 수행해야 하는 단계를 설명합니다. 이 문서에서는 사용자를 AD LDS에 예제 LDAP 디렉터리로 프로비전하는 방법을 보여 주지만, 다음 섹션에서 언급한 지원되는 LDAP 디렉터리 서버에 프로비전할 수 있습니다. 이 솔루션을 통해 사용자를 Active Directory Domain Services에 프로비전하는 것은 지원되지 않습니다.

이 서비스의 기능, 작동 방식, 질문과 대답에 대한 중요한 세부 정보는 Microsoft Entra ID를 사용하여 SaaS 애플리케이션에 대한 사용자 프로비전 및 프로비전 해제 자동화 및 온-프레미스 애플리케이션 프로비전 아키텍처를 참조하세요. 다음 비디오는 온-프레미스 프로비전에 대한 개요를 제공합니다.

사용자를 LDAP 디렉터리에 프로비전하기 위한 필수 구성 요소

온-프레미스 필수 조건

디렉터리 서버를 사용하여 사용자를 쿼리하는 애플리케이션.
사용자를 만들고, 업데이트하고, 삭제할 수 있는 Active Directory Domain Services가 아닌 대상 디렉터리. 예: AD LDS(Active Directory Lightweight Directory Services). 이 디렉터리 인스턴스는 사용자를 Microsoft Entra ID에 프로비전하는 데에도 사용되는 디렉터리면 안 됩니다. 두 시나리오는 모두 Microsoft Entra Connect를 사용하여 루프를 만들 수 있기 때문입니다.
프로비저닝 에이전트를 호스팅하기 위한 최소 3GB의 RAM이 있는 컴퓨터. 컴퓨터에는 대상 디렉터리에 대한 연결 및 login.microsoftonline.com, 기타 Microsoft Online Services 및 Azure 도메인에 대한 아웃바운드 연결을 사용하는 Windows Server 2016 또는 이후 버전의 Windows Server가 있어야 합니다. 예를 들어 Azure IaaS 또는 프록시 뒤에서 호스트되는 Windows Server 2016 가상 머신이 있습니다.
.NET Framework 4.7.2를 설치해야 합니다.
선택 사항: 필수는 아니지만 Windows Server용 Microsoft Edge를 다운로드하여 Internet Explorer 대신 사용하는 것이 좋습니다.

지원되는 LDAP 디렉터리 서버

커넥터는 LDAP 서버를 검색하고 식별하는 다양한 기술을 사용합니다. 커넥터는 루트 DSE, 공급업체 이름 및 버전을 사용하고 스키마를 검사하여 특정 LDAP 서버에 있다고 알려진 고유 개체 및 특성을 찾습니다.

OpenLDAP
Microsoft Active Directory Lightweight Directory Services
389 디렉터리 서버
Apache 디렉터리 서버
IBM Tivoli DS
Isode 디렉터리
NetIQ eDirectory
Novell eDirectory
DJ 열기
DS 열기
Oracle(이전 Sun ONE) Directory Server Enterprise Edition
RadiantOne 가상 디렉터리 서버(VDS)

자세한 내용은 일반 LDAP 커넥터 참조를 참조하세요.

클라우드 요구 사항

Microsoft Entra ID P1 또는 Premium P2(또는 EMS E3 또는 E5)를 사용하는 Microsoft Entra 테넌트입니다.

이 기능을 사용하려면 Microsoft Entra ID P1 라이선스가 필요합니다. 요구 사항에 적합한 라이선스를 찾으려면 Microsoft Entra ID의 일반 공급 기능 비교를 참조하세요.
Azure Portal에서 프로비저닝을 구성하기 위한 프로비전 에이전트와 애플리케이션 관리자 또는 클라우드 애플리케이션 관리자 역할을 구성하기 위한 하이브리드 ID 관리자 역할입니다.
LDAP 디렉터리에 프로비전할 Microsoft Entra 사용자는 디렉터리 서버 스키마에 필요하고 각 사용자에 한정된 특성으로 채워져 있어야 합니다. 예를 들어, 디렉터리 서버에서 POSIX 워크로드를 지원하기 위해 각 사용자에게 사용자 ID 번호로 10000에서 30000 사이의 고유 번호를 요구하는 경우 사용자의 기존 특성에서 해당 번호를 생성하거나 Microsoft Entra 스키마를 작성하고 LDAP 기반 애플리케이션 범위에 있는 사용자의 해당 특성을 채웁니다. 추가 디렉터리 확장을 만드는 방법은 그래프 확장성을 참조하세요.

추가 권장 사항 및 제한 사항

다음 글머리 기호 항목은 추가 권장 사항 및 제한 사항입니다.

클라우드 동기화 및 온-프레미스 앱 프로비전에 동일한 에이전트를 사용하지 않는 것이 좋습니다. Microsoft는 클라우드 동기화 및 온-프레미스 앱 프로비전에 각각 별도의 에이전트를 사용하도록 권장합니다.
현재 AD LDS의 경우 사용자에게 암호를 프로비전할 수 없습니다. 따라서 AD LDS에 대한 암호 정책을 사용하지 않도록 설정하거나 사용 안 함 상태에서 사용자를 프로비전해야 합니다.
다른 디렉터리 서버의 경우 초기 임의 암호를 설정할 수 있지만 Microsoft Entra 사용자의 암호를 디렉터리 서버에 프로비전할 수는 없습니다.
사용자를 Microsoft Entra ID에서 Active Directory Domains Services로 프로비전하는 것은 지원되지 않습니다.
사용자를 LDAP에서 Microsoft Entra ID로 프로비전하는 것은 지원되지 않습니다.
디렉터리 서버에 대한 그룹 및 사용자 멤버 자격 프로비전은 지원되지 않습니다.

실행 프로필 선택

커넥터가 디렉터리 서버와 상호 작용하도록 구성을 만드는 경우 먼저 커넥터가 디렉터리의 스키마를 읽도록 구성하고, 스키마를 Microsoft Entra ID의 스키마에 매핑한 다음, 실행 프로필을 통해 커넥터가 지속적으로 사용해야 하는 접근 방식을 구성합니다. 구성할 각 실행 프로필은 커넥터가 디렉터리 서버에서 데이터를 가져오거나 내보내는 LDAP 요청을 생성하는 방법을 지정합니다. 기존 디렉터리 서버에 커넥터를 배포하기 전에 디렉터리 서버에서 수행할 작업 패턴을 조직의 디렉터리 서버 운영자와 논의해야 합니다.

구성 후 프로비저닝 서비스가 시작되면 전체 가져오기 실행 프로필에 구성된 상호 작용을 자동으로 수행합니다. 이 실행 프로필에서 커넥터는 LDAP 검색 작업을 사용하여 디렉터리에서 사용자의 모든 레코드를 읽습니다. 이 실행 프로필은 나중에 Microsoft Entra ID가 사용자를 변경해야 하는 경우 Microsoft Entra ID가 해당 사용자에 대한 새 개체를 만드는 대신 디렉터리에서 해당 사용자에 대한 기존 개체를 업데이트하는 데 필요합니다.
애플리케이션에 새 사용자를 할당하거나 기존 사용자를 업데이트하는 것과 같이 Microsoft Entra ID에서 변경할 때마다 프로비전 서비스는 내보내기 실행 프로필에서 LDAP 상호 작용을 수행합니다. 내보내기 실행 프로필에서 Microsoft Entra ID는 디렉터리의 콘텐츠를 Microsoft Entra ID와 동기화하기 위해 디렉터리에서 개체의 추가, 수정, 제거 또는 이름 바꾸기에 대한 LDAP 요청을 실행합니다.
디렉터리에서 지원하는 경우 필요에 따라 델타 가져오기 실행 프로필을 구성할 수도 있습니다. 이 실행 프로필에서 Microsoft Entra ID는 마지막 전체 또는 델타 가져오기 이후 Microsoft Entra ID가 아닌 디렉터리에서 변경된 내용을 읽습니다. 디렉터리가 델타 가져오기를 지원하도록 구성되지 않았을 수 있으므로 이 실행 프로필은 선택 사항입니다. 예를 들어 조직에서 OpenLDAP를 사용하는 경우 OpenLDAP는 액세스 로그 오버레이 기능이 사용하도록 설정된 상태에서 배포되었어야 합니다.

Microsoft Entra LDAP 커넥터가 디렉터리 서버와 상호 작용하는 방법 결정

기존 디렉터리 서버에 커넥터를 배포하기 전에 디렉터리 서버와 통합하는 방법을 조직의 디렉터리 서버 운영자와 논의해야 합니다. 수집할 정보에는 디렉터리 서버에 연결하는 방법, 커넥터가 디렉터리 서버에 자신을 인증하는 방법, 디렉터리 서버가 사용자를 모델링하기 위해 선택한 스키마, 명명 컨텍스트의 기본 고유 이름 및 디렉터리 계층 구조 규칙, 디렉터리 서버의 사용자를 Microsoft Entra ID의 사용자와 연결하는 방법, 사용자가 Microsoft Entra ID의 범위를 벗어나는 경우 발생하는 상황에 관한 네트워크 정보가 포함됩니다. 이 커넥터를 배포하려면 디렉터리 서버 구성 및 Microsoft Entra ID 구성을 변경해야 할 수 있습니다. 프로덕션 환경에서 Microsoft Entra ID를 타사 디렉터리 서버와 통합해야 하는 배포의 경우 고객은 이 통합에 대한 도움말, 참고 자료 및 지원을 위해 디렉터리 서버 공급업체 또는 배포 파트너와 협력하는 것이 좋습니다. 이 문서에서는 AD LDS 및 OpenLDAP의 두 디렉터리에 대해 다음 샘플 값을 사용합니다.

구성 설정	값이 설정된 위치	예제 값
디렉터리 서버의 호스트 이름	구성 마법사 연결 페이지	`APP3`
디렉터리 서버의 포트 번호	구성 마법사 연결 페이지	636. LDAP over SSL 또는 TLS(LDAPS)의 경우 포트 636을 사용합니다. `Start TLS`의 경우 포트 389를 사용합니다.
커넥터가 디렉터리 서버에 식별하기 위한 계정	구성 마법사 연결 페이지	AD LDS의 경우 `CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab` 및 OpenLDAP의 경우 `cn=admin,dc=contoso,dc=lab`
커넥터가 디렉터리 서버에 인증하기 위한 암호	구성 마법사 연결 페이지
디렉터리 서버의 사용자에 대한 구조적 개체 클래스	구성 마법사 개체 유형 페이지	AD LDS의 경우 `User` 및 OpenLDAP의 경우 `inetOrgPerson`
디렉터리 서버의 사용자에 대한 보조 개체 클래스	Azure Portal 프로비전 페이지 특성 매핑	POSIX 스키마를 사용하는 OpenLDAP의 경우, `posixAccount` 및 `shadowAccount`
새 사용자에 대해 채울 특성	구성 마법사 특성 선택 페이지 및 Azure Portal 프로비전 페이지 특성 매핑	AD LDS의 경우 `msDS-UserAccountDisabled`, `userPrincipalName`, `displayName` 및 OpenLDAP의 경우 `cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword`
디렉터리 서버에 필요한 명명 계층 구조	Azure Portal 프로비전 페이지 특성 매핑	새로 만든 사용자의 DN을 바로 아래에서 `CN=CloudUsers,CN=App,DC=Contoso,DC=lab`(AD LDS) 및 `DC=Contoso,DC=lab`(OpenLDAP)으로 설정합니다.
Microsoft Entra ID 및 디렉터리 서버 간에 사용자를 상호 연결하기 위한 특성	Azure Portal 프로비전 페이지 특성 매핑	AD LDS의 경우 이 예는 초기에 빈 디렉터리에 대한 것이고, OpenLDAP `mail`에 대한 것이므로 구성되지 않았습니다.
사용자가 Microsoft Entra ID의 범위를 벗어나는 경우 프로비전 해제 동작	구성 마법사 프로비전 해제 페이지	디렉터리 서버에서 사용자 삭제

디렉터리 서버의 네트워크 주소는 호스트 이름 및 TCP 포트 번호(일반적으로 포트 389 또는 636)입니다. 디렉터리 서버가 동일한 Windows Server의 커넥터와 함께 공동 배치되거나 네트워크 수준 보안을 사용하는 경우를 제외하고 커넥터에서 디렉터리 서버로 네트워크 연결은 SSL 또는 TLS를 사용하여 보호해야 합니다. 커넥터는 포트 389의 디렉터리 서버에 연결하고 TLS 시작을 사용하여 세션 내에서 TLS를 사용하도록 설정하는 기능을 지원합니다. 커넥터는 LDAPS(LDAP over TLS)에 대한 포트 636에서 디렉터리 서버에 연결하는 기능도 지원합니다.

커넥터가 디렉터리 서버에 이미 구성된 디렉터리 서버에 인증하려면 식별된 계정이 있어야 합니다. 이 계정은 일반적으로 고유 이름으로 식별되며 연결된 암호 또는 클라이언트 인증서를 보유합니다. 연결된 디렉터리에서 개체에 대한 가져오기 및 내보내기 작업을 수행하려면 커넥터 계정에는 디렉터리의 액세스 제어 모델 내에서 충분한 권한이 있어야 합니다. 커넥터에는 내보낼 수 있는 쓰기 권한 및 가져올 수 있는 읽기 권한이 있어야 합니다. 사용 권한 구성은 대상 디렉터리 자체의 관리 환경 내에서 수행됩니다.

디렉터리 스키마는 디렉터리의 실제 엔터티를 나타내는 개체 클래스 및 특성을 지정합니다. 커넥터는 inetOrgPerson과 같은 구조적 개체 클래스 및 필요에 따라 추가 보조 개체 클래스로 표시되는 사용자를 지원합니다. 커넥터가 사용자를 디렉터리 서버에 프로비전할 수 있도록 Azure Portal에서 구성 중에 Microsoft Entra 스키마에서 모든 필수 특성으로 매핑을 정의합니다. 여기에는 구조적 개체 클래스의 필수 특성, 해당 구조적 개체 클래스의 모든 슈퍼클래스 및 보조 개체 클래스의 필수 특성이 포함됩니다. 또한 이러한 클래스의 일부 선택적 특성에 대한 매핑도 구성할 수 있습니다. 예를 들어 새 사용자가 다음 예제와 같은 특성을 보유하려면 OpenLDAP 디렉터리 서버에 개체가 필요할 수 있습니다.

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

디렉터리 서버에서 구현하는 디렉터리 계층 구조 규칙은 각 사용자의 개체가 디렉터리의 기존 개체와 서로 어떻게 관련되는지 설명합니다. 대부분의 배포에서 조직은 각 사용자의 각 개체가 공통 기본 개체 바로 아래에 있는 디렉터리 서버에 평면 계층 구조를 포함하도록 선택했습니다. 예를 들어 디렉터리 서버의 명명 컨텍스트에 대한 기본 고유 이름이 dc=contoso,dc=com이면 새 사용자는 cn=alice,dc=contoso,dc=com 같은 고유 이름을 보유합니다. 그러나 일부 조직에는 더 복잡한 디렉터리 계층 구조가 있을 수 있습니다. 이 경우 커넥터에 대한 고유 이름 매핑을 지정할 때 규칙을 구현해야 합니다. 예를 들어 디렉터리 서버는 사용자가 부서별 조직 구성 단위에 있을 것으로 예상할 수 있으므로 새 사용자는 cn=alice,ou=London,dc=contoso,dc=com 같은 고유 이름을 보유합니다. 커넥터는 조직 구성 단위에 대한 중간 개체를 만들지 않으므로 디렉터리 서버 규칙 계층 구조에서 예상하는 중간 개체는 디렉터리 서버에 이미 있어야 합니다.

다음으로, 커넥터에서 Microsoft Entra 사용자에 해당하는 사용자가 디렉터리 서버에 이미 있는지 확인하는 방법에 대한 규칙을 정의해야 합니다. 모든 LDAP 디렉터리에는 디렉터리 서버의 각 개체에 대해 고유한 고유 이름이 있지만 Microsoft Entra ID의 사용자에 대해 고유 이름이 없는 경우가 많습니다. 대신 조직에는 Microsoft Entra ID의 사용자에 대해서도 존재하는 디렉터리 서버 스키마의 mail 또는 employeeId와 같은 다른 특성이 있을 수 있습니다. 그런 다음, 커넥터가 새 사용자를 디렉터리 서버에 프로비전할 때 커넥터는 해당 특성의 특정 값을 사용하는 사용자가 해당 디렉터리에 이미 있는지 여부를 검색하고 없는 경우에만 디렉터리 서버에서 새 사용자를 만들 수 있습니다.

시나리오에서 기존 사용자를 업데이트하거나 삭제하는 것만이 아니라 LDAP 디렉터리에서 새 사용자를 만들어야 하는 경우 해당 디렉터리 서버를 사용하는 애플리케이션이 인증을 처리하는 방법도 결정해야 합니다. 권장되는 접근 방식은 애플리케이션이 SAML, OAuth 또는 OpenID Connect와 같은 페더레이션 또는 SSO 프로토콜을 사용하여 Microsoft Entra ID에 인증하고 특성에 대해서만 디렉터리 서버를 사용하는 것입니다. 일반적으로 LDAP 디렉터리는 애플리케이션에서 암호를 확인하여 사용자를 인증하는 데 사용할 수 있지만 이 사용 사례는 다단계 인증의 경우 또는 사용자가 이미 인증된 경우 가능하지 않습니다. 일부 애플리케이션은 디렉터리에서 사용자의 SSH 공개 키 또는 인증서를 쿼리할 수 있으며, 이 방법은 사용자가 관련 양식의 자격 증명을 이미 보유하고 있는 경우 적합할 수 있습니다. 그러나 디렉터리 서버를 사용하는 애플리케이션이 최신 인증 프로토콜 또는 더 강력한 자격 증명을 지원하지 않는 경우 Microsoft Entra ID는 사용자의 Microsoft Entra 암호 프로비전을 지원하지 않으므로 디렉터리에서 새 사용자를 만들 때 애플리케이션별 암호를 설정해야 합니다.

마지막으로, 프로비전 해제 동작에 동의해야 합니다. 커넥터가 구성되고 Microsoft Entra ID가 이미 디렉터리에 있는 사용자 또는 새 사용자에 대해 Microsoft Entra ID의 사용자와 디렉터리의 사용자 간에 링크를 설정한 경우 Microsoft Entra ID는 Microsoft Entra 사용자의 특성 변경 사항을 디렉터리에 프로비전할 수 있습니다. 애플리케이션에 할당된 사용자가 Microsoft Entra ID에서 삭제되면 Microsoft Entra ID는 디렉터리 서버에 삭제 작업을 보냅니다. 사용자가 애플리케이션을 사용할 수 있는 범위를 벗어난 경우 Microsoft Entra ID에서 디렉터리 서버의 개체를 업데이트하도록 할 수도 있습니다. 이 동작은 디렉터리 서버를 사용할 애플리케이션에 따라 달라집니다. OpenLDAP와 같은 많은 디렉터리에는 사용자의 계정이 비활성화되었음을 나타내는 기본 방법이 없을 수 있기 때문입니다.

LDAP 디렉터리 준비

디렉터리 서버가 아직 없고 이 기능을 사용해 보려는 경우 Microsoft Entra ID에서 프로비전을 위한 Active Directory Lightweight Directory Services 준비에서는 테스트 AD LDS 환경을 만드는 방법을 보여 줍니다. 다른 디렉터리 서버를 이미 배포한 경우 해당 문서를 건너뛰고 ECMA 커넥터 호스트를 계속 설치 및 구성할 수 있습니다.

Microsoft Entra Connect 프로비전 에이전트 설치 및 구성

프로비전 에이전트를 이미 다운로드하고 다른 온-프레미스 애플리케이션에 대해 구성한 경우 다음 섹션에서 계속 읽어 보세요.

Azure Portal에 로그인합니다.
엔터프라이즈 애플리케이션으로 이동하고 새 애플리케이션을 선택합니다.
온-프레미스 ECMA 앱 애플리케이션을 검색하고, 앱 이름을 지정하고, 만들기를 선택하여 테넌트에 추가합니다.
메뉴에서 애플리케이션의 프로비전 페이지로 이동합니다.
시작하기를 선택합니다.
프로비전 페이지에서 모드를 자동으로 변경합니다.

온-프레미스 연결에서 다운로드 및 설치를 선택하고 약관 동의 및 다운로드를 선택합니다.

포털을 종료하고 프로비전 에이전트 설치 프로그램을 열고 서비스 약관에 동의한 후 다음을 선택합니다.
Microsoft Entra 프로비전 에이전트 구성 마법사가 나타날 때까지 기다린 후 다음을 선택합니다.
확장 선택 단계에서 온-프레미스 애플리케이션 프로비전을 선택한 후 다음을 선택합니다.
프로비전 에이전트는 운영 체제의 웹 브라우저를 사용하여 Microsoft Entra ID 및 잠재적으로 조직의 ID 공급자를 인증할 수 있는 팝업 창을 표시합니다. Windows Server에서 Internet Explorer를 브라우저로 사용하는 경우 JavaScript가 올바르게 실행되도록 하려면 브라우저의 신뢰할 수 있는 사이트 목록에 Microsoft 웹 사이트를 추가해야 할 수 있습니다.
권한 부여하라는 메시지가 표시되면 Microsoft Entra 관리자의 자격 증명을 제공합니다. 사용자에게는 최소한 하이브리드 ID 관리자 역할이 있어야 합니다.
확인을 선택하여 설정을 확인합니다. 설치가 완료되면 종료를 선택하고 프로비전 에이전트 패키지 설치 프로그램을 닫을 수도 있습니다.

온-프레미스 ECMA 앱 구성

포털로 돌아가서 온-프레미스 연결 섹션에서 배포한 에이전트를 선택하고 에이전트 할당을 선택합니다.
구성 마법사를 사용하여 구성의 다음 단계를 수행하는 경우 이 브라우저 창을 열어 둡니다.

Microsoft Entra ECMA 커넥터 호스트 인증서 구성

프로비전 에이전트가 설치된 Windows Server의 시작 메뉴에서 Microsoft ECMA2Host 구성 마법사를 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행합니다. 마법사가 필요한 Windows 이벤트 로그를 만들려면 Windows 관리자로 실행해야 합니다.
ECMA 커넥터 호스트 구성이 시작된 후 마법사를 처음 실행하는 경우 인증서를 만들라는 메시지가 표시됩니다. 기본 포트 8585를 그대로 두고 인증서 생성을 선택하여 인증서를 생성합니다. 자동 생성된 인증서는 신뢰할 수 있는 루트의 일부로 자체 서명됩니다. SAN은 호스트 이름과 일치합니다.
저장을 선택합니다.

참고 항목

새 인증서를 생성하도록 선택한 경우 인증서 만료 날짜를 기록하여 구성 마법사로 돌아가 만료되기 전에 인증서를 다시 생성하도록 예약하세요.

일반 LDAP 커넥터 구성

선택한 옵션에 따라 일부 마법사 화면을 사용하지 못할 수 있으며 정보가 약간 다를 수도 있습니다. 이 예제 구성을 위해 User 개체 클래스를 사용하여 사용자를 프로비전하는 것은 AD LDS에 대해 표시되고 OpenLDAP의 경우 inetOrgPerson 개체 클래스가 표시됩니다. 다음 정보를 사용하여 구성 작업을 수행합니다.

Microsoft Entra ID를 커넥터에 인증하는 데 사용할 비밀 토큰을 생성합니다. 최소 12자여야 하며 각 애플리케이션에 대해 고유해야 합니다. 비밀 생성기가 아직 없는 경우 다음과 같은 PowerShell 명령을 사용하여 예제 임의 문자열을 생성할 수 있습니다.
```
-join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
```
아직 수행하지 않은 경우 시작 메뉴에서 Microsoft ECMA2Host 구성 마법사를 시작합니다.
새 커넥터를 선택합니다.

속성 페이지에서 상자를 이미지 뒤에 나오는 표에 지정된 값으로 채우고, 다음을 선택합니다.

속성	값
속성	환경의 모든 커넥터에서 고유해야 하는 커넥터에 대해 선택한 이름입니다. 예: `LDAP`.
자동 동기화 타이머(분)	120
비밀 토큰	여기에 비밀 토큰을 입력합니다. 12자 이상이어야 합니다.
확장 DLL	일반 LDAP 커넥터의 경우 Microsoft.IAM.Connector.GenericLdap.dll을 선택합니다.

연결 페이지에서 ECMA 커넥터 호스트가 디렉터리 서버와 통신하는 방법을 구성하고 일부 구성 옵션을 설정합니다. 이미지 다음에 나오는 표에 지정된 값으로 상자를 채우고 다음을 선택합니다. 다음을 선택하면 커넥터가 디렉터리 서버의 해당 구성을 쿼리합니다.

속성	설명
Host	LDAP 서버가 있는 호스트 이름입니다. 이 샘플에서는 예제 호스트 이름으로 `APP3`를 사용합니다.
Port	TCP 포트 번호입니다. 디렉터리 서버가 LDAP over SSL에 대해 구성된 경우 포트 636을 사용합니다. `Start TLS`의 경우 또는 네트워크 수준 보안을 사용하는 경우 포트 389를 사용합니다.
연결 제한 시간	180
바인딩	이 속성은 커넥터가 디렉터리 서버에 인증하는 방법을 지정합니다. `Basic` 설정을 사용하거나 `SSL` 또는 `TLS` 설정을 사용하고 클라이언트 인증서가 구성되지 않은 경우 커넥터는 고유 이름과 암호로 인증하기 위해 LDAP 단순 바인딩을 보냅니다. `SSL` 또는 `TLS` 설정 및 클라이언트 인증서가 지정되면 커넥터는 클라이언트 인증서로 인증하기 위해 LDAP SASL `EXTERNAL` 바인딩을 보냅니다.
사용자 이름	ECMA 커넥터가 디렉터리 서버에 인증하는 방법입니다. AD LDS에 대한 이 샘플에서 예제 사용자 이름은 `CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab`이고 OpenLDAP의 경우 `cn=admin,dc=contoso,dc=lab`입니다.
암호	ECMA 커넥터가 디렉터리 서버에 대해 자신을 인증하는 사용자의 암호입니다.
영역/도메인	이 설정은 사용자의 영역/도메인을 제공하기 위해 바인딩 옵션으로 `Kerberos`를 선택한 경우에만 필요합니다.
인증서	이 섹션의 설정은 바인딩 옵션으로 `SSL` 또는 `TLS`를 선택한 경우에만 사용됩니다.
특성 별칭	특성 별칭 텍스트 상자는 RFC4522 구문을 사용하여 스키마에 정의된 특성에 사용됩니다. 이러한 특성은 스키마 검색 중에 검색될 수 없고 커넥터는 해당 특성을 식별하는 데 도움이 필요합니다. 예를 들어 디렉터리 서버가 `userCertificate;binary`를 게시하지 않는데 해당 특성을 프로비전하려는 경우 userCertificate 특성을 이진 특성으로 올바르게 식별하려면 특성 별칭 상자에 `userCertificate;binary` 문자열을 입력해야 합니다. 스키마에 없는 특수 특성이 필요하지 않은 경우 이 상자를 비워 둘 수 있습니다.
운영 특성 포함	`Include operational attributes in schema` 확인란을 선택하여 디렉터리 서버에서 생성된 특성도 포함합니다. 여기에는 개체를 만든 시점과 마지막 업데이트 시간 등의 특성을 포함합니다.
확장 가능한 특성 포함	확장 가능한 개체(RFC4512/4.3)가 디렉터리 서버에서 사용되는 경우 `Include extensible attributes in schema` 확인란을 선택합니다. 이 옵션을 사용하도록 설정하면 모든 개체에 대한 모든 특성을 사용할 수 있습니다. 이 옵션을 선택하면 스키마가 매우 커지므로 연결된 디렉터리가 이 기능을 사용하지 않는 한 옵션을 선택하지 않는 것이 좋습니다.
수동 앵커 선택 허용	확인되지 않은 상태로 둡니다.

참고 항목

연결 시도 중 문제가 발생하고 전역 페이지로 진행할 수 없는 경우에는 AD LDS 또는 다른 디렉터리 서버의 서비스 계정이 사용하도록 설정되어 있는지 확인합니다.

전역 페이지에서 델타 변경 로그의 고유 이름(필요한 경우) 및 추가 LDAP 기능을 구성합니다. 페이지는 LDAP 서버에서 제공하는 정보로 미리 채워집니다. 표시된 값을 검토하고 다음을 선택합니다.

속성	설명
지원되는 SASL 메커니즘	위쪽 섹션에는 SASL 메커니즘 목록을 포함하여 서버 자체에서 제공하는 정보가 표시됩니다.
서버 인증서 세부 정보	`SSL` 또는 `TLS`가 지정된 경우 마법사는 디렉터리 서버에서 반환된 인증서를 표시합니다. 발급자, 주체 및 지문이 올바른 디렉터리 서버에 해당하는지 확인합니다.
필수 기능 발견	또한 커넥터는 필수 컨트롤이 루트 DSE에 있는지 확인합니다. 이러한 제어가 나열되지 않으면 경고가 표시됩니다. 일부 LDAP 디렉터리는 루트 DSE의 모든 기능을 나열하지는 않고 경고가 있는 경우에 커넥터가 문제 없이 작동할 수 있습니다.
지원되는 컨트롤	지원되는 컨트롤 확인란은 특정 작업에 대한 동작을 제어합니다.
델타 가져오기	변경 로그 DN은 델타 변경 로그에서 사용하는 명명 컨텍스트입니다. 예: cn=changelog. 델타 가져오기를 수행할 수 있으려면 이 값을 지정해야 합니다.
암호 특성	디렉터리 서버가 다른 암호 특성 또는 암호 해시를 지원하는 경우 암호 변경 대상을 지정할 수 있습니다.
파티션 이름	추가 파티션 목록에서 자동으로 검색된 추가 네임스페이스를 추가할 수 있습니다. 예를 들어 이 설정은 여러 서버가 논리 클러스터를 구성하는 경우 사용될 수 있으며 이는 동시에 모두 가져와야 합니다. Active Directory가 하나의 포리스트에서 여러 도메인을 가질 수 있지만 모든 도메인이 하나의 스키마를 공유하는 것처럼 동일하게 이 상자에 추가 네임스페이스를 입력하여 시뮬레이션할 수 있습니다. 각 네임스페이스는 서로 다른 서버에서 가져올 수 있으며 파티션 및 계층 구조 구성 페이지에서 구성됩니다.

파티션 페이지에서 기본값을 유지하고, 다음을 선택합니다.

프로필 실행 페이지에서 내보내기 확인란 및 전체 가져오기 확인란이 모두 선택되어 있는지 확인합니다. 그런 후 다음을 선택합니다.

속성	설명
내보내기	데이터를 LDAP 디렉터리 서버로 내보낼 프로필을 실행합니다. 이 실행 프로필은 필수입니다.
전체 가져오기	이전에 지정한 LDAP 원본에서 모든 데이터를 가져오는 실행 프로필입니다. 이 실행 프로필은 필수입니다.
델타 가져오기	마지막 전체 또는 델타 가져오기 이후의 변경 내용만 LDAP에서 가져오는 실행 프로필입니다. 디렉터리 서버가 필요한 요구 사항을 충족하는지 확인한 경우에만 이 실행 프로필을 사용하도록 설정합니다. 자세한 내용은 일반 LDAP 커넥터 참조를 참조하세요.

내보내기 페이지에서 기본값을 변경하지 않고 그대로 두고 다음을 클릭합니다.
전체 가져오기 페이지에서 기본값을 변경하지 않고 그대로 두고 다음을 클릭합니다.
델타 가져오기 페이지에서 있는 경우 기본값을 변경하지 않고 그대로 두고 다음을 클릭합니다.

개체 형식 페이지에서 상자를 채우고, 다음을 선택합니다.

속성	설명
대상 개체	이 값은 LDAP 디렉터리 서버에서 사용자의 구조적 개체 클래스입니다. 예를 들어 `inetOrgPerson`(OpenLDAP) 또는 `User`(AD LDS)입니다. 이 필드에 보조 개체 클래스를 지정하지 마세요. 디렉터리 서버에 보조 개체 클래스가 필요한 경우 Azure Portal에서 특성 매핑을 사용하여 구성됩니다.
기준 위치	이 특성의 값은 대상 데이터베이스의 각 개체에 대해 고유해야 합니다. Microsoft Entra 프로비전 서비스는 초기 주기 후에 이 특성을 사용하여 ECMA 커넥터 호스트를 쿼리합니다. AD LDS의 경우 `ObjectGUID`를 사용하고 다른 디렉터리 서버에의 경우 다음 표를 참조하세요. 고유 이름은 `-dn-`으로 선택될 수 있습니다. OpenLDAP 스키마의 `uid` 특성과 같은 다중값 특성은 앵커로 사용할 수 없습니다.
쿼리 특성	이 특성은 앵커와 동일해야 합니다(예: AD LDS가 디렉터리 서버인 경우 `objectGUID`, OpenLDAP인 경우 `_distinguishedName`).
DN	대상 개체의 distinguishedName입니다. `-dn-`를 유지합니다.
자동 생성	unchecked

다음 표에서는 사용 중인 LDAP 서버 및 앵커를 나열합니다.

디렉터리	기준 위치
Microsoft AD LDS 및 AD GC	objectGUID. `ObjectGUID`가 앵커로 사용되려면 에이전트 버전 1.1.846.0 이상을 사용해야 합니다.
389 디렉터리 서버	dn
Apache 디렉터리	dn
IBM Tivoli DS	dn
Isode 디렉터리	dn
Novell/NetIQ eDirectory	GUID
DJ/DS 열기	dn
LDAP 열기	dn
Oracle ODSEE	dn
RadiantOne VDS	dn
Sun One 디렉터리 서버	dn

ECMA 호스트는 대상 디렉터리에서 지원하는 특성을 검색합니다. Microsoft Entra ID에 노출하려는 특성을 선택할 수 있습니다. 그런 다음, 프로비저닝을 위해 Azure Portal에서 특성을 구성할 수 있습니다. 특성 선택 페이지에서 필수 특성으로 필요하거나 Microsoft Entra ID에서 프로비전하려는 드롭다운 목록의 특성을 모두 한 번에 하나씩 추가합니다.
특성 드롭다운 목록에는 대상 디렉터리에서 검색되었고 구성 마법사 특성 선택 페이지의 이전 사용에서 선택되지 않은 모든 특성이 표시됩니다.

Treat as single value 확인란이 objectClass 특성에 대해 선택 취소되었고 userPassword가 설정되는 경우 userPassword에 대해 선택할 수 없거나 선택되었는지 확인합니다.

inetOrgPerson 스키마와 함께 OpenLDAP를 사용하는 경우 다음 특성에 대한 표시 여부를 구성하세요.

Attribute 단일 값으로 처리

cn Y

mail Y

objectClass

sn Y

userPassword Y

POSIX 스키마와 함께 OpenLDAP를 사용하는 경우 다음 특성에 대한 표시 여부를 구성하세요.

Attribute 단일 값으로 처리

_distinguishedName

-dn-

export_password

cn Y

gidNumber

homeDirectory

mail Y

objectClass

sn Y

uid Y

uidNumber

userPassword Y

관련 특성을 모두 추가했으면 다음을 선택합니다.
프로비전 해제 페이지에서 사용자가 애플리케이션의 범위를 벗어난 경우 Microsoft Entra ID가 디렉터리에서 사용자를 제거하도록 할지 지정할 수 있습니다. 이 경우 흐름 사용 안 함에서 삭제를 선택하고 흐름 삭제에서 삭제를 선택합니다. Set attribute value가 선택된 경우 이전 페이지에서 선택한 특성은 프로비전 해제 페이지에서 선택할 수 없습니다.

Attribute	단일 값으로 처리
cn	Y
mail	Y
objectClass
sn	Y
userPassword	Y

Attribute	단일 값으로 처리
_distinguishedName
-dn-
export_password
cn	Y
gidNumber
homeDirectory
mail	Y
objectClass
sn	Y
uid	Y
uidNumber
userPassword	Y

참고 항목

특성 값 설정을 사용하는 경우 부울 값만 허용된다는 점에 유의합니다.

마침을 선택합니다.

ECMA2Host 서비스가 실행 중이고 디렉터리 서버에서 읽을 수 있는지 확인

커넥터 호스트가 시작되었고 디렉터리 서버에서 커넥터 호스트로 기존 사용자를 읽어왔음을 확인하려면 다음 단계를 수행합니다.

Microsoft Entra ECMA 커넥터 호스트를 실행하는 서버에서 시작을 선택합니다.
필요한 경우 실행을 선택한 다음, 상자에 services.msc를 입력합니다.
서비스 목록에서 Microsoft ECMA2Host가 있고 실행 중인지 확인합니다. 실행되고 있지 않으면 시작을 선택합니다.
최근에 서비스를 시작했고 디렉터리 서버에 많은 사용자 개체가 있는 경우 커넥터가 디렉터리 서버에 대한 연결을 설정할 때까지 몇 분 정도 기다립니다.
Microsoft Entra ECMA 커넥터 호스트를 실행하는 서버에서 PowerShell을 시작합니다.
ECMA 호스트가 설치된 폴더(예: C:\Program Files\Microsoft ECMA2Host)로 변경합니다.
하위 디렉터리 Troubleshooting으로 변경합니다.
다음 예제와 같이 해당 디렉터리에서 TestECMA2HostConnection.ps1 스크립트를 실행하고 커넥터 이름과 ObjectTypePath 값 cache를 인수로 제공합니다. 커넥터 호스트가 TCP 포트 8585에서 수신 대기하지 않는 경우 -Port 인수도 제공해야 할 수 있습니다. 메시지가 표시되면 해당 커넥터에 대해 구성된 비밀 토큰을 입력합니다.
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
```
스크립트에 오류 또는 경고 메시지가 표시되면 서비스가 실행 중이고 커넥터 이름 및 비밀 토큰이 구성 마법사에서 구성한 값과 일치하는지 확인합니다.
스크립트에 출력 False가 표시되면 커넥터가 기존 사용자에 대한 원본 디렉터리 서버의 항목을 확인하지 못한 것입니다. 새 디렉터리 서버 설치인 경우 이 동작이 예상되며 다음 섹션에서 계속할 수 있습니다.
그러나 디렉터리 서버에 이미 하나 이상의 사용자가 있지만 스크립트에 False가 표시된 경우 이 상태는 커넥터가 디렉터리 서버에서 읽을 수 없음을 나타냅니다. 프로비저닝을 시도하는 경우 Microsoft Entra ID는 해당 원본 디렉터리의 사용자와 Microsoft Entra ID의 사용자와 올바르게 일치하지 않을 수 있습니다. 커넥터 호스트가 기존 디렉터리 서버에서 개체 읽기를 완료할 때까지 몇 분 정도 기다린 다음, 스크립트를 다시 실행합니다. 출력이 계속 False인 경우 커넥터의 구성 및 디렉터리 서버의 권한에서 커넥터가 기존 사용자를 읽도록 허용하는지 확인합니다.

Microsoft Entra ID에서 커넥터 호스트로 연결 테스트

포털에서 애플리케이션 프로비전을 구성했던 웹 브라우저 창으로 돌아갑니다.

참고 항목

작업 시간이 초과되었으면 에이전트를 다시 선택해야 합니다.
1. Azure Portal에 로그인합니다.
2. 엔터프라이즈 애플리케이션 및 온-프레미스 ECMA 앱 애플리케이션으로 이동합니다.
3. 프로비전을 클릭합니다.
4. 시작이 나타나면 모드를 자동으로 변경하고 온-프레미스 연결 섹션에서 방금 배포한 에이전트를 선택하고 에이전트 할당을 선택하고 10분 동안 기다립니다. 그렇지 않으면 프로비전 편집으로 이동합니다.
관리자 자격 증명 섹션에서 다음 URL을 입력합니다. connectorName 부분을 LDAP와 같은 ECMA 호스트의 커넥터 이름으로 바꿉니다. ECMA 호스트에 대한 인증 기관의 인증서를 제공한 경우 localhost를 ECMA 호스트가 설치된 서버의 호스트 이름으로 바꿉니다.

속성 값

테넌트 URL https://localhost:8585/ecma2host_connectorName/scim
커넥터를 만들 때 정의한 비밀 토큰 값을 입력합니다.

참고 항목

애플리케이션에 에이전트를 할당한 경우 등록이 완료될 때까지 10분 정도 기다려주세요. 연결 테스트는 등록이 완료될 때까지 작동하지 않습니다. 서버에서 프로비전 에이전트를 다시 시작하여 에이전트 등록을 강제로 완료하도록 하면 등록 프로세스의 속도가 빨라질 수 있습니다. 서버로 이동하고, Windows 검색 창에서 서비스를 검색하고, Microsoft Entra Connect 프로비전 에이전트 서비스를 식별하고, 마우스 오른쪽 단추로 해당 서비스를 클릭하고, 다시 시작합니다.
연결 테스트를 선택하고, 1분 동안 기다립니다.
연결 테스트가 성공하고 제공된 자격 증명이 프로비저닝을 사용하도록 설정할 수 있는 권한이 있다고 표시되면 저장을 선택합니다.

속성	값
테넌트 URL	https://localhost:8585/ecma2host_connectorName/scim

Microsoft Entra 스키마 확장(선택 사항)

디렉터리 서버에 사용자를 위한 기본 Microsoft Entra 스키마의 일부가 아닌 추가 특성이 필요한 경우 프로비전할 때 상수, 다른 Microsoft Entra 특성에서 변환된 식 또는 Microsoft Entra 스키마 확장을 통해 해당 특성 값을 제공하도록 구성할 수 있습니다.

디렉터리 서버에서 사용자에게 OpenLDAP POSIX 스키마에 대한 uidNumber와 같은 특성이 필요하고 해당 특성이 아직 사용자에 대한 Microsoft Entra 스키마의 일부가 아니며 각 사용자에 대해 고유해야 하는 경우 다음이 필요합니다. 식을 통해 사용자의 다른 특성에서 해당 특성을 생성하거나 디렉터리 확장 기능을 사용하여 해당 특성을 확장으로 추가합니다.

사용자가 Active Directory Domain Services에서 시작되고 해당 디렉터리에 특성이 있는 경우 Microsoft Entra Connect 또는 Microsoft Entra Connect 클라우드 동기화를 사용하여 특성을 Active Directory 도메인 서비스에서 Microsoft Entra ID로 동기화하여 다른 시스템에 프로비전하는 데 사용할 수 있도록 구성할 수 있습니다.

사용자가 Microsoft Entra ID에서 시작된 경우 사용자에게 저장해야 하는 새 특성마다 디렉터리 확장을 정의해야 합니다. 그런 다음 프로비전할 예정인 Microsoft Entra 사용자를 업데이트하여 각 사용자에게 해당 특성 값을 제공합니다.

특성 매핑 구성

이 섹션에서는 Microsoft Entra 사용자의 특성과 ECMA 호스트 구성 마법사에서 이전에 선택한 특성 간에 매핑을 구성합니다. 나중에 커넥터가 디렉터리 서버에서 개체를 만들면 Microsoft Entra 사용자의 특성은 커넥터를 통해 해당 새 개체의 일부로 디렉터리 서버에 전송됩니다.

Microsoft Entra 관리 센터의 엔터프라이즈 애플리케이션에서 온-프레미스 ECMA 앱 애플리케이션을 선택한 다음 프로비전 페이지를 선택합니다.
프로비저닝 편집을 선택합니다.
매핑을 확장한 후 Microsoft Entra 사용자 프로비전을 선택합니다. 이 애플리케이션에 대한 특성 매핑을 처음으로 구성한 경우 자리 표시자에 대해 하나의 매핑만 존재합니다.
Microsoft Entra ID에서 디렉터리 서버의 스키마를 사용할 수 있는지 확인하려면 고급 옵션 표시 확인란을 선택하고 ScimOnPremises의 특성 목록 편집을 선택합니다. 구성 마법사에서 선택한 모든 특성이 나열되는지 확인합니다. 모두 나열되지 않으면 스키마가 새로 고쳐질 때까지 몇 분 정도 기다린 다음, 탐색 줄에서 특성 매핑을 선택한 다음, ScimOnPremises에 대한 특성 목록 편집을 다시 선택하여 페이지를 다시 로드합니다. 특성이 나열되면 이 페이지에서 취소하여 매핑 목록으로 돌아갑니다.
디렉터리의 모든 사용자에게는 고유한 고유 이름이 있어야 합니다. 특성 매핑을 사용하여 커넥터가 고유 이름을 구성하는 방법을 지정할 수 있습니다. 새 매핑 추가를 선택합니다. 다음 예제의 값을 사용하여 매핑을 만들고 식의 고유 이름을 대상 디렉터리의 조직 구성 단위 또는 다른 컨테이너의 이름과 일치하도록 변경합니다.
- 매핑 유형: 식
- 식, AD LDS로 프로비전하는 경우: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
- 식, OpenLDAP로 프로비전하는 경우: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
- 대상 특성: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
- 이 매핑 적용: 개체를 만드는 동안에만
디렉터리 서버에서 여러 구조적 개체 클래스 값 또는 보조 개체 클래스 값을 objectClass 특성으로 제공해야 하는 경우 해당 특성에 대한 매핑을 추가합니다. AD LDS로 프로비전하는 이 예제에서는 objectClass 매핑이 필요하지 않지만 다른 디렉터리 서버 또는 다른 스키마에 필요할 수 있습니다. objectClass에 대한 매핑을 추가하려면 새 매핑 추가를 선택합니다. 다음 예제의 값을 사용하여 매핑을 만들고 식의 개체 클래스 이름을 대상 디렉터리 스키마의 이름과 일치하도록 변경합니다.
- 매핑 유형: 식
- 식, inetOrgPerson 스키마를 프로비전하는 경우: Split("inetOrgPerson",",")
- 식, POSIX 스키마를 프로비전하는 경우: Split("inetOrgPerson,posixAccount,shadowAccount",",")
- 대상 특성: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- 이 매핑 적용: 개체를 만드는 동안에만
AD LDS로 프로비전하고 userPrincipalName에서 PLACEHOLDER로 매핑이 있는 경우 해당 매핑을 클릭하고 편집합니다. 아래 값을 사용하여 매핑을 업데이트합니다.
- 매핑 유형: 직접
- 원본 특성: userPrincipalName
- 대상 특성: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
- 일치 우선 순위: 1
- 이 매핑 적용: 개체를 만드는 동안에만
AD LDS로 프로비전하는 경우 isSoftDeleted에 대한 매핑을 추가합니다. 새 매핑 추가를 선택합니다. 아래 값을 사용하여 매핑을 만듭니다.
- 매핑 유형: 직접
- 원본 특성: isSoftDeleted
- 대상 특성: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

디렉터리 서버에 대한 다음 표의 각 매핑에 대해 새 매핑 추가를 선택하고 원본 및 대상 특성을 지정합니다. 기존 사용자가 있는 기존 디렉터리로 프로비전하는 경우 공통 특성에 대한 매핑을 편집하여 해당 특성에 대해 이 특성을 사용하여 Match 개체를 설정해야 합니다. 여기에서 특성 매핑에 대해 자세히 알아봅니다.

AD LDS의 경우:

매핑 유형	원본 특성	대상 특성
Direct	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName`

OpenLDAP의 경우:

매핑 유형	원본 특성	대상 특성
Direct	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn`
Direct	`surname`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn`
Direct	`userPrincipalName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail`

POSIX 스키마가 있는 OpenLDAP의 경우 gidNumber, homeDirectory, uid 및 uidNumber 특성도 제공해야 합니다. 각 사용자에게는 고유한 uid 및 고유한 uidNumber가 필요합니다. 일반적으로 homeDirectory는 사용자의 userID에서 파생된 식으로 설정됩니다. 예를 들어, 사용자의 uid가 사용자 계정 이름에서 파생된 식으로 생성된 경우 해당 사용자의 홈 디렉터리 값도 사용자 계정 이름에서 파생된 유사한 식으로 생성될 수 있습니다. 그리고 사용 사례에 따라 모든 사용자를 동일한 그룹에 두기를 원할 수 있으므로 상수에서 gidNumber를 할당합니다.

매핑 유형	원본 특성	대상 특성
식	`ToLower(Word([userPrincipalName], 1, "@"), )`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid`
Direct	(디렉터리에 특정한 특성)	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber`
식	`Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory`
상수	`10000`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber`

AD LDS가 아닌 디렉터리에 프로비전하는 경우 사용자의 초기 임의 암호를 설정하는 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword에 매핑을 추가합니다. AD LDS의 경우 userPassword에 대한 매핑이 없습니다.
저장을 선택합니다.

애플리케이션에 프로비전할 사용자가 Microsoft Entra ID에서 필수 특성이 있는지 확인합니다.

LDAP 디렉터리에 기존 사용자 계정이 있는 사람이 있는 경우 Microsoft Entra 사용자 표현에 일치에 필요한 특성이 있는지 확인해야 합니다.

LDAP 디렉터리에 새 사용자를 만들려는 경우 해당 사용자의 Microsoft Entra 표현에 대상 디렉터리의 사용자 스키마에 필요한 원본 특성이 있는지 확인해야 합니다.

Microsoft Graph PowerShell cmdlet을 사용하면 사용자에게 필요한 특성을 자동으로 확인할 수 있습니다.

예를 들어, 프로비전에서 사용자에게 세 가지 특성 DisplayName, surname 및 extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty가 필요하다고 가정합니다. Get-MgUser cmdlet을 사용하여 각 사용자를 검색하고 필수 특성이 있는지 확인할 수 있습니다. Graph v1.0 Get-MgUser cmdlet은 요청에서 특성이 반환할 속성 중 하나로 지정되지 않는 한 기본적으로 사용자의 디렉터리 확장 특성을 반환하지 않습니다.

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

LDAP 디렉터리에서 기존 사용자 수집

Active Directory와 같은 많은 LDAP 디렉터리에는 사용자 목록을 출력하는 명령이 포함됩니다.

애플리케이션의 사용자 범위에 있는 해당 디렉터리의 사용자를 식별합니다. 이 선택은 애플리케이션 구성에 따라 달라집니다. 일부 애플리케이션의 경우 LDAP 디렉터리에 있는 모든 사용자가 유효한 사용자입니다. 다른 애플리케이션에서는 사용자가 특정 특성을 가지고 있거나 해당 디렉터리에 있는 그룹의 구성원이어야 할 수 있습니다.
LDAP 디렉터리에서 해당 사용자 하위 집합을 검색하는 명령을 실행합니다. 출력에 Microsoft Entra ID와 일치시키는 데 사용할 사용자 특성이 포함되어 있는지 확인합니다. 이러한 특성의 예로는 직원 ID, 계정 이름 및 이메일 주소가 있습니다.

예를 들어, AD LDS csvde 프로그램을 사용하는 Windows의 이 명령은 디렉터리에 있는 모든 사람의 userPrincipalName 특성을 사용하여 현재 파일 시스템 디렉터리에 CSV 파일을 생성합니다.
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
필요한 경우 사용자 목록이 포함된 CSV 파일을 Microsoft Graph PowerShell cmdlet이 설치된 시스템으로 전송합니다.
이제 애플리케이션에서 가져온 모든 사용자 목록이 있으므로 애플리케이션 데이터 저장소의 해당 사용자를 Microsoft Entra ID의 사용자와 일치시킵니다. 계속하기 전에 원본 및 대상 시스템에서 사용자 일치에 대한 정보를 검토합니다.

Microsoft Entra ID에서 사용자의 ID를 검색합니다.

이 섹션에서는 Microsoft Graph PowerShell cmdlet을 사용하여 Microsoft Entra ID와 상호 작용하는 방법을 보여 줍니다.

조직에서 이 시나리오에 이러한 cmdlet을 처음 사용하는 경우 테넌트에서 Microsoft Graph PowerShell을 사용할 수 있도록 허용하는 전역 관리자 역할이 필요합니다. 후속 상호 작용에서 다음과 같은 낮은 권한 있는 역할을 사용할 수 있습니다.

사용자 관리자(새 사용자를 만들 것으로 예상되는 경우)
애플리케이션 관리자 또는 ID 거버넌스 관리자(애플리케이션 역할 할당만 관리하는 경우)

PowerShell을 엽니다.
Microsoft Graph PowerShell 모듈을 아직 설치하지 않았으면 이 명령을 사용하여 Microsoft.Graph.Users 모듈과 다른 모듈을 설치합니다.
```
Install-Module Microsoft.Graph
```
모듈이 이미 설치되어 있으면 최신 버전을 사용하고 있는지 확인합니다.
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Microsoft Entra ID에 연결합니다.

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

이 명령을 처음 사용하는 경우 Microsoft Graph 명령줄 도구에 이러한 사용 권한이 있도록 허용한다는 데 동의해야 할 수 있습니다.
애플리케이션의 데이터 저장소에서 가져온 사용자 목록을 PowerShell 세션으로 읽어 들입니다. 사용자 목록이 CSV 파일에 있으면 PowerShell cmdlet Import-Csv를 사용하고 이전 섹션의 파일 이름을 인수로 제공할 수 있습니다.

예를 들어, SAP Cloud Identity Services에서 가져온 파일의 이름이 Users-exported-from-sap.csv이고 현재 디렉터리에 있는 경우 이 명령을 입력합니다.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
또 다른 예를 들어, 데이터베이스나 디렉터리를 사용하는 경우 파일 이름이 users.csv이고 현재 디렉터리에 있는 경우 다음 명령을 입력합니다.
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Microsoft Entra ID의 사용자 특성과 일치할 users.csv 파일의 열을 선택합니다.

SAP Cloud Identity Services를 사용하는 경우 기본 매핑은 Microsoft Entra ID 특성이 userPrincipalName인 SAP SCIM 특성 userName입니다.
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
또 다른 예로, 데이터베이스나 디렉터리를 사용하는 경우 EMail이라는 열의 값이 Microsoft Entra 특성 userPrincipalName의 값과 동일한 데이터베이스에 사용자가 있을 수 있습니다.
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Microsoft Entra ID에서 해당 사용자의 ID를 검색합니다.

다음 PowerShell 스크립트에서는 앞에서 지정한 $dbusers, $db_match_column_name 및 $azuread_match_attr_name 값을 사용합니다. Microsoft Entra ID를 쿼리하여 원본 파일의 각 레코드에 대해 일치하는 값을 가진 특성을 가진 사용자를 찾습니다. 원본 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리에서 가져온 파일에 사용자가 많은 경우 이 스크립트를 완료하는 데 몇 분 정도 걸릴 수 있습니다. 값이 있는 Microsoft Entra ID 특성이 없고 contains 또는 다른 필터 식을 사용해야 하는 경우 이 스크립트를 사용자 지정하고 다음 11단계에서 다른 필터 식을 사용해야 합니다.

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

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

이전 쿼리의 결과를 봅니다. 오류 또는 일치 엔터티 누락으로 인해 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리의 사용자를 Microsoft Entra ID에서 찾을 수 없는 사용자가 있는지 확인합니다.

다음 PowerShell 스크립트에 찾지 못한 레코드 수가 표시됩니다.

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

스크립트가 완료되면 데이터 원본의 레코드가 Microsoft Entra ID에 없는 경우 오류가 표시됩니다. 애플리케이션 데이터 저장소의 사용자에 대한 모든 레코드를 Microsoft Entra ID의 사용자로 찾을 수 없는 경우 일치하지 않는 레코드와 그 이유를 조사해야 합니다.

예를 들어, 애플리케이션의 데이터 원본에서 해당 mail 속성이 업데이트되지 않은 상태에서 누군가의 이메일 주소와 userPrincipalName이 Microsoft Entra ID에서 변경되었을 수 있습니다. 또는 사용자가 이미 조직을 떠났지만 여전히 애플리케이션의 데이터 원본에 있을 수 있습니다. 또는 Microsoft Entra ID의 특정 개인과 일치하지 않는 애플리케이션의 데이터 원본에 공급업체 또는 최고 관리자 계정이 있을 수 있습니다.
Microsoft Entra ID에서 찾을 수 없거나 활성 상태가 아니어서 로그인할 수 없는 사용자가 있지만 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리에서 해당 사용자의 액세스 권한을 검토하거나 해당 특성을 업데이트하려는 경우, 애플리케이션, 일치 규칙을 업데이트하거나 Microsoft Entra 사용자를 업데이트하거나 만들어야 합니다. 어떤 변경을 해야 하는지에 대한 자세한 내용은 Microsoft Entra ID의 사용자와 일치하지 않는 애플리케이션의 매핑 및 사용자 계정 관리를 참조하세요.

Microsoft Entra ID에서 사용자 만들기 옵션을 선택한 경우 다음 중 하나를 사용하여 사용자를 대량으로 만들 수 있습니다.
- CSV 파일(Microsoft Entra 관리 센터에서 사용자 대량 만들기에 설명됨)
- New-MgUser cmdlet
이러한 새 사용자가 나중에 애플리케이션의 기존 사용자와 일치하도록 Microsoft Entra ID에 필요한 특성과 userPrincipalName, mailNickname 및 displayName을 포함하여 Microsoft Entra ID에 필요한 특성으로 채워졌는지 확인합니다. userPrincipalName은 디렉터리의 모든 사용자 중에서 고유해야 합니다.

예를 들어, 데이터베이스에는 EMail이라는 열의 값이 Microsoft Entra 사용자 계정 이름으로 사용하려는 값이고, Alias 열의 값에 Microsoft Entra ID 메일 별명이 포함되어 있고 Full name 열의 값에는 사용자의 표시 이름이 포함됩니다.
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
그런 다음, 이 스크립트를 사용하여 Microsoft Entra ID의 사용자와 일치하지 않는 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리에 대한 Microsoft Entra 사용자를 만들 수 있습니다. 조직에 필요한 Microsoft Entra 특성을 추가하거나 $azuread_match_attr_name이 mailNickname도 아니고 userPrincipalName도 아닌 경우 해당 Microsoft Entra 특성을 제공하려면 이 스크립트를 수정해야 할 수도 있습니다.
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

누락된 사용자를 Microsoft Entra ID에 추가한 후 7단계의 스크립트를 다시 실행합니다. 그런 다음, 8단계에서 스크립트를 실행합니다. 오류가 보고되지 않는지 확인합니다.

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

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

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

애플리케이션에 사용자 할당

이제 Microsoft Entra ID와 통신하는 Microsoft Entra ECMA 커넥터 호스트가 있고 특성 매핑이 구성되었으므로 프로비전 범위에 속하는 사용자를 구성하는 단계로 이동할 수 있습니다.

Important

하이브리드 ID 관리자 역할을 사용하여 로그인한 경우 로그아웃하고 이 섹션에 대해 최소한 애플리케이션 관리자 역할이 있는 계정으로 로그인해야 합니다. 하이브리드 ID 관리자 역할에는 애플리케이션에 사용자를 할당할 수 있는 권한이 없습니다.

LDAP 디렉터리에 기존 사용자가 있는 경우 Microsoft Entra ID에서 기존 사용자에 대한 애플리케이션 역할 할당을 만들어야 합니다. New-MgServicePrincipalAppRoleAssignedTo를 사용하여 애플리케이션 역할 할당을 대량으로 만드는 방법에 대한 자세한 내용은 Microsoft Entra ID에서 애플리케이션의 기존 사용자 관리를 참조하세요.

그렇지 않고, LDAP 디렉터리가 비어 있으면 Microsoft Entra ID에서 필수 특성을 갖고 애플리케이션의 디렉터리 서버에 프로비전될 테스트 사용자를 선택합니다.

선택할 사용자에게 디렉터리 서버 스키마의 필수 특성에 매핑될 모든 속성이 있는지 확인합니다.
Azure Portal에서 엔터프라이즈 애플리케이션을 선택합니다.
온-프레미스 ECMA 앱 애플리케이션을 선택합니다.
왼쪽의 관리 아래에서 사용자 및 그룹을 선택합니다.
사용자/그룹 추가를 선택합니다.
사용자 아래에서 선택된 항목 없음을 선택합니다.
오른쪽에서 사용자를 선택하고 선택 단추를 선택합니다.
이제 할당을 선택합니다.

프로비전 테스트

이제 특성이 매핑되고 초기 사용자가 할당되었으므로 사용자 중 한 명을 대상으로 주문형 프로비전을 테스트할 수 있습니다.

Microsoft Entra ECMA 커넥터 호스트를 실행하는 서버에서 시작을 선택합니다.
상자에서 run, services.msc를 차례로 입력합니다.
서비스 목록에서 Microsoft Entra Connect 프로비전 에이전트 서비스와 Microsoft ECMA2Host 서비스가 모두 실행되고 있는지 확인합니다. 그렇지 않은 경우 시작을 선택합니다.
Azure Portal에서 엔터프라이즈 애플리케이션을 선택합니다.
온-프레미스 ECMA 앱 애플리케이션을 선택합니다.
왼쪽에서 프로비전을 선택합니다.
주문형 프로비전을 선택합니다.
테스트 사용자 중 한 명을 검색하고, 프로비전을 선택합니다.
몇 초 후 사용자 특성 목록과 함께 대상 시스템에서 사용자를 만듦 메시지가 표시됩니다. 대신 오류가 표시되면 프로비전 오류 문제 해결을 참조하세요.

사용자 프로비저닝 시작

주문형 프로비전 테스트가 성공한 후 나머지 사용자를 추가합니다.

Azure Portal에서 애플리케이션을 선택합니다.
왼쪽의 관리 아래에서 사용자 및 그룹을 선택합니다.
모든 사용자가 애플리케이션 역할에 할당되었는지 확인합니다.
프로비전 구성 페이지로 다시 변경합니다.
할당된 사용자 및 그룹으로만 범위가 설정되어 있는지 확인하고, 프로비전 상태를 켜기로 설정한 다음, 저장을 선택합니다.
프로비전이 시작될 때까지 몇 분 정도 기다립니다. 최대 40분이 걸릴 수 있습니다. 다음 섹션에 설명된 대로 프로비전 작업이 완료된 후

프로비전 오류 문제 해결

오류가 표시되면 프로비전 로그 보기를 선택합니다. 로그에서 [상태]가 실패인 행을 찾아 해당 행을 클릭합니다.

사용자를 만들지 못함이라는 오류 메시지인 경우 디렉터리 스키마의 요구 사항에 대해 표시되는 특성을 확인합니다.

자세한 내용을 보려면 문제 해결 및 권장 사항 탭으로 변경합니다.

문제 해결 오류 메시지에 objectClass 값이 invalid per syntax라는 내용이 포함된 경우 objectClass 특성에 대한 프로비전 특성 매핑에 디렉터리 서버에서 인식되는 개체 클래스의 이름만 포함해야 합니다.

다른 오류는 온-프레미스 애플리케이션 프로비전 문제 해결을 참조하세요.

이 애플리케이션에 대한 프로비전을 일시 중지하려면 프로비전 구성 페이지에서 프로비전 상태를 해제로 변경하고 저장을 선택합니다. 이 작업은 나중에 프로비전 서비스의 실행을 중지합니다.

사용자가 성공적으로 프로비전되었는지 확인

기다린 후에 디렉터리 서버를 확인하여 사용자가 프로비전되고 있는지 확인합니다. 디렉터리 서버에 대해 수행하는 쿼리는 디렉터리 서버에서 제공하는 명령에 따라 달라집니다.

다음 지침에서는 AD LDS를 확인하는 방법을 보여 줍니다.

서버 관리자를 열고, 왼쪽에서 AD LDS를 선택합니다.
마우스 오른쪽 단추로 AD LDS 인스턴스를 클릭하고, 팝업에서 ldp.exe를 선택합니다.
ldp.exe의 위쪽에서 연결 및 연결을 차례로 선택합니다.
다음 정보를 입력하고, 확인을 클릭합니다.
- 서버: APP3
- 포트: 636
- SSL 상자에 확인 표시
위쪽의 연결 아래에서 바인딩을 선택합니다.
기본값을 그대로 두고, 확인을 클릭합니다.
위쪽에서 보기 및 트리를 선택합니다.
BaseDN에 대해 CN=App,DC=contoso,DC=lab을 입력하고, 확인을 클릭합니다.
왼쪽에서 DN을 펼치고, CN=CloudUsers,CN=App,DC=contoso,DC=lab을 클릭합니다. Microsoft Entra ID에서 프로비전된 사용자가 표시됩니다.

다음 지침에서는 OpenLDAP를 확인하는 방법을 보여 줍니다.

OpenLDAP가 설치된 시스템에서 명령 셸을 사용하여 터미널 창을 엽니다.
ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson) 명령을 입력합니다.
결과 LDIF에 Microsoft Entra ID에서 프로비전된 사용자가 포함되어 있는지 확인합니다.

다음을 통해 공유

사용자를 LDAP 디렉터리로 프로비전하도록 Microsoft Entra ID 구성

사용자를 LDAP 디렉터리에 프로비전하기 위한 필수 구성 요소

온-프레미스 필수 조건

지원되는 LDAP 디렉터리 서버

클라우드 요구 사항

추가 권장 사항 및 제한 사항

실행 프로필 선택

Microsoft Entra LDAP 커넥터가 디렉터리 서버와 상호 작용하는 방법 결정

LDAP 디렉터리 준비

Microsoft Entra Connect 프로비전 에이전트 설치 및 구성

온-프레미스 ECMA 앱 구성

Microsoft Entra ECMA 커넥터 호스트 인증서 구성

일반 LDAP 커넥터 구성

ECMA2Host 서비스가 실행 중이고 디렉터리 서버에서 읽을 수 있는지 확인

Microsoft Entra ID에서 커넥터 호스트로 연결 테스트

Microsoft Entra 스키마 확장(선택 사항)

특성 매핑 구성

애플리케이션에 프로비전할 사용자가 Microsoft Entra ID에서 필수 특성이 있는지 확인합니다.

LDAP 디렉터리에서 기존 사용자 수집

Microsoft Entra ID에서 사용자의 ID를 검색합니다.

애플리케이션에 사용자 할당

프로비전 테스트

사용자 프로비저닝 시작

프로비전 오류 문제 해결

사용자가 성공적으로 프로비전되었는지 확인

다음 단계

피드백

추가 리소스