Active Directory의 포레스트에서 트러스트 관계가 작동하는 방식(미리 보기)

AD DS(Active Directory Domain Services)는 도메인 및 포리스트 트러스트 관계를 통해 여러 도메인 또는 포리스트 간에 보안을 제공합니다. 트러스트 간에 인증이 수행되기 전에 Windows는 먼저 사용자, 컴퓨터 또는 서비스에서 요청하는 도메인이 요청 계정의 도메인과 트러스트 관계가 있는지 확인해야 합니다.

이 트러스트 관계를 확인하기 위해 Windows 보안 시스템은 요청을 수신하는 서버의 DC(도메인 컨트롤러)와 요청 계정의 도메인에 있는 DC 간의 트러스트 경로를 계산합니다.

AD DS 및 Windows 분산 보안 모델에서 제공하는 액세스 제어 메커니즘은 도메인 및 포리스트 트러스트 작업을 위한 환경을 제공합니다. 이러한 트러스트가 제대로 작동하려면 모든 리소스 또는 컴퓨터가 있는 도메인의 DC에 대한 직접 신뢰 경로가 있어야 합니다.

Net Logon 서비스는 신뢰할 수 있는 도메인 기관에 대한 인증된 RPC(원격 프로시저 호출) 연결을 사용하여 트러스트 경로를 구현합니다. 또한 보안 채널은 도메인 간 트러스트 관계를 통해 다른 AD DS 도메인으로 확장됩니다. 이 보안 채널은 사용자 및 그룹에 대한 SID(보안 식별자)를 포함하여 보안 정보를 가져오고 확인하는 데 사용됩니다.

메모

Domain Services는 양방향 트러스트의 현재 미리 보기 및 들어오거나 나가는 단방향 트러스트를 포함하여 여러 포리스트 트러스트 방향을 지원합니다.

트러스트가 Domain Services에 적용되는 방법에 대한 개요는 포레스트 개념 및 기능을 참조하세요.

Domain Services에서 트러스트 사용을 시작하려면, 포리스트 트러스트를 사용하는 관리형 도메인을 생성하십시오.

신뢰 관계 흐름

트러스트를 통한 보안 통신 흐름은 트러스트의 탄력성을 결정합니다. 트러스트를 만들거나 구성하는 방법은 통신이 포리스트 내에서 또는 포리스트 간에 얼마나 확장되는지를 결정합니다.

신뢰 방향은 신뢰를 통해 이루어지는 소통 흐름을 결정합니다. 신탁은 단방향 또는 양방향일 수 있으며 전이적이거나 전이적이지 않을 수 있습니다.

다음 다이어그램은 트리 1 및 트리 2의 모든 도메인이 기본적으로 전이적 트러스트 관계를 가지고 있음을 보여줍니다. 따라서 트리 1 사용자는 트리 2 도메인의 리소스에 액세스할 수 있으며 트리 2 사용자는 리소스에 적절한 권한이 할당될 때 트리 1리소스에 액세스할 수 있습니다.

단방향 및 양방향 신뢰

트러스트 관계를 사용하면 리소스에 대한 액세스가 단방향 또는 양방향일 수 있습니다.

단방향 트러스트는 두 도메인 간에 생성된 단방향 인증 경로입니다. Domain A 및 Domain B간의 단방향 트러스트에서 Domain A 사용자는 Domain B리소스에 액세스할 수 있습니다. 그러나 Domain B 사용자는 Domain A리소스에 액세스할 수 없습니다.

일부 단방향 트러스트는 생성되는 트러스트 유형에 따라 전이적이지 않거나 전이적일 수 있습니다.

양방향 신뢰에서 도메인 A는 도메인 B를 신뢰하고, 도메인 B는 도메인 A를 신뢰합니다. 이 구성은 두 도메인 간에 양방향으로 인증 요청을 전달할 수 있음을 의미합니다. 일부 양방향 관계는 생성되는 신뢰 유형에 따라 전이적이지 않거나 전이적일 수 있습니다.

온-프레미스 AD DS 포리스트의 모든 도메인 트러스트는 양방향 전이적 트러스트입니다. 새 자식 도메인이 만들어지면 새 자식 도메인과 부모 도메인 간에 양방향 전이적 트러스트가 자동으로 만들어집니다.

전이적 트러스트 및 비 전이적 트러스트

전이성은 트러스트가 형성된 두 도메인 외부에서 트러스트를 확장할 수 있는지 여부를 결정합니다.

• 전이적 트러스트를 사용하여 다른 도메인과의 트러스트 관계를 확장할 수 있습니다.
• 비 전이적 트러스트를 사용하여 다른 도메인과의 트러스트 관계를 거부할 수 있습니다.

포리스트에서 새 도메인을 만들 때마다 새 도메인과 해당 부모 도메인 간에 양방향 전이적 트러스트 관계가 자동으로 만들어집니다. 자식 도메인이 새 도메인에 추가되면 트러스트 경로는 도메인 계층 구조를 통해 위쪽으로 이동하여 새 도메인과 해당 부모 도메인 간에 생성된 초기 신뢰 경로를 확장합니다. 전이적 트러스트 관계는 형성된 대로 도메인 트리를 통해 위쪽으로 흐르며 도메인 트리의 모든 도메인 간에 전이적 트러스트를 만듭니다.

인증 요청은 이러한 신뢰 경로를 따르므로 포리스트의 모든 도메인에서 계정을 포리스트의 다른 도메인에서 인증할 수 있습니다. 단일 로그인 프로세스를 사용하면 적절한 권한이 있는 계정은 포리스트의 모든 도메인에 있는 리소스에 액세스할 수 있습니다.

산림 신탁

포리스트 트러스트는 분할된 AD DS 인프라를 관리하고 여러 포리스트에서 리소스 및 기타 개체에 대한 액세스를 지원하는 데 도움이 됩니다. 포리스트 트러스트는 서비스 제공 업체, 합병 또는 인수를 진행 중인 회사, 공동 비즈니스 엑스트라넷 및 관리 자율성에 대한 해결책을 모색하는 회사에 유용합니다.

포리스트 트러스트를 사용하여 서로 다른 두 포리스트를 연결하여 단방향 또는 양방향 전이적 트러스트 관계를 형성할 수 있습니다. 포리스트 트러스트를 사용하면 관리자가 두 AD DS 포리스트를 단일 신뢰 관계와 연결하여 포리스트 전체에서 원활한 인증 및 권한 부여 환경을 제공할 수 있습니다.

포리스트 트러스트는 한 포리스트의 포리스트 루트 도메인과 다른 포리스트의 포리스트 루트 도메인 간에만 만들 수 있습니다. 포리스트 트러스트는 두 포리스트 간에만 만들 수 있으며 암시적으로 세 번째 포리스트로 확장할 수 없습니다. 이 동작은 포리스트 1과 포리스트 2사이에 포리스트 트러스트가 생성되고, 포리스트 2와 포리스트 3사이에 다른 포리스트 트러스트가 만들어질 경우, 포리스트 1은 포리스트 3과 암시적 트러스트가 없음을 의미합니다.

다음 다이어그램에서는 단일 조직의 세 AD DS 숲 간에 두 개의 별도 신뢰 관계를 보여줍니다.

이 예제 구성은 다음과 같은 액세스를 제공합니다.

• 포리스트 2의 사용자는 포리스트 1 또는 포리스트 3의 모든 도메인에서 리소스에 액세스할 수 있습니다.
• 포리스트 3 사용자는 포리스트 2 모든 도메인의 리소스에 액세스할 수 있습니다.
• 포리스트 1에 있는 사용자는 포리스트 2의 모든 도메인 내 리소스에 액세스할 수 있습니다.

이 구성은 포리스트 1의 사용자가 포리스트 3의 리소스에 액세스할 수 없으며, 그 반대로도 액세스할 수 없습니다. 포리스트 1 및 포리스트 3 사용자가 리소스를 공유할 수 있도록 하려면 두 포리스트 간에 양방향 전이적 신뢰 관계를 만들어야 합니다.

두 포리스트 간에 단방향 포리스트 트러스트가 만들어지면 신뢰할 수 있는 포리스트의 멤버가 신뢰할 수 있는 포리스트에 있는 리소스를 활용할 수 있습니다. 그러나 트러스트는 한 방향으로만 작동합니다.

예를 들어, 포리스트 1(신뢰받는 포리스트)와 포리스트 2(신뢰하는 포리스트) 간에 단방향 포리스트 신뢰가 생성될 때:

• 포리스트 1 멤버는 포리스트 2있는 리소스에 액세스할 수 있습니다.
• 숲 2의 멤버는 동일한 트러스트를 사용하여 숲 1에 있는 리소스에 액세스할 수 없습니다.

중요하다

Microsoft Entra Domain Services는 포리스트 트러스트에 대한 여러 방향을 지원합니다.

포리스트 트러스트 요구 사항

포리스트 트러스트를 만들려면 올바른 DNS(도메인 이름 시스템) 인프라가 있는지 확인해야 합니다. 포리스트 트러스트는 다음 DNS 구성 중 하나를 사용할 수 있는 경우에만 만들 수 있습니다.

• 단일 루트 DNS 서버는 두 포리스트 DNS 네임스페이스의 루트 DNS 서버입니다. 루트 영역에는 각 DNS 네임스페이스에 대한 위임이 포함되고 모든 DNS 서버의 루트 힌트에는 루트 DNS 서버가 포함됩니다.

• 공유 루트 DNS 서버가 없고 각 포리스트 DNS 네임스페이스에 루트 DNS 서버가 없는 경우 각 DNS 네임스페이스에 대한 DNS 조건부 전달자를 사용하여 다른 네임스페이스의 이름에 대한 쿼리를 라우팅합니다.

  중요하다

  트러스트가 있는 모든 Microsoft Entra Domain Services 포리스트에는 이 DNS 구성이 필요합니다. 포리스트 DNS 네임스페이스 이외의 DNS 네임스페이스를 호스팅하는 것은 Microsoft Entra Domain Services의 기능이 아닙니다. 조건부 전달자는 적절한 구성입니다.

• 공유 루트 DNS 서버가 없고 각 포리스트 DNS 네임스페이스에 루트 DNS 서버가 있는 경우 각 DNS 네임스페이스에서 DNS 보조 영역을 사용하여 다른 네임스페이스의 이름에 대한 쿼리를 라우팅합니다.

AD DS에서 포리스트 트러스트를 만들려면 포리스트 루트 도메인에 있는 Domain Admins 그룹 또는 Active Directory의 Enterprise Admins 그룹의 구성원이어야 합니다. 각 트러스트에는 두 포리스트의 관리자가 알아야 하는 암호가 할당됩니다. 두 포리스트의 Enterprise Admins 멤버는 한 번에 두 포리스트에서 트러스트를 만들 수 있으며, 이 시나리오에서는 암호화 임의 암호가 자동으로 생성되고 두 포리스트에 대해 기록됩니다.

관리되는 도메인 포리스트는 온-프레미스 포리스트에 대한 최대 5개의 단방향 아웃바운드 포리스트 트러스트를 지원합니다. Microsoft Entra Domain Services에 대한 아웃바운드 포리스트 트러스트는 Microsoft Entra 관리 센터에서 만들어집니다. 온-프레미스 Active Directory에서 이전에 언급한 권한이 있는 사용자는 수신 포리스트 트러스트를 구성해야 합니다.

신뢰 프로세스 및 상호 작용

많은 도메인 간 및 포리스트 간 트랜잭션은 다양한 작업을 완료하기 위해 도메인 또는 포리스트 트러스트에 의존합니다. 이 섹션에서는 트러스트 간에 리소스에 액세스하고 인증 조회를 평가할 때 발생하는 프로세스 및 상호 작용에 대해 설명합니다.

인증 조회 처리 개요

인증 요청이 도메인에 참조되면 해당 도메인의 도메인 컨트롤러는 요청이 들어오는 도메인과 트러스트 관계가 있는지 여부를 결정해야 합니다. 트러스트의 방향과 트러스트가 전이적인지 아니면 전이적이지 않은지 여부도 사용자가 도메인의 리소스에 액세스하도록 인증하기 전에 결정해야 합니다. 신뢰할 수 있는 도메인 간에 발생하는 인증 프로세스는 사용 중인 인증 프로토콜에 따라 달라집니다. Kerberos V5 및 NTLM 프로토콜은 도메인에 대한 인증에 대한 조회를 다르게 처리합니다.

Kerberos V5 조회 처리

Kerberos V5 인증 프로토콜은 클라이언트 인증 및 권한 부여 정보를 위해 도메인 컨트롤러의 Net Logon 서비스에 종속됩니다. Kerberos 프로토콜은 세션 티켓을 위해 KDC(온라인 키 배포 센터) 및 Active Directory 계정 저장소에 연결합니다.

Kerberos 프로토콜은 TGS(영역 간 티켓 부여 서비스)에 대한 트러스트를 사용하고 보안 채널에서 PAC(권한 특성 인증서)의 유효성을 검사합니다. Kerberos 프로토콜은 MIT Kerberos 영역과 같은 비 Windows 브랜드 운영 체제 Kerberos 영역에서만 영역 간 인증을 수행하며 Net Logon 서비스와 상호 작용할 필요가 없습니다.

클라이언트가 인증에 Kerberos V5를 사용하는 경우 계정 도메인의 도메인 컨트롤러에서 대상 도메인의 서버에 대한 티켓을 요청합니다. Kerberos KDC는 클라이언트와 서버 간의 신뢰할 수 있는 중개자 역할을 하며 두 당사자가 서로를 인증할 수 있도록 하는 세션 키를 제공합니다. 대상 도메인이 현재 도메인과 다른 경우 KDC는 논리 프로세스를 따라 인증 요청을 참조할 수 있는지 여부를 확인합니다.

1. 현재 도메인은 요청 중인 서버의 도메인에서 직접 신뢰되나요?

   • 그렇다면 클라이언트에게 요청된 도메인에 대한 조회를 보냅니다.
   • 없는 경우 다음 단계로 이동합니다.

2. 현재 도메인과 트러스트 경로의 다음 도메인 사이에 전이적 트러스트 관계가 있나요?

   • 그렇다면 클라이언트에게 신뢰 경로의 다음 도메인에 대한 조회를 보냅니다.
   • 그렇지 않은 경우 클라이언트에 로그인 거부 메시지를 보냅니다.

NTLM 조회 처리

NTLM 인증 프로토콜은 클라이언트 인증 및 권한 부여 정보를 위해 도메인 컨트롤러의 Net Logon 서비스에 종속됩니다. 이 프로토콜은 Kerberos 인증을 사용하지 않는 클라이언트를 인증합니다. NTLM은 트러스트를 사용하여 도메인 간에 인증 요청을 전달합니다.

클라이언트가 인증에 NTLM을 사용하는 경우 인증에 대한 초기 요청은 클라이언트에서 대상 도메인의 리소스 서버로 직접 이동합니다. 이 서버는 클라이언트가 응답해야 하는 도전과제를 생성합니다. 그런 다음 서버는 컴퓨터 계정 도메인의 도메인 컨트롤러에 사용자의 응답을 보냅니다. 이 도메인 컨트롤러는 보안 계정 데이터베이스에 대해 사용자 계정을 확인합니다.

계정이 데이터베이스에 없는 경우 도메인 컨트롤러는 다음 논리를 사용하여 통과 인증을 수행하거나 요청을 전달하거나 요청을 거부할지 여부를 결정합니다.

1. 현재 도메인이 사용자의 도메인과 직접 신뢰 관계를 가지고 있나요?

   • 그렇다면 도메인 컨트롤러는 통과 인증을 위해 클라이언트의 자격 증명을 사용자 도메인의 도메인 컨트롤러로 보냅니다.
   • 없는 경우 다음 단계로 이동합니다.

2. 현재 도메인이 사용자의 도메인과 전이적 트러스트 관계를 가지고 있나요?

   • 그렇다면 인증 요청을 신뢰 경로의 다음 도메인에 전달합니다. 이 도메인 컨트롤러는 자체 보안 계정 데이터베이스에 대해 사용자의 자격 증명을 확인하여 프로세스를 반복합니다.
   • 없으면 클라이언트에 로그온 거부 메시지를 보냅니다.

포리스트 트러스트를 통한 인증 요청의 Kerberos 기반 처리

두 포리스트가 포리스트 트러스트에 의해 연결된 경우 Kerberos V5 또는 NTLM 프로토콜을 사용하여 수행한 인증 요청을 포리스트 간에 라우팅하여 두 포리스트의 리소스에 대한 액세스를 제공할 수 있습니다.

포리스트 트러스트가 처음 설정되면, 각 포리스트는 파트너 포리스트의 모든 신뢰할 수 있는 네임스페이스를 수집하고 신뢰할 수 있는 도메인 객체에 정보를 저장합니다. 신뢰할 수 있는 네임스페이스에는 도메인 트리 이름, UPN(사용자 계정 이름) 접미사, SPN(서비스 사용자 이름) 접미사 및 다른 포리스트에서 사용되는 SID(보안 ID) 네임스페이스가 포함됩니다. TDO 개체는 글로벌 카탈로그에 복제됩니다.

메모

트러스트의 대체 UPN 접미사는 지원되지 않습니다. 온-프레미스 도메인이 Domain Services와 동일한 UPN 접미사를 사용하는 경우 로그인은 sAMAccountName사용해야 합니다.

인증 프로토콜이 포리스트 트러스트 경로를 따르려면 먼저 리소스 컴퓨터의 SPN(서비스 주체 이름)을 다른 포리스트의 위치로 확인해야 합니다. SPN은 다음 이름 중 하나일 수 있습니다.

• 호스트의 DNS 이름입니다.
• 도메인의 DNS 이름입니다.
• 서비스 연결 지점 개체의 고유 이름입니다.

한 포리스트의 워크스테이션이 다른 포리스트의 리소스 컴퓨터에 있는 데이터에 액세스하려고 하면 Kerberos 인증 프로세스는 리소스 컴퓨터의 SPN에 대한 서비스 티켓을 위해 도메인 컨트롤러에 연결합니다. 도메인 컨트롤러가 글로벌 카탈로그를 쿼리하고 SPN이 도메인 컨트롤러와 동일한 포리스트에 있지 않다고 확인하면 도메인 컨트롤러는 부모 도메인에 대한 조회를 워크스테이션으로 다시 보냅니다. 이 시점에서 워크스테이션은 서비스 티켓에 대한 부모 도메인을 쿼리하고 리소스가 있는 도메인에 도달할 때까지 조회 체인을 계속 따릅니다.

다음 다이어그램 및 단계에서는 Windows를 실행하는 컴퓨터가 다른 포리스트에 있는 컴퓨터에서 리소스에 액세스하려고 할 때 사용되는 Kerberos 인증 프로세스에 대한 자세한 설명을 제공합니다.

포리스트 트러스트에 대한 Kerberos 프로세스의

1. User1는 europe.tailspintoys.com 도메인의 자격 증명을 사용하여 Workstation1에 로그인합니다. 그런 다음 사용자는 usa.wingtiptoys.com 포리스트에 있는 FileServer1 공유 리소스에 액세스하려고 시도합니다.

2. Workstation1 자신의 도메인에 있는 도메인 컨트롤러, 즉 ChildDC1에서 Kerberos KDC에 연결하고, FileServer1 서비스 주체 이름(SPN)에 대한 서비스 티켓을 요청합니다.

3. ChildDC1 해당 도메인 데이터베이스에서 SPN을 찾지 못하고 전역 카탈로그를 쿼리하여 tailspintoys.com 포리스트의 도메인에 이 SPN이 포함되어 있는지 확인합니다. 글로벌 카탈로그는 자체 포리스트로 제한되므로 SPN을 찾을 수 없습니다.

   그런 다음 글로벌 카탈로그는 해당 포리스트와 함께 설정된 포리스트 트러스트에 대한 정보를 데이터베이스에서 확인합니다. 발견된 경우 포리스트 TDO(신뢰할 수 있는 도메인 개체)에 나열된 이름 접미사를 대상 SPN의 접미사와 비교하여 일치 항목을 찾습니다. 일치 항목이 발견되면 글로벌 카탈로그는 ChildDC1라우팅 힌트를 제공합니다.

   라우팅 힌트는 대상 포리스트에 대한 직접 인증 요청을 도와줍니다. 힌트는 로컬 도메인 컨트롤러 및 글로벌 카탈로그와 같은 모든 기존 인증 채널이 SPN을 찾지 못하는 경우에만 사용됩니다.

4. ChildDC1 부모 도메인에 대한 참조를 Workstation1로 다시 전송합니다.

5. Workstation1은 ForestRootDC1(부모 도메인)의 도메인 컨트롤러에 연결하여 wingtiptoys.com 숲 루트 도메인 내 도메인 컨트롤러(ForestRootDC2)에 대한 조회를 요청합니다.

6. Workstation1은 요청된 서비스에 대한 서비스 티켓에 대한 wingtiptoys.com 포리스트의 ForestRootDC2 연락처를.

7. ForestRootDC2가 SPN을 찾기 위해 글로벌 카탈로그에 연결하면, 글로벌 카탈로그는 SPN에 대한 일치 항목을 찾아 ForestRootDC2에 다시 보냅니다.

8. ForestRootDC2usa.wingtiptoys.comWorkstation1다시 보내기 위해 조회를 보냅니다.

9. Workstation1ChildDC2의 KDC에 연락하여 User1에게 티켓을 협상하여 FileServer1에 대한 액세스 권한을 얻습니다.

10. Workstation1 서비스 티켓이 있으면 서비스 티켓을 FileServer1보냅니다. 이 티켓은 User1보안 자격 증명을 읽고 그에 따라 액세스 토큰을 생성합니다.

신뢰할 수 있는 도메인 개체

도메인 내의 System 컨테이너에 저장된 TDO(신뢰할 수 있는 도메인 개체)는 조직 내의 각 도메인 또는 포리스트 트러스트를 나타냅니다.

TDO 콘텐츠

TDO에 포함된 정보는 TDO가 도메인 트러스트에 의해 만들어졌는지 또는 포리스트 트러스트에 의해 만들어졌는지에 따라 달라집니다.

도메인 트러스트가 만들어지면 DNS 도메인 이름, 도메인 SID, 신뢰 유형, 트러스트 전이성 및 상호 도메인 이름과 같은 특성이 TDO에 표시됩니다. 포리스트 트러스트 TDO는 파트너 포리스트에서 모든 신뢰할 수 있는 네임스페이스를 식별하는 추가 특성을 저장합니다. 이러한 특성에는 도메인 트리 이름, UPN(사용자 계정 이름) 접미사, SPN(서비스 사용자 이름) 접미사 및 SID(보안 ID) 네임스페이스가 포함됩니다.

트러스트는 Active Directory에 TDO로 저장되므로 포리스트의 모든 도메인에는 포리스트 전체에 있는 트러스트 관계에 대한 지식이 있습니다. 마찬가지로, 둘 이상의 포리스트가 포리스트 트러스트를 통해 함께 조인되는 경우 각 포리스트의 포리스트 루트 도메인은 신뢰할 수 있는 포리스트의 모든 도메인에 걸쳐 있는 트러스트 관계에 대한 지식을 갖습니다.

TDO 암호 변경

트러스트 관계의 두 도메인은 Active Directory의 TDO 개체에 저장된 암호를 공유합니다. 계정 유지 관리 프로세스의 일부로 신뢰할 수 있는 도메인 컨트롤러는 30일마다 TDO에 저장된 암호를 변경합니다. 모든 양방향 트러스트는 실제로 반대 방향으로 진행되는 단방향 트러스트 두 개로 구성되어 있기 때문에, 양방향 트러스트의 경우 프로세스가 두 번 발생합니다.

신탁에는 신뢰하는 측면과 신뢰받는 측면이 있습니다. 신뢰할 수 있는 쪽에서 모든 쓰기 가능한 도메인 컨트롤러를 프로세스에 사용할 수 있습니다. 신뢰하는 측에서 PDC 에뮬레이터가 암호를 변경합니다.

암호를 변경하기 위해 도메인 컨트롤러는 다음 프로세스를 완료합니다.

1. 신뢰할 수 있는 도메인의 PDC(주 도메인 컨트롤러) 에뮬레이터는 새 암호를 만듭니다. 신뢰할 수 있는 도메인의 도메인 컨트롤러는 암호 변경을 시작하지 않습니다. 항상 신뢰할 수 있는 도메인 PDC 에뮬레이터에서 시작됩니다.

2. 신뢰할 수 있는 도메인의 PDC 에뮬레이터는 TDO 개체의 OldPassword 필드를 현재 NewPassword 필드로 설정합니다.

3. 신뢰 도메인의 PDC 에뮬레이터는 TDO 개체의 NewPassword 필드를 새 암호로 설정합니다. 이전 암호의 복사본을 유지하면 신뢰할 수 있는 도메인의 도메인 컨트롤러가 변경 내용을 수신하지 못하거나 새 신뢰 암호를 사용하는 요청이 수행되기 전에 변경 내용이 복제되지 않는 경우 이전 암호로 되돌릴 수 있습니다.

4. 신뢰할 수 있는 도메인의 PDC 에뮬레이터는 트러스트 계정의 암호를 새 암호로 설정하도록 요청하는 신뢰할 수 있는 도메인의 도메인 컨트롤러에 대한 원격 호출을 수행합니다.

5. 신뢰할 수 있는 도메인의 도메인 컨트롤러는 트러스트 암호를 새 암호로 변경합니다.

6. 트러스트의 각 쪽에서 업데이트는 도메인의 다른 도메인 컨트롤러에 복제됩니다. 신뢰 도메인에서 변경은 신뢰할 수 있는 도메인 개체의 긴급 복제를 트리거합니다.

이제 두 도메인 컨트롤러에서 암호가 변경되었습니다. 일반 복제는 TDO 개체를 도메인의 다른 도메인 컨트롤러에 배포합니다. 그러나 신뢰할 수 있는 도메인의 도메인 컨트롤러를 성공적으로 업데이트하지 않고도 신뢰할 수 있는 도메인의 도메인 컨트롤러가 암호를 변경할 수 있습니다. 이 시나리오는 암호 변경을 처리하는 데 필요한 보안 채널을 설정할 수 없기 때문에 발생할 수 있습니다. 또한 프로세스 중에 신뢰할 수 있는 도메인의 도메인 컨트롤러를 사용할 수 없으며 업데이트된 암호를 받지 못할 수도 있습니다.

암호 변경이 성공적으로 전달되지 않는 상황을 처리하기 위해 트러스트 도메인의 도메인 컨트롤러는 새 암호를 사용하여 성공적으로 인증(보안 채널 설정)하지 않는 한 새 암호를 변경하지 않습니다. 이 동작으로 인해 이전 암호와 새 암호가 모두 신뢰할 수 있는 도메인의 TDO 개체에 유지됩니다.

암호 변경은 암호를 사용한 인증이 성공할 때까지 완료되지 않습니다. 신뢰할 수 있는 도메인의 도메인 컨트롤러가 새 암호를 받을 때까지 저장된 이전 암호를 보안 채널을 통해 사용할 수 있으므로 중단 없는 서비스를 사용할 수 있습니다.

암호가 잘못되어 새 암호를 사용하는 인증이 실패하면 트러스트하는 도메인 컨트롤러가 이전 암호를 사용하여 인증을 시도합니다. 이전 암호를 사용하여 성공적으로 인증하는 경우 15분 이내에 암호 변경 프로세스를 다시 시작합니다.

신뢰 암호 업데이트는 30일 이내에 트러스트 양쪽의 도메인 컨트롤러에 복제해야 합니다. 신뢰 암호가 30일 후에 변경되고 도메인 컨트롤러에 N-2 암호만 있는 경우, 신뢰하는 측의 트러스트를 사용할 수 없으며, 신뢰받는 측에서 보안 채널을 만들 수 없습니다.

트러스트에서 사용하는 네트워크 포트

트러스트는 다양한 네트워크 경계를 넘어 배포해야 하므로 하나 이상의 방화벽에 걸쳐 있어야 할 수 있습니다. 이 경우 방화벽을 통해 트러스트 트래픽을 터널로 연결하거나 방화벽에서 특정 포트를 열어 트래픽이 통과하도록 허용할 수 있습니다.

중요하다

Active Directory Domain Services는 Active Directory RPC 트래픽을 특정 포트로 제한하는 것을 지원하지 않습니다.

Windows Server 2008 이상 버전 섹션의 Microsoft 지원 문서 Active Directory 도메인 및 트러스트 대한 방화벽을 구성하여 포리스트 트러스트에 필요한 포트에 대해 알아봅니다.

지원 서비스 및 도구

트러스트 및 인증을 지원하기 위해 몇 가지 추가 기능 및 관리 도구가 사용됩니다.

네트 로그온

Net Logon 서비스는 Windows 기반 컴퓨터에서 DC로 보안 채널을 유지 관리합니다. 또한 다음과 같은 신뢰 관련 프로세스에도 사용됩니다.

• 신뢰 설정 및 관리 - Net Logon은 신뢰 암호를 유지하고, 신뢰 정보를 수집하고, LSA 프로세스 및 TDO와 상호 작용하여 트러스트를 확인하는 데 도움이 됩니다.

  포리스트 트러스트의 경우, 트러스트 정보에는 신뢰할 수 있는 포리스트가 관리한다고 주장하는 네임스페이스 집합이 포함된 포리스트 트러스트 정보(FTInfo) 레코드가 포함되어 있으며, 각 주장(claim)이 신뢰하는 포리스트에 의해 신뢰받는지를 나타내는 필드가 추가로 주석이 달려 있습니다.

• 인증 – 보안 채널을 통해 사용자 자격 증명을 도메인 컨트롤러에 제공하고 사용자에 대한 도메인 SID 및 사용자 권한을 반환합니다.

• 도메인 컨트롤러 위치 – 도메인 또는 도메인 간에 도메인 컨트롤러를 찾거나 찾는 데 도움이 됩니다.

• 통과 유효성 검사 – 다른 도메인에 있는 사용자의 자격 증명은 Net Logon에 의해 처리됩니다. 신뢰할 수 있는 도메인이 사용자의 ID를 확인해야 하는 경우 확인을 위해 Net Logon을 통해 사용자의 자격 증명을 신뢰할 수 있는 도메인에 전달합니다.

• PAC(권한 특성 인증서) 확인 – 인증에 Kerberos 프로토콜을 사용하는 서버가 서비스 티켓에서 PAC를 확인해야 하는 경우 확인을 위해 보안 채널을 통해 PAC를 도메인 컨트롤러로 보냅니다.

로컬 보안 기관

LSA(로컬 보안 기관)는 시스템에서 로컬 보안의 모든 측면에 대한 정보를 유지하는 보호된 하위 시스템입니다. 로컬 보안 정책이라고도 하는 LSA는 이름과 식별자 간 번역을 위한 다양한 서비스를 제공합니다.

LSA 보안 하위 시스템은 개체에 대한 액세스의 유효성을 검사하고, 사용자 권한을 확인하고, 감사 메시지를 생성하기 위한 커널 모드와 사용자 모드 모두에서 서비스를 제공합니다. LSA는 신뢰할 수 있거나 신뢰할 수 없는 도메인의 서비스에서 제공하는 모든 세션 티켓의 유효성을 확인해야 합니다.

관리 도구

관리자는 Active Directory 도메인 및 트러스트, Netdom 및 nltest 사용하여 트러스트를 노출, 생성, 제거 또는 수정할 수 있습니다.

• Active Directory 도메인 및 트러스트 도메인 트러스트, 도메인 및 포리스트 기능 수준 및 사용자 계정 이름 접미사를 관리하는 데 사용되는 MMC(Microsoft Management Console)입니다.
• Netdom 및 Nltest 명령줄 도구를 사용하여 트러스트를 찾고, 표시하고, 만들고, 관리할 수 있습니다. 이러한 도구는 도메인 컨트롤러의 LSA 기관과 직접 통신합니다.

다음 단계

포리스트 트러스트를 사용하여 관리되는 도메인 만들기를 시작하려면 Domain Services 관리되는 도메인만들기 및 구성을 참조하세요. 그런 다음 온-프레미스 도메인 에 대한 아웃바운드 포레스트 트러스트를만들 수 있습니다.