社名変更のシステム対応どうする？GOする！

2023年7月6日 20:31

こんにちは、GO株式会社 IT戦略部システムサービスグループの白井です。
弊社は2023年4月1日に株式会社Mobility TechnologiesからGO株式会社に社名変更を行いました。この社名変更に伴い、全情シスが震える「ドメイン変更」が発生しました😇

ドメイン変更PJは2月〜5月下旬までの約４ヶ月間で調査から検証、実施まで完了させる特急PJでした。これからドメイン変更を控えている方も、そうでない方もぜひ最後までお付き合いください！

注目ポイント

今回のドメイン変更の注目ポイントは以下の3点です！

ユーザのログインをほとんど止めることなく、ドメイン変更をしました
SSOの切り替えも、ユーザに不便を感じさせることなくこっそり行いました
グループウェアのテナントはそのまま、権限やグループもそのまま引き継ぎました

それではまず、弊社の環境についてご説明いたします。

弊社の環境について

IdP：AzureAD
グループウェア：Microsoft365、Google Workspace
デバイス管理：Intune（Windows）、Jamf（mac）
　Windows：AzureAD Join
　Mac認証：Jamf Connect
その他多数のアプリケーションをSSOで接続
メール：Google側で送受信

そう、お気づきでしょうか。ドメイン変更でもっとも影響を受けるのはSSOであるということに…。たくさん手が伸びてるなぁ👀

ユーザのログインを止めない？

ユーザのログインを止めないでドメイン変更をするなんて、何を言っているんだ！と思われるかもしれません。でもできちゃうんです。そう、UPNを変えなければ！

UPNを変えない？

私たちはIdPとしてAzureADを利用しているので、全ての大元はAzureADアカウントとなり、他のアプリケーションとSAML SSOを設定する際の「一意のユーザーID」はデフォルトのままであればUPNになっている状態です。

ドメイン変更でUPNを変更してしまうと、全てのSSOができない状態になってしまいます。AzureAD側からプロビジョニングしているシステムはまだしも、そうではないシステムのドメイン変更までメンテナンスに入れる1日の間に完了させることはほぼ不可能・・・。

そこで私たちは、SSOしているシステムの変更をドメイン変更と別日に対応する方法を考えることにしました。

あれ…一意のユーザーIDって変えられるぞ…？

一意のユーザーIDを、変えても問題ない値に変えてしまおう！
そして、一通りSSOを新しいドメインで行えるようにしてからUPNの変更をしよう！
ということで、目をつけたのが「user.mail」です。

AzureADでuser.mailを設定する

と言うことで、user.mailに当たる連絡先情報のメールを設定していくことにしました。UPNを変更しないので、まだログインに影響は与えません。こちらの設定が終わった後、各種SAML SSOの「一意のユーザーID」をUPNからuser.mailに向けていくと言う算段です。

連絡先情報のメールは、エイリアスをいくつか持たせることができるため、以下のように設定します。

プライマリーメールアドレス：新ドメインのメールアドレス（goinc.jp）
セカンダリーメールアドレス：旧ドメインのメールアドレス（mo-t.com）

と思ったんですが、MS Graphではプライマリーもセカンダリーもなく、明示的に序列をつけてエイリアスを持たせることができませんでした。
そこで、エイリアスを持たせるために、Exchange Online モジュールを利用しました。（私たちは普段Google側でメールの送受信を行なっているため、普段はExchangeを利用していません）

プライマリーに新ドメインのメールアドレスを設定することでuser.mailで拾えるようにして、セカンダリーに旧ドメインのメールアドレスを設定することで、メールの受信が継続できるようにしました。
（グループアドレスも同様）

メールアドレスの設定には、Microsoft Graph APIとExchange Online Powershellモジュールを利用しました！（この２つはmacでも実行可能）

## ユーザ情報をエクスポートする

Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -All | Select-Object UserPrincipalName,Mail | Export-csv -Path /Users/hogehoge/Desktop/hogeUser.csv -NoTypeInformation -Encoding UTF8
Disconnect-MgGraph

### 区切り位置でドメインを分ける

## 作成したリストを取り込む
Connect-ExchangeOnline -UserPrincipalName hogehoge

$Array = Import-Csv -Path C/Users/hogehoge/Desktop/hogeUser.csv | ForEach-Object {
    $_.UserPrincipalName
}

foreach($a in $Array){
    $old = "$a@旧ドメイン"
    $new = "$a@新ドメイン"
    Set-Mailbox -Identity  $old -EmailAddresses "SMTP:$new","smtp:$old"
}

Disconnect-ExchangeOnline

## メールが新しくなって、UPNが変更されていないことを確認する
Connect-MgGraph -Scopes 'User.read.All'

Get-MgUser -All | Select-Object  ID,DisplayName,Mail,UserPrincipalName | Export-Csv -Path /Users/hogehoge/Desktop/NewMailList.csv  -Encoding UTF8 -NoTypeInformation
Disconnect-MgGraph

## Groupをエクスポートする
Connect-MgGraph -Scopes 'Group.Read.All'
Get-MgGroup | Select-Object Id, DisplayName, Mail| Export-Csv -Path /Users/hogehoge/Desktop/hogeGroups.csv -NoTypeInformation -Encoding UTF8

## セキュリティグループなどを除外するため、ドメインごとリストに作成しなおす
## Mail列のみをコピーしてCSVを作成する

## 作成したリストを取り込む
Connect-ExchangeOnline -UserPrincipalName hogehoge

$Array = Import-Csv -Path /Users/hogehoge/Desktop/hogeGroups.csv | ForEach-Object {
    $_.Mail
}

foreach($a in $Array){
    $old = "$a@旧ドメイン"
    $new = "$a@新ドメイン"
    Set-UnifiedGroup -Identity  "$old" -EmailAddresses "SMTP:$new","smtp:$old"
}

Disconnect-ExchangeOnline

## メールが新しくなっていることを確認する。
Get-Mailbox -GroupMailbox | Select-Object Name,PrimarySmtpAddress,EmailAddresses  | Export-Csv -Path /Users/hogehoge/Desktop/NewGroupList.csv  -Encoding UTF8 -NoTypeInformation

◾️注意点

Exchangeのライセンスがないアカウントはエラーになります！
- P1だけつけている場合などご注意ください
弊社は全てのメールをGoogle側で送受信しているため、Microsoft365のみの場合の検証を行なっていません！

Google認証を使っているシステムのログインをID/PASSに変えてもらう

非常に重要な課題です。この後GWSのプライマリドメイン、メインアドレスを新ドメインに変更してしまうため、Google認証が通らなくなります。
Google認証を何に使っているのか確認する場合は、以下の通り。弊社では気の遠くなる量が確認できました😇

テナント全体：アプリのアクセス制御
個人：サードパーティ製のアプリとサービス

もしもGASなどGoogle内のサービスがある場合は、気にしなくても権限はそのまま引き継がれました。（実際に操作する場合は必ず検証を行なってください）

SSOの切り替えをこっそり行う？

ここまでで、SSOをこっそり行うための準備が完了しました。
まずはSSO先で最も利用頻度の高いGoogle Workspaceのドメイン変更作業を社名変更の当日（土曜日）に行いました。

Googleのメインアドレスを入れ替える！

いよいよ「一意のユーザーID」をuser.mailに入れ替えます。
入れ替える前にやらないといけないことは、

プロビジョニングのマッピングを修正する

プロビジョニングのマッピング修正は、エンタープライズアプリケーションのプロビジョニングでキーになっているAADの属性をUPN→mailに変更して、Googleのメインアドレスが新ドメインになるようにします。

mail=user.mailなので、新ドメインがGoogle側のメインアドレスになる

ちなみに、旧ドメインのメールアドレスは、特に何も指定しなくてもGoogle側で「予備のメールアドレス」に追加されていたため、送受信に問題はありませんでした。プロビジョニングが反映された時点から、Googleのユーザログインが新ドメインに変わってしまうので、次の操作を行うまでログインができません！お気をつけください。

いざ入れ替え！！
「一意のユーザーID」をUPN→user.mailに入れ替えます！

この時点で、すでに新しいドメインでGoogleにログインができるようになりました。（旧ドメインのログインは不可）

テナントのプライマリドメインを変更する
今回はテナントのプライマリドメインも変更する必要があるため、以下の対応を行いました。

Google Workspaceのプライマリドメインを変更する
Microsoft365のプライマリドメインを変更する
AzureADのSAML設定で、応答URLなどに記載のドメインを変更する

そして必ず、一度Googleからログアウト→再ログインを行なってください。メールが送信できなくなります😭

その他のシステムのSSOの切り替えをこっそり行う

その他のシステムのSSOの切り替えはここから2ヶ月かけて完了させました。UPNの変更を行なっていないため、急にログインができない！といったトラブルは最小限に抑えることができました。

また、SSOを行う際ユーザからするとAzureAD認証の画面が表示されるだけなので、中で何が起こっているのかは知り得ません。なので、
「本当に社名変更したの👀？」
という気持ちになっている方が多数発生するほどに、大きな障害もなく進めることができました。

コーポレートロゴが変わっただけ、いつもと同じログイン画面
まだ、AzureAD認証は旧ドメイン

UPNを変更する

最後にUPNも新ドメインに変更する

そして、全てのSSOの切り替えが完了したタイミングで、AzureADのUPNの変更を行いました。

UPNの設定には、またまたMicrosoft Graph APIとExchange Online Powershellモジュールを利用しました！（メールを流し込んだ時とほぼ同様の内容です）

## ユーザー情報をエクスポートする

Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -All | Select-Object ID,UserPrincipalName | Export-csv -Path /Users/hogehoge/Desktop/hogeUser.csv -NoTypeInformation -Encoding UTF8
Disconnect-MgGraph

### 区切り位置でドメインを分ける
### GUESTを含まないように、”#EXT”を含まない　フィルターをかける
### 自分の管理者アカウントを除外しておく（リカバリーのため）

## 作成したリストを取り込む
Connect-MgGraph -Scopes 'User.ReadWrite.All'
$Array = Import-Csv -Path C/Users/hogehoge/Desktop/hogeUser.csv | ForEach-Object {
    $_.UserPrincipalName

foreach($a in $Array){
    $old = "$a@旧ドメイン"
    $new = "$a@新ドメイン"
    Update-MgUser -UserId $old -UserPrincipalName $new
}
Disconnect-MgGraph

## UPNが更新されて、UserIdが変わっていないことを確認する
Connect-MgGraph -Scopes 'User.read.All'

Get-MgUser -All | Select-Object  ID,UserPrincipalName | Export-Csv -Path /Users/hogehoge/Desktop/NewUPNList.csv  -Encoding UTF8 -NoTypeInformation
Disconnect-MgGraph

ここまで完了すると、ついにAzureAD認証時も新ドメインを使うようになります。次に起こるのは、PCログイン時のユーザ名問題です。

Windowsの場合

UPNの変更後、端末の再起動が必要

弊社では、AzureAD Joinしているためユーザ名が変更になりました。ただし、ユーザフォルダなどは継続して利用が可能だったため、特に大きな問題は発生しませんでした。

Macの場合

UPNの変更後、Jamf Connectの認証が必要

弊社ではJamf Connectを利用しているため、UPNの変更後に各端末へパスワード同期の通知が届きました。

この通知から新しいドメインのメールアドレスを入力してもらうだけで、ユーザ側の操作は完了です。Jamf Connectスゴイ👍

Macも特にユーザフォルダなどへの影響がなかったため、トラブルはありませんでした。

グループウェアのテナントはそのまま、権限やグループもそのまま？

今回のドメイン変更では、お金も手間も最小限にできました！その理由がこの２つです。

既存のグループウェアのテナントをそのまま利用
ユーザも既存のまま書き換えただけ

社名変更や統合などでドメインを変更する場合、テナントのお引越しをする場合もあると思いますが、今回は純粋にドメイン変更だけが目的だったため、既存のテナントをそのまま利用することができました。

このメリットはなんといっても、
環境・権限がそのまま引き継がれる！！

特にGoogle関連のサービスでは、多数の部署が色々なサービスを利用していたこともあり、なんとかそのままの環境を利用することができないか…という気持ちがありました。
Googleドライブがそのまま使えるのは、本当に助かりました！

唯一Google siteのドメインについては、最初に公開した時のドメインを新しいドメインに変更することができなかったため、サイトのコピーなどで対応が必要でした。

その他対応したこと

SharePoint Onlineのドメイン変更
AzureADフォールバックドメインの変更
各種ロゴの変更
DUNSナンバーの社名変更後に、ABMの社名変更

参考にしたリンク

STORESさん、
社名変更前にアドバイスをいただきありがとうございました！

社名変更に伴うGoogle Workspaceアカウントの引越し手順を解説します

STORESさんのブログ

まとめ

今思い出しても、このドメイン変更は表面上なかなかスムーズに進められたのではないかと思います！
それもこれも、既にSSOに移行ができていたから！
IdPのことだけ気にすればよかったのはとても大きいですねー。

裏側ではとにかく検証、検証、検証・・・でした！
以下の３つを行なって、本番環境と同様の検証環境を作り上げたことで、安心して実行に移せました。

ドメインの取得
Google Workspace Enterpriseの新規契約
Microsoft365 開発者プログラムでテナントの取得

ここでは検証について触れていませんが、実際は検証に一番時間がかかっています。この検証環境はことあるごとに役に立っているので、作ってよかったなーとなっています。

このブログが少しでも誰かの役に立てば幸いです！

※掲載内容は、2023年6月16日時点の情報となります。
※記載されている会社名、サービス名、製品名は、一般に各社の登録商標または商標です。

弊社では、私たちと共に働く仲間を募集中です。
興味がある方は、お気軽にご連絡ください！