皆さんこんにちは。国井です。
今日は普段のトレーニングで時間の都合や優先順位の関係上、省略してしまうことの多いAzure ADの基本機能について紹介します。今回はAzure AD Connectの代替として期待されているAzure AD Connectクラウド同期についてです。
Azure ADクラウド同期とはオンプレミスActive Directoryのユーザーやグループの情報をAzure ADに同期するサービスで、まさにAzure AD Connectの代わりとなるサービスです。
ADの情報を同期すると言ったら今まではAzure AD Connectを使っていましたが、Azure AD Connectを利用しようと思ったらアプリケーションをインストールしなければならず、さらに(必要に応じて)アプリケーションの設定をAzure AD Connect側で行う必要がありました。
それに対してAzure AD Connectクラウド同期の場合、Azure AD Connectをインストールしたときに利用可能なSynchronization ServicesやSynchronization Rules Editorなどのツールに相当する機能をクラウド側で持つため、Azure AD Connectのサービスや設定のバックアップを考える必要がないというメリットがあります。(本当はMSがデータセンターに保存しているデータを消してしまうようなトラブルがあった時のためのバックアップは必要なんでしょうけどね)
では、Azure AD Connectクラウド同期を利用しながら、
Azure AD Connectとの違いを見ていきましょう。
インストール
インストールって、、さっきAzure AD Connect入れなくていいって言ったじゃない！と思うかもしれませんが、クラウド同期を行うためのエージェントはインストールする必要があります。
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期を管理する をクリックして、エージェントをダウンロードし、ドメインコントローラーにインストールします。
Azure AD Connectではプロビジョニングエンジンそのものをインストールするため、一元的な同期が実現できるよう、アクティブーパッシブの構成をとるとき以外は複数のサーバーにAzure AD Connectをインストールしてはならないというルールがありました。
しかし、クラウド同期の場合は複数のドメインコントローラーにエージェントをインストールして冗長構成にすることができます。
Azure AD Connect cloud syncの構成
Synchronization ServicesやSynchronization Rules Editorを通じて設定するはずの構成は
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期 のメニューから[新しい構成]をクリックして設定します。
設定画面はこちら。
①から順番に設定していきます。
①ではエージェントをインストールすることによって同期元のADドメインは既に認識しているので、ドメインの中のどのグループ/OUを同期対象にするかをスコープフィルターで設定します。対象となるグループやOUはDNで指定します。DNってOU=xxxx,DC=contoso,DC=comみたいに書く設定のことです。
ちなみにAzure AD Connectだと10GB(オブジェクト数で言うとおよそ10万)を超える場合、SQL Serverが必要になりますが、クラウド同期に10GBの上限はないので大規模環境だとコスト的なメリットがあったりします。
②ではSynchronization Rules Editorで設定していた属性マッピングの設定です。
以前、このブログでADユーザーの国/地域の属性をAzure ADユーザーの利用場所属性にマッピングさせる設定というのを紹介しましたが、こうした設定を含むマッピング設定がクラウド側で定義できます。
(ちなみにマッピング設定はユーザー、グループ、連絡先と別々のタブで用意されています)
利用場所属性のマッピング
Azure ADの利用場所属性はusagelocationなので、usagelocation属性のソース属性側(右側)で属性に入れる値を定義します。
デフォルトではmsExchUsageLocation属性を引っ張ってくる設定になっていますが、
ADの国/地域属性を利用するように設定するなら
IIF(IsNullOrEmpty(),”JP”, )
と入れてあげれば国/地域属性がセットされ、ADの属性値が空ならJPの値が自動的に入るようになります。
代替ログインIDの設定
代替ログインIDをAzure AD Connectで利用するときにはウィザードの中で属性を定義していましたが、クラウド同期で同じことをする場合は②の中で定義します。例えば、ADユーザーのmail属性をAzure ADユーザーのUPN属性として使いたい場合はこんな感じで設定します。
って紹介しようと思ったら画面が切れちゃって見えないので、こちらで紹介します。
IIF(IsPresent([mail]), [mail], IIF(IsPresent([userPrincipalName]), [userPrincipalName], Error(“AccountName is not present”)))
mail属性が値が入っていればmail属性をそのままUPN属性へマップ、そうでなければADのUPN属性をマップするように設定してみました。
ただしProxyAddresses属性にメールアドレスが入っている場合はマップさせる方法がないんですよね。。ProxyAddresses属性に入るメールアドレスって、SMTP:に続く文字列だけをマップさせなければならないのですが
Mid(Item([proxyAddresses],Contains([proxyAddresses], “SMTP:”)),6)
のような書き方ができないんですよ(Contains関数が使えない)。
色々書き方を工夫してみたのですが、タイムアップで挫折してしまいました。
※クラウド同期ではAzure AD Connectで利用可能だった関数すべてをサポートしているわけではなく、このことが互換性の上で課題になるケースがありそうです。
Azure AD Connect cloud syncの構成に話を戻します
属性マッピングの話が長くなりましたが、クラウド同期構成に話を戻します。
②の部分でマッピング設定ができたら、同時にパスワードハッシュ同期を行うか選択します。
この時に注意したいのはパスワードハッシュを同期しなかったらパススルー認証になるのか？と言ったらパススルー認証しない(というかできない)点です。(じゃあ何のためにあるんだ？とつっこみたくなりますが、恐らくADFSのためにあるのでしょう)
また、Azure AD Connectでは一部のユーザーだけパスワードハッシュ同期するように構成できますが、クラウド同期ではその選択肢はありません。
以上の設定ができたら、続いて③を利用して同期の検証を行います。
③の[ユーザーのプロビジョニング]ボタンを押して、同期させたいADユーザーのDNを指定すると、そのユーザーだけがAzure ADに同期されます。(※Azure AD Connectに用意されているInvoke-ADSyncSingleObjectSyncコマンドレットとおなじものとお考え下さい)
そしてその結果をみて問題がなければ、最後に⑤の部分で[有効にする]を選択すれば同期が始まります。
なお、docsの説明には以下の内容が書かれています。
エージェントは再起動時 (およびその後 10 分ごと) にブートストラップ サービスを呼び出して、構成に更新がないか確認します。
このことから同期は10分間隔で行われることになります。Azure AD Connectだとパスワードの同期はPCNSコンポーネントを利用することによりリアルタイムに近い形で行われますが、クラウド同期だとPCNSを利用している様子はなく、他の属性と同じようにパスワードを同期していました。(ウラが取れないので確かなことは言えないのですが..)
Azure AD Connectはもう要らないのか？
ここまでの設定でクラウド同期が始まり、Azure AD Connectなしでの同期が実現します。
すると次にAzure AD Connectはもう要らないのか？という疑問が出てきます。
将来的にはAzure AD Connectをインストールしなくても良い世界を目指していることはなんとなくわかりますが、現時点では足りていない機能がたくさんあります。
代表的なのがコンピューターアカウントの同期です。コンピューターアカウントの同期はハイブリッドAzure AD参加という機能に必要なもので、これが利用できないと条件付きアクセスの一部機能が利用できなくなるので困る人は多いと思います。そのほか、オンプレミスAD以外のディレクトリに接続して利用できないことや、パスワード等のライトバックがりようできないなど、本稿執筆時点では一部の人が困る機能制限が色々あるのです。詳しくはMicrosoft docsで確認してもらえればと思いますが、すべての会社にお勧めできる状況でないことがわかります。
今すぐ同期を実行したい
ここからは思いつくままに書いていきます。
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期 のメニューからクラウド同期構成の編集画面を開き、[同期の再開]をクリックすれば今すぐ同期が始められます。
エージェントをインストールしたコンピューターから同期を始めたければMicrosoft Azure AD Connect Provisioning Agentサービスを再起動すればOKです。
同期の結果を確認する
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期 のメニューから[状態]欄の[正常]と書かれたところをクリックすれば
結果が確認できます。
またオブジェクト単位での結果(ログ)を参照したければ、上の画面から[ログ]をクリックすればCSVまたはJSON形式でダウンロードできます。
ただしSynchronization Serviceで見てきたログとはフォーマットが違う点に注意です。
複数のADドメインと同期
エージェントをインストールするときに複数のドメインを指定できます。
既存のAzure AD Connectから移行は可能？
可能です。移行方法に関するドキュメントがdocsに記載されていました。
docs内の説明でcloudNoFlow属性のくだりなどイマイチ理解できないところがあるのですが、自分自身が検証した限りではAzure AD Connect側の同期設定を停止し、クラウド同期のエージェントをインストールすれば、そのまま切り替えることができました。
ちなみにAzure AD Connectをインストールしたサーバーとクラウド同期のエージェントをインストールするサーバーは同一のサーバーでも動作していました。
一意のユーザー識別の設定変更は可能？
Azure AD Connect cloud syncの構成画面からソースアンカーの設定変更はできません。
また、Azure AD Connectから移行を行う際のdocsドキュメントに次のようなことが書かれています。
Azure AD Connect 同期のソース アンカーが objectGuid または ms-ds-consistencyGUID であること
チュートリアル – 既存の同期済み AD フォレストに対して Azure AD Connect クラウド同期のパイロットを実施する | Microsoft Docs
以上のことからソースアンカーを変更したクラウド同期の運用は不可能なものと考えています。
所属OUの情報を同期させられるか？
ADにあって、Azure ADにない概念にOUがあります。似たような概念でAUっていうのがあるんだけど、Azure ADでOUを使いたいと言っている人の多くはOUの中にいるユーザーだけが管理画面に表示されるようにフィルターをかけたいんだと思うんです。
そこで私はOUの情報を含むDNをAzure ADの会社名属性にマップしてあげました。
CStr([distinguishedName])と書けば、DN属性が文字列として会社名属性に入ってくるので、こうすれば会社名でOUの名前による検索がかけられます。
ところが、Azure AD管理センターのフィルター設定って前方一致しかできないんですよ！
というわけで、ADからとってくるDN属性のうちOU=で始まる部分だけを切り出してマップしなければならないのですが、うまく切り出せないんですよね。。
何かいい方法があったら誰か教えてください！
■ ■ ■
ここまでのところでクラウド同期について見てきました。
繰り返しになりますが、クラウド同期には利用できない機能があるので、
自社での要件と照らし合わせて利用可否については決定するようにするとよいでしょう。
