Microsoft Entray Domain Services의 사용자 계정, 암호 및 관리에 대한 관리 개념
Microsoft Entra Domain Services 관리형 도메인을 만들고 실행할 때 기존 온-프레미스 AD DS 환경과 몇 가지 다른 동작이 있습니다. Domain Services에서 동일한 관리 도구를 자체 관리되는 도메인으로 사용할 수 있지만 DC(도메인 컨트롤러)에 직접 액세스할 수는 없습니다. 또한 사용자 계정 생성 원본에 따라 암호 정책 및 암호 해시에 대한 동작에 몇 가지 차이점이 있습니다.
이 개념 문서에서는 관리되는 작업을 관리하는 방법기본 생성 방법에 따라 사용자 계정의 다양한 동작을 자세히 설명합니다.
Do기본 관리
관리되는 do기본 DNS 네임스페이스 및 일치하는 디렉터리입니다. 관리되는 do기본 사용자 및 그룹, 자격 증명 및 정책과 같은 모든 리소스를 포함하는 dc(do기본 컨트롤러)는 관리되는 서비스의 일부입니다. 중복성을 위해 두 DC가 관리되는 도메인의 일부로 생성됩니다. 이러한 DC에 로그인하여 관리 작업을 수행할 수 없습니다. 대신 관리되는 do기본 조인된 관리 VM을 만든 다음, 일반 AD DS 관리 도구를 설치합니다. 예를 들어 Active Directory 관리istrative Center 또는 MMC(Microsoft Management Console) 스냅인(예: DNS 또는 그룹 정책 개체)을 사용할 수 있습니다.
사용자 계정 만들기
사용자 계정은 여러 가지 방법으로 관리되는 do기본 만들 수 있습니다. 대부분의 사용자 계정은 Microsoft Entra ID에서 동기화되며, 온-프레미스 AD DS 환경에서 동기화된 사용자 계정을 포함할 수도 있습니다. 관리되는 do기본 직접 계정을 수동으로 만들 수도 있습니다. 초기 암호 동기화 또는 암호 정책과 같은 일부 기능은 사용자 계정을 만드는 방법 및 위치에 따라 다르게 작동합니다.
- 사용자 계정은 Microsoft Entra ID에서 동기화할 수 있습니다. 여기에는 Microsoft Entra ID에서 직접 만든 클라우드 전용 사용자 계정과 Microsoft Entra Connect를 사용하여 온-프레미스 AD DS 환경에서 동기화된 하이브리드 사용자 계정이 포함됩니다.
- 관리되는 도메인에 있는 대부분의 사용자 계정은 Microsoft Entra ID에서 동기화되는 프로세스를 통해 생성됩니다.
- 사용자 계정은 관리되는 도메인에서 수동으로 만들 수 있으며 Microsoft Entra ID에 존재하지 않습니다.
- 관리되는 작업에서만 실행되는 애플리케이션에 대한 서비스 계정을 만들어야 하는 경우기본 관리되는 do기본 수동으로 만들 수 있습니다. Microsoft Entra ID에서 단방향으로 동기화가 이루어지므로 관리되는 도메인에서 만든 사용자 계정은 Microsoft Entra ID에 다시 동기화되지 않습니다.
암호 정책
Domain Services에는 계정 잠금, 최대 암호 사용 기간 및 암호 복잡성과 같은 항목에 대한 설정을 정의하는 기본 암호 정책이 포함됩니다. 계정 잠금 정책과 같은 설정 이전 섹션에 설명된 대로 사용자가 만들어진 방법에 관계없이 관리되는 do기본의 모든 사용자에게 적용됩니다. 최소 암호 길이 및 암호 복잡성과 같은 몇 가지 설정은 관리되는 도메인에서 직접 만든 사용자에게만 적용됩니다.
사용자 고유의 사용자 지정 암호 정책을 만들어 관리되는 do기본 기본 정책을 재정의할 수 있습니다. 그런 다음 필요에 따라 특정 사용자 그룹에 이러한 사용자 지정 정책을 적용할 수 있습니다.
사용자 생성 원본에 따라 암호 정책을 적용하는 방법의 차이점에 대한 자세한 내용은 관리되는 작업에 대한 암호 및 계정 잠금 정책을 참조하세요기본.
암호 해시
관리되는 도메인에서 사용자를 인증하려면 Domain Services에는 NTLM(NT LAN Manager) 및 Kerberos 인증에 적합한 형식의 암호 해시가 필요합니다. Microsoft Entra ID는 테넌트에 대해 Domain Services를 사용하도록 설정할 때까지 NTLM 또는 Kerberos 인증에 필요한 형식으로 암호 해시를 생성하거나 저장하지 않습니다. 보안상의 이유로 Microsoft Entra ID는 암호 자격 증명을 일반 텍스트 형식으로 저장하지 않습니다. 따라서 Microsoft Entra ID는 사용자의 기존 자격 증명을 기반으로 이러한 NTLM 또는 Kerberos 암호 해시를 자동으로 생성할 수 없습니다.
클라우드 전용 사용자 계정의 경우 사용자는 관리되는 작업을 사용하려면 먼저 암호를 변경해야 합니다기본. 이 암호 변경 프로세스로 인해 Kerberos 및 NTLM 인증을 위한 암호 해시가 생성되어 Microsoft Entra ID에 저장됩니다. 암호가 변경될 때까지 계정은 Microsoft Entra ID에서 Domain Services로 동기화되지 않습니다.
Microsoft Entra Connect를 사용하여 온-프레미스 AD DS 환경에서 동기화된 사용자의 경우 암호 해시 동기화를 사용하도록 설정합니다.
Important
Microsoft Entra Connect는 Microsoft Entra 테넌트에서 Domain Services를 사용하도록 설정하는 경우에만 레거시 암호 해시를 동기화합니다. Microsoft Entra Connect를 사용하여 온-프레미스 AD DS 환경을 Microsoft Entra ID와 동기화하는 경우에만 레거시 암호 해시가 사용되지 않습니다.
레거시 애플리케이션에서 NTLM 인증 또는 LDAP 단순 바인딩을 사용하지 않는 경우 Domain Services에 NTLM 암호 해시 동기화를 사용하지 않는 것이 좋습니다. 자세한 내용은 취약한 암호화 제품군 비활성화 및 NTLM 자격 증명 해시 동기화를 참조하세요.
적절히 구성되면 사용 가능한 암호 해시가 관리되는 도메인에 저장됩니다. 관리되는 도메인을 삭제하면 해당 지점에 저장된 암호 해시도 모두 삭제됩니다. Microsoft Entra ID의 동기화된 자격 증명 정보는 나중에 다른 관리되는 도메인을 만드는 경우 다시 사용할 수 없습니다. 암호 해시를 다시 저장하려면 암호 해시 동기화를 다시 구성해야 합니다. 이전에 도메인에 조인된 VM 또는 사용자는 즉시 인증할 수 없습니다. Microsoft Entra ID는 새 관리되는 도메인에 암호 해시를 생성하고 저장해야 합니다. 자세한 내용은 Domain Services 및 Microsoft Entra Connect의 암호 해시 동기화 프로세스를 참조하세요.
Important
Microsoft Entra Connect는 온-프레미스 AD DS 환경과의 동기화를 위해서만 설치 및 구성되어야 합니다. 관리되는 do기본에 Microsoft Entra 커넥트 설치하여 개체를 Microsoft Entra ID로 다시 동기화하는 것은 지원되지 않습니다.
포리스트 및 트러스트
포리스트는 AD DS(Active Directory 도메인 Services)에서 하나 이상의 작업을 그룹화하기 위해 사용하는 논리 구문입니다기본. 그런 다음 기본 사용자 또는 그룹에 대한 개체를 저장하고 인증 서비스를 제공합니다.
Domain Services에서 포리스트는 도메인을 하나만 포함합니다. 온-프레미스 AD DS 포리스트에는 종종 많은 할 일기본 포함됩니다. 대규모 조직에서 특히 인수 합병 후에는 각각 여러 개의 할 일기본 포함하는 여러 온-프레미스 포리스트로 끝날 수 있습니다.
기본적으로 관리되는 도메인은 온-프레미스 AD DS 환경에서 만든 사용자 계정을 포함하여 Microsoft Entra ID의 모든 개체를 동기화합니다. 사용자 계정은 할 일기본 조인된 VM에 로그인하는 등 관리되는 할 일기본기본 대해 직접 인증할 수 있습니다. 이 방식은 암호 해시를 동기화할 수 있고 사용자가 스마트 카드 인증과 같은 독점적인 로그인 방법을 사용하지 않을 때 작동합니다.
Domain Services에서는 사용자가 온-프레미스 AD DS에서 로그인할 수 있도록 단방향 포리스트 트러스트를 만들 수도 있습니다. 이 방법을 사용하면 사용자 개체 및 암호 해시가 Domain Services와 동기화되지 않습니다. 사용자 개체 및 자격 증명은 온-프레미스 AD DS에만 존재합니다. 이 접근 방식을 통해 엔터프라이즈는 Azure에서 LDAPS, Kerberos 또는 NTLM 등의 클래식 인증에 의존하는 리소스 및 애플리케이션 플랫폼을 호스트할 수 있지만 인증 문제나 우려는 해소됩니다.
Domain Services SKU
Domain Services에서 사용 가능한 성능 및 기능은 SKU에 따라 다릅니다. 관리되는 도메인을 만들 때 SKU를 선택할 수 있으며, 관리되는 도메인이 배포된 후 비즈니스 요구 사항이 변경됨에 따라 SKU를 전환할 수 있습니다. 다음 표에서는 사용 가능한 SKU와 이러한 SKU 간의 차이점을 간략하게 설명합니다.
| SKU 이름 | 최대 개체 수 | Backup 주기 |
|---|---|---|
| Standard | 제한 없음 | 5일마다 |
| Enterprise | 제한 없음 | 3일마다 |
| Premium | 제한 없음 | 일간 |
이러한 Domain Services SKU 이전에는 관리되는 도메인의 개체 수(사용자 및 컴퓨터 계정)를 기준으로 하는 청구 모델이 사용되었습니다. 관리되는 do기본 개체 수에 따라 더 이상 가변 가격 책정이 없습니다.
자세한 내용은 Domain Services 가격 책정 페이지를 참조하세요.
관리되는 도메인 성능
도메인 성능은 애플리케이션에 인증을 구현하는 방법에 따라 달라집니다. 추가 컴퓨팅 리소스는 쿼리 응답 시간을 개선하고 동기화 작업에 소요되는 시간을 줄이는 데 도움이 될 수 있습니다. SKU 수준이 증가함에 따라 관리되는 do기본 사용할 수 있는 컴퓨팅 리소스가 증가합니다. 애플리케이션의 성능을 모니터링하고 필요한 리소스를 계획합니다.
비즈니스 또는 애플리케이션 요구 사항이 변경되고 관리되는 작업에 대한 추가 컴퓨팅 성능이 필요한 경우기본 다른 SKU로 전환할 수 있습니다.
Backup 주기
백업 빈도는 관리되는 도메인의 스냅샷이 생성되는 빈도를 결정합니다. 백업은 Azure 플랫폼에서 관리하는 자동 프로세스입니다. 관리되는 do기본 문제가 발생하는 경우 Azure 지원 백업에서 복원하는 데 도움이 될 수 있습니다. 동기화는 Microsoft Entra ID에서 단방향으로만 이루어지므로 관리되는 도메인의 모든 문제는 Microsoft Entra ID 또는 온-프레미스 AD DS 환경 및 기능에 영향을 주지 않습니다.
SKU 수준이 증가함에 따라 이러한 백업 스냅샷 빈도가 증가합니다. 비즈니스 요구 사항 및 RPO(복구 지점 목표)를 검토하여 관리되는 도메인에 필요한 백업 빈도를 결정합니다. 비즈니스 또는 애플리케이션 요구 사항이 변경되어 더 자주 백업해야 하는 경우 다른 SKU로 전환할 수 있습니다.