Cloud SQL에 관리형 Microsoft AD 사용

MySQL | PostgreSQL | SQL Server

이 페이지에서는 Cloud SQL을 사용하여 다음을 수행하는 방법을 설명합니다.

Microsoft Active Directory용 관리형 서비스와 통합합니다(관리형 Microsoft AD라고도 함).
AD 사용자로 인스턴스에 연결합니다.

관리형 Microsoft AD와 통합된 Cloud SQL 인스턴스는SQL 인증 외에도 Windows 인증을 지원합니다.

시작하기 전에

Google Cloud Console에서 프로젝트 이름을 선택합니다.
Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.
gcloud CLI를 설치하고 초기화합니다.
사용자 계정에 Cloud SQL Admin 역할이 있는지 확인합니다. IAM 페이지로 이동합니다.
통합 기본 요건을 검토합니다.

Windows 인증을 사용하여 인스턴스 만들기

인스턴스 만들기 중 관리형 Microsoft AD와 통합하여 인스턴스에 대해 Windows 인증을 사용 설정할 수 있습니다. 통합하려면 인스턴스와 조인할 도메인을 선택합니다. 도메인 연결이 실패하면 인스턴스 만들기가 실패합니다.

Windows 인증으로 인스턴스 만들기를 준비할 때 팁과 제한사항 및 대안을 검토합니다.

공개 IP를 포함하는 인스턴스는 비공개 IP도 포함하는 경우에만 지원됩니다. 인스턴스에 대해 비공개 IP가 사용 설정되어야 합니다. 그러면 두 항목을 모두 사용할 수 있는 한 공개 IP 또는 비공개 IP를 사용하여 인스턴스에 연결하도록 선택할 수 있습니다.

참고: Windows 인증을 사용하여 인스턴스를 만들면 SQL Server용 Cloud SQL 로그인이 추가로 생성됩니다. 로그인은 [domain]\sql_[letters-and-digits] 형식입니다. 예를 들어 Cloud SQL은 AD\sql_1a1a6145bc1aaaa라는 로그인을 만들 수 있습니다. 로그인은 관리형 AD 도메인에 있습니다. 로그인은 무시할 수 있고 삭제할 수 없습니다. 그러나 인스턴스에 대해 Windows 인증을 사용 중지하면 로그인이 자동으로 삭제됩니다.

다음은 관리형 Microsoft AD와 통합된 인스턴스를 만들기 위한 옵션입니다.

Console

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스 만들기를 클릭합니다.
SQL Server 선택을 클릭합니다.
인스턴스의 이름을 입력합니다. 인스턴스 이름은 외부에 공개되므로 민감한 정보나 개인 식별 정보는 포함하지 마세요. 인스턴스 이름에 프로젝트 ID를 포함하지 않아도 됩니다. 필요한 경우 자동으로 생성됩니다(예: 로그 파일에서).
'sqlserver' 사용자의 비밀번호를 입력합니다.
인스턴스의 리전을 설정합니다. 관리형 Microsoft AD와 통합 권장사항을 참조하세요.
구성 옵션 섹션에서 원하는 옵션을 설정합니다(인증 옵션의 다음 단계까지 대기).
인증을 클릭합니다. 관리형 Active Directory 도메인을 연결하기 위한 드롭다운 메뉴에 이전에 프로젝트에서 추가된 모든 관리형 Microsoft AD 도메인이 나열됩니다.
관리형 Active Directory 도메인을 연결하기 위한 드롭다운 메뉴에서 도메인을 선택합니다.
구성 옵션 선택을 마쳤으면 만들기를 클릭합니다. Cloud SQL은 제품별, 프로젝트별 서비스 계정을 자동으로 만듭니다. 계정에 적절한 역할이 없으면 managedidentities.sqlintegrator 역할을 부여하라는 메시지가 표시됩니다.

gcloud

다음 명령어는 관리형 Microsoft AD와 통합된 인스턴스를 만듭니다. 따라서 Windows 인증이 사용 설정됩니다. 인스턴스 만들기 기본 명령어에 대한 자세한 내용은 인스턴스 만들기를 참조하세요.

gcloud 명령어에 --active-directory-domain=DOMAIN 매개변수를 지정합니다. 예를 들어 --active-directory-domain=ad.mydomain.com을 지정합니다.

다음은 gcloud 명령어의 프로토타입입니다.

gcloud beta sql instances create INSTANCE_NAME \
--database-version=EDITION \
--root-password=PASSWORD \
--active-directory-domain=DOMAIN\
--cpu=CPU \
--memory=MEMORY  \
--network=NETWORK

Terraform

관리형 Microsoft AD와 통합되는 인스턴스를 만들려면 Terraform 리소스를 사용합니다.

resource "google_sql_database_instance" "instance_with_ad" {
  name             = "database-instance-name"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"

  depends_on = [google_service_networking_connection.private_vpc_connection]

  settings {
    tier = "db-custom-2-7680"
    active_directory_config {
      domain = "ad.domain.com"
    }
    ip_configuration {
      ipv4_enabled    = "false"
      private_network = google_compute_network.private_network.id
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

REST

REST API를 사용하여 관리형 Microsoft AD와 통합된 인스턴스를 만들 수 있습니다. 요청의 이 프로토타입에 표시된 것처럼 domain 필드에 대해 subdomain.mydomain.com과 같은 도메인을 지정합니다.

{
   "databaseVersion":"database-version",
   "name":"instance-id",
   "region":"region",
   "rootPassword":"password",
   "settings":{
      "tier":"machine-type",
      "ipConfiguration":{
         "privateNetwork":"network"
      },
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

Windows 인증으로 인스턴스 업데이트

도메인 변경 또는 추가와 같이 기존 인스턴스의 도메인을 업데이트할 수 있습니다.

인스턴스 업데이트에 대한 일반적인 내용은 인스턴스 수정을 참조하세요.

인스턴스가 현재 관리형 AD 도메인과 연결된 경우 새 도메인에 연결되기 전 해당 도메인에서 먼저 연결 해제됩니다. 업데이트에 실패하면 인스턴스가 더 이상 어느 도메인에도 연결되지 않을 수 있습니다.

Console

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
수정을 클릭합니다.
인증을 클릭합니다. Active Directory 도메인에 조인 드롭다운 메뉴에는 이전에 프로젝트에서 추가된 관리형 Microsoft AD 도메인이 나열됩니다.
관리형 Active Directory 도메인을 연결하기 위한 드롭다운 메뉴에서 인스턴스에 대해 새(교체) 도메인을 선택합니다.
저장을 클릭하여 변경사항을 적용합니다.

gcloud

다음은 기존 인스턴스를 업데이트하기 위한 명령어의 프로토타입입니다. 이 명령어는 도메인을 추가하거나 바꿉니다. 다음과 같이 --active-directory-domain=DOMAIN을 명령어에 전달합니다.

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=DOMAIN

REST

REST API를 사용하여 기존 인스턴스를 업데이트할 수 있습니다. domain 필드에 subdomain.mydomain.com과 같은 도메인을 지정합니다. 다음은 요청의 프로토타입입니다.

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

다른 프로젝트의 관리형 AD 도메인과 통합

인스턴스를 다른 프로젝트에 있는 관리형 Microsoft AD 도메인과 통합할 수 있습니다.

참고: 다른 프로젝트의 AD 도메인과 통합하려면 gcloud 명령어 또는 Cloud SQL REST API를 사용해야 합니다. 현재는 이 목적으로 Google Cloud 콘솔을 사용할 수 없습니다.

통합을 계획하면서 제약조건을 검토합니다.

도메인 피어링 사용 설정

아래 섹션의 단계를 진행하기 전에 도메인 피어링을 사용 설정하여 SQL Server용 Cloud SQL 인스턴스가 있는 모든 필수 프로젝트에서 도메인을 사용할 수 있게 하세요.

이미 사용 가능한 다른 프로젝트의 도메인 목록에 대해 다음을 지정할 수 있습니다.

`gcloud active-directory peerings list`

자세한 내용은 도메인 피어링 나열을 참조하세요.

gcloud active-directory peerings list 명령어에는 managedidentities.peerings.list 권한이 필요합니다. 다음 역할에는 이 권한이 있습니다.

roles/managedidentities.peeringViewer
roles/managedidentities.viewer

자세한 내용은 IAM으로 액세스 제어를 참조하세요.

서비스 계정 만들기

통합하려는 SQL Server용 Cloud SQL 인스턴스가 포함된 각 프로젝트에 이 단계를 반복합니다.

서비스 계정 만들기에 대한 배경 정보를 검토합니다.
다음과 비슷한 명령어를 사용하여 서비스 계정을 만듭니다. SQL Server용 Cloud SQL 인스턴스가 포함된 프로젝트의 ID를 지정합니다.
```
gcloud beta services identity create --service=sqladmin.googleapis.com \
--project=[PROJECT_ID]
```
관리형 Microsoft AD 인스턴스가 있는 프로젝트에서 managedidentities.sqlintegrator 역할을 부여합니다. 관리형 Microsoft AD 인스턴스가 포함된 프로젝트의 ID를 지정합니다.
```
gcloud projects add-iam-policy-binding [PROJECT_ID] \
--member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator
```

프로젝트 간 Windows 인증 사용 설정

gcloud 명령어 또는 Cloud SQL REST API를 사용하여 다른 프로젝트의 AD 도메인과 통합할 수 있습니다. 두 경우 모두 전체 도메인 리소스 이름을 지정해야 합니다.

SQL Server용 Cloud SQL 인스턴스가 생성되거나 업데이트될 때 전체 도메인 리소스 이름을 지정합니다. 두 가지 형식이 지원됩니다.

projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME
projects/PROJECT_NUMBER/locations/global/domains/DOMAIN_NAME

다음은 gcloud를 사용하는 예시입니다.

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME

짧은 도메인 리소스 이름(예: DOMAIN_NAME)을 사용하는 경우 시스템은 관리형 Microsoft AD 도메인이 SQL Server용 Cloud SQL 인스턴스와 동일한 프로젝트에 있다고 가정합니다.

다른 프로젝트와의 통합을 위한 제약조건

다른 프로젝트에서 관리형 AD 도메인과 통합하는 경우 다음 제약조건이 적용됩니다.

SQL Server용 Cloud SQL 인스턴스가 있는 최대 10개의 네트워크는 다른 프로젝트에 있는 하나의 관리형 Microsoft AD 인스턴스를 공유할 수 있습니다.
Google Cloud 콘솔은 동일한 프로젝트에 있는 관리형 Microsoft AD 인스턴스만 지원합니다. Google Cloud 콘솔을 사용하는 대신 gcloud 명령어 또는 Cloud SQL REST API를 사용하여 통합할 수 있습니다.
VPC 서비스 제어를 사용하는 경우 SQL Server용 Cloud SQL 인스턴스와 관리형 Microsoft AD 인스턴스는 동일한 경계에 있어야 합니다.

또한 인스턴스가 다른 프로젝트의 관리형 AD 도메인과 통합된 경우 Google Cloud 콘솔에 표시된 정규화된 도메인 이름(FQDN)이 인스턴스에 정확하지 않을 수 있습니다. 구체적으로 인스턴스의 개요 페이지에서 이 인스턴스에 연결 아래에 있는 FQDN에 슬래시로 구분된 문자열이 포함될 수 있으며 이를 무시해도 됩니다. 예를 들어 부정확한 FQDN은 다음과 같이 표시될 수 있습니다.

private.myinstance.myregion.myproject.projects/mydirectory/locations/global/domains/mydomain.com

이 경우 정확한 FQDN은 다음과 같습니다.

private.myinstance.myregion.myproject.cloudsql.mydomain.com

인스턴스에서 Windows 인증 삭제

기존 인스턴스에서 관리형 Microsoft AD 통합과 같이 Windows 인증을 삭제할 수 있습니다.

Console

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
수정을 클릭합니다.
인증을 클릭합니다. 관리형 Active Directory 도메인을 연결하기 위한 드롭다운 메뉴에 이전에 프로젝트에서 추가된 모든 관리형 Microsoft AD 도메인이 나열됩니다.
드롭다운 메뉴에서 인스턴스에 대해 도메인 없음/나중에 연결을 선택합니다.
인스턴스 다시 시작에 대한 메시지를 읽고 닫기를 클릭합니다.
저장을 클릭하여 변경사항을 적용합니다.

gcloud

Windows 인증과 같이 도메인에서 인스턴스를 삭제하려면 도메인에 빈 값을 사용합니다. 즉, 명령어에서 다음과 같이 --active-directory-domain 매개변수에 대해 빈 값을 사용합니다.

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=

REST

REST API를 사용하여 도메인에서 인스턴스를 삭제할 수 있습니다. 다음과 같이 domain 필드에 빈 값을 지정합니다.

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":""
      }
   }
}

사용자로 인스턴스에 연결

SQL Server용 Cloud SQL의 경우 기본 사용자는 sqlserver입니다.

인스턴스를 관리형 Microsoft AD와 통합한 후 다음과 같이 sqlserver 사용자로 인스턴스에 연결할 수 있습니다.

다음과 같이 Windows 사용자 또는 그룹을 기준으로 SQL Server 로그인을 만듭니다.
```
CREATE LOGIN [domain\user_or_group] FROM WINDOWS
```
Windows 인증을 사용하여 인스턴스 DNS 이름으로 인스턴스에 로그인합니다. 지정할 인스턴스 DNS 이름 예시는 다음과 같습니다.
- 비공개 IP를 통해 연결하려면 다음 안내를 따르세요.
```
private.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- 공개 IP를 통해 연결하려면 다음 안내를 따르세요.
```
public.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- Cloud SQL 인증 프록시를 통해 연결하려면 다음 안내를 따르세요(또한 아래 참조).
```
proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
인스턴스 IP 주소를 사용할 경우 IP 호스트 이름을 지원하도록 Kerberos 클라이언트를 구성해야 합니다. Cloud SQL은 트러스트 관계를 통해 연결된 도메인의 로그인을 지원하지 않습니다.

Windows 인증으로 Cloud SQL 인증 프록시 사용

관리형 Microsoft AD 통합에 Cloud SQL 인증 프록시를 사용할 수 있습니다.

시작하기 전에 다음을 검토하세요.

Windows 인증 단계

Cloud SQL 인증 프록시 시작에 대한 배경 정보는 Cloud SQL 인증 프록시 시작을 참조하세요.

Windows 인증의 경우 포트 1433에서 Cloud SQL 인증 프록시를 실행해야 합니다. 사전 정의된 서비스 기본 이름(SPN) 항목을 Cloud SQL 인증 프록시 주소에 매핑하려면 다음 안내를 따르세요.

proxy.[instance].[location].[project].cloudsql.[domain]

로컬로 Cloud SQL 인증 프록시 실행

Cloud SQL 인증 프록시를 로컬로 실행하려면 호스트 파일을 사용하여 다음을 127.0.0.1에 매핑합니다.

proxy.[instance].[location].[project].cloudsql.[domain]

예를 들어 호스트 파일에 다음을 추가할 수 있습니다(예: c:\windows\system32\drivers\etc\hosts).

127.0.0.1 proxy.[instance].[location].[project].cloudsql.[domain]

이 예시에서는 다음 명령어를 사용하여 Cloud SQL 인증 프록시를 실행하고 127.0.0.1:1433에 제공할 수 있습니다.

cloud-sql-proxy.exe --credentials-file credential.json project:name

로컬이 아닌 방식으로 Cloud SQL 인증 프록시 실행

로컬이 아닌 방식으로 Cloud SQL 인증 프록시를 실행하려면 로컬로 Cloud SQL 인증 프록시 실행의 안내를 따릅니다. 하지만 호스트 파일에 다른 항목을 사용합니다.

특히 로컬이 아닌 호스트가 예를 들어 MyOtherHost이면 호스트 파일에 다음을 추가할 수 있습니다.

127.0.0.1 MyOtherHost proxy.[instance].[location].[project].cloudsql.[domain]

클라이언트의 NTLM 대체 문제 해결

Windows 인증 및 인스턴스 IP 주소를 사용하여 인스턴스에 로그인하는 경우 IP 호스트 이름을 지원하도록 Kerberos 클라이언트를 구성해야 합니다.

Cloud SQL은 NTLM 인증을 지원하지 않지만 일부 Kerberos 클라이언트가 이것으로 대체하려고 시도할 수 있습니다. 이 섹션에서 설명한 것처럼 SQL Server Management Studio (SSMS)에 연결하려고 할 때 다음 오류 메시지가 발생하면 NTLM 대체가 원인일 수 있습니다.

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)

NTLM은 인증에 대한 Microsoft 보안 프로토콜 집합입니다. NTLM 대체 이유도 참조하세요.

Windows 클라이언트의 NTLM 대체 확인

Windows에서 NTLM 대체로 인해 오류가 발생했는지 확인하려면 다음 안내를 따르세요.

원하는 온프레미스 사용자 인증 정보로 로그인합니다('Run as...'를 사용하지 마세요).
명령 프롬프트를 엽니다.
klist purge을 실행합니다.
SSMS에서 Windows 인증을 사용하여 SQL Server에 연결해 봅니다.
klist를 실행하고 "MSSQLSvc/<address>:1433 @ domain"에 대해 발급된 티켓이 있는지 확인합니다.
티켓이 없으면 NTLM이 오류의 원인일 수 있습니다.
티켓이 있는 경우 SQL Server 드라이버가 NTLM 인증을 적용하지 않는지 확인합니다. 또한 그룹 정책을 통해 NTLM 인증이 적용되는지 확인합니다.

Linux 클라이언트의 NTLM 대체 확인

Ubuntu 16.04에서 NTLM 대체로 오류가 발생했는지 확인하려면 이 섹션의 단계를 따르세요. 이 단계는 다른 Linux 배포의 단계와 비슷합니다.

Kerberos 인증 설정

Kerberos 클라이언트를 설정합니다.
```
sudo apt-get install krb5-user
```
기본 렐름을 입력하라는 메시지가 표시되면 온프레미스 도메인 이름을 대문자로 입력합니다.

다음을 실행하여 SQL Server 명령줄 도구를 설치합니다.

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
sudo apt-get update
sudo apt-get install mssql-tools unixodbc-dev

Windows 인증 연결

kinit 도구를 kinit <user_account>와 같이 실행합니다.
Windows 인증을 연결하려면 /opt/mssql-tools/bin/sqlcmd -S <address >>를 실행합니다.
klist 명령어를 실행하고 "MSSQLSvc/<address>:1433 @ domain"에 대해 특별히 티켓이 발급되었는지 확인합니다.
티켓이 발급되지 않았다면 위 오류는 NTLM 대체를 초래한 문제를 나타낼 가능성이 높습니다.

NTLM 대체 이유

NTLM로의 대체는 다음 조건과 관련될 수 있는 클라이언트 구성 오류입니다.

기본적으로 호스트 이름이 IP 주소인 경우 Windows는 호스트에 대해 Kerberos 인증을 시도하지 않습니다. 관리형 도메인에서 Kerberos 인증을 사용 설정하려면 Microsoft 문서에 설명된 방법을 시도하세요. 이 방법은 FQDNS를 사용해야 할 때 온프레미스 사용자 인증 정보로 작동하지 않습니다.
외부 트러스트를 통한 Kerberos 인증은 작동하지 않습니다. 대신 여기에 설명된 대로 포리스트 트러스트를 사용하세요.
다른 포리스트에서 서비스를 찾을 수 있도록 하려면 Kerberos 인증에 이름 서픽스 라우팅이 필요합니다. 여기에 설명된 방법을 시도해보세요.
서비스에 등록된 SPN이 없으면 Kerberos 인증은 작동하지 않습니다. Google Cloud 콘솔에서 가져온 FQDN 또는 IP 주소만 사용하여 Windows 인증과 연결합니다.

온프레미스 AD 사용자: Windows 로그인 만들기

온프레미스 AD 사용자를 사용하여 SQL Server용 Cloud SQL에 대한 Windows 로그인을 만들 수 있습니다.

예를 들어 Google Cloud 프로젝트의 Virtual Private Cloud(VPC)에 호스팅된 Windows VM에서 실행되는 SQL Server Management Studio(SMSS)를 사용하여 연결할 수 있습니다.

이러한 상황에서 Windows 인증을 위해 SQL Server용 Cloud SQL은 Kerberos 프로토콜만 지원합니다. Kerberos 기반 Windows 인증의 경우 클라이언트가 온프레미스 AD 및 관리형 Microsoft AD의 DNS 이름을 확인해야 합니다.

단방향 또는 양방향 트러스트 구성

먼저 단방향 또는 양방향 트러스트 관계 중 무엇을 사용할지 결정합니다.

그런 후 온프레미스 AD 도메인과 관리형 Microsoft AD 도메인 간 트러스트 설정 안내를 따릅니다.

온프레미스 AD 도메인과 관리형 Microsoft AD 도메인 간에 트러스트를 설정한 후 다음 단계를 완료합니다. 예시를 보여주기 위해 이 단계에서는 Google Cloud 프로젝트의 VPC에서 호스팅되고 Windows VM으로 실행되는 SQL Server Management Studio(SSMS)를 사용합니다.

Windows VM을 만듭니다.
- 관리형 Microsoft AD에서 지원되는 Windows 버전으로 VM을 만듭니다.
- 관리형 Microsoft AD 도메인을 호스팅하는 프로젝트에서 VM을 만듭니다. 승인된 네트워크인 공유 VPC가 있는 경우 해당 서비스 프로젝트에서 VM을 만들 수도 있습니다.
- 관리형 Microsoft AD 도메인의 승인된 네트워크이고 Cloud SQL에 대해 비공개 서비스 액세스를 구성한 VPC 네트워크에서 VM을 만듭니다.
Windows VM을 관리형 Microsoft AD 도메인에 연결합니다.
Windows VM에 SSMS를 설치합니다.
VPC 네트워크에서 온프레미스 도메인을 확인합니다.
- Windows VM이 실행되는 승인된 네트워크에서 비관리형 Microsoft AD 객체에 대한 쿼리 확인 페이지의 단계를 수행하여 온프레미스 DNS 변환을 사용 설정합니다. 이 페이지의 단계는 Kerberos 기반 Windows 인증이 온프레미스 사용자에 대해 작동하기 위한 기본 요건입니다.
온프레미스 사용자에 대한 Windows 로그인을 만듭니다.
- CREATE LOGIN 안내에 따라 온프레미스 사용자에 대해 Windows 로그인을 만듭니다. 예를 들어 다음과 비슷한 명령어를 지정합니다.
```
CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
```
온프레미스 사용자를 로그인하기 위한 애플리케이션 특정 안내에 따라 SQL Server용 Cloud SQL 인스턴스에 로그인합니다. 예를 들어 SQL Server Management Studio를 사용하는 경우 이 안내를 참조하세요.

SQL Server용 Cloud SQL 인스턴스에 로그인하는 동안 문제가 발생하면 다음 항목의 확인 작업을 수행하세요.

온프레미스 도메인으로 트러스트 만들기의 안내에 따라 온프레미스 네트워크 및 프로젝트 승인 VPC의 방화벽 구성을 확인합니다.
온프레미스 트러스트 관계에 대해 이름 서픽스 라우팅을 확인합니다.
SSMS를 실행하는 Windows VM에서 이러한 DNS 확인 작업을 수행할 수 있는지 확인합니다.
- nslookup fqdn-for-managed-ad-domain
- nslookup fqdn-for-on-premises-ad-domain
- nslookup fqdn-for-cloud-sql-server-instance

팁

공개 IP를 포함하는 인스턴스는 비공개 IP도 포함하는 경우에만 지원됩니다. 인스턴스에 대해 비공개 IP가 사용 설정되어야 합니다. 그러면 두 항목을 모두 사용할 수 있는 한 공개 IP 또는 비공개 IP를 사용하여 인스턴스에 연결하도록 선택할 수 있습니다.
대체 인스턴스를 포함하여 인스턴스를 만들기 전에 필요에 따라 다음을 검토합니다.
- 비공개 IP 사용 알아보기
- 공개 IP 구성
Terraform이 지원됩니다.
다음 오류 중 하나가 수신될 경우에는 통합 기본 요건을 모두 충족하는지 확인합니다.
- '제품별, 프로젝트별 서비스 계정을 찾을 수 없음'
- 'Microsoft Active Directory용 관리형 서비스 도메인과 통합하는 데 필요한 권한 부족'
'도메인을 찾을 수 없음' 오류가 발생하면 대소문자를 구분하는 도메인 이름이 올바른지 확인합니다.
트러스트 관계를 통해 연결된 도메인에서 Windows 인증이 실패하면 관리형 도메인의 사용자로 Windows 인증이 작동하는지 확인합니다. 이 경우 다음을 수행합니다.
1. DNS 이름을 사용했는지 확인합니다. 트러스트 관계를 사용하여 연결된 도메인에서는 IP 주소가 지원되지 않습니다.
2. 모든 방화벽 포트 열기를 포함하여 온프레미스 도메인으로 트러스트 만들기의 모든 단계를 수행했는지 확인합니다.
3. 트러스트를 검증합니다.
4. 트러스트 방향에 따라 트러스트 관계를 통해 연결된 도메인의 사용자가 관리형 도메인에서 인증을 수행하도록 허용되는지 확인합니다.
5. 트러스트 관계를 통해 연결된 도메인에 이름 서픽스 라우팅이 설정되어 있는지 확인합니다.
6. SQL Server용 Cloud SQL을 사용하지 않고 트러스트가 작동하는지 확인합니다.
  1. Windows VM을 만듭니다.
  2. 관리형 Microsoft AD 도메인에 연결합니다.
  3. 예를 들어 트러스트 관계를 통해 연결된 도메인의 사용자로 메모장 실행을 시도합니다.
7. 클라이언트 VM을 다시 시작하고 Windows 인증을 다시 테스트합니다.
SQL Server 로그인 만들기를 시도할 수 있지만 다음 오류가 발생합니다. 'Windows NT 사용자 또는 그룹 도메인\이름을 찾을 수 없습니다. 이름을 다시 확인하세요.' 이 오류는 도메인 로컬 그룹이 지원되지 않기 때문에 발생했을 수 있습니다. 해당하는 경우 대신 전역 또는 범용 그룹을 사용하세요.
트러스트 관계를 통해 연결된 도메인의 사용자로 실행될 때 SQL Server 쿼리는 다음 오류를 일으킬 수 있습니다. 'Windows NT 그룹/사용자에 대한 정보를 가져올 수 없습니다.' 예를 들어 트러스트 관계를 통해 연결된 도메인의 로그인을 만드는 경우 이 오류가 발생할 수 있습니다. 또한 트러스트 관계를 통해 연결된 도메인의 로그인에 권한을 부여하는 경우에도 이 오류가 발생할 수 있습니다. 이러한 경우 작업을 재시도하면 성공하는 경우가 많습니다. 재시도해도 실패하면 연결을 닫고 새 연결을 엽니다.
'Windows NT 그룹/사용자에 대한 정보를 얻을 수 없습니다' 오류가 발생하면 SQL Server용 Cloud SQL 인스턴스의 Cloud Logging에서 제공되는 로그 파일 active_directory.log를 사용하여 온프레미스 도메인의 네트워크 연결을 확인하세요. 이 파일에는 온프레미스 도메인 연결 변경사항과 관련된 다음 진단이 포함되어 있습니다.

참고: 파일의 타임스탬프는 현지 시간으로 표시됩니다.
- SQL Server용 Cloud SQL 인스턴스에 의해 신뢰할 수 있는 온프레미스 도메인. 예를 들어 다음 로그는 신뢰할 수 있는 도메인 없이 NetBIOS 이름 ONPREM 및 CHILD와 같이 두 개의 새로운 신뢰할 수 있는 도메인으로의 변경사항을 보여줍니다.
```
2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]
```
  온프레미스 도메인이 나열되지 않거나 신뢰할 수 없는 것으로 로깅되었으면 관리형 AD 도메인에 트러스트가 존재하고 검증되었는지 확인합니다. 관리형 AD 도메인과 온프레미스 도메인 간에 단방향 트러스트가 있는 경우 온프레미스 도메인에서 신뢰하는 다른 온프레미스 도메인이 표시되지 않을 수 있습니다.
- SQL Server용 Cloud SQL 인스턴스에서 일반 핑을 사용하여 연결 및 연결할 수 없는 온프레미스 도메인. 예를 들어 다음 로그는 연결 가능한 도메인 없음과 연결 가능한 새 도메인 두 개(onprem.com 및 child.onprem.com)의 변경사항을 보여줍니다.
```
2023-06-12 20:55:10.664 Detected change in reachable onprem domains: Previously reachable onprem domains: []. Current reachable onprem domains: [onprem.com child.onprem.com]
```
  도메인이 연결 가능성 로그에 나열되지 않는 경우 먼저 신뢰할 수 있는 도메인으로 로깅되는지 확인합니다. 그렇지 않으면 연결 가능성을 확인하지 않습니다. 온프레미스 인스턴스와 Google Cloud 프로젝트가 있는 프로젝트 간에는 항상 VPC 피어링이 있습니다. 하나 이상의 VPC 피어링이 있으면 Cloud SQL에서 지원하지 않는 전환 피어링 연결이 발생합니다. 대신 VPN 터널을 사용하여 온프레미스 도메인을 Cloud SQL에 연결하는 것이 좋습니다. SQL Server용 Cloud SQL 인스턴스가 있는 온프레미스 프로젝트와 Google Cloud 프로젝트 간에 최대 한 개의 피어링 연결이 있어야 합니다.
- SQL Server용 Cloud SQL 인스턴스에서 온프레미스 도메인에 대한 Microsoft 리모트 프로시져 콜(MSRPC) 핑의 성공 및 실패. 예를 들어 다음 로그는 MSRPC 핑 가능 도메인이 없는 두 개의 새로운 MSRPC 핑 가능한 도메인(ONPREM 및 CHILD)으로의 변경사항을 보여줍니다.
```
2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]
```
  MSRPC 핑은 추가 진단으로 포함되며 일부 구성에서 작동하지 않을 수 있습니다. 처음 두 가지 진단을 통해 온프레미스 도메인 연결을 계속 확인할 수 있습니다.
SQL Server 쿼리로 '신뢰할 수 없는 도메인의 로그인입니다.' 오류가 발생하면 트러스트 관계를 통해 연결된 도메인의 사용자에 대해 지원되지 않는 IP 주소 때문인지 확인합니다. 또한 다음 작업을 통해 이 문제를 해결할 수도 있습니다.
- 관리형 도메인의 사용자를 연결하기 위해 IP 주소를 사용하는 경우 다음 안내를 참조하세요.
- Google Cloud Console에 이름이 표시되므로 프록시를 사용하지 않고 항상 동일한 DNS 이름을 사용하여 SQL Server용 Cloud SQL에 연결합니다.
- 기존 Kerberos 티켓을 삭제합니다. 최근 SQL Server용 Cloud SQL 인스턴스에 연결된 클라이언트가 있고 인스턴스가 중지되고 시작된 경우 위 오류가 발생할 수 있습니다. 또는 Windows 인증이 사용 중지되었고 SQL Server용 Cloud SQL 인스턴스에 대해 다시 사용 설정된 경우 오류가 발생할 수 있습니다. 클라이언트에 Windows 인증서 캐시가 사용된 경우 클라이언트 워크스테이션을 잠그고 다시 잠금 해제하거나 klist purge를 실행합니다.
Windows 인증을 사용 설정하려고 시도하면 다음 오류가 발생할 수 있습니다. 'Microsoft Active Directory용 관리형 서비스를 지원하려면 이 인스턴스의 생성 날짜가 더 최근이어야 합니다.' 이 오류에 대한 다음 사항에 유의하세요.
- Cloud SQL에서 SQL Server용 Cloud SQL 인스턴스가 2021년 3월 12일(포함) 이전에 생성된 경우에는 관리형 Microsoft AD와 통합될 수 없습니다.
- 경우에 따라 SQL Server용 Cloud SQL 인스턴스를 만들고 관리형 Microsoft AD를 사용 설정하지 않으면 같은 오류가 발생할 수 있습니다. 이 섹션의 다른 팁을 검토한 후 새 인스턴스를 만들어 인스턴스를 만들 때 관리형 Microsoft AD를 사용 설정합니다.
SQL Server용 Cloud SQL 인스턴스를 만들려고 시도하면 다음 오류가 발생할 수 있습니다. '이 인스턴스는 Microsoft Active Directory용 관리형 서비스를 지원하지 않습니다.' 이 오류가 발생하면 프로젝트가 지원되지 않을 수 있습니다. 다른 프로젝트를 사용해보세요.
인스턴스가 최근에 업데이트되었는지 여부에 관계없이 인스턴스에서 Windows 인증 관련 문제가 계속 발생하면 관리형 Active Directory 도메인을 연결 해제한 후 다시 연결해보세요. 이렇게 하려면 업데이트 절차에 따라 도메인을 연결 해제한 후 다시 연결합니다. 이렇게 해도 데이터베이스에 존재하는 기존 Windows 인증 사용자 또는 로그인은 삭제되지 않습니다. 하지만 Windows 인증을 삭제하면 인스턴스가 다시 시작됩니다.
AD 진단 도구를 사용하여 Google Cloud 콘솔에서 온프레미스 도메인 및 SQL Server용 Cloud SQL 인스턴스의 AD 설정 문제 해결

문제 해결

자세한 내용을 보려면 표의 링크를 클릭하세요.

발생 오류	문제 원인	해결 방법
`Per-product, per-project service account not found.`	서비스 계정 이름이 잘못되었습니다.	서비스 계정 페이지에서 올바른 사용자 프로젝트에 대해 서비스 계정을 만들었는지 확인합니다.
`Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain.`	서비스 계정에 `managedidentities.sqlintegrator` 역할이 누락되었습니다.	IAM 및 관리 페이지에서 서비스 계정에 `managedidentities.sqlintegrator` 역할을 추가합니다.
`Domain not found`.	도메인이 존재하지 않거나 잘못 입력되었습니다.	도메인 이름이 올바른지 확인하세요. 대소문자를 구분하며,
`The domain is busy with another operation. Please retry.`	다른 Cloud SQL 인스턴스가 동일한 관리형 Active Directory 도메인에서 작업을 실행하는 중입니다.	작업을 재시도합니다. 동일한 도메인에 연결된 Cloud SQL 인스턴스에 일괄 업데이트를 수행하는 경우 동시에 수행되는 개수를 제한합니다.
`The operation completed but an update to Active Directory failed. You may experience issues with Windows Authentication on this instance, please see https://cloud.google.com/sql/docs/sqlserver/configure-ad for tips`.	필요한 업데이트를 관리형 Active Directory 도메인에서 수행할 수 없습니다.	Windows 인증에 문제가 발생하면 관리형 Active Directory 도메인을 연결 해제한 후 다시 연결하도록 시도할 수 있습니다. 이렇게 하려면 업데이트 절차에 따라 도메인을 연결 해제한 후 다시 연결합니다. 이렇게 해도 데이터베이스에 존재하는 기존 Windows 인증 사용자 또는 로그인은 삭제되지 않습니다. 하지만 Windows 인증을 삭제하면 인스턴스가 다시 시작됩니다.
`This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory.`	Cloud SQL에서 SQL Server용 Cloud SQL 인스턴스가 2021년 3월 12일(포함) 이전에 생성된 경우에는 관리형 Microsoft AD와 통합될 수 없습니다.	2021년 3월 12일 이후 생성된 인스턴스에서 작업을 시도해보세요.

다음 단계

제한 및 지원되지 않는 기능이 포함된 개요 페이지를 자세히 검토했는지 확인합니다. 이 페이지에는 추가 문서에 대한 링크도 포함되어 있습니다.

Cloud SQL에 관리형 Microsoft AD 사용

시작하기 전에

Windows 인증을 사용하여 인스턴스 만들기

Console

gcloud

Terraform

REST

Windows 인증으로 인스턴스 업데이트

Console

gcloud

REST

다른 프로젝트의 관리형 AD 도메인과 통합

도메인 피어링 사용 설정

서비스 계정 만들기

프로젝트 간 Windows 인증 사용 설정

다른 프로젝트와의 통합을 위한 제약조건

인스턴스에서 Windows 인증 삭제

Console

gcloud

REST

사용자로 인스턴스에 연결

Windows 인증으로 Cloud SQL 인증 프록시 사용

Windows 인증 단계

로컬로 Cloud SQL 인증 프록시 실행

로컬이 아닌 방식으로 Cloud SQL 인증 프록시 실행

클라이언트의 NTLM 대체 문제 해결

Windows 클라이언트의 NTLM 대체 확인

Linux 클라이언트의 NTLM 대체 확인

Kerberos 인증 설정

Windows 인증 연결

NTLM 대체 이유

온프레미스 AD 사용자: Windows 로그인 만들기

단방향 또는 양방향 트러스트 구성

Windows VM 설정 및 Windows 로그인 만들기

온프레미스 AD 사용자 관련 문제 해결

팁

문제 해결

다음 단계