このドキュメントでは、Google Cloud Directory Sync(GCDS)を使用して、Active Directory と Cloud Identity アカウントまたは Google Workspace アカウントの間でユーザーとグループのプロビジョニングを設定する方法について説明します。
このガイドの手順を実施する前に、Active Directory 内のユーザーとグループを管理できる Active Directory ユーザーが必要です。また、Cloud Identity アカウントまたは Google Workspace アカウントをまだ取得していない場合は、ドメインを検証するために DNS ゾーンへの管理者権限も必要です。Cloud Identity アカウントまたは Google Workspace アカウントをすでに取得している場合は、ユーザーに特権管理者権限があることを確認してください。
目標
- GCDS をインストールして、Active Directory と、Cloud Identity または Google Workspace に接続する。
- Google Cloud にユーザーとグループ(必要な場合)をプロビジョニングするように GCDS を構成する。
- 継続的プロビジョニング用にスケジュールされたタスクを設定する。
費用
Cloud Identity Free Edition を利用している場合、このガイドの手順で課金対象の Google Cloud コンポーネントは使用しません。
始める前に
- Active Directory ID 管理を Google Cloud に拡張する方法を十分に理解します。
ID、グループ、ドメインのマッピング方法を決定します。具体的には、次の質問にすべて答えられるようにします。
- Cloud Identity または Google Workspace のプライマリ ドメインとして使用する予定の DNS ドメインはどれか。セカンダリ ドメインとして使用する予定の追加の DNS ドメインはどれか。
- ドメイン置換を使用する必要があるか。
- ユーザーの共通 ID としてメールアドレス(
mail
)またはユーザー プリンシパル名(userPrincipalName
)を使用する予定はあるか。 - グループをプロビジョニングする予定はあるか。その場合、グループの共通 ID として共通名(
cn
)またはメールアドレス(mail
)を使用するか。
こうした決定を行う際の指針については、Active Directory の ID とアクセス管理の Google Cloud への拡張に関する概要ドキュメントをご覧ください。
本番環境の Active Directory を Google Cloud に接続する前に、Active Directory のテスト環境を使用してユーザーのプロビジョニングの設定とテストを行うことをおすすめします。
アカウントをまだ取得していない場合は Cloud Identity に登録し、必要に応じて DNS ドメインを追加してください。
Cloud Identity Free Edition を利用していて、プロビジョニングするユーザー数が 50 を超える場合は、サポートに連絡し、無料の Cloud Identity ユーザーの合計数を増やすようにリクエストしてください。
Cloud Identity に使用する予定のドメインを、従業員が一般ユーザー向けアカウントの登録に使用している可能性がある場合は、まずそれらのユーザー アカウントを移行することを検討してください。詳しくは、既存のユーザー アカウントの評価をご覧ください。
GCDS のデプロイを計画する
以降のセクションでは、GCDS のデプロイを計画する方法について説明します。
GCDS のデプロイ先を決める
GCDS では、LDAP ディレクトリから Cloud Identity または Google Workspace にユーザーとグループをプロビジョニングできます。GCDS は LDAP サーバーと Cloud Identity または Google Workspace の仲介役として機能します。LDAP ディレクトリにクエリを行って必要な情報をディレクトリから取得し、Directory API を使用して Cloud Identity または Google Workspace でユーザーを追加、変更、削除します。
Active Directory ドメイン サービスは LDAP に基づいているため、GCDS は Active Directory と Cloud Identity または Google Workspace 間のユーザー プロビジョニングの実装に適しています。
オンプレミスの Active Directory インフラストラクチャを Google Cloud に接続する場合、GCDS はオンプレミスで実行することも、Google Cloud の Compute Engine 仮想マシンで実行することもできます。ほとんどの場合、GCDS をオンプレミスで実行することをおすすめします。
- Active Directory で管理される情報には、個人を特定できる情報が含まれ、通常は機密とみなされるため、ローカル ネットワーク外から Active Directory にアクセスされないようにする必要があります。
- デフォルトでは、Active Directory は暗号化されていない LDAP を使用します。Google Cloud 内から Active Directory にリモートでアクセスする場合は、暗号化された通信を使用する必要があります。ただし、LDAPS(LDAP+SSL)または Cloud VPN を使用すると接続を暗号化できます。
- GCDS から Cloud Identity または Google Workspace への通信は HTTPS を介して行われるため、ファイアウォールの構成はほとんど変更の必要がないか一切変更の必要がありません。
GCDS は Windows と Linux のいずれでも実行できます。GCDS はドメイン コントローラにデプロイできますが、別のマシンで GCDS を実行することをおすすめします。Cloud Directory Sync を実行するマシンはシステム要件を満たし、Active Directory への LDAP アクセス権が必要です。このマシンがドメインに参加していることや Windows を実行していることは前提条件ではありませんが、このガイドではドメインに参加している Windows マシンで Cloud Directory Sync が実行されていると想定します。
プロビジョニングの設定を支援するために、GCDS には設定マネージャーというグラフィック ユーザー インターフェース(GUI)が組み込まれています。GCDS を実行するサーバーにデスクトップ エクスペリエンスの機能があれば、サーバー自体で設定マネージャーを実行できます。それ以外の場合は、設定マネージャーをローカルで実行してから、その結果の構成ファイルを、それを使用して GCDS を実行するサーバーにコピーする必要があります。このガイドでは、GUI を使用してサーバーで構成マネージャーを実行することを想定します。
データの取得元を決める
GCDS では LDAP を使用して Active Directory にアクセスし、ユーザーとグループに関する情報を取得します。この実行を可能にするには、構成内のホスト名とポートを GCDS に指定する必要があります。グローバル カタログ(GC)サーバーを 1 つだけ稼働するような小規模の Active Directory 環境では、GCDS をグローバル カタログ サーバーに直接ポイントできるため、ホスト名とポートを指定することによる問題は生じません。
冗長性を備えた GC サーバーが稼働する複雑な環境では、GCDS で単一のサーバーをポイントしても冗長性を活用できなくなるため、適切ではありません。LDAP クエリを複数の GC サーバーに分散するロードバランサを設定して、一時的に使用できなくなったサーバーを追跡することもできますが、サーバーを動的に特定する DC ロケータ メカニズムの使用をおすすめします。
GCDS のデフォルトでは、LDAP サーバーのエンドポイントを明示的に指定する必要があります。DC ロケータ メカニズムの使用はサポートされていません。このガイドでは、DC ロケータ メカニズムを使用する小規模な PowerShell スクリプトを使用して GCDS を補完します。これにより、グローバル カタログ サーバーのエンドポイントを静的に構成する必要がなくなります。
Cloud Identity アカウントまたは Google Workspace アカウントを準備する
このセクションでは、GCDS のユーザーを作成する方法について説明します。GCDS が Cloud Identity または Google Workspace の Directory API および Domain Shared Contacts API と通信できるようにするには、アプリケーションで管理者権限のあるユーザー アカウントが必要になります。
Cloud Identity または Google Workspace の登録時に、すでに 1 人の特権管理者ユーザーを作成しています。このユーザーを GCDS に使用できますが、Cloud Directory Sync 専用のユーザーを別途作成することをおすすめします。
- 管理コンソールを開き、Cloud Identity または Google Workspace の登録時に作成した特権管理者ユーザーを使用してログインします。
- メニューの [ディレクトリ] > [ユーザー] をクリックし、[新しいユーザーの追加] をクリックしてユーザーを作成します。
適切な名前とメールアドレスを次のように入力します。
- 名:
Google Cloud
- 姓:
Directory Sync
- メインのメールアドレス:
cloud-directory-sync
メールアドレスのプライマリ ドメインは、プロビジョニング元のフォレストにそのドメインが対応していない場合でもそのまま保持してください。
- 名:
[Automatically generate a new password] が [Disabled] に設定されていることを確認し、パスワードを入力します。
[Ask for a password change at the next sign-in] が [Disabled] に設定されていることを確認します。
[Add New User] をクリックします。
[完了] をクリックします。
GCDS でユーザー アカウントとグループの作成、一覧表示、削除を有効にするには、ユーザーに追加の権限が必要です。また、ユーザーをシングル サインオンから除外することをおすすめします。そうしないと、シングル サインオンの問題が発生したときに GCDS の再承認ができなくなる可能性があります。上記の操作はいずれもユーザーを特権管理者にすることで実施できます。
- 新しく作成したユーザーを一覧から見つけ、開きます。
- [Admin roles and privileges] で [Assign Roles] をクリックします。
- Super Admin のロールを有効にします。
- [保存] をクリックします。
ユーザー プロビジョニングを構成する
以降のセクションでは、ユーザーのプロビジョニングを構成する方法について説明します。
GCDS 用に Active Directory ユーザーを作成する
GCDS で Active Directory からユーザーとグループに関する情報を取得するには、十分なアクセス権限を持つドメイン ユーザーが GCDS に必要です。既存の Windows ユーザーをこの目的に転用するのではなく、GCDS 専用のアカウントを作成してください。
グラフィカル インターフェース
- [スタート] メニューから [Active Directory ユーザーとコンピュータ] MMC スナップインを開きます。
- ユーザーを作成するドメインと組織単位に移動します。フォレスト内に複数のドメインがある場合は、GCDS のマシンと同じドメインでユーザーを作成します。
- 右側のウィンドウ ペインを右クリックし、[新規作成] > [ユーザー] を選択します。
- 適切な名前とメールアドレスを次のように入力します。
- 名:
Google Cloud
- 姓:
Directory Sync
- ユーザー ログオン名:
gcds
- ユーザー ログオン名(Windows 2000 より前):
gcds
- 名:
- [Next] をクリックします。
- パスワード ポリシーに従ったパスワードを入力します。
- [ユーザーは次回のログオン時にパスワード変更が必要] をオフにします。
- [パスワードを無期限にする] を選択します。
- [次へ] をクリックし、[完了] をクリックします。
PowerShell
- 管理者として PowerShell コンソールを開きます。
次のコマンドを実行してユーザーを作成します。
New-ADUser -Name "Google Cloud Directory Sync" ` -GivenName "Google Cloud" ` -Surname "Directory Sync" ` -SamAccountName "gcds" ` -UserPrincipalName (-Join("gcds@",(Get-ADDomain).DNSRoot)) ` -AccountPassword(Read-Host -AsSecureString "Type password for User") ` -Enabled $True
これで GCDS をインストールするための前提条件が整いました。
GCDS をインストールする
GCDS を実行するマシンで GCDS のインストーラをダウンロードして実行します。ブラウザを使用してダウンロードを行うのではなく、次の PowerShell コマンドを使用してインストーラをダウンロードできます。
(New-Object net.webclient).DownloadFile("https://dl.google.com/dirsync/dirsync-win64.exe", "$(pwd)\dirsync-win64.exe")
ダウンロードが完了したら、次のコマンドを実行してインストール ウィザードを起動できます。
.\dirsync-win64.exe
GCDS がすでにインストールされている場合は、GCDS を更新して最新バージョンを使用できます。
GCDS 構成用のフォルダを作成する
GCDS の構成は XML ファイルに保存されます。この構成には Google の認証用に GCDS が使用する OAuth 更新トークンが含まれるため、この構成に使用されるフォルダは適切に保護する必要があります。
さらに、このフォルダ以外に GCDS からアクセスする必要があるローカル リソースはないため、制限ユーザー LocalService として実行されるよう GCDS を構成します。
- GCDS をインストールしたマシンで、ローカル管理者としてログインします。
- 管理者権限がある PowerShell コンソールを開きます。
次のコマンドを実行して、構成を保存するフォルダを
$Env:ProgramData\gcds
という名前で作成し、GCDS と管理者だけがアクセスできるようにアクセス制御リスト(ACL)を適用します。$gcdsDataFolder = "$Env:ProgramData\gcds" New-Item -ItemType directory -Path $gcdsDataFolder &icacls "$gcdsDataFolder" /inheritance:r &icacls "$gcdsDataFolder" /grant:r "CREATOR OWNER:(OI)(CI)F" /T &icacls "$gcdsDataFolder" /grant "BUILTIN\Administrators:(OI)(CI)F" /T &icacls "$gcdsDataFolder" /grant "Domain Admins:(OI)(CI)F" /T &icacls "$gcdsDataFolder" /grant "LOCAL SERVICE:(OI)(CI)F" /T
ProgramData フォルダの場所を特定するには、コマンド
Write-Host $Env:ProgramData
を実行します。英語版の Windows の場合、この場所のパスは通常、c:\ProgramData
として設定されます。このパスは後で必要になります。
Google に接続する
ここで、構成マネージャーを使用して GCDS の構成を準備します。以下の手順では、GCDS を実行するサーバーで構成マネージャーを実行することを想定しています。
別のマシンで設定マネージャーを実行する場合は、構成ファイルを GCDS サーバーにコピーする必要があります。また、別のマシンでは構成のテストができないことがあるので注意してください。
- 構成マネージャを起動します。構成マネージャは Windows の [スタート] メニューから [Google Cloud Directory Sync] > [Configuration Manager] と選択します。
[Google Domain Configuration] > [Connection Settings] の順にクリックします。
メニューで [File] > [Save as] をクリックします。
ファイル ダイアログにファイル名として「
PROGRAM_DATA\gcds\config.xml
」と入力します。PROGRAM_DATA
は、前の手順で PowerShell コマンドの実行時に返されたProgramData
フォルダのパスで置き換えます。[Save] をクリックし、続いて [OK] をクリックします。
Active Directory に接続する
次の手順では、GCDS を構成して Active Directory に接続します。
- 設定マネージャーで、[LDAP Configuration] > [Connection Settings] の順にクリックします。
- LDAP 接続を構成します。
- Server Type: [MS Active Directory] を選択します。
- Connection Type: [Standard LDAP] または [LDAP+SSL] を選択します。
- ホスト名: GC サーバーの名前を入力します。この設定はテスト専用です。後で GC サーバーの検出を自動化します。
- Port: 3268(GC)または 3269(SSL を介した GC)。ドメイン コントローラの代わりに GC サーバーを使用すると、Active Directory フォレストのすべてのドメインのユーザーをプロビジョニングできるようにします。また、Microsoft ADV190023 更新後の認証を確認します。
- Authentication Type: Simple
- Authorized User: 前の手順で作成したドメイン ユーザーのユーザー プリンシパル名(UPN)の
gcds@UPN_SUFFIX_DOMAIN
を入力します。UPN_SUFFIX_DOMAIN
はそのユーザーの適切な UPN サフィックスのドメインに置き換えます。また、NETBIOS_DOMAIN_NAME\gcds
構文を使用してユーザーを指定することも可能です。 - Base DN: このフィールドは空にして、フォレスト内のすべてのドメインに対して検索が行われるようにします。
- 設定を検証するには、[Test connection] をクリックします。接続に失敗した場合は、GC サーバーのホスト名を指定していること、ユーザー名とパスワードが正しいことを再確認してください。
- [Close] をクリックします。
プロビジョニング対象を決める
GCDS が正常に接続されたので、プロビジョニングする項目を決めます。
- 設定マネージャーで [General Settings] をクリックします。
- [User Accounts] が選択されていることを確認します。
- グループをプロビジョニングする場合は [Groups] がオンになっていることを確認し、そうでない場合はこのチェックボックスをオフにします。
- 組織単位の同期についてはこのガイドの説明には含まれないため、[Organizational Units] はオフにしておいてください。
- [User Profiles] と [Custom Schemas] はオフのままにします。
詳細については、プロビジョニングする対象を決定するをご覧ください。
ユーザーをプロビジョニングする
ユーザーをプロビジョニングするには、Active Directory 間でユーザーをマッピングする方法を構成します。
- 構成マネージャーで、[User Accounts] > [Additional User Attributes] の順にクリックします。
- [Use defaults] をクリックすると、属性 [Given Name] と [Family Name] にそれぞれ
givenName
とsn
が自動的に入力されます。
残りの設定は、UPN またはメールアドレスを使用して Active Directory を Cloud Identity または Google Workspace のユーザーにマッピングするのか、ドメイン名の置換を適用するのかによって異なります。最適なオプションが不明の場合は、Active Directory ID 管理を Google Cloud に拡張する方法の記事をご覧ください。
UPN
- 設定マネージャーで [User Accounts] > [User Attributes] の順にクリックします。
- [Use defaults] をクリックします。
- [Email Address Attribute] を
userPrincipalName
に変更します。 - エイリアス アドレスを同期しない場合は、[
proxyAddresses
] > [Remove
] をクリックします。 - [Search Rules] タブをクリックし、[Add Search Rule] をクリックします。
次の設定を入力します。
- Scope: Sub-tree
Rule:
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(userPrincipalName=gcds@*)))
このルールでは、無効になっていないすべてのユーザーが照合対象になりますが、コンピュータ アカウント、マネージド サービス アカウント、および
gcds
ユーザー アカウントは無視されます。Base DN: 空白のままにして、フォレスト内のすべてのドメインを検索対象にします。
[OK] をクリックしてルールを作成します。
UPN: ドメイン置換
- 構成マネージャで、[User Accounts] > [User Attributes] タブの順にクリックします。
- [Use defaults] をクリックします。
- [Email Address Attribute] を
userPrincipalName
に変更します。 - エイリアス アドレスを同期しない場合は、[
proxyAddresses
] > [Remove
] をクリックします。 - [Search Rules] タブをクリックし、[Add Search Rule] をクリックします。
次の設定を入力します。
- Scope: Sub-tree
Rule:
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(userPrincipalName=gcds@*)))
このルールでは、無効になっていないすべてのユーザーが照合対象になりますが、コンピュータ アカウント、マネージド サービス アカウント、および
gcds
ユーザー アカウントは無視されます。Base DN: 空白のままにして、フォレスト内のすべてのドメインを検索対象にします。
[OK] をクリックしてルールを作成します。
[Google Domain Configuration] > [Connection Settings] の順にクリックし、[Replace domain names in LDAP email addresses with this domain name] を選択します。
メール
- 構成マネージャで [User Accounts] > [User Attributes] の順にクリックします。
- [Use defaults] をクリックします。
- [Search Rules] タブをクリックし、[Add Search Rule] をクリックします。
次の設定を入力します。
- Scope: Sub-tree
Rule:
(&(objectCategory=person)(objectClass=user)(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
このルールでは、メールアドレスが空でなく、無効になっていないすべてのユーザーが照合対象になりますが、コンピュータ アカウントとマネージド サービス アカウントは無視されます。
Base DN: 空白のままにして、フォレスト内のすべてのドメインを検索対象にします。
[OK] をクリックしてルールを作成します。
メール: ドメイン置換
- 構成マネージャで [User Accounts] > [User Attributes] の順にクリックします。
- [Use defaults] をクリックします。
- エイリアス アドレスを同期しない場合は、[
proxyAddresses
] > [Remove
] をクリックします。 - [ルールを検索] タブをクリックし、[デフォルトを使用] をクリックします。
- [Google Domain Configuration] > [Connection Settings] の順にクリックし、[Replace domain names in LDAP email addresses with this domain name] を選択します。
ユーザー属性のマッピングの詳細については、設定マネージャーを使用した同期の設定をご覧ください。
削除ポリシー
ここまでの構成では、Cloud Identity または Google Workspace のユーザーの追加と更新に重点を置いてきました。しかし、Active Directory で無効化または削除されたユーザーが、Cloud Identity で一時停止または削除されるという点も重要です。
プロビジョニング プロセスの一環として、GCDS は、Active Directory LDAP のクエリ結果に対応するものがない Cloud Identity ユーザーまたは Google Workspace ユーザーのリストを生成します。LDAP クエリには (!(userAccountControl:1.2.840.113556.1.4.803:=2))
という句が組み込まれているため、前回のプロビジョニング以降に Active Directory で無効化または削除されたユーザーのすべてがこのリストに含まれます。GCDS のデフォルトの動作では、こうしたユーザーは Cloud Identity または Google Workspace から削除されますが、この動作はカスタマイズできます。
- 設定マネージャーで [User Accounts] > [User Attributes] の順にクリックします。
- [Google Domain Users Deletion/Suspension Policy] で [Don't suspend or delete Google domain admins not found in LDAP] がオンになっていることを確認します。この設定をしておくと、Cloud Identity アカウントまたは Google Workspace アカウントの構成に使用した特権管理者ユーザーが GCDS で一時停止または削除されることはありません。
- 必要に応じて管理者以外のユーザーの削除ポリシーを変更します。
GCDS の複数のインスタンスを使用して、1 つの Cloud Identity アカウントまたは Google Workspace アカウントに異なるドメインやフォレストをプロビジョニングする場合は、異なる GCDS インスタンスが相互に干渉しないようにする必要があります。デフォルトのままにすると、別のソースからプロビジョニングされた Cloud Identity または Google Workspace のユーザーが、Active Directory では削除済みと誤って認識されます。このような状況を回避するには、プロビジョニング元以外のドメインまたはフォレストのユーザーすべてを単一の OU に移動して、対象の OU を除外します。
- 構成マネージャで、[Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: Organization Complete Path
- Match Type: 完全一致
除外ルール: OU のパスとその名前を入力します。次に例を示します。
ROOT OU/EXCLUDED OU
ROOT OU/EXCLUDED OU
を OU パスと除外される OU の名前に置き換えます。
[OK] をクリックしてルールを作成します。
また、単一の OU を除外してもビジネスに適合しない場合は、ユーザーのメールアドレスに基づいてドメインやフォレストを除外できます。
UPN
- 構成マネージャで、[Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: ユーザーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!UPN_SUFFIX_DOMAIN).*)$
UPN_SUFFIX_DOMAIN
は、次の例のように、使用する UPN サフィックスのドメインに置き換えます。.*@((?!corp.example.com).*)$
複数の UPN サフィックスのドメインを使用する場合は、式を次のように拡張します。
.*@((?!corp.example.com|branch.example.com).*)$
[OK] をクリックしてルールを作成します。
UPN: ドメイン置換
- 構成マネージャで、[Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: ユーザーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!SUBSTITUTION_DOMAIN).*)$
SUBSTITUTION_DOMAIN
には、次の例のように、UPN サフィックスのドメインの置き換え用のドメインを指定します。.*@((?!corp.example.com).*)$
[OK] をクリックしてルールを作成します。
- 構成マネージャで、[Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: ユーザーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!MX_DOMAIN).*)$
MX_DOMAIN
は、次の例のように、メールアドレスで使用するドメイン名に置き換えます。.*@((?!corp.example.com).*)$
複数の UPN サフィックスのドメインを使用する場合は、式を次のように拡張します。
.*@((?!corp.example.com|branch.example.com).*)$
[OK] をクリックしてルールを作成します。
メール: ドメイン置換
- 構成マネージャで、[Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: ユーザーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!SUBSTITUTION_DOMAIN).*)$
SUBSTITUTION_DOMAIN
には、次の例のように、メールドメインの置き換え用のドメインを指定します。.*@((?!corp.example.com).*)$
[OK] をクリックしてルールを作成します。
削除と停止の設定の詳細については、構成マネージャーのオプションに関する詳細情報をご覧ください。
グループをプロビジョニングする
次に、Active Directory と、Cloud Identity または Google Workspace 間でのグループのマッピングを構成します。このプロセスは、グループのマッピングに共通名とメールアドレスのどちらを使用するかによって異なります。
共通名でグループ マッピングを構成する
まずプロビジョニングするセキュリティ グループの種類を指定し、次に、該当する LDAP クエリを公式化します。次の表に、利用可能な共通的なクエリを示します。
種類 | LDAP クエリ |
---|---|
ドメイン ローカル グループ | (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483652)) |
グローバル グループ | (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483650)) |
ユニバーサル グループ | (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483656)) |
グローバル グループとユニバーサル グループ | (&(objectCategory=group)(|(groupType:1.2.840.113556.1.4.803:=2147483650)(groupType:1.2.840.113556.1.4.803:=2147483656))) |
すべてのグループ | (objectCategory=group) |
グローバル グループのクエリでは、ドメイン コントローラなどの Active Directory で定義されたグループも対象になります。これらのグループは、組織単位(ou
)を基準にして検索を絞り込むことでフィルタリングできます。
残りの設定は、Active Directory から Cloud Identity または Google Workspace のユーザーへのマッピングに UPN とメールアドレスのどちらを使用するかによって異なります。
UPN
- 設定マネージャーで、[Groups] > [Search Rules] の順にクリックします。
- [Use Defaults] をクリックして、デフォルトのルールを 2 つ追加します。
- 最初のルールの編集アイコンをクリックします。
- [ルール] を編集して LDAP クエリを置き換えます。
- [Groups] ボックスに次の設定を入力します。
- Group Email Address Attribute:
cn
- User email address attribute:
userPrincipalName
- Group Email Address Attribute:
- [Prefix-Suffix] タブをクリックします。
[Group Email Address] ボックスに次の設定を入力します。
Suffix:
@PRIMARY_DOMAIN
。ここで@PRIMARY_DOMAIN
は、Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメインに置き換えます。GCDS によってドメインが自動的に追加されるため、この設定は冗長に見えます。しかし、GCDS インスタンスが複数ある場合に、この設定を明示的に指定することでインスタンスが自ら追加していないグループ メンバーを消去しないようにする必要があります。例:
@example.com
[OK] をクリックします。
2 つ目のルールの十字アイコンをクリックして、そのルールを削除します。
メール
- 設定マネージャーで、[Groups] > [Search Rules] の順にクリックします。
- [Use Defaults] をクリックして、デフォルトのルールをいくつか追加します。
- 最初のルールの編集アイコンをクリックします。
- [ルール] を編集して LDAP クエリを置き換えます。
- [Groups] ボックスで [Group Email Address Attribute] を編集して、
cn
の設定を入力します。 - [OK] をクリックします。
ユーザーのマッピング時にドメイン置換を使用した場合も同じ設定が適用されます。
メールアドレスでグループ マッピングを構成する
まずプロビジョニングするセキュリティ グループの種類を指定し、次に、該当する LDAP クエリを公式化します。次の表に、利用可能な共通的なクエリを示します。
種類 | LDAP クエリ |
---|---|
メールアドレスを使用するドメイン ローカル グループ | (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483652)(mail=*)) |
メールアドレスを使用するグローバル グループ | (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483650)(mail=*)) |
メールアドレスを使用するユニバーサル グループ | (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483656)(mail=*)) |
メールアドレスを使用するグローバル グループとユニバーサル グループ | (&(objectCategory=group)(|(groupType:1.2.840.113556.1.4.803:=2147483650)(groupType:1.2.840.113556.1.4.803:=2147483656))(mail=*)) |
メールアドレスを使用するすべてのグループ | (&(objectCategory=group)(mail=*)) |
残りの設定は、Active Directory から Cloud Identity または Google Workspace のユーザーへのマッピングに UPN とメールアドレスのどちらを使用するかによって異なります。
UPN
- 設定マネージャーで、[Groups] > [Search Rules] の順にクリックします。
- [Use Defaults] をクリックして、デフォルトのルールを 2 つ追加します。
- 最初のルールの編集アイコンをクリックします。
- [ルール] を編集して LDAP クエリを置き換えます。
- [グループ] ボックスで [ユーザーメール名の属性] を編集し、
userPrincipalName
の設定を入力します。 - [OK] をクリックします。
- 2 つ目のルールの十字アイコンをクリックして、そのルールを削除します。
メール
- 設定マネージャーで、[Groups] > [Search Rules] の順にクリックします。
- [Use Defaults] をクリックして、デフォルトのルールをいくつか追加します。
- 最初のルールの編集アイコンをクリックします。
- [ルール] を編集して LDAP クエリを置き換えます。
- [OK] をクリックします。
- 2 つ目のルールの十字アイコンをクリックして、このルールを削除します。
[Replace domain names in LDAP email addresses with this domain name] を有効にしている場合は、グループとメンバーのメールアドレスにも適用されます。
削除ポリシー
GCDS では、グループの削除もユーザーの場合と同様に処理されます。GCDS の複数のインスタンスを使用して、1 つの Cloud Identity アカウントまたは Google Workspace アカウントに異なるドメインやフォレストをプロビジョニングする場合は、異なる GCDS インスタンスが相互に干渉しないようにする必要があります。
デフォルトでは、別のソースからプロビジョニングされた Cloud Identity または Google Workspace のグループ メンバーが、Active Directory で削除済みであるとして誤って認識されます。このような状況を回避するには、現在のプロビジョニング元以外のドメインやフォレストのグループ メンバーがすべて無視されるように GCDS を構成します。
UPN
- [Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: グループ メンバーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!UPN_SUFFIX_DOMAIN).*)$
UPN_SUFFIX_DOMAIN
は、次の例のように、お使いの UPN サフィックスのドメインに置き換えます。.*@((?!corp.example.com).*)$
複数の UPN サフィックスのドメインを使用する場合は、式を次のように拡張します。
.*@((?!corp.example.com|branch.example.com).*)$
[OK] をクリックしてルールを作成します。
UPN: ドメイン置換
- [Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: グループ メンバーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!SUBSTITUTION_DOMAIN).*)$
SUBSTITUTION_DOMAIN
には、次の例のように、UPN サフィックスのドメインの置き換え用のドメインを指定します。.*@((?!corp.example.com).*)$
[OK] をクリックしてルールを作成します。
- [Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: グループ メンバーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!MX_DOMAIN).*)$
MX_DOMAIN
は、次の例のように、メールアドレスで使用するドメイン名に置き換えます。.*@((?!corp.example.com).*)$
複数の UPN サフィックスのドメインを使用する場合は、式を次のように拡張します。
.*@((?!corp.example.com|branch.example.com).*)$
[OK] をクリックしてルールを作成します。
メール: ドメイン置換
- [Google Domain Configuration] > [Exclusion Rules] の順にクリックします。
- [Add Exclusion Rule] をクリックします。
以下の設定を構成します。
- Type: グループ メンバーのメールアドレス
- Match Type: 正規表現
Exclusion Rule: 単一の UPN サフィックスのドメインを使用する場合は、次の正規表現を入力します。
.*@((?!SUBSTITUTION_DOMAIN).*)$
SUBSTITUTION_DOMAIN
は、次の例のように、メールドメインの置き換えに使用するドメインに置き換えます。.*@((?!corp.example.com).*)$
[OK] をクリックしてルールを作成します。
グループ設定の詳細については、設定マネージャーのオプションに関する詳細情報をご覧ください。
ロギングと通知の構成
ユーザーを同期した状態に保持するには、スケジュールに従って GCDS を定期的に実行する必要があります。GCDS でログファイルが作成される方法とタイミングを制御すると、GCDS のアクティビティと潜在的な問題を追跡できます。
- 構成マネージャで [Logging] をクリックします。
- [File name] を
PROGRAM_DATA\gcds\gcds_sync.#{timestamp}.log
に設定します。PROGRAM_DATA
は、前の手順で PowerShell コマンドの実行時に返されたProgramData
フォルダのパスで置き換えます。 [File] > [Save] の順にクリックして構成変更をディスクに commit し、[OK] をクリックします。
GCDS は、ロギングに加えてメールでも通知を送信します。このサービスを有効にするには、[Notifications] をクリックし、お使いのメールサーバーの接続情報を入力します。
ユーザー プロビジョニングをシミュレートする
GCDS の構成が完了しました。構成が意図したとおりに動作することを確認するには、まず構成をディスクに保存して、ユーザー プロビジョニングの実行をシミュレートする必要があります。シミュレーション時に、GCDS は Cloud Identity または Google Workspace アカウントへの変更を行いませんが、通常のプロビジョニング実行時に実行する変更をレポートします。
- 構成マネージャーで [Sync] をクリックします。
- 画面下部の [Clear cache] を選択し、続いて [Simulate sync] をクリックします。
- プロセスが完了したら、ダイアログの下部に表示されるログの [Proposed changes] セクションを確認し、ユーザーまたはグループの削除や一時停止などの不要な変更がないことを確認します。
最初のユーザーのプロビジョニング
最初のユーザーのプロビジョニングをトリガーできるようになりました。
警告
- ユーザー プロビジョニングをトリガーすると、Cloud Identity アカウントまたは Google Workspace アカウント内のユーザーとグループに永続的な変更が行われます。
- プロビジョニングするユーザー数が多い場合は、一時的に LDAP クエリを変更して、一部のユーザーだけを対象にすることを検討してください。このユーザーのサブセットでプロセスをテストし、必要に応じて設定を調整します。結果の検証が正しく行われたら、LDAP クエリを元に戻して、残りのユーザーをプロビジョニングします。
- テストを行う際は、多くのユーザーの変更や削除を繰り返し行わないでください。このような操作は不適切な動作として報告される場合があります。
次のようにプロビジョニングの実行をトリガーします。
- 構成マネージャーで [Sync] をクリックします。
画面下部で [Clear cache] を選択し、[Sync & apply changes] をクリックします。
ステータスを示すダイアログが表示されます。
処理が完了したら、このダイアログの下半分に表示されるログを確認します。
- [Successful user changes] で、ユーザーが 1 件以上作成されていることを確認します。
- [Failures] で、エラーが発生していないことを確認します。
プロビジョニングのスケジュールを設定する
Active Directory で実施された変更が確実に Cloud Identity または Google Workspace アカウントに反映されるようにするために、タスクが 1 時間ごとにプロビジョニングを開始するようにスケジュール設定します。
- 管理者として PowerShell コンソールを開きます。
次のようにして、システムで Active Directory PowerShell モジュールが使用できるかどうかを確認します。
import-module ActiveDirectory
コマンドが失敗した場合は、リモート サーバー管理ツールをダウンロードおよびインストールしてから、コマンドを再実行してみてください。
メモ帳を使ってファイルを作成し、ファイルに次の内容をコピーして
%ProgramData%\gcds\sync.ps1
に保存します。保存したらファイルを閉じます。[CmdletBinding()] Param( [Parameter(Mandatory=$True)] [string]$config, [Parameter(Mandatory=$True)] [string]$gcdsInstallationDir ) import-module ActiveDirectory # Stop on error. $ErrorActionPreference ="stop" # Ensure it's an absolute path. $rawConfigPath = [System.IO.Path]::Combine((pwd).Path, $config) # Discover closest GC in current domain. $dc = Get-ADDomainController -discover -Service "GlobalCatalog" -NextClosestSite Write-Host ("Using GC server {0} of domain {1} as LDAP source" -f [string]$dc.HostName, $dc.Domain) # Load XML and replace the endpoint. $dom = [xml](Get-Content $rawConfigPath) $ldapConfigNode = $dom.SelectSingleNode("//plugin[@class='com.google.usersyncapp.plugin.ldap.LDAPPlugin']/config") # Tweak the endpoint. $ldapConfigNode.hostname = [string]$dc.HostName $ldapConfigNode.ldapCredMachineName = [string]$dc.HostName $ldapConfigNode.port = "3268" # Always use GC port # Tweak the tsv files location $googleConfigNode = $dom.SelectSingleNode("//plugin[@class='com.google.usersyncapp.plugin.google.GooglePlugin']/config") $googleConfigNode.nonAddressPrimaryKeyMapFile = [System.IO.Path]::Combine((pwd).Path, "nonAddressPrimaryKeyFile.tsv") $googleConfigNode.passwordTimestampFile = [System.IO.Path]::Combine((pwd).Path, "passwordTimestampCache.tsv") # Save resulting config. $targetConfigPath = $rawConfigPath + ".autodiscover" $writer = New-Object System.IO.StreamWriter($targetConfigPath, $False, (New-Object System.Text.UTF8Encoding($False))) $dom.Save($writer) $writer.Close() # Start provisioning. Start-Process -FilePath "$gcdsInstallationDir\sync-cmd" ` -Wait -ArgumentList "--apply --config ""$targetConfigPath"""
設定マネージャーでは、構成ファイル内の認証情報を暗号化するための秘密鍵が作成されています。GCDS がスケジュールされたタスクとして実行された場合でも構成を読み取れるようにするため、次のコマンドを実行して自分のプロファイルから
NT AUTHORITY\LOCAL SERVICE
のプロファイルに秘密鍵をコピーしてください。New-Item -Path Registry::HKEY_USERS\S-1-5-19\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp -Force; Copy-Item -Path Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp\util ` -Destination Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp\util
コマンドが失敗した場合は、PowerShell コンソールを管理者として開始したかどうかを確認します。
次のコマンドを実行して、スケジュールに基づくタスクを作成します。このタスクは 1 時間ごとに起動し、
sync.ps1
スクリプトをNT AUTHORITY\LOCAL SERVICE
として呼び出します。$taskName = "Synchronize to Cloud Identity" $gcdsDir = "$Env:ProgramData\gcds" $action = New-ScheduledTaskAction -Execute 'PowerShell.exe' ` -Argument "-ExecutionPolicy Bypass -NoProfile $gcdsDir\sync.ps1 -config $gcdsDir\config.xml -gcdsInstallationDir '$Env:Programfiles\Google Cloud Directory Sync'" ` -WorkingDirectory $gcdsDir $trigger = New-ScheduledTaskTrigger ` -Once ` -At (Get-Date) ` -RepetitionInterval (New-TimeSpan -Minutes 60) ` -RepetitionDuration (New-TimeSpan -Days (365 * 20)) $principal = New-ScheduledTaskPrincipal -UserID "NT AUTHORITY\LOCAL SERVICE" -LogonType ServiceAccount Register-ScheduledTask -Action $action -Trigger $trigger -Principal $principal -TaskName $taskName $task = Get-ScheduledTask -TaskName "$taskName" $task.Settings.ExecutionTimeLimit = "PT12H" Set-ScheduledTask $task
詳細については、自動同期のスケジュールを設定するをご覧ください。
ユーザー プロビジョニングをテストする
これで GCDS のインストールと構成が完了しました。スケジュールに基づくタスクによってプロビジョニングが 1 時間ごとにトリガーされます。
プロビジョニングの実行を手動でトリガーするには、PowerShell コンソールに切り替えて、次のコマンドを実行します。
Start-ScheduledTask "Synchronize to Cloud Identity"
クリーンアップ
GCDS を削除する手順は次のとおりです。
- Windows コントロール パネルを開き、[プログラム] > [プログラムのアンインストール] の順にクリックします。
- [Google Cloud Directory Sync] を選択し、[アンインストール] または [変更] をクリックしてアンインストール ウィザードを起動します。その後はウィザードの指示に従って操作します。
PowerShell コンソールを開き、次のコマンドを実行して、スケジュールされたタスクを削除します。
$taskName = "Synchronize to Cloud Identity" Unregister-ScheduledTask -TaskName $taskName -Confirm:$False
次のコマンドを実行して構成とログファイルを削除します。
Remove-Item -Recurse -Force "$Env:ProgramData\gcds" Remove-Item -Recurse -Path Registry::HKEY_USERS\S-1-5-19\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp
次のステップ
- Active Directory と Google Cloud 間でのシングル サインオンを構成する。
- GCDS のベスト プラクティスとよくある質問を確認する。
- GCDS の一般的な問題のトラブルシューティングを確認する。
- アカウントと組織の計画に関するベスト プラクティスと、Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。
- 特権管理者ユーザーを管理するためのベスト プラクティスを確認する。