2015年1月16日金曜日

[AADSync/DirSync]同期に使うAzureAD管理者アカウントの管理

twitterで少し話題に上ったので、色々と調べ&試してみました。

きっかけは、複数企業(マルチドメイン)で一つのAzure Active Directory(AzureAD)テナントを共同利用するようなケースにおいて、各企業のオンプレミスActive Directoryから各社のユーザをAADSyncやDirSyncを使って同期する場合にAADSyncやDirSyncに設定するAzureADの管理者アカウントをどのように管理するべきなのか?という議論でした。

同期に利用するAzureAD上のユーザアカウントはテナントの全体管理者の権限が必要なので、同じAzureADテナント上のユーザやグループであれば他企業のものであっても管理することが権限上は可能となってしまいます。

参考)AADSyncに必要なAzureADアカウントの権限等
 http://msdn.microsoft.com/en-us/library/azure/dn757602.aspx
 ・必要な要件
  全体管理者ロールを持ったアカウントを利用すること
 ・推奨事項
  ①パスワード期限を無期限に設定すること(パスワードを16文字以上の強固なものにすること)
  ②AADSync専用のアカウントを作成すること


そこで、各AADSyncに設定する管理アカウントの権限をうまく制限出来ないか?という話になります。

まず、テナント内のユーザ情報の閲覧・更新を行うには、以下の4つの方法が考えられます。
①管理ポータルへアクセスする
②PowerShellのコマンドレット(Get-MsolUser等)を使う
③AADSyncの内部(Connector Space)を参照する
④GraphAPIを使う

AADSyncに設定するユーザで上記①~④を実行できなければよいのですが、結論としてはすべてを満たすのは無理なのですが、それぞれどのような状態になるのかを紹介してみます。

①管理ポータルへのアクセスを制限する
 これは比較的簡単です。
 単純にAzureのサブスクリプションを対象のアカウントに紐づけなければ済む話です。
 管理ポータルにアクセスしても以下の画面が表示され、ディレクトリの管理までたどりつけません。



②PowerShellのコマンドレットの実行を制限する
 まず、テナント中の特定ドメインのユーザのみを管理する、という思想がないのでコマンドレットの内部での権限分離は絶望的です。
 となると、コマンドレット自体を実行できないようにするには?という話になってきます。

 対策案としては、各企業に配る同期用ユーザのMFA(多要素認証)を有効にしてしまう、ということが考えられます。こうすれば勝手に各企業管理者が同期用ユーザを使って何かをしようとしても追加認証(例えばSMS通知)を抑えておけば勝手にログインすることはできなくなります。(当然管理ポータルへもログインできなくなります)

 これで問題ないのではないか?と思い、いざAADSyncの設定を行おうとすると認証エラーが出てしまいます。


 ちなみに設定時はMFAを設定せずに後からMFAを設定すると同期エラー(stopped-extension-dll-exception)が出ます。


 イベントログを見るとやはり認証エラーが出ています。



 次に試すのは多要素認証をONにして、アプリケーションパスワードを使ってAADSyncの設定をしてみます。
 結果、エラー内容は変わりますが、やはりだめです。



Technetのアプリケーションパスワードの説明を見ると、以下の記述があります。(強調は筆者追加)
 http://technet.microsoft.com/ja-jp/library/dn270518.aspx

[多要素認証をサポートしないブラウザー以外のクライアントに必要なアプリ パスワード] 多要素認証がユーザーのアカウントで有効になると、Outlook や Lync などの大半のブラウザー以外のクライアントでアプリ パスワードを使用できますが、そのユーザーが管理アカウントを保持している場合でも、Windows PowerShell などのブラウザー以外のアプリケーションではアプリ パスワードを使用した管理操作は実行できない点に注意してください。Powershell スクリプトを実行するための強力なパスワードでサービス アカウントを作成し、そのアカウントで多要素認証を有効にしないでください

クライアントがオンプレミスとクラウドの両方の自動検出エンドポイントと通信するハイブリッド環境ではアプリ パスワードは機能しない - オンプレミスでの認証にはドメイン パスワードが必要で、クラウドでの認証にはアプリ パスワードが必要なので、クライアントがオンプレミスとクラウドの両方の自動検出エンドポイントと通信するハイブリッド環境では、アプリ パスワードが機能しないことに注意してください。


 中々対応は難しそうです。
 ただ、このあたりを見ると
 「現在、Windows PowerShell 用 Azure Active Directory はアプリ パスワードに対応していません。」
 とあるので、将来的にはサポートするのかも知れません。


③AADSyncの内部(Connector Space)を参照を制限する
 Synchronization Service Manager(miisclient.exe)の利用を制限することは無理ですので、Connector SpaceやMetaverseの中身を見ればAzureADからのImportやSynchronizationジョブで同期されたユーザ一覧が参照できてしまいます。
 ここで自社のユーザ以外を見れなくしようとするとあらかじめルールエディタでフィルタを設定する必要がありますが、当然あとから設定を変えることも可能なので、完全に制限をかけるのは無理です。



④GraphAPIを使わせない
 これは割と簡単です。
 GraphAPIを使うにはAzureAD上にクライアントアプリケーションを登録する必要がありますが、登録作業は管理ポータルから実施するため、①の方法で管理ポータルへアクセスできないようにしておけばOKです。



◆まとめ
現状、同一AzureADテナント内に複数ドメインをホストし、ドメイン毎に管理アカウントの権限を完全に分離するのは不可能
⇒MFAを有効にしたり、アプリケーションパスワードを使うとAADSyncでの同期に支障が出るので対策とはならない。

とりあえず、セキュリティの境界を分けたければテナントを分けましょう、ということですね。


6 件のコメント:

タケ さんのコメント...

Azure ADにAADAync専用のドメインを追加し、Federated設定をすることでADFSなどでAADSyncのみのアクセスに制限できないでしょうか。このときユーザーエージェントで判定することになると思いますが、問題はその中にAADSyncを判別できるものが含まれているかということと、ユーザーエージェントはわりと簡単に偽装できてしまうことでしょうか。

Naohiro Fujie さんのコメント...

コメントありがとうございます。

AADSyncやPowerShell用にFederated Userをそもそも使えないんです。
SAMLやws-federationで外部のIdPへリダイレクトする部分の実装がHTTP依存なので基本はブラウザ(もしくはWebViewなどのブラウザコントロール)向けの仕組みなので。

タケ さんのコメント...

返信ありがとうございます。PowerShellではWS-TrustもしくはSAML-ECPでFederated Userをつかえた記憶がありますが、ちょっと記憶違いかもしれません。時間があるときに確かめてみようとおもいます。

Naohiro Fujie さんのコメント...

ありがとうございます。
確かにPowerShell⇒サインインアシスタント⇒AzureAD⇒(ws-trust)⇒AD FSという経路ならアクセスでいけそうですね。(Lyncのコミュニケータと同じパターン)
アクセス制限は難しそうですが。。。

Naohiro Fujie さんのコメント...

軽く試してみました。行けますね。

アクセス制御についてもネットワークレベルで実装すれば大丈夫みたいです。
またBlogに書きますが、Active(ws-trust)エンドポイントのみをパブリックURLに設定し、PassiveエンドポイントはプライベートURLすると、AADSyncおよびPowerShellだとアクセス出来るけどブラウザ経由だとADFSにリーチ出来ないのでアクセスできない、という構成が出来ました。
(もちろんPowerShellでアクセスできてしまうので、他の企業のユーザ一覧を参照できてしまうことには変わりありませんが。。。)

Naohiro Fujie さんのコメント...

引き続きuser-agent(x-ms-client-user-agent)をトレースしてみましたが、PowerShell、AADSyncなどサインインアシスタントを使っているモジュールはMSOIDSVC.EXEを含む値になり、AADSyncだけ通してPowerShellは通さない、という制御は難しいようです。