VM が自動的にドメインに参加するように Active Directory を構成する

Last reviewed 2024-08-08 UTC

このドキュメントでは、Windows 仮想マシン（VM）インスタンスが Active Directory ドメインに自動的に参加できるように、Active Directory と Compute Engine を構成する方法について説明します。

Windows VM を Active Directory に参加させるプロセスを自動化すると、Windows サーバーのプロビジョニングプロセスを簡略化できます。この方法により、Active Directory を使用してアクセスと構成を管理するメリットを損なうことなく、自動スケーリングを活用することも可能になります。

このドキュメントはシステム管理者を対象としており、Active Directory と Google Cloud ネットワーキングについて理解していることを前提としています。

このドキュメントの手順に沿って作成する構成は、Google Cloud 内で Windows Server で行う追加の作業の基礎になります。たとえば、この手順を完了すると、Windows コンテナで Windows 認証を使用して ASP.NET アプリケーションをデプロイできます。

Managed Microsoft AD を使用していて、古いコンピュータアカウントの自動クリーンアップを必要としない場合は、自動化されたドメイン参加機能を使用して Windows VM に参加することを検討してください。詳細については、Windows VM をドメインに自動的に参加させるをご覧ください。

目標

選択したプロジェクトの VM インスタンスを Active Directory ドメインに自動的に参加させる Cloud Run アプリをデプロイする。
Cloud Scheduler ジョブを作成して Active Directory ドメインを定期的にスキャンし、古いコンピュータアカウントを検出して削除する。
ドメインに参加している VM インスタンスに自動スケーリングのマネージドインスタンスグループ（MIG）を作成して、設定をテストする。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

このドキュメントの手順は、リソース使用量が Google Cloud の無料枠ティアの制限内に収まるように設計されています。料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントの完了後に作成したリソースを削除すれば、今後課金は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

このドキュメントでは、Managed Service for Microsoft Active Directory（Managed Microsoft AD）を使用するか、Google Cloud 上にセルフマネージドドメインコントローラをデプロイして、Google Cloud に Active Directory がすでにデプロイされていることを前提としています。

手順を完了するには、次のものが必要です。

ユーザー、グループ、組織単位（OU）の作成権限を含む Active Directory ドメインの管理者権限。
Active Directory ドメインコントローラがデプロイされている VPC 内で未使用の /28 CIDR IP 範囲。この IP 範囲を使用して、サーバーレス VPC アクセスを構成します。
Windows インスタンスをデプロイする 1 つのサブネット。サブネットは、限定公開の Google アクセスを使用するように構成する必要があります。

セルフマネージドドメインコントローラを使用する場合は、次のものも必要です。

DNS クエリを Active Directory ドメインコントローラに転送する限定公開 DNS 転送ゾーン。

この手法の実装

オンプレミス環境で新たなコンピュータを自動的にドメインに参加させるには、応答ファイル（unattend.xml）および JoinDomain カスタマイズを使用できます。Google Cloud でも同じ方式を使用できますが、次のような制限があります。

カスタマイズした unattend.xml ファイルを使用するには、カスタムの Compute Engine イメージを保持する必要があります。Windows Updates を使用してカスタムイメージを最新の状態に保つには、メンテナンスの継続または最初に自動化を設定する作業が必要になります。他の理由によりカスタムイメージを保持する必要がない場合は、この追加作業は不要です。
JoinDomain カスタマイズを使用すると、unattend.xml にドメイン名を指定する必要があるため、1 つのイメージは 1 つの Active Directory ドメインに結び付けられます。複数の Active Directory ドメインやフォレスト（独立したテスト環境や本番環境など）を維持する場合は、ドメインごとに複数のカスタムイメージを保持する必要があります。
Windows コンピュータをドメインに参加させるには、ディレクトリにコンピュータオブジェクトを作成する権限を持つユーザーの認証情報が必要です。unattend.xml で JoinDomain カスタマイズを使用する場合、これらの認証情報を unattend.xml に平文で埋め込む必要があります。このように認証情報を埋め込むことで、イメージが攻撃者の標的になる危険性が生じます。適切な Identity and Access Management（IAM）権限を設定することでイメージへのアクセスを制御できますが、カスタムイメージへのアクセスを管理すると、不必要に複雑になります。

このドキュメントで説明する手法では、応答ファイルを使用しないため、特別に準備されたイメージは必要ありません。代わりに、VM インスタンスの作成時に次の Sysprep specialize スクリプレットを使用します。

iex((New-Object System.Net.WebClient).DownloadString('https://DOMAIN'))

Sysprep の specialize スクリプレットにより、次の図に示すプロセスが開始されます。

Sysprep の specialize スクリプレットが開始するプロセス。

このプロセスは次のように動作します。

VM インスタンスが作成された後、Windows が初めて起動します。specialize 構成パスの一部として、Windows が Sysprep の specialize スクリプレットを実行します。specialize スクリプレットにより register-computer Cloud Run アプリが起動され、ドメイン参加プロセスを制御する PowerShell スクリプトがダウンロードされます。
Windows が、ダウンロードされた PowerShell スクリプトを呼び出します。
PowerShell スクリプトはメタデータサーバーを呼び出し、VM インスタンスを安全に識別する ID トークンを取得します。
このスクリプトは register-computer アプリを再度呼び出し、ID トークンを渡して認証を行います。
このアプリで ID トークンを検証し、VM インスタンスの名前、ゾーン、Google Cloud プロジェクト ID を抽出します。
このアプリで、指定されたプロジェクトの VM インスタンスによるドメイン参加を許可するように Active Directory ドメインが構成されていることを確認します。この検証を完了するため、アプリは Active Directory ドメインコントローラを検索して接続し、名前が ID トークンの Google Cloud プロジェクト ID と一致する組織部門（OU）を探します。一致する OU が見つかった場合、プロジェクトの VM インスタンスは、指定された OU の Active Directory ドメインに参加する権限が与えられていることになります。
VM インスタンスが Active Directory に参加できるよう、Google Cloud プロジェクトが構成されていることを確認します。この検証を完了するために、アプリは Compute Engine API を使用して VM インスタンスにアクセスできるかどうかを確認します。
すべての確認が正常に終わると、アプリは Active Directory にコンピュータアカウントを事前ステージングします。このアプリは、コンピュータアカウントが VM インスタンスに関連付けられるように、VM インスタンスの名前、ゾーン、ID を属性としてコンピュータアカウントオブジェクトに保存します。
次に、Kerberos パスワード設定プロトコルを使用して、ランダムなパスワードをコンピュータアカウントに割り当てます。
コンピュータ名とパスワードが、TLS で保護されたチャネルを介して Windows インスタンスに返されます。
事前ステージングのコンピュータアカウントを使用して、PowerShell スクリプトがコンピュータをドメインに参加させます。
specialize 構成パスが完了すると、マシンが再起動します。

この手順の残りの部分では、自動化されたドメイン参加の設定に必要な手順について説明します。

Active Directory ドメインの準備

まず、Active Directory ドメインを用意します。この手順を最後まで進めるには、Active Directory ドメインに対して管理者権限を持つマシンが必要です。

省略可: コンピュータをドメインに追加できるユーザーを制限する

コンピュータをドメインに参加させられるユーザーを制限できます。デフォルトでは、Default Domain Controller Policy 用のグループポリシーオブジェクト（GPO）構成により、認証済みユーザーすべてに Add workstations to domain ユーザー権限が付与されています。このユーザー権限を持つユーザーであれば、コンピュータをドメインに参加させることができます。コンピュータを Active Directory ドメインに参加させるプロセスを自動化しているため、このレベルのアクセス権を広く付与することは、不必要にセキュリティリスクを高めることになります。

コンピュータを Active Directory ドメインに参加させることが可能なユーザーを制限するには、Default Domain Controller Policy GPO のデフォルトの構成を変更します。

RDP クライアントを使用して、Active Directory ドメインに対する管理者権限があるマシンにログインします。
グループポリシー管理コンソール（GPMC）を開きます。
[フォレスト] > [ドメイン] > [domain-name] > [グループポリシーオブジェクト] に移動します。ここで domain-name は Active Directory ドメインの名前です。
[既定のドメインコントローラポリシー] を右クリックし、[編集] をクリックします。
グループポリシー管理エディタ画面で、[コンピュータの構成] > [ポリシー] > [Windows の設定] > [セキュリティの設定] > [ローカルポリシー] > [ユーザー権利の割り当て] に移動します。
[ドメインにワークステーションを追加] をダブルクリックします。
[プロパティ] で、リストから [認証済みユーザー] を削除します。
（省略可）管理者が手動でドメインに参加できるようにするには、[Add user or group] をクリックし、リストに管理グループを追加します。
[OK] をクリックします。

グループポリシー管理エディタ画面と GPMC を閉じます。

ディレクトリ構造を初期化する

次に、プロジェクト固有の OU にコンテナとして機能する OU を作成します。

RDP クライアントを使用して、Active Directory ドメインに対する管理者権限があるマシンにログインします。
昇格した PowerShell セッションを開きます。

新しい組織部門を作成するには:

$ParentOrgUnitPath = (Get-ADDomain).ComputersContainer
$ProjectsOrgUnitPath = New-ADOrganizationalUnit `
  -Name 'Projects' `
  -Path $ParentOrgUnitPath `
  -PassThru

Active Directory ユーザーアカウントを作成する

Active Directory と事前ステージングのコンピュータアカウントにアクセスするには、register-computer アプリに Active Directory ユーザーアカウントが必要です。

register-computer という名前の Active Directory ユーザーアカウントを作成し、ランダムなパスワードを割り当てて、Projects OU に配置します。

# Generate a random password
$Password = [Guid]::NewGuid().ToString()+"-"+[Guid]::NewGuid().ToString()

# Create user
$UpnSuffix = (Get-ADDomain).DNSRoot
$RegisterComputerUser = New-ADUser `
    -Name "register-computer Cloud Run app" `
    -GivenName "Register" `
    -Surname "Computer" `
    -Path $ProjectsOrgUnitPath `
    -SamAccountName "register-computer" `
    -UserPrincipalName "register-computer@$UpnSuffix" `
    -AccountPassword (ConvertTo-SecureString "$Password" -AsPlainText -Force) `
    -PasswordNeverExpires $True `
    -Enabled $True `
    -PassThru

register-computer アカウントに、Projects OU とサブ OU にあるコンピュータアカウントとグループの管理に必要な一連の最小限の権限を付与します。

$AcesForContainerAndDescendents = @(
    "CCDC;Computer",               # Create/delete computers
    "CCDC;Group"                   # Create/delete users
)

$AcesForDescendents = @(
    "LC;;Computer" ,               # List child objects
    "RC;;Computer" ,               # Read security information
    "WD;;Computer" ,               # Change security information
    "WP;;Computer" ,               # Write properties
    "RP;;Computer" ,               # Read properties
    "CA;Reset Password;Computer",  # ...
    "CA;Change Password;Computer", # ...
    "WS;Validated write to service principal name;Computer",
    "WS;Validated write to DNS host name;Computer",

    "LC;;Group",                   # List child objects
    "RC;;Group",                   # Read security information
    "WD;;Group",                   # Change security information
    "WP;;Group",                   # Write properties
    "RP;;Group"                    # Read properties
)

$AcesForContainerAndDescendents | % { dsacls.exe $ProjectsOrgUnitPath /G "${RegisterComputerUser}:${_}" /I:T | Out-Null }
$AcesForDescendents | % { dsacls.exe $ProjectsOrgUnitPath /G "${RegisterComputerUser}:${_}" /I:S | Out-Null }

このコマンドが完了するまで数分かかる場合があります。

register-computer Active Directory ユーザーアカウントの Projects OU パスと生成されたパスワードを表示します。後で必要になるため、値をメモします。
```
Write-Host "Password: $Password"
Write-Host "Projects OU: $ProjectsOrgUnitPath"
```

Google Cloud プロジェクトの準備

次に、ドメインプロジェクトを構成します。

Managed Microsoft AD を使用する場合、ドメインプロジェクトは Managed Microsoft AD をデプロイしたプロジェクトになります。
セルフマネージド Active Directory を使用する場合、ドメインプロジェクトは Active Directory ドメインコントローラを実行するプロジェクトになります。共有 VPC の場合、このプロジェクトは VPC ホストプロジェクトと同一である必要があります。

このドメインプロジェクトを使用して、次のことを行います。

register-computer Active Directory ユーザーアカウントのパスワードを含む Secret Manager シークレットを作成します。
サーバーレス VPC アクセスをデプロイして、Cloud Run が Active Directory にアクセスできるようにします。
register-computer アプリをデプロイします。
使用されていないコンピュータアカウントのクリーンアップを開始するように、Cloud Scheduler を構成します。

最小権限の基本としてドメインプロジェクトへのアクセス権を付与することをおすすめします。

Secret Manager のシークレットを作成する

Google Cloud Console で Cloud Shell を開きます。

Cloud Shell を開く
PowerShell を起動します。
```
pwsh
```
次の変数を初期化します。domain-project-id は、ドメインプロジェクトの ID で置き換えます。
```
$DomainProjectId = "domain-project-id"
```
ドメインプロジェクトをデフォルトプロジェクトとして設定します。
```
& gcloud config set project $DomainProjectId
```

Secret Manager API を有効にします。

& gcloud services enable secretmanager.googleapis.com

register-computer Active Directory ユーザーアカウントのパスワードを入力し、Secret Manager のシークレットに保存します。

$RegisterComputerCredential = (Get-Credential -Credential 'register-computer')

$TempFile = New-TemporaryFile
Set-Content $TempFile $($RegisterComputerCredential.GetNetworkCredential().Password) -NoNewLine

& gcloud secrets create ad-password --data-file $TempFile

Remove-Item $TempFile

サーバーレス VPC アクセスをデプロイする

register-computer アプリは、Active Directory ドメインコントローラと通信する必要があります。Cloud Run が VPC 内のリソースにアクセスできるように、サーバーレス VPC アクセスを構成します。

次の変数を初期化します。
```
$VpcName = "vpc-name"
$ServerlessRegion = "serverless-region"
$ServerlessIpRange = "serverless-ip-range"
```
次のように置き換えます。
- vpc-name: Active Directory ドメインコントローラを含む VPC ネットワークの名前。
- serverless-region: Cloud Run をデプロイするリージョン。Cloud Run とサーバーレス VPC アクセスの両方をサポートするリージョンを選択してください。ここで選択するリージョンは、VM インスタンスをデプロイするリージョンと同じにする必要はありません。
- serverless-ip-range: VPC 内での Cloud Run とリソース間の通信で、サーバーレス VPC アクセスによって使用されます。予約されていない /28 CIDR IP 範囲に設定します。VPC ネットワーク内の、既存のサブネットと重複しないようにする必要があります。
  
  注: 正確な /28 のサイズの CIDR IP 範囲を使用します。異なるサイズは使用できません。

Serverless VPC Access API を有効にします。

& gcloud services enable vpcaccess.googleapis.com

サーバーレス VPC アクセスをデプロイします。

& gcloud compute networks vpc-access connectors create serverless-connector `
    --network $VpcName `
    --region $ServerlessRegion `
    --range $ServerlessIpRange

Kerberos と LDAP へのアクセス権を付与する

サーバーレス VPC アクセスにより、Cloud Run が VPC 内のリソースにアクセスできるようになりますが、ドメインコントローラの Kerberos エンドポイントと LDAP エンドポイントへの接続には引き続きファイアウォールルールが適用されます。

LDAP（TCP/389）、LDAPS（TCP/636）、Kerberos（UDP/88、TCP/88）、または Kerberos パスワード変更（UDP/464、TCP/464）を使用して、サーバーレスリソースにドメインコントローラへのアクセスを許可するファイアウォールルールを作成する必要があります。ドメインコントローラに割り当てたネットワークタグに基づいてルールを適用するか、サービスアカウントを使用してルールを適用できます。

ファイアウォールルールを適用するには、Cloud Shell で次のいずれかのコマンドを実行します。
ネットワークタグを使用
```
& gcloud compute firewall-rules create allow-adkrb-from-serverless-to-dc `
    --direction INGRESS `
    --action allow `
    --rules udp:88,tcp:88,tcp:389,tcp:636,udp:464,tcp:464 `
    --source-ranges $ServerlessIpRange `
    --target-tags dc-tag `
    --network $VpcName `
    --project vpc-project-id `
    --priority 10000
```
次のように置き換えます。
- dc-tag: ドメインコントローラ VM に割り当てられたネットワークタグ。
- vpc-project-id: VPC が定義されているプロジェクトの ID。共有 VPC を使用する場合は、VPC ホストプロジェクトを使用します。それ以外の場合は、ドメインプロジェクトの ID を使用します。
サービスアカウントを使用
```
& gcloud compute firewall-rules create allow-adkrb-from-serverless-to-dc `
    --direction INGRESS `
    --action allow `
    --rules udp:88,tcp:88,tcp:389,tcp:636,udp:464,tcp:464 `
    --source-ranges $ServerlessIpRange `
    --target-service-accounts dc-sa `
    --network $VpcName `
    --project vpc-project-id `
    --priority 10000
```
次のように置き換えます。
- dc-sa: ドメインコントローラ VM が使用するサービスアカウントのメールアドレス。
- vpc-project-id: VPC が定義されているプロジェクトの ID。共有 VPC を使用する場合は、VPC ホストプロジェクトを使用します。それ以外の場合は、ドメインプロジェクトの ID を使用します。

Cloud Run アプリをデプロイする

次に、register-computer アプリを Cloud Run にデプロイするように Cloud Build を設定します。

Cloud Shell で GitHub リポジトリのクローンを作成します。

& git clone https://github.com/GoogleCloudPlatform/gce-automated-ad-join.git
cd gce-automated-ad-join/ad-joining

次の変数を初期化します。
```
$AdDomain = "dns-domain-name"
$AdNetbiosDomain = "netbios-domain-name"
$ProjectsOrgUnitPath = "projects-ou-distinguished-name"
```
次のように置き換えます。
- dns-domain-name: Active Directory ドメインの DNS ドメイン名。
- netbios-domain-name: Active Directory ドメインの NetBIOS 名。
- projects-ou-distinguished-name: Projects OU の識別名。

Cloud Run と Cloud Build API を有効にします。

& gcloud services enable run.googleapis.com cloudbuild.googleapis.com

Cloud Run アプリにサービスアカウント register-computer-app を作成します。

& gcloud iam service-accounts create register-computer-app `
  --display-name="register computer Cloud Run app"

Cloud Build トリガーを実行するサービスアカウント build-service を作成します。
```
& gcloud iam service-accounts create build-service `
  --display-name="Cloud Build build agent"
```

Cloud Run サービスアカウントに、Active Directory のパスワードを含むシークレットの読み取りを許可します。

& gcloud secrets add-iam-policy-binding ad-password `
  --member "serviceAccount:register-computer-app@$DomainProjectId.iam.gserviceaccount.com" `
  --role "roles/secretmanager.secretAccessor"

Cloud Run へのデプロイに必要な権限を Cloud Build に付与します。

$DomainProjectNumber = (gcloud projects describe $DomainProjectId --format='value(projectNumber)')
& gcloud iam service-accounts add-iam-policy-binding register-computer-app@$DomainProjectId.iam.gserviceaccount.com `
  --member "serviceAccount:build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --role "roles/iam.serviceAccountUser"

& gcloud projects add-iam-policy-binding $DomainProjectId `
  --member "serviceAccount:build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --role roles/cloudbuild.builds.builder

& gcloud projects add-iam-policy-binding $DomainProjectId `
  --member "serviceAccount:build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --role roles/run.admin

cloudbuild.yaml ファイルをテンプレートとして使用して、環境に合ったカスタム Cloud Run ビルド構成を作成します。
```
$Build = (Get-Content cloudbuild.yaml)
$Build = $Build.Replace('__SERVERLESS_REGION__', "$ServerlessRegion")
$Build = $Build.Replace('__PROJECTS_DN__', "$ProjectsOrgUnitPath")
$Build = $Build.Replace('__AD_DOMAIN__', "$AdDomain")
$Build = $Build.Replace('__AD_NETBIOS_DOMAIN__', "$AdNetbiosDomain")
$Build = $Build.Replace('__SERVICE_ACCOUNT_EMAIL__', "register-computer-app@$DomainProjectId.iam.gserviceaccount.com")
$Build | Set-Content .\cloudbuild.hydrated.yaml
```
注: アプリでは、LDAP ではなく LDAPS を使用するなど、追加構成設定が可能です。詳しくは、アプリの README.md ファイルをご覧ください。追加の構成を適用するには、cloudbuild.yaml ファイルを編集して、必要な環境変数を cloud-sdk ステップの引数に追加します。

アプリをビルドして Cloud Run にデプロイします。

& gcloud builds submit . `
  --config cloudbuild.hydrated.yaml `
  --substitutions _IMAGE_TAG=$(git rev-parse --short HEAD) `
  --service-account "projects/$DomainProjectId/serviceAccounts/build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --default-buckets-behavior regional-user-owned-bucket

デプロイの完了には、数分かかることがあります。

Cloud Run アプリの URL を確認します。
```
$RegisterUrl = (gcloud run services describe register-computer `
  --platform managed `
  --region $ServerlessRegion `
  --format=value`(status.url`))
Write-Host $RegisterUrl
```
URL をメモします。このファイルは、Active Directory に参加させる VM インスタンスを作成するときに常に必要です。
Cloud Run アプリを呼び出して、デプロイが成功したことを確認します。
```
Invoke-RestMethod $RegisterUrl
```
PowerShell スクリプトが表示されます。このスクリプトは、ドメインに VM を参加させる specialize フェーズで VM によって実行されます。

プロジェクトの自動ドメイン参加を有効にする

VM のプロジェクトでドメインの自動参加が有効になっていない場合、register-computer アプリは VM インスタンスを Active Directory ドメインに参加させることはできません。このセキュリティ対策により、未承認のプロジェクトに接続されている VM がドメインにアクセスすることを防ぎます。

プロジェクトの自動ドメイン参加を有効にするには、次のことを行う必要があります。

Active Directory に、Google Cloud プロジェクト ID と名前が一致する組織単位を作成する。
register-computer アプリに Google Cloud プロジェクトへのアクセスを許可します。

まず、次の手順で OU を作成します。

RDP クライアントを使用して、Active Directory ドメインに対する管理者権限があるマシンにログインします。
MMC の [Active Directory ユーザーとコンピュータ] スナップインで、Projects OU に移動します。
OU を右クリックし、[新規作成] > [組織単位] を選択します。
[新しいオブジェクト] ダイアログで、VM をデプロイする Google Cloud プロジェクトの ID を入力します。
[OK] をクリックします。

次に、register-computer アプリに Google Cloud プロジェクトへのアクセスを許可します。

Cloud Shell で PowerShell を起動します。
```
pwsh
```
次の変数を初期化します。
```
$ProjectId = "project-id"
$DomainProjectId = "domain-project-id"
```
次のように置き換えます。
- project-id は、VM をデプロイする Google Cloud プロジェクトの ID で置き換えます。
- domain-project-id は、ドメインプロジェクトの ID に置き換えます。

register-computer-app サービスアカウントにプロジェクトの Compute Viewer ロールを付与します。

& gcloud projects add-iam-policy-binding $ProjectId `
    --member "serviceAccount:register-computer-app@$DomainProjectId.iam.gserviceaccount.com" `
    --role "roles/compute.viewer"

これで、プロジェクトでドメインの自動参加をサポートする準備が整いました。

ドメイン参加のテスト

次の方法で、設定が正しく機能していることを確認できます。

Active Directory ドメインを自動的に参加させる単一の VM インスタンスを作成する
Active Directory ドメインに自動的に参加する VM インスタンスのマネージドインスタンスグループを作成する

単一の VM インスタンスを作成して参加させる

Active Directory ドメインを自動的に参加させる VM インスタンスを作成します。

Cloud Shell の PowerShell セッションに戻り、次の変数を初期化します。
```
$Region = "vpc-region-to-deploy-vm"
$Zone = "zone-to-deploy-vm"
$Subnet = "vpc-subnet-to-deploy-vm"
$ServerlessRegion = "serverless-region"
```
次のように置き換えます。
- vpc-region-to-deploy-vm: VM インスタンスをデプロイするリージョン。
- vpc-subnet-to-deploy-vm: VM インスタンスをデプロイするサブネット。
- zone-to-deploy-vm: VM インスタンスをデプロイするゾーン。
- serverless-region: Cloud Run アプリをデプロイしたリージョン。

デフォルトのプロジェクトとゾーンを設定します。

& gcloud config set project $ProjectId
& gcloud config set compute/zone $Zone

Cloud Run アプリの URL を再度検索します。

$RegisterUrl = (gcloud run services describe register-computer `
  --platform managed `
  --region $ServerlessRegion `
  --format value`(status.url`) `
  --project $DomainProjectId)

VM をドメインに参加させる specialize スクリプレットを渡すことにより、インスタンスを作成します。
共有 VPC
```
$VpchostProjectId = (gcloud compute shared-vpc get-host-project $ProjectId --format=value`(name`))
& gcloud compute instances create join-01 `
    --image-family windows-2019-core `
    --image-project windows-cloud `
    --machine-type n1-standard-2 `
    --no-address `
    --subnet projects/$VpchostProjectId/regions/$Region/subnetworks/$Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"
```
スタンドアロン VPC
```
& gcloud compute instances create join-01 `
    --image-family=windows-2019-core `
    --image-project=windows-cloud `
    --machine-type=n1-standard-2 `
    --no-address `
    --subnet $Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"
```
カスタムホスト名を使用する場合は、コマンドに --hostname パラメータを追加します。

Windows Server 2019 より前のバージョンの Windows Server を使用すると、TLS 1.2 がデフォルトで無効になる場合があります。その場合、specialize スクリプレットは失敗します。TLS 1.2 を有効にするには、代わりに次のスクリプトレットを使用します。
```
[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))
```
注: NetBIOS がサポートするコンピュータ名は最大 15 文字です。VM インスタンスのホスト名がこの最大長を超えた場合、specialize スクリプレットは、コンピュータ名を一意の名前（最大 15 文字）に自動的に変更します。

VM インスタンスを追加作成する場合は、インスタンス名がこの文字数制限を超えないようにしてください。制限を超えると、VM インスタンスのドメイン参加が失敗する可能性が高くなります。

起動プロセスをモニタリングします。

& gcloud compute instances tail-serial-port-output join-01

約 1 分後に、マシンが Active Directory ドメインに参加します。出力は次のようになります。

Domain           : corp.example.com
DomainController : dc-01.corp.example.com.
OrgUnitPath      : OU=test-project-123,OU=Projects,DC=corp,DC=example,DC=com

WARNING: The changes will take effect after you restart the computer

Computer successfully joined to domain

起動プロセスの監視を停止するには、CTRL+C を押します。

VM が Active Directory に参加していることを確認する

RDP クライアントを使用して、Active Directory ドメインに対する管理者権限があるマシンにログインします。
MMC の [Active Directory ユーザーとコンピュータ] スナップインを開きます。
メニューで [表示] > [高度な機能] が有効なことを確認します。
VM インスタンスを作成した Google Cloud プロジェクト ID から付けた名前の OU に移動します。
join-01 アカウントをダブルクリックします。

[プロパティ] ダイアログで、[属性エディター] タブをクリックします。

コンピュータアカウントに、追加の LDAP 属性のアノテーションが付けられます。これらの属性を使用すると、コンピュータオブジェクトと Compute Engine インスタンス間のひも付けを追跡できます。

リストに次の LDAP 属性と値が含まれていることを確認します。

LDAP 属性	値
`msDS-cloudExtensionAttribute1`	Google Cloud プロジェクト ID
`msDS-cloudExtensionAttribute2`	Compute Engine ゾーン
`msDS-cloudExtensionAttribute3`	Compute Engine インスタンス名

msDS-cloudExtensionAttribute 属性は汎用属性であり、Active Directory 自体では使用されません。

エラーを診断する

VM インスタンスがドメインに参加できなかった場合は、register-computer アプリのログを確認します。

Google Cloud コンソールで、[Cloud Run] に移動します。

Cloud Run に移動します。
register-computer アプリをクリックします。
メニューで [ログ] をクリックします。

インスタンスの削除

VM インスタンスが Active Directory ドメインに参加していることを確認したら、インスタンスを削除します。

インスタンスを削除します。

& gcloud compute instances delete join-01 --quiet

マネージドインスタンスグループを作成して参加させる

MIG のインスタンスがドメインに自動的に参加できることも確認できます。

VM をドメインに参加させる specialize スクリプレットを渡すことにより、インスタンステンプレートを作成します。

共有 VPC

$VpchostProjectId = (gcloud compute shared-vpc get-host-project $ProjectId --format=value`(name`))
& gcloud compute instance-templates create ad-2019core-n1-std-2 `
    --image-family windows-2019-core `
    --image-project windows-cloud `
    --no-address `
    --machine-type n1-standard-2 `
    --subnet projects/$VpchostProjectId/regions/$Region/subnetworks/$Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"

スタンドアロン VPC

& gcloud compute instance-templates create ad-2019core-n1-std-2 `
    --image-family windows-2019-core `
    --image-project windows-cloud `
    --no-address `
    --machine-type n1-standard-2 `
    --subnet projects/$ProjectId/regions/$Region/subnetworks/$Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"

このインスタンステンプレートを使用するマネージドインスタンスグループを作成します。
```
& gcloud compute instance-groups managed create group-01 `
    --template ad-2019core-n1-std-2 `
    --size=3
```

数分待ち、MMC の [Active Directory ユーザーとコンピュータ] スナップインを使用して、Active Directory に 4 つの新しいオブジェクトが作成されたことを確認します。

3 つのコンピュータアカウント（マネージドインスタンスグループの 3 つの VM インスタンス）。
3 つのコンピュータアカウントを含む group-01 グループ。グループマネージドサービスアカウント（gMSA）を使用する場合は、このグループを使用して gMSA へのアクセス権を付与できます。

MIG の VM インスタンスが Active Directory ドメインに参加できることを確認したら、次の手順でマネージドグループとインスタンステンプレートを削除できます。

Cloud Shell で、インスタンスグループを削除します。
```
& gcloud compute instance-groups managed delete group-01 --quiet
```

インスタンステンプレートを削除します。

& gcloud compute instance-templates delete ad-2019core-n1-std-2 --quiet

使われていないコンピュータアカウントのクリーンアップのスケジューリング

コンピュータをドメインに参加させるプロセスを自動化することで、新しいサーバーを設定する手間が軽減され、マネージドインスタンスグループでドメイン参加済みのサーバーを使用できるようになります。ただし、時間の経過とともに使われなくなったコンピュータアカウントがドメインに蓄積される可能性があります。

この蓄積を防ぐには、Active Directory ドメインを定期的にスキャンするように register-computer アプリを設定します。これによって、使われていないアカウントを探して自動的に削除できます。

register-computer アプリは、コンピュータアカウントの msDS-cloudExtensionAttribute 属性を使用して、使われていないコンピュータアカウントを特定します。これらの属性には、Compute Engine の対応する VM インスタンスのプロジェクト、ゾーン、インスタンス名が含まれます。各コンピュータアカウントに対し、対応する VM インスタンスがまだあるかどうかをアプリで確認できます。VM インスタンスがない場合、そのコンピュータアカウントは使われていないとみなされ、削除されます。

コンピュータアカウントのクリーンアップをトリガーするには、Cloud Run アプリの /cleanup エンドポイントを呼び出します。未承認のユーザーがクリーンアップをトリガーできないように、このリクエストは register-computer-app サービスアカウントを使用して認証する必要があります。

Cloud Scheduler を構成する

次の手順では、Cloud Scheduler を Pub/Sub と組み合わせて、24 時間ごとに自動的にクリーンアップをトリガーする方法を説明します。

Cloud Shell で、ドメインプロジェクトの Cloud Scheduler API を有効にします。
```
& gcloud services enable cloudscheduler.googleapis.com
```
AppEngineLocation を、Cloud Scheduler をデプロイする有効な App Engine のロケーションに設定します。
```
$AppEngineLocation = "location"
```
location は、VPC リソース用に選択した App Engine リージョン（us-central など）に置き換えます。そのリージョンが App Engine のロケーションとして利用できない場合は、地理的に近いロケーションを選択します。詳細については、リージョンとゾーンをご覧ください。

App Engine を初期化します。

& gcloud app create --region $AppEngineLocation --project $DomainProjectId

Cloud Scheduler のジョブを作成します。

& gcloud scheduler jobs create http cleanup-computer-accounts `
    --schedule "every 24 hours" `
    --uri "$RegisterUrl/cleanup" `
    --oidc-service-account-email register-computer-app@$DomainProjectId.iam.gserviceaccount.com `
    --oidc-token-audience "$RegisterUrl/" `
    --project $DomainProjectId

このジョブは 24 時間に 1 回 register-computer アプリを呼び出し、認証に register-computer-app サービスアカウントを使用します。

クリーンアップをトリガーする

使われていないコンピュータアカウントをクリーンアップするための構成を確認するには、Cloud Scheduler ジョブを手動で起動します。

Google Cloud コンソールで、[Cloud Scheduler] に移動します。

Cloud Scheduler に移動
作成した cleanup-computer-accounts ジョブの [今すぐ実行] をクリックします。

数秒後、[結果] の列に [成功] と表示されると、クリーンアップが正常に完了したことになります。数秒以内に [結果] の列が自動で更新されない場合は、[更新] ボタンをクリックします。

クリーンアップされたアカウントの詳細については、register-computer アプリのログを確認してください。

Google Cloud コンソールで、[Cloud Run] に移動します。

Cloud Run に移動します。
register-computer アプリをクリックします。
メニューで [ログ] をクリックします。

ドメインへの参加をテストするために使用した VM インスタンスのコンピュータアカウントが使われなくなったと判断され、削除されたことが、ログエントリに示されます。

クリーンアップ

このドキュメントを他のリファレンスアーキテクチャとデプロイのベースラインとして使用する場合は、クリーンアップ手順を実施するタイミングに関する他のドキュメントをご覧ください。

このドキュメントで使用した Google Cloud の設定を保持しない場合は、次の手順で元に戻すことができます。

Cloud Shell で、Cloud Scheduler ジョブを削除します。

& gcloud scheduler jobs delete cleanup-computer-accounts `
  --project $DomainProjectId

Cloud Run アプリを削除します。

& gcloud run services delete register-computer `
  --platform managed `
  --project $DomainProjectId `
  --region $ServerlessRegion

Secret Manager シークレットを削除します。

gcloud secrets delete ad-password --project $DomainProjectId

LDAP と Kerberos のアクセスに対するファイアウォールルールを削除します。
```
gcloud compute firewall-rules delete allow-adkrb-from-serverless-to-dc --project=vpc-project-id
```
vpc-project-id は、VPC が定義されているプロジェクトの ID に置き換えます。共有 VPC を使用する場合は、VPC ホストプロジェクトを使用します。それ以外の場合は、ドメインプロジェクトの ID を使用します。

サーバーレス VPC アクセスを削除します。

gcloud compute networks vpc-access connectors delete serverless-connector --region $ServerlessRegion --quiet

Active Directory の変更を元に戻す

RDP クライアントを使用して、Active Directory ドメインに対する管理者権限があるマシンにログインします。
MMC の [Active Directory ユーザーとコンピュータ] スナップインで、Projects OU に移動します。
register-computer Active Directory ユーザーアカウントを削除します。
自動化されたドメイン参加のテスト用に作成した OU を削除します。

次のステップ

自動化されたドメイン参加を使用して Windows VM を Managed Microsoft AD ドメインに参加させるには、Windows VM をドメインに自動的に参加させるをご覧ください。
Google Cloud での Active Directory リソースフォレストのデプロイに関するベストプラクティスを確認する。
Cloud アーキテクチャセンターで、リファレンスアーキテクチャ、図、ベストプラクティスを確認する。

VM が自動的にドメインに参加するように Active Directory を構成する

目標

費用

始める前に

この手法の実装

Active Directory ドメインの準備

省略可: コンピュータをドメインに追加できるユーザーを制限する

ディレクトリ構造を初期化する

Active Directory ユーザー アカウントを作成する

Google Cloud プロジェクトの準備

Secret Manager のシークレットを作成する

サーバーレス VPC アクセスをデプロイする

Kerberos と LDAP へのアクセス権を付与する

ネットワーク タグを使用

サービス アカウントを使用

Cloud Run アプリをデプロイする

プロジェクトの自動ドメイン参加を有効にする

ドメイン参加のテスト

単一の VM インスタンスを作成して参加させる

共有 VPC

スタンドアロン VPC

VM が Active Directory に参加していることを確認する

エラーを診断する

インスタンスの削除

マネージド インスタンス グループを作成して参加させる

共有 VPC

スタンドアロン VPC

使われていないコンピュータ アカウントのクリーンアップのスケジューリング

Cloud Scheduler を構成する

クリーンアップをトリガーする

クリーンアップ

Active Directory の変更を元に戻す

次のステップ

Active Directory ユーザーアカウントを作成する

ネットワークタグを使用

サービスアカウントを使用

マネージドインスタンスグループを作成して参加させる

使われていないコンピュータアカウントのクリーンアップのスケジューリング