ActiveDirectoryとOffice365のID同期で起きた事件(利用開始済みOffice365ユーザーとADユーザーの同期)

こんにちは！

よくあるお話なのですが、Office365を利用するにあたってオンプレのActiveDirectoryとOffice365(AzureAD)のID同期をしたい！！ってことが。。。。

実際それ自体は推奨されていますし、ID管理の上でも実施すべきだな～って僕自身思います！！

今回そんなID同期にて事件発生！(ただの障害なんですが。。。笑)ってことで何がおきたのかとどうすべきだったかを記載して

Office365とADの同期を後から実施することに悩まれてる方がいらっしゃったら参考にしていただけると嬉しいです。

そしてなにより言いたいのは

「お願いだからOffice365の利用開始時にオンプレADとOffice365のID同期やっといて」ってこと！！笑

今回記載する内容は「Office365もオンプレActiveDirectoryもID同期なしで利用スタートしちゃって今からID同期やりたいよ！！！！！」ってパターン

• トラブった内容

今回のケースのご紹介です。

1. すでにオンプレActiveDirectoryとOffice365をID同期なしで利用
2. Microsoft365利用のためにオンプレActiveDirectoryとOffice365のIDを同期したい要件が発生(最終的にはHybridAzureADJoined構成)
3. Office365ではExchange Online,SharePoint Onlineを利用中
4. Exchange OnlineではAliasを利用　←今回これを見逃しました

今回の構成ではオンプレActiveDirectoryとOffice365(AzureAD)間のID同期はAzureADConnectサーバー2台を導入して同期します。

AzureADConnectサーバーは冗長化する場合、1台を「Active」１台を「Staging Mode」として構成します。

※細かいお話は割愛します。知りたいよってかたがもしいたらコメントください。

そもそもオンプレActiveDirectory(以後AD)とOffice365をあとから同期する場合、ユーザー間の紐づけが必要となります。

ソフトマッチやハードマッチといったマッチング方法があるのですが、

今回はソフトマッチを利用しています。

ソフトマッチって何かというと、ADのID情報(AzureADConnectを構築時に指定するパラメータ)とOffice365のID(UserPrincipalName)が一致していたら同一ユーザーとみなして、同期するよってこと！

今回その情報にAD側は「Mail」属性を利用しています。※これを代替IDって呼んだりします。

AzureADConnectのインストール画面にて以下の通り構成しています。

これ失敗するとOffice365に別ユーザーとして複製されてしまい後戻りできないので実施する場合は慎重にやってくださいね！！！(状況によってはなんとかなりますが)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2021/5/13

失敗時に対応方法についても記載したので追記

kbtblog.hatenablog.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

余談ですが、「HybridAzureADJoined」を完了するためにはオンプレActiveDirectoryの「UserPrincipalName」とOffice365の「UserPrincipalName」が一致していないといけないので、HybridAzureADJoinedを利用するよって場合は代替UPNサフィックスを利用してください。

この辺もいつの日か書けるといいなあ。

さらにADとOffice365(AzureAD)間でID同期すると同期したユーザーの情報はADでしか変更することができなくなります。

※現在ExchangeOnlineで利用している値をAD側で変更するためにはAD側にExchangeスキーマ拡張が必要になるケースが多々あるので、事前に利用している値を確認してくださいね！

ありがちな値は「ユーザーをアドレス帳から非表示にする」という項目です。

これはExchangeスキーマ拡張してないとADで操作できないのでご注意ください。

以下のパターンの時(作業前状態図)でも色々考えないといけないことがあります。

作業前状態図

上記図をみていただくとざっとこんな問題が。。。。。。。。。。。

1. ADのドメインが「test.local」
2. ADとOffice365で「UserPrincipalName」「DisplayName」「部署名」が違う
3. ExchangeOnlineで上司情報を利用している(メールルールで上司をCCに強制追加等)
4. （補足）図では分からないのですが、Office365側のユーザーがOffice365管理者の管理者になっていると同期エラーになります。※一度管理者権限を外し、同期を終えてから再度管理者権限を付与してください。

順番に解説していくと

・１について

ADのドメインが「.local」だったとしても、Office365側も「.local」ってことはありえません。

世の中に「.local」なんてドメインがないからです。通常Office365で作成するカスタムドメインは「co.jp」や「.com」だったりします。なので、ADの「UserPrincipalName」を利用してOffice365に同期するとADとドメインが違いただしくユーザー同期をしてくれません。※今回はそもそもADとOffice365の「UserPrincipalName」の情報がずれているのでNGですが・・・・・

・２について

ADとOffice365を同期するとADの情報でOffice365のユーザー情報を上書きします。

そのため、事前にどちらの値を利用していくか決定しておく必要があります。

※今回はOffice365のユーザー情報を利用することとしました。

ADの「UserPrincepalName」をOffice365に合わせるために、代替UPNサフィックスというものを利用しています。

・３について

ExchangeOnlineにてユーザーの上司の情報を利用している場合、ADとID同期すると上司の情報もAD内で設定し同期する必要があります。

しかし、ADで上司設定を使用とすると、フリー入力ではなくAD内のオブジェクト検索でヒットしたものが登録されます。そのため、上司をメールアドレスで検索できず、Office365への登録した際も正しい状態とならないことが想定されます。

※２での対応にも記載の通り、代替UPNサフィックスを利用してADの「UserPrincipalName」をメールアドレスの状態とすることでオブジェクト検索でメールアドレス形式で検索してもヒットするようになります。

色々記載しましたが、結局どうしないといけないかというとこんな感じ「下図(同期直前状態)」です。

ADのユーザー情報を下図の通り変更してから、AzureADConnectを利用して同期します。

同期直前状態

しかし！！！！！！！！

ここで今回の僕の大きな見落としが！

実はExchangeOnlineでメールエイリアスを利用していたのです。。。。

メールエイリアスとは別名としてメインのメールアドレスとは別に受信のみできるメールアドレスを保有するイメージです。

同期前の見落とし

その状態でユーザー同期を実施したために。。。。。。。。。。

Office365側のメールエイリアスが全ユーザー分消えた。。。。。。。。。。

きえた。。。。。。。。。。。これは事件だ。。。。。。

この事件俺が必ず解決して見せる！じっちゃんの名にかけて！！

ふざけてすみません。ほんとに焦りました。

見落とした状態での同期

今回のケースでどうしておかないといけなかったかというと、

AD側の「ProxyAddresses」という属性値にプライマリメールアドレスとセカンダリメールアドレスを登録しておく必要がありました。。。。。

下図「正しい状態(同期前)」の状態にしておくのが正しい状態でした。。。。

今回は事前にユーザーの情報を取得しておいたのでその情報をもとにデータを戻していきました。

正しい状態(同期前)

ADの「ProxyAddresses」という属性に「SMTP:メインのメールアドレス」「smtp:Alias用メールアドレス」として登録することで正しく同期されます。

「SMTP:」がメイン、「smtp:」がエイリアスと覚えてください。

考えるべき内容をざっとまとめてみました。

実施すべき内容は以上です！！！！

が、これって1ユーザーずつやってるとめっちゃ大変なのでは？？？？

って思いますよね

ここでPowershellを利用することで一括登録できます。

※今回はProxyAddressesのみを登録するスクリプトをご紹介します。

需要あればそのうち、UserPrincipalNameやその他値の一斉変更も書こうかな

• Powershellでの変更方法

ADユーザーの情報変更は以下のコマンドレットを利用します。

 Set-ADUser

今回はProxyAddressesに登録するのでこんな書き方です。

 Get-ADUser -SearchBase "CN=Users,DC=test,DC=Local" -Filter {UserPrincipalname -eq "ユーザーA@test.co.jp" } | Set-ADUser -Add @{"ProxyAddresses"="SMTP:メインメールアドレス","smtp:サブメールアドレス"} 

 「-SearchBase」は設定変更するユーザーの検索先OUもしくはCNを指定します。

例では[test.local]内のUsersコンテナ配下を検索するように記載しています。

※例えば下図の「Office365内のUsers」を指定したい場合は「OU=Users,OU=Office365,DC=test,DC=Local」となります。

ただ、複数ユーザーでこれを実施したいので！！

まずはcsvデータを作成します。

SMTPData.csvという名前で作成しています。

変更が必要なユーザー分記載します。(同一OUもしくはCNにいるユーザーである必要があります)

上記ファイルをADサーバ上の以下のフォルダに保管します。

「C:\temp\UPN\SMTPData.csv」

以下内容をスクリプトとして作成します。

#検索対象OU指定
$Searchtarget = "CN=Users,DC=test,DC=Local"

#import用CSVの指定
$Data = "C:\temp\UPN\SMTPData.csv"

#データのインポート
$UserDatas = Import-Csv -Path $Data -Encoding Default

#インポート情報のループ
foreach($User in $UserDatas){
 
        #ユーザー情報のセット
        $Setinfo = 'Get-ADUser -SearchBase $Searchtarget -Filter {UserPrincipalname -eq "' +  $User.UPN + '" } | Set-ADUser -Add @{"ProxyAddresses"="' + $User.Primary + '","' + $User.Second + '"}' 
        Invoke-Expression $Setinfo
}

$Searchtarget = "CN=Users,DC=test,DC=Local" と記載のある箇所は

実際に情報変更したいユーザーが格納されている場所を指定してください。

※1 csvファイルの文字コードを[Shift-JIS]想定で8行目を -Encoding Defaultとしています。違う場合は修正してください。

※2 今回はProxyAddressesに追記する想定のため、14行目で -Addとしていますが、データを置き換えたい場合は-Addではなく-Replaceと記載してくださいね！

CSVファイルに変更が必要なユーザー分データを用意して上記スクリプトを実行することで一斉に変更をかけることができます！

前回に引き続きforeachを利用しています。

とても便利なのでぜひ使ってみてくださいね！

• 最後に！

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！

Follow @KKubo19