2024年4月22日 / 最終更新日時 : 2024年6月18日 officeの杜 Google

Google Workspaceの管理対象に含まれないユーザ用の移行ツールを検証してみた

Google Workspace導入前に別にメールボックスがあり（会社ドメイン）、そのアドレスを元にGoogleアカウントを会社ドメインで野良で作成できてしまう。これが後にGoogle Workspace導入時にちょっとした問題になることがあります。

このアカウントは会社ドメインではあるものの、会社管理のテナント外のアカウントであるため、GWS導入したならば自社テナントのアカウントとして引き込みたい。今回これを実現する機能である「管理対象に含まれないユーザ用の移行ツール」を深掘りしてみたいと思います。

今回利用するツール

このツールはいわゆるドメインで作成された野良のGmailアカウントを取り込む為のツールです。Microsoft365やレンタルサーバのメールアカウントがある場合、GWSを導入するとこのような野良アカウントが発生する可能性があります。

誰でも何でも野良アカウントが自由に作れるわけじゃないのですが、GWS導入の障害の１つになるので要注意です。

※GWSのプランがEnterprise EssentialのようなGMailの無いプランの場合、GMailの設定が無い為、疑似的に野良アカウントを作成して検証は出来ません（ルーティングが出来ない為）

個人GoogleアカウントをGoogle Workspaceに移管する手法

何が問題になるのか？

個人の野良アカウントというのは、メールアドレスが自社のドメインであるが自社のGWSテナントでは管理されていない個人アカウントです。GWSではないので、以下のようなリスクがあります。

管理されていないので当然レポートなどで追跡することも保護することも出来ません。
情報漏洩の制御なども一切することが出来ません。
GWSと違い中身はただのgmailアカウントなので、利用できるサービスも全く違い低機能です。
一見するとメアドが会社ドメインなので、相手からしたらあたかも会社から送られたように見えてしまう。
ドメインは同じでもGWSテナント管理下にはないので、共有ドライブなどにアクセスすることは出来ません。
移行ツールで移行は強制出来ません。よって、相手が承諾して移行してくれないとそのままです（社内での運用を要する）
最も面倒なのが退職者のアカウント。すでに連絡が取れないだとかもう忘れて入れないだとか。これは移行出来ない可能性が高いです。

とまぁ、なんでこんな機能があるのかと思いますが、あるのだから仕方ないです。しかしこの問題はどの企業にも起こり得る問題です。

検証用環境の構築

ルーティングの設定

とは言え、どうやって自分のドメインにて無償の野良アカウントを作るのか？ですが、そもそもその同一アカウントで他にメールを受信する環境がなければ出来ません（例えばMicrosoft365側にメールボックスが用意されている等）。理由は、作成時に確認用メールをそのアドレス宛に送信する為。

つまりメアドに対するメールボックスが既に別に用意されていないと野良アカウントは作れません。

それが無い場合の検証としてはテナントに於けるルーティングで指定のメアドを別のメアドに転送する設定を追加しておく必要性があります。

管理コンソールに入る
サイドバーからアプリ⇒Google Workspace⇒Gmailを開く
下の方にあるルーティングを開く
設定の名称を適当にまずは入力します。
下の方にある「受信者アドレスマップを使用したメール転送」を見つけ、別のルールを追加をクリック
追加をクリックして、アドレスに対して作成する野良アカウントのメアドを入れる
マッピング先のアドレスに自身が利用してる別のメアドを入れる
保存をクリックする

これで、5.で入力したメアドあてのメールは6.で入力したアカウントに転送されるようになるので、確認メールを受信することが可能になります。

図：メールを転送する設定を入れる

無償gmailアカウントを作成

今回、テストでnoraemon@hogehoge.coｍといったスタイルで作成してみようと思います。

サインアップのページを開く
姓名を入れて次へをクリックする
生年月日や性別を入れて次へをクリックする
次の画面では「既存のメールアドレスを使用する」をクリックする
前述のルーティングにて登録した野良アカウントメールアドレスを入力して次へをクリックする
ルーティングで転送設定した宛先に「メールアドレスの確認」のメールが届くので開く
中にコードが入ってるので、これを入力して次へをクリックする
パスワードを設定して次へ進む
電話番号を追加はスキップでオッケー（ここで強制で電話番号認証を求められた場合そのままでは続行出来ません。Androidなどのスマフォからだとスキップして作成できる裏技がありますが、独自ドメインの場合この手は使えません。別のマシンから行うとスキップできる場合があります）。
次へをクリックする
規約が出るので同意するをクリックする
これでアカウントが作成されました。
次に作成したアカウントでGmailを開いてみます。
Gmail を Google アカウントに追加するという項目が出てきます。メールを追加したい場合は指示に従って追加します。（デフォルトだとメールが使えない状態です）。
Driveなどを開くとなぜかデフォルトだと英語表記の画面になってるので言語設定から変更可能です。

検証が完了したらこのアカウントは面倒なので削除しておきましょう。

図：簡単に作れちゃうんですよね・・・

図：デフォルトで英語表記の謎

GWSテナントで同名のアカウントを作る

この時点ではまだ競合していないので、「管理対象外ユーザ」には出てきません。GWSにて野良アカウントと同名のアカウントを作成してみます。ちなみに先にGWSにアカウントが存在してる場合には、対象の同名では野良アカウントは作れなくなります。

管理コンソールにログインする
左サイドバーより、ディレクトリ⇒ユーザを開き新しいユーザの追加をクリックする
ユーザのアドレスは野良アカウントと同じメアドで作成します。
すると、ユーザはすでに存在しますと出ます。今回ここでは「既存のユーザーに移行リクエストをメールで送信する（推奨）」にして、続行をクリックします。
4.で下のオプションを選択してしまうと、相手のメアドがgtempaccount.comに変更されてしまい、競合するアカウントには出てこなくなります。

これで野良アカウントの検証環境が整いました。但しGWS側にはまだ4.の時点でリクエストを投げただけなので、アカウントは作成されていません。

図：競合アカウントが検出される

競合アカウントの管理

さて、この時点で野良アカウントおよびGWSに同名のアカウントがある状態で、IDが競合してる状態になっています。ここで出てくるのが「管理対象に含まれないユーザ用の移行ツール」になります。

アカウント枠に注意

管理対象外アカウントを取り込むということは、事前にテナント側に相応の「アカウント枠」が用意されてる必要性があります。Google WorkspaceのライセンスもしくはGoogle Cloud Identity Freeなどのライセンスの残り残がなければ取り込むことはできません。

取り込んだ対象者にGoogle Workspaceのライセンスを割り当てないのであれば、事前にCloud Identity Freeのサブスクをテナントに追加しておく必要性がありますが、デフォルトでは50ライセンスしか無償枠がないので、特権管理者のメアドにてフォームを利用して無償枠の拡大をGoogleに依頼しておく必要があります。

Google Cloud Identityはどこまで使えるのか実験

移行ツールを使ってみる

以下の手順で競合アカウントを発見し、移行を促すことが可能です。

管理コンソールにログインする
左サイドバーからディレクトリ⇒ユーザを開く
上部メニューのその他のオプションを開き、管理対象に含まれないユーザ用の移行ツールをクリックする
管理対象外ユーザ画面が開かれて、招待してる状態の者一覧が出てきます。

この画面はこれだけです。前述のGWS側アカウント作成時に新しいユーザを作成するオプションを選択した場合、相手のアカウントからは独自ドメインを剥がしてgtempaccount.comに強制変更は出来ますが、この時点で管理対象外からも外れてしまうので、一覧に出てこなくなります。

図：管理対象外ユーザとしてリストアップされた

移行をしてみる

さて、招待された野良アカウント側はどうなっているのか？見てみましょう。

ルーティングで転送先アドレスに対して「Googleアカウントの移行リクエスト」というメールが飛んできています。
中にある「アカウントを移行」をクリックします
野良アカウントでログインする
今後の流れというページが開かれます。今すぐご対応くださいというメッセージが表示されてるので次へをクリックする
メール、カレンダー、ドライブ、ドキュメントなどの画面がでて、Discoverというページが表示されれば完了です。この時点で承諾済みとなります。
この状態でシークレットウィンドウを開いて、野良アカウントで入ってみます。
Googleデータエクスポート画面が出てきて、旧データのエクスポートに関して出てきます。
管理コンソールへ特権管理者でログインしてみます。
GWS側にユーザが追加されており、正式にメンバーとして追加されているのが確認できます。
なお、移行ユーザは組織部門としてはドメインのルート直下に配置されるので設定周りに注意です（例えば外部共有など）

これが届いても無視しつづける人や移行を拒否する人に対しては、なんらかの策を企業側は用意しておく必要があります。

また、この時点で個人としての独自ドメインメアドは消滅しGWSに１本化されます。データは移行されますが個人以外にアクセスは出来ません。

※移行がなされても管理者に「移行されたよ通知」が来るわけじゃないみたいなので、運用ルールが必要そうです。

図：移行メッセージが届く

図：今後の流れ

それまでのデータについて

実際に野良アカウントからテナントに移行してみました。主に以下のようなデータの移行は確認しています。

Google Drive上のデータ
Googleドキュメントやスプレッドシート類
連絡先
カレンダー
Google Keep
Googleフォト
Googleカレンダー
GMail

Cloud Identity Freeで移管してしまったのですが、再度Enterprise Standardでライセンスを後から割り当てたら上記のデータは普通に出てきました。故にあとからでもデータはライセンス次第で問題なく閲覧が出来るので、慌てる必要性はありません。

尚、サービスが無効となってるものでも、以前のデータはGoogleデータエクスポートからはこれまでの過去データはダウンロードが可能なことも確認しています。

※管理コンソール上のデータエクスポートはこちらのURLになります。

２段階認証について

ルート直下の組織部門に対して、2段階認証を設定している場合どうなるのか？ということで以下の設定で設定してる状態で、移行をしてみました。

今回はいますぐ強制
且つ新しいユーザの登録期間の猶予を1日で設定

実際に移行を要請されたユーザ側で作業をしてみると、二段階認証設定を促す画面が出てきました。よって、既に存在してるアカウントではあるもののテナントに移行する時には新規作成ユーザと同じ扱いとなるため、いきなり2段階認証設定していないからといって入れなくなるということはなさそうです。

図：二段階認証の設定

図：移行したら二段階認証設定が出てきた

競合するアカウントの管理

自動送信の設定について

しかし、これでは手動でいちいちユーザを作成する度に競合アカウントが出ては移行メッセージを送るといった面倒な作業が発生します。そこで、この作業を自動化する為の設定が用意されています。それが競合するアカウントの管理になります。

管理コンソールにログインする
左サイドバーより、アカウント⇒アカウント設定を開きます。
競合するアカウントの管理をクリックして開きます。
ユーザを自動的に招待して・・・とすると自動で移行リクエストを送信しつづける間隔や、期間内に移行しなかったユーザの対応を自動指定出来ます。
競合するアカウントを置き換えないとした場合はこれまで通り競合するアカウント画面からの手動の管理となります。
競合するアカウントを対象アカウントに置き換えた場合、GWS側にアカウントが移り、個人アドレスはgtempaccount.comに変更されます。
他問答無用で置き換える下のオプションや、デフォルトは置き換えないという選択肢が用意されています。

※但し、この設定が働くのは手動でユーザを作成した場合や、Directory APIでユーザを作成した場合であり、Entra IDやCSVでの一括作成などからのプロビジョニングの場合は有効にならず強制的にアカウントが作成され、野良アカウントはgtempaccount.comに変換されてしまいますので注意（この件についてどこにも公式ドキュメントには記載がありません）。

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - Provisioning編

図：競合が発生した時の対応を自動化出来る

プロビジョニングをしてしまうと・・・

通常、Google Workspaceのテナントに於いてユーザを手動で追加した場合に、同名のドメインのgoogleアカウントが外部に存在する場合、競合するアカウントとして検出され、競合するアカウントの設定に基づいて対象者に移行招待のメールが飛ぶ、もしくはgtempaccount.comに変換されてテナントにアカウントが作成されます。

これらは競合アカウントの解消を手動で行う場合のフローになります。また、Directory APIで作業を行った場合も同様です（ブログの記事）。

一方で、Entra IDからのプロビジョニングを実行した場合には、この設定によらず強制的にアカウントが作成され、対象の野良アカウントはgtempaccount.comに変換されてしまいます。よって、移行招待のメールが飛ばず、野良アカウントを即座に解消してしまいます。つまり、Directory APIに基づかないでプロビジョニングが実行されている（この件についてどこにも公式ドキュメントには記載がありません）。

強制移行された後

また、この時旧来の野良アカウント側は

username%domainname@gtempaccount.comというアカウント名に変換される（例：yamada%hoge.com@gtempaccount.com)
データはこのgtempaccount.comに保存されている
Google Takeoutからデータをバックアップし、本来のドメインのアカウントに対してアップロードは可能。
外部GoogleサービスであるGoogle Analyticsなどはgtempaccount.comで入ることが可能
この際に、本来のドメインのアカウントに対してアカウントの管理から管理者等として追加することで、再度引き継ぐことが可能

よって、野良アカウントが業務で活用されていると思われる場合には、手動でユーザを追加し競合アカウントに通知を送ってからから、Entra IDからのプロビジョニングを実行するのが望ましい（ユーザが対処をしたのちにプロビジョニングのグループに追加してあげる）

図：Analyticsはgtempaccountで入れる

図：GWSのアカウントを共有に追加して譲渡可能

野良アカウントに戻す手法

一度、Google Workspaceのテナントに対象アカウントを強制的に移行させてしまった場合、元の同名アカウントにあるデータは引き継げません。また、Analyticsなどのアカウントも移行されてるわけではないので、このままだとユーザに一手間かけてもらって前述のように本来のGWSアカウントに共有を掛けたり、ドライブに手動でアップロードが必要です。

では元に戻せないのか？といったら、以下の手法で戻すことが可能です。ユーザの方に作業を１つして貰う必要があります。

Google Workspace側のテナントから対象ユーザを削除する（まだgtempaccount.comが存在してることを要確認）
Entra ID側のグループアドレスから対象のユーザを外しておく（同期が走ると再度作成されてしまう為）
ユーザ側はgtempaccount.comのアカウント設定画面に入り、Googleアカウントのメールアドレスのメアドをクリック
本来のドメインのメアドを入れて変更を掛ける（例：test@domain.comなど）
確認のメールが本人のtest@domain.comに届くので、メール本文内の「こちらをクリック」をクリックする
変更が完了し、元の野良アカウントとしてドメインのあるアカウントに戻る
この状態で、Google Workspace側で再度同じアカウントに対して手動でユーザを追加すると招待メール送信画面が出るので、招待を掛ける

7.の状態にまでなったら、移管が完了したものから順次、Entra IDのグループアドレスに追加を行い、プロビジョニングを実施します。

図：ユーザ側で再度元のメアドに戻す手順

図：変更確認のメールが来る

図：再度招待メールが送れるようになる

競合するアカウントの管理の自動送信について

今回の取組の中で競合するアカウントの管理の機能について不可解な点があった為以下にまとめておきます。

競合するアカウントの管理に於いて、ユーザの自動招待を期待してCSVでの一括追加を行ったものの作動せず強制的に移行が行われました。
また、自動送信を利用せず「競合する管理対象外のアカウントを管理対象のアカウントの置き換えない」にセットしてる場合は、CSVでの追加やEntra IDでのプロビジョニングでは「CONSUMER_ACCOUNT_CONFLICT」や「GoogleAppsObjectNotFound」としてエラーとなり追加そのものが出来ませんでした。
手動で追加の場合についてはどちらの設定であっても「必ず招待の可否のダイアログ」が出る
Directory APIの場合はドキュメントにもあるように「resolveConflictAccount=true」のパラメータを追加する必要がある。

また、対象のテナントにMXレコードが設定されていない場合、招待メールが遅れるかどうかは確認が必要です（ライセンスによってはメール機能が無い為）。

結果的に競合アカウントの管理をするうえでは、対象のユーザを選定し手動で追加する必要性があり、自動送信の機能が動くシーンが非常に限られてるため、プロビジョニング前にこれらは別にわけて処理をしておく必要があります。

GASでresolveConflictAccountを付けて作成

前述の通り、Directory APIでユーザを作成する場合のドキュメントにはresolveConflictAccountのクエリパラメータをtrueにして送信しろと書いてあります。UrlfetchAppであるならばURLのパラメータにつなげて掛けば良いとは思うのですが、Google Apps Scriptでの送信方法がウェブ上のどこにも書いてありません。

そこで色々なパターンを試してみましたが、GASでこれを実現するには以下のようにパラメータを構築すれば行けることがわかりました。

//ユーザを追加（競合アカウント対策版）
//ユーザを連続で作成
function batchUserAdd(){
  //スプレッドシートを取得
  let sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("userlist");
  let ss = sheet.getRange("A2:D").getValues();
  let ui = SpreadsheetApp.getUi();

  //ユーザを一括で作成
  for(let i = 0;i<ss.length;i++){
    //レコードを一個取得
    let rec = ss[i];

    //完了チェックがtrueならばスルーする
    if(rec[3] == true){
      continue;
    }

    //レコードデータが無い場合にはスルーする
    if(rec[0] == "" || rec[0] == undefined){
      continue;
    }

    //ユーザパラメータを取得する
    let email = rec[0];
    let lastname = rec[2];
    let firstname = rec[1];

    //Directory APIリクエスト
    let result = addUser(email,firstname,lastname);

    //resultの結果に応じて処理を分岐
    if(result == 0){
      //エラー発生時は特に何もしない
    }else{
      //作成済みとしてssデータを書き換え
      ss[i][3] = true;
    }

    //ウェイトを入れる
    Utilities.sleep(100)
  }

  //完了した処理をスプシに書き戻す
  let lastColumn = ss[0].length;  //カラムの数を取得する
  let lastRow = ss.length;        //行の数を取得する
  sheet.getRange(2,1,lastRow,lastColumn).setValues(ss); 

  //終了処理
  ui.alert("完了しました。")
}

//ユーザを作成
function addUser(email,firstname,lastname) {
  //パスワードをランダム生成
  var pass = String("gs_" + Math.random().toString(36).slice(-11));

  //ユーザ作成情報
  var user = {
    primaryEmail: email,
    name: {
      givenName: lastname,
      familyName: firstname
    },
    password: pass,
    changePasswordAtNextLogin: true,
  };

  //ユーザ作成実行
  let result;
  try{
    result = AdminDirectory.Users.insert(user,{resolveConflictAccount:true})
  }catch(e){
    console.log(e);
    result = 0
  }
  
  return result;
}

//ユーザを追加（競合アカウント対策版）

//ユーザを連続で作成

function batchUserAdd(){

//スプレッドシートを取得

let sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("userlist");

let ss = sheet.getRange("A2:D").getValues();

let ui = SpreadsheetApp.getUi();

//ユーザを一括で作成

for(let i = 0;i<ss.length;i++){

//レコードを一個取得

let rec = ss[i];

//完了チェックがtrueならばスルーする

if(rec[3] == true){

continue;

}

//レコードデータが無い場合にはスルーする

if(rec[0] == "" || rec[0] == undefined){

continue;

}

//ユーザパラメータを取得する

let email = rec[0];

let lastname = rec[2];

let firstname = rec[1];

//Directory APIリクエスト

let result = addUser(email,firstname,lastname);

//resultの結果に応じて処理を分岐

if(result == 0){

//エラー発生時は特に何もしない

}else{

//作成済みとしてssデータを書き換え

ss[i][3] = true;

}

//ウェイトを入れる

Utilities.sleep(100)

}

//完了した処理をスプシに書き戻す

let lastColumn = ss[0].length; //カラムの数を取得する

let lastRow = ss.length; //行の数を取得する

sheet.getRange(2,1,lastRow,lastColumn).setValues(ss);

//終了処理

ui.alert("完了しました。")

}

//ユーザを作成

function addUser(email,firstname,lastname) {

//パスワードをランダム生成

var pass = String("gs_" + Math.random().toString(36).slice(-11));

//ユーザ作成情報

var user = {

primaryEmail: email,

name: {

givenName: lastname,

familyName: firstname

password: pass,

changePasswordAtNextLogin: true,

};

//ユーザ作成実行

let result;

try{

result = AdminDirectory.Users.insert(user,{resolveConflictAccount:true})

}catch(e){

console.log(e);

result = 0

}

return result;

}

AdminDirectory.Users.insertの第二引数にオブジェクトとしてresolveConflictAccountをtrueで指定した値を指定して送信することで、競合するアカウントの管理に於いて、自動送信がオンの状態の場合自動で招待メールが飛び、管理対象外のユーザに自動で登録されました。

この画面に登録された後にもう一度実行すると、すでに管理対象外ユーザとして登録済みな為、「API call to directory.users.insert failed with error: Entity already exists.」というエラーが出て再度のリクエストは拒否されました。相手がメールを無視して指定日数経過したらどうなるのか？ウォッチしてみたいと思います。

※GASで連続でユーザ作成を行わせる場合、Directory APIのQuota上限に注意が必要です。

裏技

とはいえ、野良アカウント対策で大量の人数がいるという場合、同数以上のCloud Identityアカウントを用意するというのが困難なケースもあると思います。しかし、Microsoft365のメールボックスがあってGoogle Workspaceも使ってるような場合にはこのままでは封じる策が使えません。

そんな時には「同名アドレスをGoogleグループで作ってしまう」という方法があります。またこの手法は対象のアドレスで外部に野良アカウントがいるということが検知することにも役立つので、Microsoft365にいるメンバー分の空の同一アドレスのグループを作って封じることで野良アカウントが作れなくなります。

但し、この手法は裏技であるため、運用上同一アドレスでGoogle Workspaceのアカウント作成が必要なケースでは、過去に作っておいた同名のグループアドレスを削除するというフローが入ることになるので、一手間が増えるので要注意です。

※グループアドレス作成は以下のエントリーのGASを使うと一括で作成などが出来ます。エラートラップを追加しておけば、外部に野良アカウント検知という形にもなるのでオススメです。

Google Apps Scriptでグループアドレスの作成・削除を行う【GAS】

Google Workspaceの管理対象に含まれないユーザ用の移行ツールを検証してみた

今回利用するツール

何が問題になるのか？