Linux 인증을 위해 사용자를 LDAP 디렉터리로 프로비전하도록 Microsoft Entra ID 구성

아티클
12/13/2024

다음 설명서는 Linux 시스템에 대한 액세스를 제어하는 방법을 보여주는 자습서입니다. Microsoft Entra는 사용자를 해당 Linux 시스템에서 신뢰할 수 있는 온-프레미스 LDAP 디렉터리로 프로비전합니다. 이를 통해 사용자는 사용자 인증을 위해 해당 LDAP 디렉터리를 사용하는 Linux 시스템에 로그인할 수 있습니다. 사용자가 Microsoft Entra ID에서 제거되면 더 이상 Linux 시스템에 로그인할 수 없습니다.

메모

이 문서에서 설명하는 시나리오는 사용자 식별 및 인증을 위해 이미 NSS(Name Services Switch) 또는 PAM(플러그형 인증 모듈) LDAP 모듈을 사용하는 기존 Linux 시스템에만 적용됩니다. Azure 또는 Azure Arc 사용의 Linux VM은 대신 Microsoft Entra 인증과 통합되어야 합니다. 이제 Microsoft Entra ID 및 OpenSSH사용하여 Azure의 Linux 가상 머신에 로그인하는 설명한 대로 Microsoft Entra ID 및 OpenSSH 인증서 기반 인증을 사용하여 Microsoft Entra ID를 핵심 인증 플랫폼 및 인증 기관으로 사용하여 Linux VM에 SSH할 수 있습니다.

Linux 인증 이외의 LDAP 디렉터리에 사용자를 프로비저닝하는 다른 시나리오는 사용자를LDAP 디렉터리로 프로비전하도록 Microsoft Entra ID를 구성하는 참조하세요.

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

이 문서에서는 사용자 인증을 위해 하나 이상의 Linux 또는 다른 POSIX 시스템에서 사용하는 온-프레미스 환경에 LDAP 서버가 이미 있다고 가정합니다.

Microsoft Entra ID에서 LDAP 디렉터리 서버로 온-프레미스 프로비저닝을 위한 아키텍처를 보여주는 다이어그램

온-프레미스 필수 구성 요소

PAM 또는 NSS 모듈을 사용하여 디렉터리 서버에 회신하는 Linux 또는 기타 POSIX 서버입니다.
사용자를 만들고 업데이트하고 삭제할 수 있는 OpenLDAP와 같은 POSIX 스키마를 지원하는 LDAP 디렉터리 서버입니다. 지원되는 디렉터리 서버에 대한 자세한 내용은 제네릭 LDAP 커넥터 참조참조하세요.
프로비저닝 에이전트를 호스트할 RAM이 3GB 이상인 컴퓨터입니다. 컴퓨터에 Windows Server 2016 이상 버전의 Windows Server가 있어야 합니다. 또한 대상 디렉터리 서버에 연결되고 다른 Microsoft Online Services 및 azure 도메인을 login.microsoftonline.com 대한 아웃바운드 연결이 있어야 합니다. 예를 들어 Azure IaaS 또는 프록시 뒤에서 호스트되는 Windows Server 2016 가상 머신이 있습니다. .NET Framework 4.7.2를 해당 서버에 설치해야 합니다.
선택 사항: 필수는 아니지만 Windows Server용 Microsoft Edge 다운로드하여 Internet Explorer 대신 사용하는 것이 좋습니다.

클라우드 요구 사항

Microsoft Entra ID P1 또는 Premium P2(또는 EMS E3 또는 E5)가 있는 Microsoft Entra 테넌트입니다.

이 기능을 사용하려면 Microsoft Entra ID P1 라이선스가 필요합니다. Microsoft Entra ID의 일반 공급 기능을 비교하여 요구 사항에 적합한 라이선스를 찾으려면 를 참조하세요.
프로비저닝 에이전트를 구성하기 위한 하이브리드 ID 관리자 역할입니다.
Azure Portal 또는 Microsoft Entra 관리 센터에서 프로비저닝을 구성하기 위한 애플리케이션 관리자 또는 클라우드 애플리케이션 관리자 역할입니다.
디렉터리 서버 스키마에는 각 Microsoft Entra 사용자에 대한 특정 특성이 LDAP 디렉터리에 프로비전되어야 하며 이러한 특성은 이미 채워져 있어야 합니다. 특히 각 사용자는 고유한 번호를 사용자 ID 번호로 사용해야 합니다. 프로비전 에이전트를 배포하고 디렉터리에 사용자를 할당하기 전에 사용자의 기존 특성에서 해당 번호를 생성하거나 Microsoft Entra 스키마를 확장해야 합니다. 그런 다음 해당 속성을 적용할 사용자 그룹을 지정할 수 있습니다. 추가 디렉터리 확장을 만드는 방법은 Graph 확장성 참조하세요.

추가 권장 사항 및 제한 사항

다음 글머리 기호는 더 많은 권장 사항 및 제한 사항입니다.

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

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

기존 디렉터리 서버에 커넥터를 배포하기 전에 조직의 디렉터리 서버 운영자와 디렉터리 서버와 통합하는 방법에 대해 논의해야 합니다. 수집할 정보에는 다음이 포함됩니다.

디렉터리 서버에 연결하는 방법에 대한 네트워크 정보입니다.
커넥터가 디렉터리 서버에 인증해야 하는 방법입니다.
디렉터리 서버가 사용자를 모델링하기 위해 선택한 스키마입니다.
명명 컨텍스트의 기본 고유 이름 및 디렉터리 계층 구조 규칙입니다.
디렉터리 서버의 사용자를 Microsoft Entra ID의 사용자와 연결하는 방법입니다.
Microsoft Entra ID에서 사용자가 범위를 벗어날 때 무엇이 발생해야 합니까?

이 커넥터를 배포하려면 디렉터리 서버의 구성을 변경하고 Microsoft Entra ID의 구성을 변경해야 할 수 있습니다. 프로덕션 환경에서 타사 디렉터리 서버와 Microsoft Entra ID를 통합하는 배포의 경우 고객은 디렉터리 서버 공급업체 또는 배포 파트너와 협력하여 이 통합에 대한 도움말, 지침 및 지원을 수행하는 것이 좋습니다. 이 문서에서는 OpenLDAP에 대해 다음 샘플 값을 사용합니다.

구성 설정	값이 설정된 위치	예제 값
디렉터리 서버의 호스트 이름	구성 설정 마법사 연결 페이지	`APP3`
디렉터리 서버의 포트 번호	구성 설정 도우미 연결 페이지	636. SSL 또는 TLS를 통한 LDAP의 경우, 포트 636을 사용합니다. `Start TLS`경우 포트 389를 사용합니다.
디렉터리 서버에 커넥터가 자신을 식별할 수 있도록 하는 계정	구성 마법사 연결 페이지	`cn=admin,dc=contoso,dc=lab`
커넥터가 디렉터리 서버에 인증하기 위한 암호	구성 마법사 연결 페이지
디렉터리 서버의 사용자에 대한 구조적 개체 클래스	구성 마법사 개체 형식 페이지	`inetOrgPerson`
디렉터리 서버의 사용자에 대한 보조 개체 클래스	Azure Portal 프로비저닝 페이지 특성 매핑	`posixAccount` 및`shadowAccount`
새 사용자에 대한 속성 항목	구성 마법사 특성 선택 페이지 및 Azure Portal 프로비저닝 페이지의 특성 매핑	`cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword`
디렉터리 서버에 필요한 명명 계층 구조	Azure Portal 프로비저닝 페이지 특성 매핑	새로 만든 사용자의 DN을 `DC=Contoso,DC=lab` 바로 아래로 설정합니다.
Microsoft Entra ID 및 디렉터리 서버 간에 사용자 상관 관계를 지정하기 위한 특성	Azure Portal 프로비저닝 페이지 특성 매핑	`mail`
사용자가 Microsoft Entra ID에서 범위를 벗어날 때의 프로비전 해제 동작	구성 마법사 프로비전 해제 페이지	디렉터리 서버에서 사용자 삭제

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

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

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

이러한 클래스의 일부 선택적 특성에 대한 매핑도 구성할 수 있습니다. Linux 인증을 지원하기 위해 POSIX 스키마가 있는 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의 사용자에 대해서는 고유 이름이 없는 경우가 많습니다. 대신 조직의 디렉터리 서버 스키마에는 mail 또는 employeeId같은 다른 특성이 있을 수 있으며, 이러한 특성이 Microsoft Entra ID 사용자에게도 존재할 수 있습니다. 그러면 커넥터가 새 사용자를 디렉터리 서버에 프로비저닝할 때, 그 특성의 특정 값을 가진 사용자가 이미 디렉터리에 있는지 검색한 후, 없는 경우에만 디렉터리 서버에 새 사용자를 생성할 수 있습니다.

시나리오에서 기존 사용자를 업데이트하거나 삭제하는 것뿐만 아니라 LDAP 디렉터리에서 새 사용자를 만드는 경우 해당 디렉터리 서버를 사용하는 Linux 시스템에서 인증을 처리하는 방법도 결정해야 합니다. 일부 시스템은 디렉터리에서 사용자의 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와 같은 많은 디렉터리에는 사용자의 계정이 비활성화되었음을 나타내는 기본 방법이 없을 수 있습니다.

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

Azure Portal에 로그인합니다.
Enterprise 애플리케이션으로 이동하여 새 애플리케이션을 선택합니다.
온-프레미스 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 커넥터 구성

선택한 옵션에 따라 일부 마법사 화면을 사용할 수 없으며 정보가 약간 다를 수 있습니다. 다음 정보를 사용하여 구성할 때 참고하십시오.

커넥터에 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 커넥터 호스트가 디렉터리 서버와 통신하는 방법을 구성하고 일부 구성 옵션을 설정합니다. 이미지 뒤에 있는 표에 지정된 값으로 상자를 채우고 다음을 선택합니다. 다음선택하면 커넥터가 디렉터리 서버에 해당 구성을 쿼리합니다. 연결 페이지를 보여 주는

재산	묘사
호스트	LDAP 서버가 있는 호스트 이름입니다. 이 샘플에서는 `APP3` 예제 호스트 이름으로 사용합니다.
항구	TCP 포트 번호입니다. 디렉터리 서버가 SSL을 통해 LDAP에 대해 구성된 경우 포트 636을 사용합니다. `Start TLS`또는 네트워크 수준 보안을 사용하는 경우 포트 389를 사용합니다.
연결 시간 제한	180
제본	이 속성은 커넥터가 디렉터리 서버에 인증하는 방법을 지정합니다. `Basic` 설정 또는 `SSL` 또는 `TLS` 설정과 클라이언트 인증서가 구성되지 않은 상태에서 커넥터는 LDAP 단순 바인딩을 전송하여 고유 이름과 암호로 인증합니다. `SSL` 또는 `TLS` 설정 및 클라이언트 인증서를 지정하면 커넥터는 클라이언트 인증서로 인증하기 위해 LDAP SASL `EXTERNAL` 바인딩을 보냅니다.
사용자 이름	ECMA 커넥터가 디렉터리 서버에 자신을 인증하는 방법입니다. 이 예제에서는 `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` 확인란을 선택합니다. 이 옵션을 사용하면 모든 개체에서 모든 특성을 사용할 수 있습니다. 이 옵션을 선택하면 연결된 디렉터리가 이 기능을 사용하지 않는 한 스키마가 매우 커지므로 옵션을 선택하지 않은 상태로 유지하는 것이 좋습니다.
수동 앵커 선택 허용	선택하지 않은 상태로 둡니다.

메모

문제가 발생하여 연결할 수 없고 전역 페이지로 진행할 수 없는 경우, 디렉터리 서버의 서비스 계정이 사용하도록 설정되어 있는지 확인하세요.

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

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

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

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

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

내보내기 페이지에서 기본값을 변경하지 않고 다음선택합니다.
전체 가져오기 페이지에서 기본값을 변경하지 않고 다음을 선택합니다.
DeltaImport 페이지에 기본값을 변경하지 않고, 있을 경우 다음 을(를) 선택합니다.

개체 유형 페이지에서 상자에 입력하고 다음을 선택합니다.

재산	묘사
대상 개체	이 값은 LDAP 디렉터리 서버에서 사용자의 구조적 개체 클래스입니다. `inetOrgPerson`사용하고 이 필드에 보조 개체 클래스를 지정하지 마세요. 디렉터리 서버에 보조 개체 클래스가 필요한 경우 Azure Portal의 특성 매핑으로 구성됩니다.
닻	이 특성의 값은 대상 디렉터리의 각 개체에 대해 고유해야 합니다. Microsoft Entra 프로비저닝 서비스는 초기 주기 후에 이 특성을 사용하여 ECMA 커넥터 호스트를 쿼리합니다. 일반적으로 `-dn-`로 선택할 수 있는 특별한 이름을 사용합니다. OpenLDAP 스키마의 `uid` 특성과 같은 다중값 특성은 앵커로 사용할 수 없습니다.
쿼리 속성	이 특성은 Anchor와 동일해야 합니다.
DN	대상 개체의 distinguishedName입니다. `-dn-`유지합니다.
자동 생성됨	선택되지 않음

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

objectClass 특성에 대해 Treat as single value 확인란이 선택되지 않은 상태인지 확인하고, userPassword가 설정된 경우 userPassword 특성이 선택 불가능하거나 선택된 상태인지 확인합니다.

다음 특성에 대한 표시 유형을 구성합니다.

속성	단일 값으로 처리
_distinguishedName
-dn-
비밀번호 내보내기
cn	Y
gidNumber
홈 디렉터리
우편	Y
objectClass
sn	Y
사용자 식별자 (uid)	Y
uidNumber
사용자 비밀번호	Y

모든 관련 특성이 추가되면 다음을 선택합니다.

프로비전 해제 페이지에서 애플리케이션 범위를 벗어날 때 Microsoft Entra ID가 디렉토리에서 사용자를 제거할 것인지 설정할 수 있습니다. 그렇다면 흐름사용 안 함에서 삭제를 선택하고, 흐름 삭제에서 삭제를 선택합니다. Set attribute value 선택하면 이전 페이지에서 선택한 특성을 프로비전 해제 페이지에서 선택할 수 없습니다.

메모

Set 특성 값을 사용할 때는 부울 값만 허용된다는 점을 주의하라.

선택 완료.

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

다음 단계에 따라 커넥터 호스트가 시작되고 디렉터리 서버에서 기존 사용자를 제대로 식별했는지 확인합니다.

Microsoft Entra ECMA 커넥터 호스트를 실행하는 서버에서 시작선택합니다.
'실행을 선택하고, 필요한 경우 상자에 services.msc 입력합니다.'
Services 목록에서 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 부분을 ECMA 호스트의 커넥터 이름(예: LDAP)으로 바꿉다. 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 Domain Services에서 Microsoft Entra ID로 동기화되도록 특성이 구성되므로 다른 시스템에 프로비전할 수 있습니다.

사용자가 Microsoft Entra ID에서 유래된 경우, 사용자의 각 새로운 속성을 저장하기 위해 디렉터리 확장 를 정의해야 합니다. 그런 다음 프로비전될 예정인 Microsoft Entra 사용자 업데이트하여 각 사용자에게 해당 특성의 값을 제공할 있습니다.

특성 매핑 구성

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

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

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

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

매핑 유형	원본 특성	대상 특성
직접적	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn`
직접적	`surname`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn`
직접적	`userPrincipalName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail`
표현	`ToLower(Word([userPrincipalName], 1, "@"), )`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid`
직접적	(디렉터리에 고유한 특성)	`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`

사용자에게 초기 무작위 암호를 설정하는 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword 매핑을 추가합니다.
저장을 선택합니다.

디렉터리에 프로비전할 사용자에게 필요한 특성이 있는지 확인

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

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

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

사용자가 Microsoft Entra ID에서 유래한 경우, 사용자의 새 특성을 저장하기 위해 각 특성에 대해 디렉터리 확장을정의해야 합니다. 그런 다음 프로비전될 예정인 Microsoft Entra 사용자 업데이트하여 각 사용자에게 해당 특성의 값을 제공할 있습니다.

PowerShell을 통해 사용자 확인

Microsoft Entra ID에서 사용자가 업데이트된 후, Microsoft Graph PowerShell cmdlets을 사용하여 사용자에게 필요한 모든 속성이 있는지 확인하는 작업을 자동화할 수 있습니다.

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

이 섹션에서는 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.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

사용자 목록 및 확인할 특성을 생성합니다.

$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 디렉터리에서 기존 사용자 수집

해당 디렉터리의 사용자 중 Linux 인증에 해당하는 사용자가 누군지 식별합니다. 이 선택은 Linux 시스템의 구성에 따라 달라집니다. 일부 구성의 경우 LDAP 디렉터리에 있는 모든 사용자는 유효한 사용자입니다. 다른 구성을 사용하려면 사용자에게 특정 특성이 있거나 해당 디렉터리에 있는 그룹의 구성원이어야 할 수 있습니다.
LDAP 디렉터리에서 CSV 파일로 해당 사용자 하위 집합을 검색하는 명령을 실행합니다. 출력에 Microsoft Entra ID와 일치하는 데 사용되는 사용자의 특성이 포함되어 있는지 확인합니다. 이러한 특성의 예로는 직원 ID, 계정 이름 또는 uid및 전자 메일 주소가 있습니다.
필요한 경우 사용자 목록이 포함된 CSV 파일을 Microsoft Graph PowerShell 커맨드릿이 설치된 시스템에 전송하십시오.
이제 디렉터리에서 가져온 모든 사용자 목록이 있으므로 디렉터리의 해당 사용자를 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를 사용하는 경우 기본 매핑은 SAP SCIM 속성 userName와 Microsoft Entra ID 속성 userPrincipalName입니다.
```
$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 커넥터 호스트가 Microsoft Entra ID와 통신하고 특성 매핑이 구성되었으므로 프로비전의 범위에 있는 대상을 구성할 수 있습니다."

중요하다

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

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

LDAP 디렉터리의 기존 사용자를 아직 업데이트하지 않으려면 필요한 특성이 있고 디렉터리 서버에 프로비전될 Microsoft Entra ID에서 테스트 사용자를 선택합니다.

선택한 사용자가 디렉터리 서버 스키마의 필수 속성으로 매핑되어야 하는 모든 속성을 가지고 있는지 확인하십시오.
Azure 포털에서 엔터프라이즈 애플리케이션을 선택합니다.
온-프레미스 ECMA 앱 애플리케이션을 선택합니다.
왼쪽의 관리아래에서 사용자 및 그룹선택합니다.
사용자/그룹추가를 선택합니다. 사용자 추가를 보여 주는
사용자아래에서 선택되지 않음을 선택합니다. 선택한 항목 없음을 보여 주는
오른쪽에서 사용자를 선택하고 '선택' 버튼을 클릭합니다. 사용자 선택을 보여주는
이제 할당을 선택합니다. 사용자 할당을 보여 주는 스크린샷

테스트 준비 설정

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

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

사용자 프로비저닝 시작

주문형 프로비전 테스트가 성공하면 나머지 사용자를 추가합니다. 사용하여 애플리케이션 역할 할당을 대량으로 만드는 방법에 대한 자세한 내용은 Microsoft Entra ID애플리케이션의 기존 사용자를 관리하는 참조하세요.

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

프로비저닝 오류 문제 해결

오류가 표시되면 프로비저닝 로그 보기를선택합니다. 로그에서 상태가 실패인 행을 찾고 해당 행을 선택합니다.

오류 메시지가 사용자생성 실패인 경우, 디렉터리 스키마의 요구 사항에 맞춰 표시된 특성을 확인하십시오.

자세한 내용은 문제 해결 & 권장 사항 탭으로 이동하세요.

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

기타 오류의 경우 온-프레미스 애플리케이션 프로비저닝문제 해결을 참조하세요.

이 애플리케이션에 대한 프로비저닝을 일시 중지하려면 프로비저닝 구성 페이지에서 프로비전 상태를 off변경하고 저장을 선택할 수 있습니다. 이 작업을 수행하면 프로비저닝 서비스가 나중에 실행될 수 없습니다.

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

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

다음 지침에서는 Linux에서 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에서 프로비전된 사용자가 포함되어 있는지 확인합니다.

다음 단계

프로비전 서비스가 수행하는 작업, 작동 방식 및 질문과 대답에 대한 자세한 내용은 microsoft Entra ID 사용하여 SaaS 애플리케이션에 대한 사용자 프로비저닝 및 프로비전 해제 자동화 및 온-프레미스 애플리케이션 프로비저닝 아키텍처참조하세요.

다음을 통해 공유