このチュートリアルでは、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 の無料枠ティアの制限内に収まるように設計されています。 料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
始める前に
このチュートリアルでは、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 スクリプレットにより、次の図に示すプロセスが開始されます。
このプロセスは次のように動作します。
- 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 を開きます。
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 ネットワーク内の、既存のサブネットと重複しないようにする必要があります。
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 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:$DomainProjectNumber@cloudbuild.gserviceaccount.com" ` --role "roles/iam.serviceAccountUser" & gcloud projects add-iam-policy-binding $DomainProjectId ` --member "serviceAccount:$DomainProjectNumber@cloudbuild.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
アプリをビルドして Cloud Run にデプロイします。
& gcloud builds submit . ` --config cloudbuild.hydrated.yaml ` --substitutions _IMAGE_TAG=$(git rev-parse --short HEAD)
デプロイの完了には、数分かかることがあります。
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'))
起動プロセスをモニタリングします。
& 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] に移動します。
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] に移動します。
作成した
cleanup-computer-accounts
ジョブの [今すぐ実行] をクリックします。数秒後、[結果] の列に [成功] と表示されると、クリーンアップが正常に完了したことになります。数秒以内に [結果] の列が自動で更新されない場合は、[更新] ボタンをクリックします。
クリーンアップされたアカウントの詳細については、register-computer
アプリのログを確認してください。
Google Cloud コンソールで、[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 リソース フォレストのデプロイに関するベスト プラクティスを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。