こんにちは、富士榮です。
Azure AD Connectを使ってオンプレミスのActive DirectoryからAzure ADへオブジェクトを同期する構成でAzure ADやOffice 365を運用している方にとって非常に大きなインパクトのある動作変更が予定されています。
これまでディレクトリ同期を行う際、しばしば問題になってきたのが、
①複数ドメインからの同期時のオブジェクト重複
②同期元ドメインでの識別子の変更時のクラウド側への反映
です。（もちろん他にもありますが）
これまでは①のオブジェクト重複が発生した際はディレクトリ同期エラーが発生し、対象オブジェクトの同期はスキップされてきました。
同じく②について、特定の条件（Office365を使っている、など）のユーザについてはオンプレミスのuserPrincipalNameを変更してもAzure AD/Office365上のユーザのuserPrincipalName（ログインID）は変更されませんでした。
それぞれの動作の詳細は後述しますが、この動作の制御パラメータの初期値が変更になっています。
◆変更点
2016年8月24日以降に新規に作成されたAzure ADディレクトリでは、①のオブジェクト重複に関するエラーを回避するロジックが走るようになっています。また、既存のディレクトリについても今後強制的に設定の変更が行われ、従来とは異なる挙動をすることになるので一部運用方法の変更が必要な場合があります。
同じく②についても
オンプレミスのuserPrincipalNameの変更がAzure AD/Office365へ反映されるように変更されています。
※ちなみに②については8/24以前にすでに変わっていた可能性があります。①のアナウンスを見て環境を比較していて気が付いたので。
※②は2015年6月～だったそうです。MVP渡辺元気さんに教えてもらいました！
参考URL）
http://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_o365admin-mso_dirservices/%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88/8b7857a5-1afd-4532-84fa-4cc70253622d?auth=1
| ディレクトリ同期機能 | 2016年8月24日までに作成したディレクトリ | 2016年8月24日以降に作成したディレクトリ |
|---|
| 重複属性の回復性 | FALSE | TRUE |
| userPrincipalNameの更新の同期 | FALSE | TRUE |
ちなみに現在の設定がどのようになっているかはConnect-MsolServiceで接続した後で、Get-MsolDirSyncFeaturesで確認することが出来ます。
以下の図は8/24より前に作成したディレクトリ同期の機能の状態です。
こちらは8/24以降に作成したディレクトリ同期の機能の状態です。
良い機会なので、それぞれの機能について簡単に解説をしつつ、動きの違いを見ていきたいと思います。
◆重複属性の回復性
まずは、オブジェクトの重複回避機能です。Azure AD/Office365ではuserPrincipalNameおよびProxyAddressが複数のオブジェクトで重複することを許可していません。
しかし、例えばuserPrincipalNameをオンプレミスのADのuserPrincipalName属性以外の属性（例えばメールアドレスなど）を使ってディレクトリ同期を構成する場合、複数のユーザが同一のuserPrincipalNameを持ってしまうことがあります。
※現状はAlternative LoginIdや別の属性をAzure ADのuserPrincipalNameにマッピングしている構成では重複回避の機能は動作しないので、これまで通りエラーではねられます。ただ、ADでユーザを削除して、Azure ADのゴミ箱からユーザが削除される前に再作成、同期するなど、AD上のuserPrincipalName属性が重複するケース、またuserPrincipalNameが他のユーザのProxyAddressと重複するケースなどが該当します。
従来は先にあげた様にエラーが発生して該当するオブジェクトが同期されることはありませんでしたが、同期パラメータを変更することでオブジェクト同期を検知した時の動作を制御することが出来ます。
該当するパラメータは、
・DuplicateUPNResiliency
・DuplicateProxyAddressResiliency
の2つで、それぞれuserPrincipalNameの重複とProxyAddressの重複に対する動作を制御します。
例えば、DuplicateUPNResiliencyをtrueに設定すると重複するuserPrincipalNameを持つユーザを検知すると、
ユーザ名+ランダムの4桁の数字@デフォルトドメイン名
というuserPrincipalNameが自動的に割り当てられます。
一応同期エラーのメールが飛んでくるので重複が発生したことはわかりますが、従来とは対応方法が変わるので要注意です。
尚、Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflictでエラーが起きているオブジェクト一覧を取得することも可能なので、メールだと気が付かない場合や自動的にアクションをしたい場合はスクリプト化をすることも可能です。
ちなみに、この重複回復機能は一旦trueに設定してもfalseに戻すことも現状（2016/09/30時点）は可能ですが、
今後は戻すことはできなくなります。また、
現在falseに設定されているディレクトリについて、強制的にtrueに設定変更がされるようなので、今のうちに運用への影響を洗い出して対応しておく必要があります。
◆userPrincipalNameの更新の同期
このパラメータは、オンプレミスのADのuserPrincipalName属性が変更された場合に、Azure AD側に変更を同期するかどうかを制御するものでした。
従来（SynchronizeUpnForManagedUsersがfalse）は以下の条件を満たさない限り、オンプレミスのADでuserPrincipalNameを更新してもAzure ADへ変更は同期されませんでした。
・ユーザが管理対象ユーザ（非フェデレーションユーザ）である
・ユーザにライセンス（Office365など）が割り当てられていない
※EMSなどAzure AD系ライセンスだけなら変更は同期される
同期ログを見ると更新がかかったように見えます。
しかし、Office365のライセンスが割り当てられているとuserPrincipalNameは変更されません。
しかし、新しく作成したディレクトリでは初期値がtrueなので、ライセンスの割り当て状況などにかかわらずオンプレミスのuserPrincipalNameの変更がAzure ADへも反映されます。つまり、従来は移行などの都合でオンプレミスのADのuserPrincipalNameを変更してもユーザがOffie365へのログインに使うIDへ影響はありませんでしたが、新しいディレクトリを使っているとログインIDが変更されます。
ちなみに旧UPNはエイリアスとして残ります。
尚、このパラメータは
一度trueに設定すると二度とfalseへ戻せないので要注意です。
つまり、古いディレクトリを使っていてfalseを前提とした運用をしている場合は絶対にtrueに設定をしてはいけません。
（現在はまだアナウンスがありませんが、先の重複回避のパラメータと同様に、どこかのタイミングで強制的にtrueに変更されることも想像できます。今のうちにtrueになってもいいように運用を見直しておくべきかもしれません）
以下、参考ページです。頻繁にアップデートされるので更新情報に注意しておく必要があります。
Azure AD Connect 同期サービスの機能
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnectsyncservice-features/
ID 同期と重複属性の回復性
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnectsyncservice-duplicate-attribute-resiliency/
投稿
