Microsoft Active Directory용 관리형 서비스에서 작동하는 도메인 컨트롤러는 LDAP, DNS, Kerberos, RPC를 포함한 많은 서비스를 노출합니다. 사용 사례에 따라 Google Cloud에 배포된 VM(가상 머신)과 온프레미스를 실행하는 머신은 Active Directory를 활용하기 위해 이러한 서비스에 액세스해야 할 수 있습니다.
도메인 컨트롤러와 VM의 공격 노출 영역을 줄이려면 방화벽을 사용하여 엄격하게 요구되지 않는 네트워크 통신을 허용하지 않아야 합니다. 이 문서에서는 다른 네트워크 통신을 허용하지 않으면서 일반적인 Active Directory 사용 사례를 수용하도록 방화벽을 구성하는 방법을 설명합니다.
로그온 및 인증 비교
로그온과 인증이라는 용어는 종종 같은 의미로 사용되지만 Windows 보안과 관련하여 다른 의미를 갖습니다. 로그온은 사용자가 액세스할 수 있는 시스템에서 발생하는 프로세스를 설명합니다. 반대로 인증은 사용자 계정이 있는 컴퓨터에서 수행됩니다.
로컬 계정을 사용하여 머신에 로그온하면 대상 머신에서 로그온과 인증을 모두 처리합니다. Active Directory 환경에서는 도메인 사용자를 사용하여 로그온하는 것이 더 일반적입니다. 이 경우 로그온은 대상 머신에서 처리되는 반면 인증은 도메인 컨트롤러에서 수행됩니다.
클라이언트는 Kerberos 또는 NTLM을 사용하여 인증할 수 있습니다. 클라이언트가 인증되면 대상 머신이 로그온을 처리해야 합니다. 클라이언트가 요청한 로그온 유형에 따라 Kerberos, NTLM, LDAP, RPC, SMB와 같은 프로토콜을 사용하여 도메인 컨트롤러와 추가 상호작용이 필요할 수 있습니다.
로그온 인증 및 처리에는 다른 프로토콜이 필요하므로 올바른 방화벽 구성을 식별할 때 두 개념을 구분하는 것이 좋습니다.
일반 사용 사례
다음 섹션에서는 관리형 Microsoft AD에 액세스하기 위한 일반적인 사용 사례를 설명하고 각 사용 사례에 대해 구성해야 하는 방화벽 규칙을 보여줍니다.
관리형 Microsoft AD를 온프레미스 Active Directory와 통합하지 않으려면 이 도움말의 첫 번째 섹션인 VPC 내에서 관리형 Microsoft AD에 액세스만 읽으면 됩니다. 관리형 Microsoft AD와 온프레미스 Active Directory 간에 트러스트 관계를 만들려는 경우 전체 문서가 해당됩니다.
방화벽 규칙 로그를 사용하여 추가 포트가 필요한지 분석할 수 있습니다. 묵시적 인그레스 거부 규칙에 로깅이 사용 중지되어 있으므로 먼저 모든 인그레스 트래픽을 거부하지만 방화벽 로깅을 사용 설정하는 우선 순위가 낮은 커스텀 방화벽 규칙을 만들어야 합니다. 이 규칙을 적용한 경우 연결 시도가 실패하면 로그 항목이 Stackdriver에 공개됩니다. 방화벽 규칙이 많은 양의 로그를 생성할 수 있으므로 분석이 완료되면 방화벽 로깅을 다시 사용 중지하세요.
VPC 내에서 관리형 Microsoft AD에 액세스
기본 네트워크를 사용하여 관리형 Microsoft AD를 배포하는 경우 VPC의 VM이 Active Directory에 액세스할 수 있도록 추가 구성이 필요하지 않습니다.
VPC 구성 또는 방화벽 규칙을 맞춤설정한 경우 방화벽 구성이 여전히 관리형 Microsoft AD와의 통신을 허용하는지 확인해야 합니다. 다음 섹션에서는 만들어야 할 방화벽 규칙에 대해 설명합니다.
도메인 이름 확인
VM이 DNS 이름을 확인하려고 하면 도메인 컨트롤러를 직접 쿼리하지 않습니다. 대신 DNS 쿼리는 메타데이터 서버(Compute Engine VM에 대해 구성된 기본 DNS 서버)로 전송됩니다. 그런 다음 메타데이터 서버는 관리형 Microsoft AD에서 만든 Cloud DNS 비공개 DNS 전달 영역으로 쿼리를 전달합니다. 그런 다음 이 전달 영역은 적절한 도메인 컨트롤러로 쿼리를 전달합니다.
이 사용 사례를 활성화하기 위해 방화벽 규칙을 구성할 필요는 없습니다. Cloud DNS 과의 통신은 VPC의 VM에 대해 항상 허용되며 관리형 Microsoft AD는 기본적으로 Cloud DNS Cloud DNS 에서 전달된 DNS 요청을 허용합니다.
Kerberos를 사용하여 VM에 인증
한 VM에 로그인한 사용자는 다른 VM에서 제공한 서비스에 액세스해야 할 수 있습니다. 예를 들어, 사용자는 RDP 연결을 열거나 파일 공유에 액세스하거나 인증이 필요한 HTTP 리소스에 액세스하려고 할 수 있습니다.
사용자가 Kerberos를 사용하여 서버 VM을 인증할 수 있으려면 클라이언트 VM이 먼저 관리형 Microsoft AD 컨트롤러 중 하나에서 적절한 Kerberos 티켓을 얻어야 합니다.
Kerberos를 사용하여 VM이 다른 VM을 인증할 수 있게 하려면 방화벽 규칙에 따라 다음 통신이 허용되어야 합니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 클라이언트 VM | 관리형 Microsoft AD 서브넷 |
Kerberos(UDP/88, TCP/88) LDAP(UDP/389, TCP/389) |
| 2 | 허용 | 클라이언트 VM | 서버 VM | HTTP(TCP/80, TCP/443) 또는 RDP(TCP/3389)와 같은 VM에 액세스하는 데 사용되는 프로토콜 |
| 3 | 허용 | 서버 VM | 관리형 Microsoft AD 서브넷 | 로그온 처리를 참조하세요. |
NTLM을 사용하여 VM에 인증
대부분의 경우 Windows는 NTLM보다 Kerberos를 선호하지만 클라이언트는 인증을 위해 NTLM을 사용하도록 전환해야 하는 경우가 종종 있습니다. NTLM은 통과 인증에 의존하므로 서버가 관리형 Microsoft AD 도메인 컨트롤러 중 하나와 통신하여 사용자를 인증해야 합니다.
NTLM을 사용하여 VM이 다른 VM을 인증할 수 있게 하려면 방화벽 규칙에 따라 다음 통신이 허용되어야 합니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 클라이언트 VM | 서버 VM | HTTP(TCP/80, TCP/443) 또는 RDP(TCP/3389)와 같은 VM에 액세스하는 데 사용되는 프로토콜 |
| 2 | 허용 | 클라이언트 VM | 관리형 Microsoft AD 서브넷 | 로그온 처리를 참조하세요. |
도메인 가입 및 로그온 처리
도메인 구성원으로 작동하고 사용자의 로그온을 처리하려면 머신이 Active Directory와 상호작용할 수 있어야 합니다. 사용되는 정확한 프로토콜 집합은 개별 클라이언트가 요청하는 로그온 유형에 따라 다릅니다. 모든 일반적인 시나리오를 지원하려면 다음과 같은 프로토콜 조합을 허용해야 합니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 서버 VM | 관리형 Microsoft AD 서브넷 |
Kerberos(UDP/88, TCP/88) NTP(UDP/123) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) LDAP GC(TCP/3268) |
또한 정확한 사용 사례에 따라 다음 프로토콜을 허용할 수도 있습니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 서버 VM | 관리형 Microsoft AD 서브넷 |
Kerberos 비밀번호 변경(UDP/464, TCP/464) 보안 LDAP (TCP/636, TCP/3269) |
관리형 Microsoft AD 관리
관리형 Microsoft AD를 관리하려면 도메인 가입 VM을 사용해야 합니다. 이 VM에서 Active Directory 관리 센터와 같은 도구를 사용하려면 VM이 관리형 Microsoft AD 도메인 컨트롤러에 의해 노출된 Active Directory 웹 서비스에도 액세스할 수 있어야 합니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 관리 VM | 관리형 Microsoft AD 서브넷 | AD 웹 서비스(TCP/9389) |
온프레미스 Active Directory에 관리형 Microsoft AD 연결
관리형 Microsoft AD를 온프레미스 Active Directory에 연결하려면 포리스트 간에 트러스트 관계를 만들어야 합니다. 또한 Google Cloud와 온프레미스 환경 간에 DNS 이름 확인을 활성화해야 합니다.
트러스트 만들기 및 확인
포리스트 트러스트를 만들고 확인하려면 온프레미스 포리스트의 관리형 Microsoft AD 도메인 컨트롤러와 루트 도메인 컨트롤러가 양방향으로 통신할 수 있어야 합니다.
트러스트 만들기 및 확인을 가능하게 하려면 다음 특성과 일치하는 인그레스 및 이그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성합니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 온프레미스 AD | 관리형 Microsoft AD |
DNS(UDP/53, TCP/53) Kerberos(UDP/88, TCP/88) Kerberos 비밀번호 변경(UDP/464, TCP/464) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
| 2 | 허용 | 관리형 Microsoft AD | 온프레미스 AD |
DNS(UDP/53, TCP/53) Kerberos(UDP/88, TCP/88) Kerberos 비밀번호 변경(UDP/464, TCP/464) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
관리형 Microsoft AD는 이러한 특성과 일치하는 트래픽을 허용하도록 미리 구성되어 있으므로 Google Cloud에서 추가 방화벽 규칙을 구성할 필요가 없습니다.
온프레미스에서 Google Cloud DNS 이름 확인
온프레미스 머신이 관리형 Microsoft AD에서 DNS 이름을 확인할 수 있는 방법은 DNS 위임 및 조건부 DNS 전달의 두 가지가 있습니다.
DNS 위임
관리형 Microsoft AD에서 사용하는 DNS 도메인은 온프레미스에서 사용되는 DNS 도메인의 하위 도메인일 수 있습니다. 예를 들어 온프레미스에서 example.com을 사용하는 동안 관리형 Microsoft AD에 cloud.example.com을 사용할 수 있습니다. 온프레미스 클라이언트가 Google Cloud 리소스의 DNS 이름을 확인할 수 있도록 DNS 위임을 설정할 수 있습니다.
DNS 위임을 사용할 때 Google Cloud 리소스의 DNS 이름을 확인하려고 시도하면 먼저 온프레미스 DNS 서버를 쿼리합니다. 그런 다음 DNS 서버는 클라이언트를 Cloud DNS로 리디렉션하여 요청을 관리형 Microsoft AD 도메인 컨트롤러 중 하나로 전달합니다.
Cloud DNS를 온프레미스 네트워크에 노출하려면 인바운드 서버 정책을 만들어야 합니다. 이렇게 하면 VPC의 일부인 인바운드 전달자 IP 주소가 생성됩니다.
온프레미스의 전달자 주소를 사용하려면 아래 특성과 일치하는 이그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 온프레미스 AD | 관리형 Microsoft AD |
DNS(UDP/53, TCP/53) Kerberos(UDP/88, TCP/88) Kerberos 비밀번호 변경(UDP/464, TCP/464) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
| 2 | 허용 | 관리형 Microsoft AD | 온프레미스 AD |
DNS(UDP/53, TCP/53) Kerberos(UDP/88, TCP/88) Kerberos 비밀번호 변경(UDP/464, TCP/464) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
조건부 DNS 전달
관리형 Microsoft AD에서 사용하는 DNS 도메인은 온프레미스에서 사용되는 DNS 도메인의 하위 도메인이 아닐 수 있습니다. 예를 들어 온프레미스에서 corp.example.local을 사용하는 동안 관리형 Microsoft AD에 cloud.example.com을 사용할 수 있습니다.
DNS 도메인이 관련이 없는 시나리오에서는 온프레미스 Active Directory DNS에서 조건부 DNS 전달을 설정할 수 있습니다. 관리형 Microsoft AD에서 사용하는 DNS 이름과 일치하는 모든 쿼리는 Cloud DNS로 전달됩니다.
조건부 DNS 전달을 사용하려면 먼저 인바운드 DNS 전달을 사용 설정하는 DNS 정책을 설정해야 합니다. 온프레미스에서 결과 전달자 주소를 사용하려면 아래 특성과 일치하는 이그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 온프레미스 AD | DNS 전달 IP 주소 | DNS(UDP/53, TCP/53) |
Google Cloud 측에서 방화벽 규칙을 만들어 이러한 기준과 일치하는 인그레스 트래픽을 허용합니다.
DNS 전달자에서 Cloud DNS (2)로의 통신을 사용 설정하기 위해 방화벽 규칙을 구성할 필요가 없습니다 (2).
Google Cloud에서 온프레미스 DNS 이름 확인
관리형 Microsoft AD는 조건부 DNS 전달을 사용하여 온프레미스 포리스트의 DNS 이름을 확인합니다. 또한 Google Cloud에서 실행 중인 클라이언트가 온프레미스 Active Directory에서 관리하는 DNS 이름을 확인할 수 있도록 쿼리를 온프레미스 도메인 컨트롤러로 전달하는 Cloud DNS DNS에서 비공개 전달 영역을 만들 수 있습니다.
Google Cloud에서 온프레미스 DNS 이름을 확인하려면 다음 표에 따라 인그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 관리형 Microsoft AD | 온프레미스 AD | DNS(UDP/53, TCP/53) |
| 2 | 허용 | Cloud DNS(35.199.192.0/19) | 온프레미스 AD | DNS(UDP/53, TCP/53) |
Google Cloud는 기본적으로 해당 이그레스 트래픽을 허용합니다.
온프레미스에서 관리형 Microsoft AD 리소스에 액세스
관리형 Microsoft AD 포리스트가 온프레미스 포리스트를 신뢰하도록 설정되어 있으면 온프레미스 사용자 및 머신이 관리형 Microsoft AD 포리스트의 리소스에 액세스할 수 있습니다.
Kerberos를 사용하여 온프레미스에서 VM에 인증
온프레미스 머신에 로그인한 사용자는 Google Cloud에서 실행되고 관리형 Microsoft AD 포리스트의 구성원인 VM에서 제공하는 서비스에 액세스해야 할 수 있습니다. 예를 들어, 사용자는 RDP 연결을 열거나 파일 공유에 액세스하거나 인증이 필요한 HTTP 리소스에 액세스하려고 할 수 있습니다.
사용자가 Kerberos를 사용하여 서버 VM에 인증할 수 있으려면 클라이언트 머신이 적절한 Kerberos 티켓을 얻어야 합니다. 이를 위해서는 온프레미스 도메인 컨트롤러 중 하나와 관리형 Microsoft AD 도메인 컨트롤러 중 하나와 통신해야 합니다.
온프레미스 VM이 Kerberos를 사용하여 인증할 수 있게 하려면 다음 이그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 클라이언트 머신(온프레미스) | 관리형 Microsoft AD 서브넷 |
LDAP(UDP/389, TCP/389) Kerberos(UDP/88, TCP/88) |
| 2 | 허용 | 클라이언트 머신(온프레미스) | 서버 VM(Google Cloud) | HTTP(TCP/80, TCP/443) 또는 RDP(TCP/3389)와 같은 애플리케이션에서 사용하는 프로토콜 |
| 3 | 허용 | 서버 VM | 관리형 Microsoft AD 서브넷 | 로그온 처리를 참조하세요. |
Google Cloud 측에서 방화벽 규칙을 만들어 (1) 및 (2)의 인그레스 트래픽을 허용하세요. 관리형 Microsoft AD (3)에 대한 이그레스 트래픽은 기본적으로 허용됩니다.
NTLM을 사용하여 온프레미스에서 VM에 인증
NTLM을 사용하여 온프레미스 Active Directory 포리스트에서 관리형 Microsoft AD 포리스트에 가입된 서버 VM으로 사용자를 인증하는 경우 관리형 Microsoft AD 도메인 컨트롤러는 온프레미스 도메인 컨트롤러와 통신해야 합니다.
온프레미스 VM이 NTLM을 사용하여 인증할 수 있도록 하려면 다음과 같이 인그레스 및 이그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 클라이언트 머신(온프레미스) | 서버 VM(Google Cloud) | HTTP(TCP/80, TCP/443) 또는 RDP(TCP/3389)와 같은 애플리케이션에서 사용하는 프로토콜 |
| 2 | 허용 | 서버 VM | 관리형 Microsoft AD 서브넷 | 로그온 처리를 참조하세요. |
| 3 | 허용 | 관리형 Microsoft AD 서브넷 | 온프레미스 AD |
LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
Google Cloud 측에서 방화벽 규칙을 만들어 (1)의 인그레스 트래픽을 허용하세요. (2) 및 (3)의 이그레스 트래픽은 기본적으로 허용됩니다.
온프레미스 포리스트 사용자의 로그온 처리
온프레미스 포리스트의 사용자에 대한 로그온을 처리하려면 VM이 온프레미스 Active Directory와 상호작용할 수 있어야 합니다. 사용되는 정확한 프로토콜 집합은 클라이언트가 요청한 로그온 유형에 따라 다릅니다. 모든 일반적인 시나리오를 지원하려면 이러한 특성과 일치하는 인그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 서버 VM(Google Cloud) | 온프레미스 AD 서브넷 |
Kerberos(UDP/88, TCP/88) NTP(UDP/123) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) LDAP GC(TCP/3268) |
정확한 사용 사례에 따라 다음 프로토콜을 허용할 수도 있습니다.
- Kerberos 비밀번호 변경(UDP/464, TCP/464)
- 보안 LDAP(TCP/636, TCP/3269)
관리형 Microsoft AD 측에서는 해당 이그레스 트래픽이 기본적으로 허용됩니다.
관리 VM에서 온프레미스 포리스트 사용자의 로그온을 허용하지 않을 수 있습니다. 그러나 관리 VM에서 수행해야 할 한 가지 활동은 그룹 구성원을 관리하는 것입니다. 객체 선택도구를 사용하여 온프레미스 포리스트의 사용자 또는 그룹을 참조할 때마다 객체 선택도구는 온프레미스 도메인 컨트롤러에 액세스해야 합니다. 이를 위해 관리 VM에 온프레미스 포리스트 사용자의 로그온을 처리할 때와 마찬가지로 온프레미스 Active Directory 도메인 컨트롤러에 대한 액세스 권한이 필요합니다.
Google Cloud에서 온프레미스 Active Directory 리소스에 액세스
온프레미스 포리스트가 관리형 Microsoft AD 포리스트를 신뢰하도록 설정된 경우 관리형 Microsoft AD 포리스트의 사용자가 온프레미스 리소스에 액세스해야 할 수 있습니다.
Kerberos를 사용하여 온프레미스 VM에 인증
Google Cloud에서 실행되는 VM에 로그인한 관리형 Microsoft AD 포리스트의 구성원인 사용자는 온프레미스 포리스트의 구성원인 온프레미스 머신에서 제공하는 서비스에 액세스해야 할 수 있습니다. 예를 들어, 사용자는 RDP 연결을 열거나 파일 공유에 액세스하거나 인증이 필요한 HTTP 리소스에 액세스하려고 할 수 있습니다.
사용자가 Kerberos를 사용하여 온프레미스 머신에 인증할 수 있으려면 VM에서 적절한 Kerberos 티켓을 얻어야 합니다. 이를 위해서는 먼저 관리형 Microsoft AD 컨트롤러 중 하나와 온프레미스 도메인 컨트롤러와 통신해야 합니다.
온프레미스 VM이 Kerberos를 사용하여 인증할 수 있도록 하려면 아래 특성과 일치하는 인그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 클라이언트 VM(Google Cloud) | 관리형 Microsoft AD 서브넷 |
Kerberos(UDP/88, TCP/88) LDAP(UDP/389, TCP/389) 로그온 처리로 암시됨 |
| 2 | 허용 | 클라이언트 VM(Google Cloud) | 온프레미스 AD |
Kerberos(UDP/88, TCP/88) LDAP(UDP/389, TCP/389) |
| 3 | 허용 | 클라이언트 VM(Google Cloud) | 서버 머신(온프레미스) | HTTP(TCP/80, TCP/443) 또는 RDP(TCP/3389)와 같은 애플리케이션에서 사용하는 프로토콜 |
Google Cloud 측에서는 해당 이그레스 트래픽이 기본적으로 허용됩니다.
NTLM을 사용하여 온프레미스 VM에 인증
NTLM을 사용하여 관리형 Microsoft AD 포리스트에서 온프레미스 포리스트에 가입된 서버 머신으로 사용자를 인증할 경우 온프레미스 도메인 컨트롤러는 관리형 Microsoft AD 도메인 컨트롤러와 통신할 수 있어야 합니다.
온프레미스 VM이 Kerberos를 사용하여 인증할 수 있도록 하려면 이러한 특성과 일치하는 인그레스 및 이그레스 트래픽을 허용하도록 온프레미스 방화벽을 구성하세요.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 클라이언트 VM(Google Cloud) | 서버 머신(온프레미스) | 애플리케이션에서 사용하는 프로토콜(예: HTTP(TCP/80, TCP/443) 또는 RDP(TCP/3389)) |
| 2 | 허용 | 온프레미스 AD | 관리형 Microsoft AD 서브넷 |
LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
Google Cloud 측에서 (1)에 대한 이그레스 트래픽과 (2)에 대한 인그레스 트래픽은 기본적으로 허용됩니다.
관리형 Microsoft AD 포리스트 사용자의 로그온 처리
관리형 Microsoft AD 포리스트 사용자의 로그온을 처리하려면 온프레미스를 실행하는 머신이 관리형 Microsoft AD 도메인 컨트롤러와 상호작용할 수 있어야 합니다. 사용되는 정확한 프로토콜 집합은 클라이언트가 요청한 로그온 유형에 따라 다릅니다. 모든 일반적인 시나리오를 지원하려면 다음과 같은 프로토콜 조합을 허용해야 합니다.
| 작업 | 원본 | 대상 | 프로토콜 | |
|---|---|---|---|---|
| 1 | 허용 | 서버 머신(온프레미스) | 관리형 Microsoft AD 서브넷 |
Kerberos(UDP/88, TCP/88) NTP(UDP/123) RPC(TCP/135, TCP/49152-65535) LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) LDAP GC(TCP/3268) |
정확한 사용 사례에 따라 다음 프로토콜을 허용할 수도 있습니다.
- Kerberos 비밀번호 변경(UDP/464, TCP/464)
- 보안 LDAP(TCP/636, TCP/3269)
온프레미스 방화벽이 이러한 특성과 일치하는 이그레스 트래픽을 허용하는지 확인하세요. 관리형 Microsoft AD에 대한 해당 인그레스 트래픽을 사용 설정하기 위해 Google Cloud에서 방화벽 규칙을 구성할 필요가 없습니다.
관리 머신에서는 관리형 Microsoft AD 포리스트 사용자의 로그온을 허용하지 않을 수 있습니다. 관리 머신에서 수행해야 할 작업 중 하나는 그룹 구성원 관리입니다. 객체 선택기를 사용하여 관리형 Microsoft AD 포리스트에서 사용자 또는 그룹을 참조할 때마다 객체 선택기가 관리형 Microsoft AD 도메인 컨트롤러에 액세스해야 합니다. 이 작업을 수행하려면 관리 머신에 관리형 Microsoft AD 포리스트 사용자의 로그온을 처리할 때와 동일한 관리형 Microsoft AD 도메인 컨트롤러 액세스 권한이 필요합니다.