G Suiteを利用していると、WindowsログインのアカウントをG Suite側に寄せられる上に、ログインIDとパスワードもG Suiteのものを利用できる上に、Windows 10搭載デバイスを統合管理できるという奇跡的な発表があった事から、どの程度のレベルでデバイス管理ができるのか、実機を用いて検証しました。
あまりにも大変だったので、結論を先に書くと、これで管理と言っていいのかあやしいところはあるものの、Microsoftと距離を置いていたはずのGoogleが、Windows端末を制御しようとしている流れを感じ取ることができます。今後に期待したいと思います。
グーグル「G Suite」の管理コンソールから「Windows 10」デバイスを管理可能に(ZDNet Japan)
必要なもの
実際にすすめていくにあたって、必要なライセンスなどがあります。
必要なライセンス一覧
- 現時点では以下のどれかのライセンスが必要です。
- G Suite Enterprise
- G Suite Enterprise for Education
- Cloud Identity Premium
- G Suiteの日本語ドキュメントには
現時点では
という表記がありました。今後はWindowsデバイス管理を利用可能なライセンスも増えていくかもしれません。
その他で必要なもの
- G Suite テナントの管理者権限(あたりまえ)
- 本検証においては特権管理者を割り当てた上で検証しています。
- Windows 10 バージョン 1809 以降、Professional または Enterprise エディション
- ※ Home エディションでは動きませんので買い換えてください。
Windowsにインストールしなければならないアプリ
- Google Chrome ブラウザ
- Chrome ブラウザがインストールされていないと G Suite アカウントでのログインができません
- Edge があるから大丈夫とおもっていたらダメでした
- Google Credential Provider for Windows(Windows 用 Google 認証情報プロバイダー)
- フリーです、インストールして使います。詳細は手順に記載。以降、GCPW と記載していきます。
デバイス登録について
G SuiteにWindows10デバイスを登録する流れについて書いていきたいと思います。
- 大まかには以下の流れで設定を行います。
- G Suite管理コンソールから登録可能にするための機能の有効化
- Windows10デバイスへ登録するための準備
- G Suiteを経由したWindows10デバイスへのログイン
1. G Suite管理コンソールから登録可能にするための機能の有効化
-
G Suiteテナントの管理コンソールにアクセスします。
-
ホームから [デバイス] へ移動します。 [デバイス] が表示されていない場合は必要な権限が足りないかも?
-
デバイス管理から、[Windows の設定] へ移動します。 ページの一番左下です。
-
その後、 [デバイス セキュリティの設定] から [高度なデスクトップ セキュリティ] を 有効 にします。この項目を 有効 にしないと、デバイス登録ができません。
2. Windows10デバイスへ登録するための準備
今度は、Windows10デバイスで作業します。Administrator権限が必要です。今回は既に作成されているWindowsローカルユーザをG Suiteログイン経由に切り替える検証をしてみましたが、既にAzureAD Joinをしている場合には、どのような挙動になるか分かりません。この場合、Intuneを利用する想定になるはずなので、MDMが重複することになります。やりたくありません。
今回検証するG Suiteログイン切り替えに限らず、AzureAD Joinへの切り替えにおいても、ローカルユーザのプロファイルがそのまま引き継がれるようなことはなく、新規でユーザ作成されたところに紐付く形になります。
デバイス登録方法は以下の2種類から選択できます
-
専用アプリ(GCPW)を利用して登録 G Suiteにデバイス登録し、Windows10へG Suiteアカウントを利用してログインする
-
Webアクセスで登録 G Suite にデバイス登録のみ行いたい場合はこちらの方法です。 より詳細な手順は以下を参考にしてください
Windows 向けの高度なデスクトップ セキュリティ サービスにデバイスを登録する
1と2の違いは、GCPWのアプリをローカルデバイスにインストールして作業を進めるか、特定のURLにアクセスして、ブラウザから作業を進めるかの違いですが、後者の場合はデバイス管理のみ機能し、OSログイン処理の置き換えは行われません。
今回はGCPWを利用して登録するパターンについて解説していきます。
GCPWを利用してデバイス登録
-
GCPWをインストールするために Windows10 にローカルアカウントを作成しました。ADバインドやAzureAD Joinユーザでは検証を行っていません。
-
GCPW のインストーラをダウンロードしてインストールします。
インストールするだけでは、G Suiteへのデバイス登録が行われません。インストールが完了すると、アプリケーションがすぐ終了します。サイレントインストールっぽい感じで、スッと消えていなくなるので何度もインストールしたくなりますが、一度で出来ていると信じましょう。
それでも2度目のインストールを実行すると、ちゃんとエラーが出てきます。親切。
- 以下のレジストリを作成します。(必須)
HKEY_LOCAL_MACHINESoftwareGoogle
へ、キーの追加から GCPW
というフォルダを作成します。 domains_allowed_to_login
という文字列値のレジストリを追加し、値に自テナントのドメイン名を追加します。(例:cloudnative.co.jp)
手動でレジストリエディタを触るとか現代において地獄の沙汰なので、Powershellスクリプトのサンプルがありますので、そちらも紹介します。
以下のスクリプトの $domainList
にログインする自テナントのドメイン名を入力し、対象端末にて実行するとレジストリが追加されます。
例: $domainList = 'cloudnative.co.jp'
ドメインが複数ある場合はカンマ(,)区切りで追加してください。
$registryPath = 'HKEY_LOCAL_MACHINESoftwareGoogleGCPW'
$regName = 'domains_allowed_to_login'
$domainList = 'mycompany.com,emea.mycompany.com,mycompany2.com'
[microsoft.win32.registry]::SetValue($registryPath, $regName, $domainList)
- Google Chrome をインストール
まさか誰があのChromeブラウザをインストールしておかないと、この仕組みが全く機能しないと思うでしょうか。ココ大事なポイントです。「ブラウザがあれば(何でも)よい」のではなく「Google Chrome」が必要です。ChromeのインストールタイミングはGCPWインストール前でもOKです。
- GCPW と Chrome がインストールされており、レジストリが追加されましたので、ここでOSを再起動します。
3. G Suite経由のWindows10デバイスへのログイン
-
再起動後に、Windows10ログイン画面に 「仕事用アカウントの追加」 をクリックしてユーザを追加作成します。ボタンがない場合は、GCPWが正しく機能していませんので、前述の手順を見直してください。
-
Googleアイコンが表示されている画面にて、仕事用アカウントにログインする をクリックします。 ここで、 「管理者がこのアカウントでのログインを許可していません。別のアカウントでお試しください。」 というエラーがでた場合、レジストリの登録が失敗している可能性があります。 その他のエラーに関しては、以下のトラブルシュートをご確認ください。 Windows 用 Google 認証情報プロバイダのトラブルシューティング
-
自テナントの G Suite アカウントでログインします。この段階では、G Suiteの全てのユーザがこのWindowsデバイスにログインを行える状態です。ユーザ単位で制御することが出来ないので、上位組織の下に下位組織を作成して、組織単位で無効化する設定を投入する以外、制御はできません。
-
そのままWindows のデスクトップ画面まで進めばログインは成功です。
-
Windows10の [設定] > [アカウント] > [職場または学校にアクセスする] にて、 G Suite MDMに接続済み の表記があればデバイス登録が完了しています。
-
G Suite管理コンソールのデバイスに登録されていることを確認したら完了です。
-
重要なのは、ログイン処理をしているデバイスと、ユーザが管理画面で紐付くことがありません。
補足
Google公式日本語ドキュメントでは、レジストリの追加が 省略化 と記載されていますが、レジストリの追加をせずに進めると ログインができませんでした となり先に進みません。 Google公式英語ドキュメントではレジストリの追加について 必須 と記載されていました。
また、同じく英語ドキュメントのにはPowershellのスクリプトサンプルや、その他オプションについてのレジストリも記載されているので、現時点では英語ドキュメントを参考にすることをオススメします。
G Suite管理コンソール 設定メニューについて
- 「Windowsの設定」←メニューの場所がわかりにくい
- G Suite管理コンソール > デバイス > 左側縦カラム一番下 デバイスの設定 Windowsの設定 より設定可能
- 全ての項目はわかりやすく日本語化
- 補足テキストは少ないものの、全て日本語化されているため、初めて設定を施す場合でもそこまで大変ではなさそうに感じます。どんなことができるのか? 後の項目で掘り下げていきます。
Windows10の制御は何ができるのか
-
設定可能な項目は以下の5項目がありました。
- デスクトップセキュリティの設定
- アカウント設定
- WindowsUpdateの設定
- BitLockerの設定
- カスタム設定(OMA-URI)
-
各項目の詳細は、このあと解説していきます。
-
また各種項目については、 G Suite の組織部門ごと に設定が可能で、ユーザ単位ではありません。つまり組織Aと組織Bという別組織部門を作成している場合、組織単位で設定が分けられます。上位組織部門に設定をした場合、下位部門には設定を行わなくても継承されます。ここから、下位部門に対して個別設定をすることも可能です。
デスクトップセキュリティの設定
「高度なデスクトップセキュリティ」という設定を有効にすることが可能です。 この設定を有効にしない場合、他の設定項目や端末の登録も進めることが出来ない為、必ず最初に有効にする必要があります。
表記のまま受け取ると、何か特別なセキュリティ対策をしてくれそうな項目ですが、そうではなく、デバイス管理機能を有効化するかどうかだけの話です。
アカウント設定
ここでは Windows10にログインしたユーザの権限を、「標準ユーザー」または「ローカル管理者」のどちらの権限を付与するか制御することができます。
設定項目としては「標準ユーザー」と「ローカル管理者」の二択のみです。
WindowsUpdateの設定
本項目では Windows Update に関連する設定が可能です。
- Microsoft アプリケーションのアップデートを承認する
- 自動更新の挙動(ダウンロード時に通知のみや自動インストール、自動再起動といったいくつかの設定が可能でした)
- 有効な時間帯(デバイスが更新後に再起動しないようにする時間を指定)
- インターネット経由 ではなく 指定のWSUSサーバーからのアップデートを承認する
- 自動更新の頻度
- クオリティ アップデートを受け取る(クオリティアップデートを指定日時延期させたり、一時停止させたりすることができるようです)
WSUSサーバの指定について
IntuneのWindowsUpdateでは、WSUSを指定することができません。まさかGoogle側にこのような設定があったのは驚きでした。今回の検証ではWSUSは用意していなかったので実際には試していません。
Intuneでも実現できるアップデートの延期機能が、こちらにもありました。
BitLocker設定
BitLockerの暗号化についての設定が可能です。こちらでBitLockerの強度や追加認証、回復オプション等が設定できます。ただ、Intuneのように自動的に暗号化されたり、回復キーをAzureADで管理するといった機能はなさそうでした。
正直、これがないとかなりきついなという印象です。
設定項目について
- システム ドライブの暗号化オプション(暗号化強度XTS-AES256から4段階まで暗号化レベルを下げられます。
- スタートアップ時の追加認証(BitLockerのPIN設定などですが、WindowsHello for Businessとは別のものです)
- 起動前の回復オプション(Windows起動前にBitLockerを解除するときに表示するメッセージや表示URLを変更できます)
- システム ドライブの回復オプション(グループポリシー同様に回復キーのバックアップ先をADに指定したりできるようですが、G Suite側を指定することは出来ませんでした)
- 固定ドライブの暗号化(システムドライブと同様です)
- リムーバブル ドライブの暗号化(暗号化強度の変更、別の組織で設定されたデバイスへの書き込みアクセスを拒否、といった設定がありました、検証できていないのでUSBフラッシュストレージなどがどのような取り扱いになるのか確認していません)
カスタム設定で外部のUSBフラッシュストレージを制御してみる
適当なUSBフラッシュストレージをデバイスに接続して、データコピーされるのを制御できるか確認してみます。
今回は Policy CSP の RemovableDiskDenyWriteAccess を指定して、USBメモリの書き込み制限を設定し、動作確認を行いました。
実際に設定を行い、端末を同期させたところ期待通りの動作が確認できました。
今回利用したCSPの詳細情報については以下を参考にしてみてください。 ポリシー CSP-記憶域
GUIでの制御ができないので触りにくいとは思いますが、OMA-URIを駆使することで細かい設定ができるのではないかと思います。 がっつり作り込めばIntuneと同等の制御が可能かも?
OMA-URIコマンドの予測候補一覧表示 予測変換機能のように、特定のワードを入れた時に当てはまりそうなコマンドラインをいくつか自動で表示してくれました。さすがGoogleは検索便利。
収集できるデバイス情報について
- G Suite に Windows10 を登録することでいくつかの情報が取得できます。この手の情報収集内容としては、一般的なレベルで、実用的です。デバイス一覧は [Windows10設定] ではなく、デバイス管理ページからアクセスすることができます。
収集できる情報
- 暗号化ステータス
- 同期時間
- デバイス ID
- シリアル番号
- OSバージョン
- Wi-Fi MAC アドレス
- ユーザー
- メーカー
- ホスト名
インストール済アプケーションの一覧は確認できませんでした。
リモートワイプ(端末初期化)
リモートワイプ指示を行ってから該当端末の電源を入れて待機していた所、何の予告もなく端末がシャットダウン、再起動し、Windows10の回復が走り、見事に初期状態(Windowsへようこそ)になりました。
リモートワイプの実行状況については監査ログで確認ができるようですが、失敗した場合のリトライなどの確認は行っていません。
デバイスワイプが完了すると、デバイス情報にワイプ済みの表記が追加されてました。
監査ログ
登録されているデバイスの同期時間やワイプの記録、デバイス状態といった内容が取得することができました。
検証期間中には、なぜか検証デバイスのWi-Fi MACアドレスが変更されたというアラートが発生し、メール通知および監査ログに記録が残っていました。メール通知はG Suiteの管理者に送られますが、MACアドレスの変更は行っていないので謎多めです。
まとめ
初期設定に関しては非常に容易で、各種ライセンスと端末があれば(ライセンスが最もハードルが高いのですが)、そこまで手を煩わすことなく、利用開始することができます。
わかりやすいUIとOMA-URIを用いた柔軟なカスタムができることで拡張性についても期待できます。ただ、アプリケーションのインストールやPowershellスクリプトの配信機能はないので、かゆいところまではまだ届かないかなという印象です。
検証は行いませんでしたが、設定の中にActive Directoryの文字がいくつかあったので、Actie Directoryとも連携ができるかもしれません。
G Suite Enteroriseライセンスにアップグレードするコストは、本機能だけに注目するべきではないので、G Suiteを積極的に利用している企業がその世界観の中で機能が広がるのはクラウドの良いところだなと思います。
ところでMacはどうしましょうか。