AD/Office365]管理者は要注意。sidebarIdM実験室いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。後は、関連するニュースなどを徒然と。AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更こんにちは、富士榮です。365を運用している方にとって非常に大きなインパクトのある動作変更が予定されています。これまでディレクトリ同期を行う際、しばしば問題になってきたのが、1複数ドメインからの同期時のオブジェクト重複2同期元ドメインでの識別子の変更時のクラウド側への反映です。(もちろん他にもありますが)これまでは1のオブジェクト重複が発生した際はディレクトリ同期エラーが発生し、対象オブジェクトの同期はスキップされてきました。AD/Office365上のユーザのuserPrincipalName(ログインID)は変更されませんでした。それぞれの動作の詳細は後述しますが、この動作の制御パラメータの初期値が変更になっています。ADディレクトリでは、1のオブジェクト重複に関するエラーを回避するロジックが走るようになっています。既存のディレクトリについても今後強制的に設定の変更が行われ、従来とは異なる挙動をすることになるので一部運用方法の変更が必要な場合があります。AD/Office365へ反映されるように変更されています。※ちなみに2については8/24以前にすでに変わっていた可能性があります。1のアナウンスを見て環境を比較していて気が付いたので。※2は2015年6月~だったそうです。TRUEちなみに現在の設定がどのようになっているかはConnect-MsolServiceで接続した後で、Get-MsolDirSyncFeaturesで確認することが出来ます。以下の図は8/24より前に作成したディレクトリ同期の機能の状態です。こちらは8/24以降に作成したディレクトリ同期の機能の状態です。良い機会なので、それぞれの機能について簡単に解説をしつつ、動きの違いを見ていきたいと思います。◆重複属性の回復性まずは、オブジェクトの重複回避機能です。AD/Office365ではuserPrincipalNameおよびProxyAddressが複数のオブジェクトで重複することを許可していません。userPrincipalNameをオンプレミスのADのuserPrincipalName属性以外の属性(例えばメールアドレスなど)を使ってディレクトリ同期を構成する場合、複数のユーザが同一のuserPrincipalNameを持ってしまうことがあります。ADのuserPrincipalNameにマッピングしている構成では重複回避の機能は動作しないので、これまで通りエラーではねられます。ADのゴミ箱からユーザが削除される前に再作成、同期するなど、AD上のuserPrincipalName属性が重複するケース、またuserPrincipalNameが他のユーザのProxyAddressと重複するケースなどが該当します。従来は先にあげた様にエラーが発生して該当するオブジェクトが同期されることはありませんでしたが、同期パラメータを変更することでオブジェクト同期を検知した時の動作を制御することが出来ます。・DuplicateUPNResiliency・DuplicateProxyAddressResiliencyの2つで、それぞれuserPrincipalNameの重複とProxyAddressの重複に対する動作を制御します。DuplicateUPNResiliencyをtrueに設定すると重複するuserPrincipalNameを持つユーザを検知すると、ユーザ名+ランダムの4桁の数字@デフォルトドメイン名というuserPrincipalNameが自動的に割り当てられます。一応同期エラーのメールが飛んでくるので重複が発生したことはわかりますが、従来とは対応方法が変わるので要注意です。PropertyConflictでエラーが起きているオブジェクト一覧を取得することも可能なので、メールだと気が付かない場合や自動的にアクションをしたい場合はスクリプト化をすることも可能です。ちなみに、この重複回復機能は一旦trueに設定してもfalseに戻すことも現状(2016/09/30時点)は可能ですが、今後は戻すことはできなくなります。現在falseに設定されているディレクトリについて、強制的にtrueに設定変更がされるようなので、今のうちに運用への影響を洗い出して対応しておく必要があります。AD側に変更を同期するかどうかを制御するものでした。ADへ変更は同期されませんでした。AD系ライセンスだけなら変更は同期される同期ログを見ると更新がかかったように見えます。Office365のライセンスが割り当てられているとuserPrincipalNameは変更されません。ADへも反映されます。従来は移行などの都合でオンプレミスのADのuserPrincipalNameを変更してもユーザがOffie365へのログインに使うIDへ影響はありませんでしたが、新しいディレクトリを使っているとログインIDが変更されます。ちなみに旧UPNはエイリアスとして残ります。このパラメータは一度trueに設定すると二度とfalseへ戻せないので要注意です。古いディレクトリを使っていてfalseを前提とした運用をしている場合は絶対にtrueに設定をしてはいけません。(現在はまだアナウンスがありませんが、先の重複回避のパラメータと同様に、どこかのタイミングで強制的にtrueに変更されることも想像できます。今のうちにtrueになってもいいように運用を見直しておくべきかもしれません)以下、参考ページです。頻繁にアップデートされるので更新情報に注意しておく必要があります。AD/Office365]管理者は要注意。よりアクセス解析を行っています。品質向上のみを目的とし、個人の特定などを目的とはしておりません。中で公開されることはあります。問い合わせ不明点等は管理人までご連絡ください。本プライバシーポリシーは予告なく変更/削除することがあります。プライバシーに関するトラブルについては一切の責任を負いかねますのでご了承ください。