Active Directory에서 포리스트에 대해 트러스트 관계가 작동하는 방식
AD DS(Active Directory Domain Services)는 도메인 및 포리스트 트러스트 관계를 통해 여러 도메인 또는 포리스트에 보안을 제공합니다. 트러스트 간에 인증이 수행되려면 먼저 사용자, 컴퓨터 또는 서비스에서 요청하는 do기본 요청 계정의 do기본 트러스트 관계가 있는지 검사 합니다.
이 트러스트 관계를 검사 위해 Windows 보안 시스템은 요청을 수신하는 서버의 do기본 컨트롤러(DC)와 요청 계정의 할 일기본 DC 간의 트러스트 경로를 계산합니다.
AD DS 및 Windows 분산 보안 모델에서 제공하는 액세스 제어 메커니즘은 할 일기본 및 포리스트 트러스트 작업을 위한 환경을 제공합니다. 이러한 트러스트가 제대로 작동하려면 모든 리소스 또는 컴퓨터가 있는 do기본 DC에 대한 직접 신뢰 경로가 있어야 합니다.
트러스트 경로는 트러스트된 도메인 기관에 대해 인증된 RPC(원격 프로시저 호출) 연결을 사용하여 Net Logon 서비스에 의해 구현됩니다. 보안 채널은 interdo기본 트러스트 관계를 통해 다른 AD DS로도 확장됩니다기본. 이 보안 채널은 사용자 및 그룹의 SID(보안 식별자)를 비롯한 보안 정보를 가져오고 확인하는 데 사용됩니다.
참고 항목
Do기본 Services는 양방향 트러스트 및 들어오거나 나가는 단방향 트러스트를 포함하여 여러 포리스트 트러스트 방향을 지원합니다.
Domain Services에 트러스트가 적용되는 방식에 대한 개요는 포리스트 개념 및 기능을 참조하세요.
Domain Services에서 트러스트 사용을 시작하려면 포리스트 트러스트를 사용하는 관리되는 도메인을 만듭니다.
트러스트 관계 흐름
트러스트를 통한 보안 통신 흐름은 트러스트의 탄력성을 결정합니다. 트러스트를 만들거나 구성하는 방법은 통신이 포리스트 내에서 또는 포리스트 간에 얼마나 확장되는지를 결정합니다.
트러스트를 통한 통신 흐름은 트러스트의 방향에 따라 결정됩니다. 트러스트는 단방향 또는 양방향일 수 있으며 전이적이거나 전이적이지 않을 수 있습니다.
다음 다이어그램에서는 ‘트리 1’ 및 ‘트리 2’의 모든 도메인이 기본적으로 전이적 트러스트 관계를 포함하고 있음을 보여 줍니다. 따라서 트리 1의 사용자는 트리 2의 기본 리소스에 액세스할 수 있으며 트리 2의 사용자는 리소스에 적절한 권한이 할당될 때 트리 1의 리소스에 액세스할 수 있습니다.
단방향 및 양방향 트러스트
트러스트 관계를 사용하면 리소스에 대한 액세스가 단방향 또는 양방향일 수 있습니다.
단방향 트러스트는 두 도메인 간에 만들어지는 단방향 인증 경로입니다. Do기본 A와 Do기본 B 간의 단방향 트러스트에서 Do기본 A의 사용자는 Do기본 B의 리소스에 액세스할 수 있습니다. 그러나 Do기본 B의 사용자는 Do기본 A의 리소스에 액세스할 수 없습니다.
일부 단방향 트러스트는 만들어지는 트러스트의 형식에 따라 비전이적 또는 전이적일 수 있습니다.
양방향 트러스트에서 Do기본 A 트러스트 Do기본 B와 Do기본 B는 Do기본 A를 신뢰합니다. 이 구성은 양방향으로 두 do기본 간에 인증 요청을 전달할 수 있음을 의미합니다. 일부 양방향 관계는 생성되는 신뢰 유형에 따라 전이적이지 않거나 전이적일 수 있습니다.
온-프레미스 AD DS 포리스트의 모든 do기본 트러스트는 양방향 전이적 트러스트입니다. 새 자식이 생성되면기본 새 자식 do기본 부모 do기본 간에 양방향 전이적 트러스트가 자동으로 생성됩니다.
전이적 및 비전이적 트러스트
전이성은 트러스트가 형성된 두 도메인의 외부로 트러스트가 확장될 수 있는 여부를 결정합니다.
- 전이적 트러스트를 사용하여 다른 do기본와의 트러스트 관계를 확장할 수 있습니다.
- 비 전이적 트러스트를 사용하여 다른 do기본와의 트러스트 관계를 거부할 수 있습니다.
포리스트에서 새 do기본 만들 때마다 새 do기본 부모 do기본 간에 양방향 전이적 트러스트 관계가 자동으로 만들어집니다. 자식 do기본s가 새 do기본에 추가되면 트러스트 경로는 do기본 계층을 통해 위쪽으로 흐르며 새 do기본 부모 do기본 사이에 만들어진 초기 신뢰 경로를 확장합니다. 전이적 트러스트 관계는 do기본 트리가 형성됨에 따라 위쪽으로 흐르며 do기본 트리의 모든 do기본 간에 전이적 트러스트를 만듭니다.
인증 요청은 이러한 신뢰 경로를 따르므로 포리스트의 모든 do기본 계정은 포리스트의 다른 do기본 인증할 수 있습니다. 단일 로그인 프로세스를 사용하면 적절한 권한이 있는 계정은 포리스트의 모든 작업기본 리소스에 액세스할 수 있습니다.
포리스트 트러스트
포리스트 트러스트는 분할된 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’에 있는 리소스에 액세스할 수 없습니다.
Important
Microsoft Entra Do기본 Services는 포리스트 트러스트에 대해 여러 방향을 지원합니다.
포리스트 트러스트 요구 사항
포리스트 트러스트를 만들려면 올바른 DNS(Do기본 Name System) 인프라가 있는지 확인해야 합니다. 포리스트 트러스트는 다음 DNS 구성 중 하나를 사용할 수 있는 경우에만 만들 수 있습니다.
단일 루트 DNS 서버는 두 포리스트 DNS 네임스페이스의 루트 DNS 서버입니다. 루트 영역에는 각 DNS 네임스페이스에 대한 위임이 포함되고 모든 DNS 서버의 루트 힌트에는 루트 DNS 서버가 포함됩니다.
공유 루트 DNS 서버가 없고 각 포리스트 DNS 네임스페이스에 루트 DNS 서버가 없는 경우 각 DNS 네임스페이스에 대한 DNS 조건부 전달자를 사용하여 다른 네임스페이스의 이름에 대한 쿼리를 라우팅합니다.
Important
트러스트가 있는 모든 Microsoft Entra Domain Services 포리스트는 이 DNS 구성을 사용해야 합니다. 포리스트 DNS 네임스페이스가 아닌 DNS 네임스페이스를 호스팅하는 것은 Microsoft Entra Domain Services의 기능이 아닙니다. 조건부 전달자는 적절한 구성입니다.
공유 루트 DNS 서버가 없고 각 포리스트 DNS 네임스페이스에 루트 DNS 서버가 있는 경우 DNS 보조 영역은 각 DNS 네임스페이스에서 구성되어 다른 네임스페이스의 이름에 대한 쿼리를 라우팅합니다.
AD DS에서 포리스트 트러스트를 만들려면 Do기본 관리s 그룹(포리스트 루트 do기본) 또는 Active Directory의 Enterprise 관리s 그룹의 구성원이어야 합니다. 각 트러스트에는 두 포리스트의 관리자가 알고 있어야 하는 암호가 할당됩니다. 두 포리스트의 엔터프라이즈 관리 멤버는 한 번에 두 포리스트에서 트러스트를 만들 수 있으며, 이 시나리오에서는 암호화 임의 암호가 자동으로 생성되고 두 포리스트에 대해 기록됩니다.
관리되는 도메인 포리스트는 온-프레미스 포리스트에 대해 최대 5개의 단방향 아웃바운드 포리스트 트러스트를 지원합니다. Microsoft Entra Domain Services에 대한 아웃바운드 포리스트 트러스트는 Microsoft Entra 관리 센터에서 만들어집니다. 들어오는 포리스트 트러스트는 이전에 온-프레미스 Active Directory 기록된 권한을 가진 사용자가 구성해야 합니다.
신뢰 프로세스 및 상호 작용
다양한 작업을 완료하기 위해 많은 do기본 및 포리스트 간 트랜잭션은 do기본 또는 포리스트 트러스트에 의존합니다. 이 섹션에서는 트러스트 간에 리소스가 액세스되고 인증 참조가 평가될 때 이루어지는 프로세스와 상호 작용에 대해 설명합니다.
인증 참조 처리 개요
인증 요청이 do기본라고 하는 경우 기본 컨트롤러는 기본 요청이 오는 do기본 트러스트 관계가 있는지 여부를 결정해야 합니다. 트러스트의 방향과 트러스트가 전이적인지 아니면 전이적이지 않은지 여부도 사용자가 do기본 리소스에 액세스하도록 인증하기 전에 결정해야 합니다. 신뢰할 수 있는 do기본 간에 발생하는 인증 프로세스는 사용 중인 인증 프로토콜에 따라 다릅니다. 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를 사용하는 경우 대상의 서버에 대한 티켓을 요청합니다기본 계정의 do기본 컨트롤러에서 기본. Kerberos KDC는 클라이언트와 서버 간의 신뢰할 수 있는 중개자 역할을 하며 두 당사자가 서로를 인증할 수 있도록 하는 세션 키를 제공합니다. 대상이 현재 수행과 다른 경우기본기본 KDC는 논리적 프로세스를 따라 인증 요청을 참조할 수 있는지 여부를 결정합니다.
현재 do기본 요청 중인 서버의 do기본 직접 신뢰할 수 있나요?
- 그렇다면 요청된 do기본 대한 추천을 클라이언트에 보냅니다.
- 없는 경우 다음 단계로 이동합니다.
트러스트 경로에서 현재 do기본 및 다음 작업기본 간에 전이적 트러스트 관계가 존재하나요?
- 그렇다면 클라이언트에게 신뢰 경로의 다음 do기본에 대한 추천을 보냅니다.
- 그렇지 않은 경우 클라이언트에 로그인 거부 메시지를 보냅니다.
NTLM 조회 처리
NTLM 인증 프로토콜은 클라이언트 인증 및 권한 부여 정보를 위해 할 일기본 컨트롤러의 Net Logon 서비스에 따라 달라집니다. 이 프로토콜은 Kerberos 인증을 사용하지 않는 클라이언트를 인증합니다. NTLM은 트러스트를 사용하여 do기본 간에 인증 요청을 전달합니다.
클라이언트가 인증에 NTLM을 사용하는 경우 인증에 대한 초기 요청은 클라이언트에서 대상의 리소스 서버로 직접 이동합니다기본. 이 서버는 클라이언트가 응답하는 문제를 만듭니다. 그런 다음 서버는 사용자의 응답을 컴퓨터 계정의 do기본 컨트롤러에 보냅니다기본. 이렇게 기본 컨트롤러는 보안 계정 데이터베이스에 대해 사용자 계정을 검사.
데이터베이스에 계정이 없는 경우 do기본 컨트롤러는 다음 논리를 사용하여 통과 인증을 수행하거나 요청을 전달하거나 요청을 거부할지 여부를 결정합니다.
현재 도메인에 사용자의 도메인과 직접 트러스트 관계가 있나요?
- 그렇다면 도메인 컨트롤러는 통과 인증을 위해 클라이언트의 자격 증명을 사용자 도메인의 도메인 컨트롤러로 보내세요.
- 없는 경우 다음 단계로 이동합니다.
현재 사용자와 전이적 트러스트 관계가 기본기본?
- 그렇다면 인증 요청을 신뢰 경로의 다음 do기본 전달합니다. 이렇게 기본 컨트롤러는 자체 보안 계정 데이터베이스에 대해 사용자의 자격 증명을 검사 프로세스를 반복합니다.
- 없으면 클라이언트에 로그온 거부 메시지를 보냅니다.
포리스트 트러스트를 통한 인증 요청의 Kerberos 기반 처리
두 포리스트가 포리스트 트러스트에 의해 연결된 경우 Kerberos V5 또는 NTLM 프로토콜을 사용하여 수행한 인증 요청을 포리스트 간에 라우팅하여 두 포리스트의 리소스에 대한 액세스를 제공할 수 있습니다.
포리스트 트러스트가 처음 설정되면 각 포리스트는 파트너 포리스트의 모든 신뢰할 수 있는 네임스페이스를 수집하고 정보를 신뢰할 수 있는 do기본 개체에 저장합니다. 신뢰할 수 있는 네임스페이스에는 do기본 트리 이름, UPN(사용자 계정 이름) 접미사, SPN(서비스 사용자 이름) 접미사 및 다른 포리스트에서 사용되는 SID(보안 ID) 네임스페이스가 포함됩니다. TDO 개체는 전역 카탈로그에 복제본(replica).
참고 항목
트러스트에 대한 대체 UPN 접미사는 지원되지 않습니다. 온-프레미스 도메인이 Domain Services와 동일한 UPN 접미사를 사용하는 경우 로그인 시 sAMAccountName을 사용해야 합니다.
인증 프로토콜이 포리스트 트러스트 경로를 따르려면 먼저 리소스 컴퓨터의 SPN(서비스 사용자 이름)을 다른 포리스트의 위치로 확인해야 합니다. SPN은 다음 이름 중 하나일 수 있습니다.
- 호스트의 DNS 이름입니다.
- do기본 DNS 이름입니다.
- 서비스 연결 지점 개체의 고유 이름입니다.
한 포리스트의 워크스테이션이 다른 포리스트의 리소스 컴퓨터에 있는 데이터에 액세스하려고 하면 Kerberos 인증 프로세스는 서비스 티켓의 do기본 컨트롤러에 리소스 컴퓨터의 SPN에 연결합니다. do기본 컨트롤러가 글로벌 카탈로그를 쿼리하고 SPN이 do기본 컨트롤러와 동일한 포리스트에 있지 않은지 확인하면 do기본 컨트롤러는 부모 do기본에 대한 조회를 워크스테이션으로 다시 보냅니다. 이 시점에서 워크스테이션은 서비스 티켓에 대해 부모 do기본 쿼리하고 리소스가 있는 do기본 도달할 때까지 조회 체인을 계속 따릅니다.
다음 다이어그램과 단계는 Windows를 실행하는 컴퓨터에서 다른 포리스트에 있는 컴퓨터의 리소스에 액세스하려고 할 때 사용되는 Kerberos 인증 프로세스에 대한 자세한 설명을 제공합니다.
User1은 europe.tailspintoys.com 기본 자격 증명을 사용하여 Workstation1에 로그인합니다. 그런 다음 사용자는 usa.wingtiptoys.com 포리스트에 있는 FileServer1의 공유 리소스에 액세스하려고 시도합니다.
Workstation1은 do기본, ChildDC1의 do기본 컨트롤러에서 Kerberos KDC에 연결하고 FileServer1 SPN에 대한 서비스 티켓을 요청합니다.
ChildDC1은 do기본 데이터베이스에서 SPN을 찾지 못하고 전역 카탈로그를 쿼리하여 tailspintoys.com 포리스트에 이 SPN이 포함되어 있는지 기본 확인합니다. 글로벌 카탈로그는 자체 포리스트로 제한되므로 SPN을 찾을 수 없습니다.
그러면 글로벌 카탈로그는 해당 데이터베이스에서 해당 포리스트에 설정된 포리스트 트러스트에 대한 정보를 확인합니다. 발견되면 포리스트의 TDO(트러스트된 도메인 개체)에 나열된 이름 접미사와 대상 SPN의 접미사를 비교하여 일치 항목을 찾습니다. 일치 항목이 발견되면 글로벌 카탈로그는 ChildDC1로 라우팅 힌트를 다시 제공합니다.
라우팅 힌트는 대상 포리스트에 대한 직접 인증 요청을 도와줍니다. 힌트는 로컬 do기본 컨트롤러 및 글로벌 카탈로그와 같은 모든 기존 인증 채널이 SPN을 찾지 못하는 경우에만 사용됩니다.
ChildDC1은 부모 do기본에 대한 조회를 Workstation1로 다시 보냅니다.
Workstation1은 포리스트 루트 do기본에서 wingtiptoys.com 포리스트의 do기본 컨트롤러(ForestRootDC2)에 대한 조회를 위해 ForestRootDC1(해당 부모 do기본)의 do기본 컨트롤러에 연결합니다.
Workstation1은 요청 대상 서비스에 대한 서비스 티켓에 wingtiptoys.com 포리스트의 ForestRootDC2를 연결합니다.
ForestRootDC2는 SPN을 찾기 위해 글로벌 카탈로그에 연결하고, 글로벌 카탈로그는 SPN에 대한 일치 항목을 찾아 ForestRootDC2로 다시 보냅니다.
그런 다음 ForestRootDC2는 usa.wingtiptoys.com 다시 Workstation1로 조회를 보냅니다.
Workstation1은 ChildDC2의 KDC에 연결하고 User1의 티켓을 협상하여 FileServer1에 대한 액세스 권한을 얻습니다.
Workstation1에 서비스 티켓이 포함되면 서비스 티켓을 FileServer1로 보냅니다. 이 티켓은 User1의 보안 자격 증명을 읽고 그에 따라 액세스 토큰을 생성합니다.
신뢰할 수 있는 do기본 개체
조직 내의 각 도메인 또는 포리스트 트러스트는 도메인 내의 ‘시스템’ 컨테이너에 저장된 TDO(트러스트된 도메인 개체)로 표시됩니다.
TDO 콘텐츠
TDO에 포함된 정보는 TDO가 do기본 트러스트에 의해 만들어졌는지 또는 포리스트 트러스트에 의해 만들어졌는지에 따라 달라집니다.
do기본 트러스트가 만들어지면 DNS do기본 이름, do기본 SID, 트러스트 형식, 트러스트 전이성 및 상호 do기본 이름과 같은 특성이 TDO에 표시됩니다. 포리스트 트러스트 TDO는 파트너 포리스트에서 트러스트된 모든 네임스페이스를 식별하기 위해 추가 특성을 저장합니다. 이러한 특성에는 do기본 트리 이름, UPN(사용자 계정 이름) 접미사, SPN(서비스 사용자 이름) 접미사 및 SID(보안 ID) 네임스페이스가 포함됩니다.
트러스트는 Active Directory에 TDO로 저장되므로 포리스트의 모든 do기본에는 포리스트 전체에 있는 트러스트 관계에 대한 지식이 있습니다. 마찬가지로, 둘 이상의 포리스트가 포리스트 트러스트를 통해 함께 조인되는 경우 각 포리스트의 포리스트 루트는 기본 트러스트된 포리스트의 모든 do기본에 걸쳐 있는 트러스트 관계에 대한 지식을 갖습니다.
TDO 암호 변경
트러스트 관계의 두 기본 모두 Active Directory의 TDO 개체에 저장된 암호를 공유합니다. 계정 기본 테넌트 프로세스의 일부로 트러스트가 수행하는 30일마다기본 컨트롤러는 TDO에 저장된 암호를 변경합니다. 모든 양방향 트러스트는 실제로 2개의 단방향 트러스트를 기반으로 하기 때문에 양방향 트러스트에서는 프로세스가 두 번 이루어집니다.
트러스트에는 신뢰와 신뢰할 수 있는 측면이 있습니다. 신뢰할 수 있는 쪽에서는 모든 쓰기 가능한 do기본 컨트롤러를 프로세스에 사용할 수 있습니다. 신뢰 쪽에서 PDC 에뮬레이터는 암호 변경을 수행합니다.
암호를 변경하기 위해 do기본 컨트롤러는 다음 프로세스를 완료합니다.
신뢰 방법의 PDC(기본 do기본 컨트롤러) 에뮬레이터는 새 암호를 만듭니다기본. 트러스트된 도메인의 도메인 컨트롤러는 절대 암호 변경을 시작하지 않습니다. 암호 변경은 항상 트러스팅 도메인 PDC 에뮬레이터에 의해 시작됩니다.
신뢰할 수 있는 do기본 PDC 에뮬레이터는 TDO 개체의 OldPassword 필드를 현재 NewPassword 필드로 설정합니다.
신뢰 do기본 PDC 에뮬레이터는 TDO 개체의 NewPassword 필드를 새 암호로 설정합니다. 이전 암호의 복사본을 유지하면 트러스트된 도메인의 도메인 컨트롤러에서 변경 내용이 수신되지 않거나 새 트러스트 암호를 사용하는 요청을 수행하기 전에 변경 내용이 복제되지 않은 경우 이전 암호로 되돌릴 수 있습니다.
신뢰할 수 있는 do기본 PDC 에뮬레이터는 신뢰할 수 있는 do기본 컨트롤러에 대한 원격 호출을 수행합니다기본 트러스트 계정의 암호를 새 암호로 설정하도록 요청합니다.
트러스트된 도메인의 도메인 컨트롤러는 트러스트 암호를 새 암호로 변경합니다.
트러스트의 양쪽에서 업데이트는 도메인의 다른 도메인 컨트롤러에 복제됩니다. trusting do기본 변경은 신뢰할 수 있는 do기본 개체의 긴급 복제본(replica)를 트리거합니다.
이제 두 do기본 컨트롤러에서 암호가 변경되었습니다. 일반 복제본(replica) do기본 TDO 개체를 다른 do기본 컨트롤러에 분산합니다. 그러나 trusting do기본의 do기본 컨트롤러는 신뢰할 수 있는 do기본 컨트롤러를 성공적으로 업데이트하지 않고도 암호를 변경할 수 있습니다기본. 이 시나리오는 암호 변경을 처리하는 데 필요한 보안 채널을 설정할 수 없기 때문에 발생할 수 있습니다. 또한 신뢰할 수 있는 do기본 컨트롤러를 사용할 수 없으며기본 프로세스 중 어느 시점에서 사용할 수 없으며 업데이트된 암호를 받지 못할 수도 있습니다.
암호 변경이 성공적으로 전달되지 않는 상황을 처리하기 위해 트러스트의 do기본 컨트롤러는 새 암호를 사용하여 성공적으로 인증(보안 채널 설정)하지 않는 한 새 암호를 변경하지 기본 않습니다. 이 동작으로 인해 이전 암호와 새 암호가 모두 trusting do기본 TDO 개체에 유지됩니다.
암호 변경은 암호를 사용한 인증이 성공할 때까지 완료되지 않습니다. 신뢰할 수 있는 do기본 컨트롤러가 새 암호를 받을 때까지 저장된 이전 암호를 보안 채널을 통해 사용할 수 기본 중단 없는 서비스를 사용할 수 있습니다.
암호가 잘못되어 새 암호를 사용하는 인증이 실패하면 트러스트할 기본 컨트롤러는 이전 암호를 사용하여 인증을 시도합니다. 이전 암호를 사용하여 성공적으로 인증하는 경우 15분 이내에 암호 변경 프로세스를 다시 시작합니다.
트러스트 암호 업데이트 항목은 30일 이내에 트러스트의 양쪽 도메인 컨트롤러에 복제되어야 합니다. 신뢰 암호가 30일 후에 변경되고 do기본 컨트롤러에 N-2 암호만 있는 경우 트러스트 쪽에서 트러스트를 사용할 수 없으며 신뢰할 수 있는 쪽에서 보안 채널을 만들 수 없습니다.
트러스트에서 사용하는 네트워크 포트
트러스트는 다양한 네트워크 경계에 배포되어야 하므로 하나 이상의 방화벽을 포괄해야 할 수도 있습니다. 이 경우 방화벽을 통해 트러스트 트래픽을 터널로 연결하거나 방화벽에서 특정 포트를 열어 트래픽이 통과하도록 허용할 수 있습니다.
Important
Active Directory 도메인 Services는 Active Directory RPC 트래픽을 특정 포트로 제한하는 것을 지원하지 않습니다.
Microsoft 지원 문서의 Windows Server 2008 이상 버전 섹션을 읽고 포리스트 트러스트에 필요한 포트에 대해 알아보기 위해 Active Directory do기본 및 트러스트에 대한 방화벽을 구성하는 방법을 알아봅니다.
지원 서비스 및 도구
트러스트 및 인증을 지원하기 위해 몇 가지 추가 기능 및 관리 도구가 사용됩니다.
Net Logon
Net Logon 서비스는 windows 기반 컴퓨터에서 DC로 보안 채널을 기본. 또한 다음과 같은 신뢰 관련 프로세스에도 사용됩니다.
신뢰 설정 및 관리 - Net Logon은 기본 트러스트 암호를 기본, 신뢰 정보를 수집하고, LSA 프로세스 및 TDO와 상호 작용하여 트러스트를 확인하는 데 도움이 됩니다.
포리스트 트러스트의 경우 트러스트 정보에는 신뢰할 수 있는 포리스트가 관리하기 위해 클레임하는 네임스페이스 집합이 포함된 FTInfo(포리스트 트러스트 정보) 레코드가 포함되며, 각 클레임이 신뢰할 수 있는 포리스트에서 신뢰할 수 있는지 여부를 나타내는 필드로 주석이 추가됩니다.
인증 – 보안 채널을 통해 사용자 자격 증명을 do기본 컨트롤러에 제공하고 사용자에 대한 do기본 SID 및 사용자 권한을 반환합니다.
할 일기본 컨트롤러 위치 – 할 일기본 또는 할 일에서 할 일기본 컨트롤러를 찾거나 찾는 데 도움이 됩니다기본.
통과 유효성 검사 – 다른 작업기본 사용자의 자격 증명은 Net Logon에 의해 처리됩니다. 트러스팅 도메인은 사용자의 ID를 확인해야 하는 경우 확인을 위해 Net Logon을 통해 트러스트된 도메인에 사용자 자격 증명을 전달합니다.
PAC(권한 특성 인증서) 확인 – 인증에 Kerberos 프로토콜을 사용하는 서버가 서비스 티켓에서 PAC를 확인해야 하는 경우 확인을 위해 보안 채널을 통해 PAC를 해당 할 일기본 컨트롤러로 보냅니다.
로컬 보안 기관
LSA(로컬 보안 기관)는 시스템에서 로컬 보안의 모든 측면에 대한 정보를 유지 관리하는 보호된 하위 시스템입니다. 로컬 보안 정책이라고도 하는 LSA는 이름과 식별자 간 번역을 위한 다양한 서비스를 제공합니다.
LSA 보안 하위 시스템은 개체에 대한 액세스의 유효성을 검사하고, 사용자 권한을 확인하고, 감사 메시지를 생성하기 위한 커널 모드와 사용자 모드 모두에 서비스를 제공합니다. LSA는 신뢰할 수 있거나 신뢰할 수 없는 do기본 서비스에서 제공하는 모든 세션 티켓의 유효성을 검사 책임이 있습니다.
관리 도구
관리자는 ‘Active Directory 도메인 및 트러스트’, Netdom, Nltest를 사용하여 트러스트를 노출, 생성, 제거 또는 수정할 수 있습니다.
- ‘Active Directory 도메인 및 트러스트’는 도메인 트러스트, 도메인 및 포리스트 기능 수준, 사용자 계정 이름 접미사를 관리하는 데 사용되는 MMC(Microsoft Management Console)입니다.
- Netdom 및 Nltest 명령줄 도구는 트러스트를 찾고, 표시하고, 만들고, 관리하는 데 사용할 수 있습니다. 해당 도구는 도메인 컨트롤러에서 LSA 기관과 직접 통신합니다.
다음 단계
포리스트 트러스트를 사용하여 관리되는 도메인을 만들기 시작하려면 Domain Services 관리되는 도메인 만들기 및 구성을 참조하세요. 그런 다음, 온-프레미스 도메인에 대한 아웃바운드 포리스트 트러스트를 만들 수 있습니다.