Azure VM을 Entra Domain Services에 조인하기: 먼저 결정하세요

관리되는 디렉터리를 사용해야 하는 Windows Server VM 앞에는 세 가지 결정이 있고, 조인 명령은 그중 가장 작습니다. 디렉터리 모델을 잘못 고르면 조인은 성공하지만 애플리케이션은 여전히 인증할 수 없습니다. 이름 확인을 잘못하면 자격 증명 문제처럼 보이는 지점에서 장애가 나타납니다.

서버를 건드리기 전에 모델과 확인 방식, 계정을 정하면 명령은 한 번에 실행됩니다.

세 가지 조인 중 실제로 원하는 것

장치 조인은 조건부 액세스와 싱글 사인온을 위해 머신을 Microsoft Entra ID에 등록하지만, 워크로드에 사내 스타일 도메인으로 가는 Kerberos 티켓을 주지는 않습니다. 전통적인 도메인 조인은 컴퓨터 개체를 디렉터리에 묶고 머신 계정, 그룹 정책, 도메인 인증을 부여합니다. 관리되는 도메인은 그 두 번째 모델을 서비스로 제공합니다. 이름은 비슷하게 들리지만 결과는 다릅니다.

일반적인 의미의 도메인 컨트롤러가 관련되는 것은 마지막 두 가지뿐이고, 패치 목록에서 서버를 빼는 것은 관리되는 옵션뿐입니다.

결정은 보통 선호가 아니라 애플리케이션에 달려 있습니다. LDAP 바인드, SPN이 있는 서비스 계정, 그룹 정책 개체가 필요한 소프트웨어는 도메인 모델에 속합니다. 회사 장치에서 사용자의 신원만 알면 되는 소프트웨어는 보통 속하지 않습니다.

조인이 끝날 수 있는지는 DNS 경로가 결정합니다

도메인 조인은 도메인의 컨트롤러 레코드에 대한 로케이터 조회로 시작하므로, 자격 증명을 확인하기 전에 이름 확인이 동작해야 합니다. VM을 관리되는 도메인의 디렉터리 주소로 향하게 하십시오. 가상 네트워크의 DNS 설정을 통하거나, 해당 네임스페이스만 보내는 조건부 전달자를 통하면 됩니다. 네임스페이스로 범위를 좁힌 전달자가 보통 더 안전한 선택이며, VM의 나머지 확인 작업을 건드리지 않기 때문입니다.

호스트 이름만이 아니라 로케이터를 시험하십시오. 도메인 이름에 대한 ping은 거의 아무것도 증명하지 못하지만, 도메인 컨트롤러 레코드에 대한 SRV 쿼리는 기대한 대상을 돌려주거나 즉시 실패합니다:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53

도메인 이름과 두 주소를 관리되는 도메인 구성의 값으로 바꾸십시오. 여기 있는 숫자는 예시이며, 쿼리가 다른 영역의 응답을 돌려주면 VM이 관리되는 네임스페이스를 전달하지 않는 확인자를 쓰고 있는 것입니다. 조인을 몇 번 반복해도 그것은 바뀌지 않습니다.

관리되는 도메인이 자체 서비스 리소스용으로 예약한 서브넷 밖에 워크로드를 두고, 디렉터리 포트는 프라이빗 경로에 두십시오. 그 포트를 공개하는 것은 지름길이 아니라 위험 프로필이 다른 다른 설계입니다.

계정 자격은 머신보다 먼저 확인됩니다

조인을 수행하는 계정에는 대상 컨테이너에 컴퓨터 개체를 만들 권한이 필요하고, 관리되는 도메인에 인증할 수 있어야 합니다. 관리되는 도메인이 생기기 전에 만든 클라우드 전용 계정은 도메인에 필요한 암호 파생 자료가 없을 수 있으며, 암호를 변경하거나 재설정하면 그것이 다시 생성됩니다. 이 세부 사항은 암호가 올바른데도 잘못된 암호처럼 보이는 조인 실패 부류를 설명합니다. 유지 관리 기간이 열리기 전에 도메인에 대해 자격 증명을 시험하십시오.

동기화된 하이브리드 계정에는 보이는 사용자 개체만으로는 충족되지 않는 자체 전제 조건이 있습니다. 디렉터리에 등재된 것과 그로부터 티켓을 받을 수 있는 것은 같지 않으므로, 유지 관리 기간 중이 아니라 그 전에 계정을 시험하십시오.

조인 권한은 좁게 위임하십시오. 등록 한 번을 위해 앞으로의 모든 서버 사용자에게 도메인 관리자 구성원 자격을 주는 것은 일시적 문제를 위한 영구적 허가입니다.

조인 자체는 명령 하나입니다

모델을 골랐고 DNS가 응답하며 계정이 자격을 갖추면 작업은 평범한 Windows 작업입니다. 프롬프트는 암호를 스크립트와 셸 기록 밖에 둡니다:

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

이 형태의 명령은 머신을 스스로 재시작하지 않으므로, 재시작은 유지 관리 계획에 따라 복구 경로가 아직 살아 있는 상태에서 이루어집니다. 이미 다른 도메인에 조인된 서버에는 마이그레이션 계획이 필요하며, 첫 번째 위에 두 번째 조인을 시도하는 것이 아닙니다.

컴퓨터 개체가 들어간 컨테이너와 그것을 만든 계정을 기록하십시오. 재구축 후 머신을 다시 조인해야 할 때 둘 다 중요하며, 나중에 서버에서 어느 것도 분명하지 않습니다.

구성원 자격이 주지 않는 것

도메인 구성원 자격은 누구도 로컬 관리자로 만들지 않으며, 원격 데스크톱이나 파일 공유 접근을 부여하지 않습니다. 그 권한은 따로 구성되며, 관리되는 도메인에서는 지원되는 관리 범위 안에 머뭅니다.

네트워크 경로는 설정 단계가 아니라 지속적인 종속성입니다. 프라이빗 연결이 사라지면 서버는 캐시된 자격 증명으로 계속 동작하며, 무언가가 디렉터리를 필요로 할 때 장애가 변경된 구성 옆이 아니라 애플리케이션 로그에 도착합니다.

Microsoft의 Windows Server 조인 지침 은 관리되는 도메인 워크플로에 지원되는 전제 조건을 나열합니다. 위의 세 가지 결정에 비추어 읽고, 어떤 불일치든 우회할 세부 사항이 아니라 멈출 이유로 다루십시오.