[AAD Connect]特定のドメインコントローラからIDを同期する

こんにちは、富士榮です。

Azure AD Connect（AAD Connect）を使ってオンプレミスのActive DirectoryからAzure Active Directory（Azure AD）へIDを同期する際、実環境においては同期元となるADドメイン上に複数のドメインコントローラが複数サイトに配置されている場合が多いと思います。

そのような場合、同期元とするドメインコントローラをある程度固定することでレプリケーションのタイムラグなどによる無用なトラブルを回避することが可能です。

※Forefront Identity Manager（FIM）やMicrosoft Identity Manager（MIM）を使っている方なら普通に行う設定ですが、AAD Connectについても考え方は同様で、正式にサポートされている方法です。


早速設定方法を見てみます。

◆AAD Connectの初期状態

複数ドメインコントローラが存在する環境にAAD Connectをインストールした状態です。
今回はds1-addsとds2-addsという2台のドメインコントローラを用意し、ds2-addsにAAD Connectを同居させているので、初期状態では自動的にds2-addsが同期元として選択されました。（基本的にネットワーク的に近い（ICMPのレスポンスが早い）サーバが自動選択される仕組みのはずです）

Synchronization Service Managerを開いて同期履歴を見ると使われたドメインコントローラがわかります。

AD DSの管理エージェントの設定の[Last used]を見ても確認できます。

◆同期元とするドメインコントローラを設定する

いよいよ同期元となるドメインコントローラを設定します。
同じくSynchronization Service ManagerのConnectorsメニューよりAD DS管理エージェントの設定を開き、[Only use preferred domain controllers]にチェックを入れ、[Configure]を開きます。

ここで使用するドメインコントローラのFQDNを入力・設定します。

この設定を行うことにより、設定したドメインコントローラからのみIDが同期されるようになります。

再度同期ジョブを流すと設定したドメインコントローラが使われることがわかります。

◆優先ドメインコントローラが停止している場合の動作

先に設定した状態だと、優先設定したドメインコントローラからのみしか同期が行われないため、設定したドメインコントローラが停止していると同期エラーが発生してしまいます。

この事態を回避するためにはPreferred DCに複数のドメインコントローラを設定するか、[Only use preferred domain controllers]のチェックを外しておきます。

こうすることで優先ドメインコントローラが停止していたら、他のドメインコントローラを使って同期ジョブが実行されるため、同期が停止することはありません。



まとめると、以下のような動作となりますので環境に応じて設定を変更してうまく運用していきましょう。

DC1	DC2	Preferred DC	Only use preferred domain controllers	同期ジョブ
起動	起動	DC1	チェックON	DC1を利用して同期実行
停止	起動	DC1	チェックON	同期エラー
起動	起動	DC1	チェックOFF	DC1を利用して同期実行
停止	起動	DC1	チェックOFF	DC2を利用して同期実行

[AADSync/MIM]プロキシサーバ経由でID同期を行う

こんにちは、富士榮です。

企業内からOffice365などのSaaSアプリケーションをAzure Active Active Directory（Azure AD）経由で使う場合、オンプレミスのActive Directory上のアカウントをAzure AD Sync（AADSync）やMicrosoft Identity Manager 2016（MIM）のAzure AD Connectorを使って同期するのが一般的なシナリオです。

しかし、ほとんどの企業のネットワークには厄介なことにプロキシサーバが配置されており、AADSyncなどクラウド上のサービスに直接通信を行うサーバーを導入する際、どこに配置するのか非常に悩んだり、面倒な申請を上げてプロキシのバイパス設定や、場合によってはネットワーク機器のフィルタリングやルーティング設定を変更する必要性が出てきたりします。

本格導入をする場合は、その辺りの環境の洗い出しや構成変更についても覚悟をもって構築作業をするのでしょうが、開発環境やテスト環境として使う場合はそこまで大掛かりな準備をする手間がかけられず、困ることが多いと思います。

そのようなケースにおいてAADSyncやMIMがプロキシサーバを参照して動作するための設定を行う必要があります。

ケースとして以下の3つのパターンに対応することが可能です。
1. 認証なしのプロキシサーバを使っている
2. BASIC認証が必要なプロキシサーバを使っている
3. NTLM認証が必要なプロキシサーバを使っている

それぞれについてどのように対応するか解説していきます。


1. 認証なしのプロキシサーバを使っている

このケースは比較的簡単です。
マイクロソフトのサポートサイトにも情報が記載されており、具体的には「C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config」にプロキシサーバに関するエントリを追加して再起動するだけです。

　サポートサイト
　https://support.microsoft.com/en-us/kb/3013032

以下のエントリをConfigurationブロックの最後に追記します。

<system.net>
  <defaultProxy>
    <proxy
      usesystemdefault="true"
      proxyaddress="http://[Proxyサーバアドレス]:[ポート番号]"
      bypassonlocal="true"
    />
  </defaultProxy>
</system.net>

2. BASIC認証が必要なプロキシサーバを使っている

ここからが少しトリッキーになってきます。

先のmachine.configには認証に使うユーザIDやパスワードを記載することが出来ないので、認証プロキシとAADSync/MIMの中間に認証なしのプロキシサーバを挟み、上位プロキシへフォワードさせる際に中間のプロキシサーバから認証情報をつける、ということを行います。

上位のプロキシサーバがBASIC認証を使う場合は、squidを使うことで対応することが可能です。

※尚、中間プロキシサーバの要件としては①http/httpsを上位プロキシサーバへフォワード出来ること、②フォワード時にBASIC認証に対応できることの2点なので、squid以外でも対応できるものがあるかもしれません。

今回はAADSyncサーバにWindows版のsquidを同居させました。

　Windows版squidのダウンロード

　http://squid.acmeconsulting.it/download/dl-squid.html

C:\squid以下にダウンロードしたモジュールを展開し、etcフォルダ以下のmime.conf.defaultをmime.confへリネームし、以下の内容のsquid.confを新規作成します。

（今回は限定的な用途なので、最低限のエントリだけしか記載していません。ログなど出したければsquid.conf.defaultを参考に追記してください）

acl all src all
acl localhost src 127.0.0.1/32
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl CONNECT method CONNECT
acl SSL method CONNECT
never_direct allow SSL
http_access deny !Safe_ports
http_access allow localhost
http_access deny all
http_port 8080
cache_peer [上位プロキシサーバのアドレス] parent [ポート番号] 0 login=[ユーザID]:[パスワード]

これでsquidを起動し、先のmachine.configのプロキシサーバ設定にlocalhostを指定すればAADSync/MIMはsquidを、squidは本来のプロキシを参照する形でインターネットへ接続できるようになります。

3. NTLM認証が必要なプロキシサーバを使っている

最後が、Windows統合認証を使っている認証プロキシです。ISAとかですね。（古）

この場合も考え方は同じですが、squidがWindows統合認証に対応していないので、Cntlmというフリーウェアを使うことで対応している例があるようです。

　Cntlmダウンロードページ

　http://cntlm.sourceforge.net/

細かい方法は今回は省略しますが、Cntlmの設定ファイル（iniファイル）に認証に使うユーザ名、ドメイン名、パスワードを記載してサービスを起動、上位プロキシサーバを参照させる、という方法をとります。

旧Forefront Identity Manager（FIM）、現Directory ServicesのMVPも在籍しているオーストラリアのkloudという会社のblogで紹介されているので、詳しくはそちらを見てください。

　kloudのblog

　http://blog.kloud.com.au/2014/12/19/using-a-proxy-with-azure-ad-sync-services/

尚、上記で紹介したのはあくまで開発・テスト時の使用にとどめておいた方が良いと思います。障害ポイントを増やすだけですし、思わぬトラブルが発生した時に切り分けが難しくなる場合もあると思われますので。

[AAD Connect]LDAPからOffice365へID同期する

こんにちは、富士榮です。

先月正式リリースされたAzure Active Directory Connector（AAD Connector）ではOffice365のアイデンティティ基盤であるAzure Active Directory（Azure AD）へのID同期元として、現状はオンプレミスのActive Directoryが利用できます。
また、今後の拡張プランとしてオフィシャルにActive Directory以外のLDAPディレクトリについても同期元として設定できるようになると思われます。（※あくまで想定です）

　参考）
　[AzureAD]AAD ConnectとConnect HealthがGAになりました
　http://idmlab.eidentity.jp/2015/06/azureadaad-connectconnect-healthga.html

ただ、現状においてもユーザ拡張管理エージェントであるExtensible Connectivity 2.0（ECMA2）を使用してユーザ自身でID同期元を定義することが可能なため、自身でECMA2を利用してLDAP接続コネクタを作成すればオンプレミスにデータソースとして使えるActive Directoryが存在しなくてもLDAPを同期元としてOffice365のアカウントを管理することが可能になります。

今回はECMA2ベースでLDAPコネクタを開発してAAD Connectに設定して、、と思いましたがForefront Identity Manager 2010 R2（FIM）用のGeneric LDAP ConnectorがECMA2ベースだったはず、と思いこちらを使ってみました。（自身で拡張エージェントを開発して設定する分にはサポートされる様ですが、このコネクタを使うのは恐らくサポート外だと思われます。実際に使う場合は自身で開発をした方がベターでしょう）

◆準備

・LDAPサーバ
今回、OpenDJを用意しました。
こちらは特にセットアップ方法などは省略します。

・LDAP接続用の管理エージェント
こちらからFIM用のGeneric LDAP Connectorは入手できますので、ダウンロードしてAAD Connectサーバへ配置しておきます。

　ダウンロードページ
　http://www.microsoft.com/en-us/download/details.aspx?id=41163

セットアップするとモジュール（dllおよびxml）が展開されますが、あくまでFIMのディレクトリ構造を想定して展開されるので、このままではAAD ConnectのAAD Syncがモジュールを認識できません。

そこで、必要なファイルを手動で移動します。

移動元）
　C:\Program Files\Microsoft Azure AD Sync\Synchronization Service
　⇒この下にExensions/UIShellというフォルダがあり、必要なファイルがあります。
移動先）
　C:\Program Files\Microsoft Azure AD Sync
　⇒同じくExtensions/UIShellフォルダがありますので、それぞれファイルを移動します。


◆コネクタの作成

AAD ConnectのSynchronization Service Managerを起動し、[Connectors]メニューより[Create]をクリックして新規コネクタを作成します。

先に用意したOpenDJへの接続情報を入力していきます。

まずは接続情報です。

次に、対象のツリーです。

そして、対象とするオブジェクトの種類（objectType）です。

属性については特に選択しておく必要はありません。


また、作成が終わったら[Configure Run Profiles]で[Full Import]および[Full Synchronizatio]のプロファイルを作っておきます。（今回は同期元として設定するだけなのでこの2つだけで大丈夫です）


◆同期ルールの作成

今度はAAD ConnectのSynchronization Rules Editorを起動し、Inboud Synchronization Ruleを作成します。

まずは接続するコネクタの定義です。
Connected Systemに先に作成したLDAPコネクタを、Object Typeに同じくinetOrgPersonを、今回はユーザ情報の同期なのでMetaverse Object Typeにperson、Metaverse上にユーザを作成するためのルールなのでLink TypeをProvisionに設定します。
※ちなみにPrecedence（優先度）は他の同期ルールと重複しない値を設定する必要があります。

次にScoping filterの定義です。ここではLDAP上のエントリの中でAzure ADに同期するエントリを絞り込むことができます。
ここではmail属性に値が入っているユーザのみを同期対象としています。

次にMetaverse上のオブジェクトとのマッチングするためのルール（Join rules）を定義します。
ここでは、mail属性がMetaverse上のユーザのuserPrincipalNameと同じ値だったら同じオブジェクトとみなすという設定をしています。

最後に各属性のマッピングです。
Azure ADへ同期するためには、accoutName/sourceAnchor/userPrincipalName/accountEnabled/sourceObjectTypeといった属性が必要なので、givenNameなどの一般属性に加えてそれらの属性についても値を設定しています。
ちなみにaccountEnabledには固定でtrueを、sourceObjectTypeには固定でUserを設定します。

これで設定は終了です。


◆実際に同期する

まず、OpenDJに同期対象のユーザを作成します。
同期条件にmail属性に値が入っていること、を設定したのでE-Mailに値を入れています。
また、同じくmail属性をuserPrinicipalNameにしているので、Azure AD/Office365に設定したカスタムドメインとドメインパートを合わせておく必要があります。

ここまで来たら実際に同期します。
実際に運用する時はスクリプトで実行することになりますが、今回は手動でRun Profileを実行します。
まずは、OpenDJからのFull Import/Full Synchronizationを実行します。

うまく行くとOutbound SynchronizationにAzure ADのコネクタへのProvisioning Addsにカウントが出て来ますので、次にAzure ADコネクタのRun ProfileのExportを実行します。
こちらも問題なく終わるとAddsにカウントが表示されます。

ここまで行けばAzure ADの管理コンソールからユーザの確認ができます。
後はOffice365のライセンスを付与するなりなんなりすれば普通に使うことができます。

後は応用なので、例えばOpenDJをレポジトリとしてOpenAMを構成してAzure AD/Office365とFederationすればオンプレミス側はOSSのみで構成ということも可能になります。
※OpenAMとの連携は以下のエントリを参考にしてください。
　本エントリとよく似たことを前回もやっていますが、当時はOutboundを中心に書いていたので、Inboundについては今回のエントリを参考に構成してください。

　[Office365/AzureAD]OpenAMとのID連携①
　http://idmlab.eidentity.jp/2014/11/office365azureadopenamid.html

　[Office365/AzureAD]OpenAMとのID連携②
　http://idmlab.eidentity.jp/2014/12/office365azureadopenamid.html

　[Office365/AzureAD]OpenAMとのID連携③
　http://idmlab.eidentity.jp/2014/12/office365azureadopenamid_25.html

[AzureAD]AAD ConnectとConnect HealthがGAになりました

ついにAzure AD ConnectとConnect Healthが一般公開されました。

公式blog）Azure AD Connect & Connect Health is now GA!
　http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

それぞれを一言で紹介すると以下の通りとなります。

モジュール	解説	主な機能
Azure AD Connect	Azure ADとオンプレミスADのハイブリッド構成（SSO、ID同期）を構成するためのツール群	AD FS/AAD Syncの簡単設定機能 マルチフォレストAD連携、非ADのオンプレミスIdPとのID同期
Connect Health	AD FSのモニタリングツール	リクエスト数、ログインエラー数などのモニタリングとグラフィカル表示

今回はAAD Connectの方を中心に紹介したいと思います。


◆AAD ConnectのリリースによりDirSyncおよびAAD Syncの個別リリースが終了

重要なポイントですがAAD Connectがリリースされたことにより、DirSyncおよびAAD Syncについては今後個別のモジュールとしてリリースされることはありません。今後はAAD Connectの更新として提供されることとなります。

Azure AD Connect incorporates the components and functionality previously released as Dirsync and AAD Sync. These tools are no longer being released individually, and all future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

出典）https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-learn-more/


◆AAD ConnectではActive Directory以外のIDストアもサポート

現状ではまだExpress Settings（簡単設定）を行うためにはActive Directoryが存在する環境でしかAAD Connectの設定はできませんが、今後はActive Directory以外のIDストアをベースにAzure ADと同期を行うことができるようになると思われます。

Ignite 2015のセッションスライド。他のIDストアとの接続が明示されている。

ドメイン参加していないサーバにAAD ConnectをセットアップしようとするとExpress Settingsは使えないもののセットアップ・ウィザードは先に進められる。

オンプレミスのIDストアの設定にDirectory Typeというプルダウンが存在する。（現在はActive Directoryしか選択できないが）

Synchronization Managerの初期状態で管理エージェントとして以下の3種類が選択できる。

• Active Directory Domain Service
• Azure Active Directory
• Extensible Connectivity 2.0（ECMA2.0）

◆その他

ウィザードの最後にドメイン参加したWindows 10のデバイスの情報をAzure ADと同期するためのオプションについての記載もあり、今後のハイブリッドシナリオの拡張を予感させます。

今後はこのツールがAzure ADとのハイブリッドシナリオでは主役となるはずなので、他の拡張要素についても今後紹介していこうと思います。
しかし一昔前に比べてものすごく簡単にセットアップができるようになったもんです・・・。

[FIM]汎用REST管理エージェントをリリースしました

Google AppsがProvisioning APIのサポートをやめる、という発表があってから、以前リリースしたGoogle Apps用管理エージェントの更新をしないと、、、と思っていたのですが、ようやく対応することが出来ました。
今年の4/20に廃止なので、かなりギリギリになりましたが。
実は前のGoogle Apps管理エージェントがインドあたりで大規模に使われていたりするらしく・・・

Google Provisioning API
　https://developers.google.com/google-apps/provisioning/

現在公開しているGoogle Apps用管理エージェント
　https://fim2010gapps.codeplex.com/

詳しい使い方は追って公開していこうと思いますので、今回は特徴だけ。

今回の目玉はGoogle Appsだけ、という特定のサービス向けではなく、RESTful APIでプロビジョニングできるサービスなら（ある程度前提はあるものの）接続できる（はず）というところです。
その意味で「汎用」としています。

Generic REST API Management Agent for Forefront Identity Management 2010 R2
　https://restmafim.codeplex.com/
　※codeplexに公開しているので基本英語でドキュメントは書いていきます。日本語版についてはこのblogで今後書いていこうと思います。


主な特徴としては、

• プラグイン型にしたので、サービス固有のパラメータ（スキーマなど）はプラグインライブラリを作ることで拡張できる
• プロキシサーバ（認証付でもOK）のサポート（DirSyncやAADSyncで困るところですよねぇ）
• セットアップを簡素化するため管理エージェントをパッケージ化（setup.exeとmapackageを作っただけですが）

です。

こんな仕組みです。（久しぶりにReflectionとか使いましたｗ）

対応しているアプリケーションには少々条件があり、

• OAuth2.0 JWT Bearer Token Flowをサポートしていること
• オブジェクト表現にJSONを使っていること
• （当然ですが）RESTful APIでオブジェクト管理が出来ること

が最低限の条件です。

現状Google Apps用のプラグインライブラリを同梱しているので、これをベースに拡張すればSalesforce.comなんかも繋がると思います。
（ちなみにAzure Active DirectoryについてはOAuth周りが特殊すぎて現状ダメですね。これはこれで別途解説したいと思います。）

ソースコードも公開していますので、FIMの管理エージェントを開発する人、OAuth2.0 JWT Bearer Token Flowを生で実装する人には参考になると幸いです。
（もちろん本来の目的であるFIMの管理エージェントとしても使ってもらえると幸いです）

プラグインライブラリの開発方法などを含めまだ公開できていないドキュメントが多数あるので、順次公開していきますので、よろしければ試してみてフィードバックいただけると助かります。

[AADSync]新バージョンがリリース（1.0.485.0222）

新しいバージョン（1.0.485.0222）がリリースされています。

今回のアップデートでは以下が更新されています。

• Password Sync honors the cloudFiltered attribute used by attribute filtering. Filtered objects will no longer be in scope for password synchronization.
• In rare situations where the topology had very many domain controllers, password sync doesn't work.
• "Stopped-server" when importing from the Azure AD Connector after device management has been enabled in Azure AD/Intune.
• Joining Foreign Security Principals (FSPs) from multiple domains in same forest causes an ambiguous-join error.

特に大きな機能追加もなく、不具合修正が中心ですね。

残念ながら今回もAzure Active DirectoryからオンプレADへのDevice情報の書き戻しもサポートされません。（AzureADのDevice Registration ServiceがAndroidをサポートしたので、この機能が一番欲しいです。まだDirSyncを手放せない最大の理由です）

[AzureAD]管理者アカウントの権限の絞り込み

注）現在Public Previewとして提供されている機能について紹介しているため、正式版がリリースされるタイミングで機能が変更になる可能性がありますのでご承知おきください。

ここしばらくAzure Active Directory（AzureAD）の管理アカウントの権限の絞り込みについて試行錯誤をしてきましたが、今回は現在Public Previewとして提供されている「Administrative Units（管理単位）」の機能について紹介します。
今のところ、やりたいことに一番近い機能はこれかも知れません。

まず、おさらいですが、やりたいことは以下の通りでした。

• シングルテナントのAzureADに複数のドメインを作成する
• 複数の企業や組織が各ドメインを使用、各組織のオンプレADからユーザを同期する
• 各組織の管理者は自ドメインのユーザのみを管理したい

これまでのポストでは多要素認証やFederationを使って各ドメインの管理者アカウント（AADSyncに設定するユーザ）の権限を制限しようとしましたが、うまい方法はありませんでした。
　[AADSync/DirSync]同期に使うAzureAD管理者アカウントの管理
　[AADSync/DirSync]同期に使うAzureAD管理者アカウントの管理（続）
　[AzureAD]管理者アカウントでAzureにサインアップする


今回は昨年12月にPublic Preview公開されたAdministrative Units（管理単位）を使ってみます。
この機能はAzureADのディレクトリを論理的な単位に分割し、それぞれの管理権限をユーザへ委譲するための仕組みです。（オンプレActive DirectoryでOU単位で管理権限を委譲するのと同様の考え方です）

想定ケースの例として地域ごとに管理者をアサインするようなケースがあげられています。

Active Directoryチームのblog
　Wrapping up the year with a boat load of Azure AD news!

MSDNドキュメント
　管理単位の管理 - パブリック プレビュー


では、簡単に試してみます。

現状はPowerShellコマンドレットでしか操作が出来ませんので、PowerShellを使います。
必要なWindows Azure Active Directory管理PowerShellモジュールのバージョンは1.0.8070.2以上です。

以下のコマンドで使っているバージョンがわかります。

> (get-item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion

⇒現状の最新版だと「1.0.8262.2」が出てきます。


以下の順に操作をします。（特定のAU以下のユーザしか管理出来ないように管理者の権限を制限します）
①グローバル管理者でAzureADに接続する
②管理単位（AU）を作成する
③管理単位（AU）に管理対象ユーザを追加する
④管理者ユーザにスコープ付管理ロールを付与する

結果的に言いますと、管理者は③で管理対象ユーザについてだけ「更新」が出来るようになります。
つまり、
・管理対象外ユーザの参照は出来てしまう
・新規にユーザを作成したり、削除することは出来ない
ということなので、やはり元々やりたかったことは実現出来ません。（当然AADSyncに管理者アカウントとして設定してもユーザの作成などが出来ないので実質使えません）


とりあえず現状出来ることを見てみます。

AU名	TestAU
AUメンバ	kenshinu@example.com
AU管理者	auadmin@example.com

◆設定
①グローバル管理者でAzureADに接続する

> Connect-MsolService

②管理単位（AU）を作成する

> New-MsolAdministrativeUnit -DisplayName "TestAU" -Description "Test AU"

ExtensionData       Description         DisplayName         ObjectId
-------------       -----------         -----------         --------
System.Runtime.S... Test AU             Test AU             edfd9c4a-e529-46...

③管理単位（AU）に管理対象ユーザを追加する

> $au = Get-MsolAdministrativeUnit -SearchString "TestAU"
> $user = Get-MsolUser -UserPrincipalName "kenshinu@example.com"
> Add-MsolAdministrativeUnitMember -AdministrativeUnitObjectId $au.ObjectId -AdministrativeUnitMemberObjectId $user.ObjectId

④管理者ユーザにスコープ付管理ロールを付与する

> $role = Get-MsolRole -RoleName "User Account Administrator"
> $admin = Get-MsolUser -UserPrincipalName "auadmin@example.com"
> Add-MsolScopedRoleMember -RoleObjectId $role.ObjectId -AdministrativeUnitObjectId $au.ObjectId -RoleMemberObjectId $admin.ObjectId

◆確認
①管理者ユーザでAzureADに接続する

> Connect-MsolService

②ユーザ一覧を参照する

> Get-MsolUser

UserPrincipalName          DisplayName                isLicensed
-----------------          -----------                ----------
mitsuhidea@example.net     Mitsuhide Akechi           True
nfujie@hoge.onmicrosof...  富士榮尚寛                 True
auadmin@example.com        AU Admin                   False
kenshinu@example.com       Kenshin Uesugi             True

⇒残念ながら全員見えてしまいます。

②管理対象ユーザを更新する

> Set-MsolUser -UserPrincipalName kenshinu@example.com -UsageLocation CA

⇒問題なく更新できます

③管理対象外ユーザを更新する

> Set-MsolUser -UserPrincipalName mitsuhidea@example.net -UsageLocation CA
Set-MsolUser : Access Denied. You do not have permissions to call this cmdlet.
発生場所 行:1 文字:1
+ Set-MsolUser -UserPrincipalName mitsuhidea@example.net -UsageLocatio ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : OperationStopped: (:) [Set-MsolUser], MicrosoftO
   nlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Acces
   sDeniedException,Microsoft.Online.Administration.Automation.SetUser

⇒権限がないって言われます

④ユーザを作成する

> New-MsolUser -UserPrincipalName hoge@example.com
New-MsolUser : Access Denied. You do not have permissions to call this cmdlet.
発生場所 行:1 文字:1
+ New-MsolUser -UserPrincipalName hoge@example.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [New-MsolUser], MicrosoftO
   nlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Acces
   sDeniedException,Microsoft.Online.Administration.Automation.NewUser

⇒権限がないって言われます

⑤ユーザを削除する

> Remove-MsolUser -UserPrincipalName kenshinu@example.com

確認
この操作を続行しますか?
[Y] はい(Y)  [N] いいえ(N)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):
Remove-MsolUser : Access Denied. You do not have permissions to call this cmdle
t.
発生場所 行:1 文字:1
+ Remove-MsolUser -UserPrincipalName kenshinu@example.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Remove-MsolUser], Microso
   ftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Acces
   sDeniedException,Microsoft.Online.Administration.Automation.RemoveUser

⇒権限がないって言われます

⑥管理者ユーザでAzureサブスクリプションにサインアップし管理ポータルからディレクトリを操作する
　⇒ユーザ一覧が見えません。PowerShellだと見えるんですが、管理ポータルからだと管理対象AUのメンバユーザすら見れません。

現状はこんな感じです。
今後はグループオブジェクトなんかもAUメンバに追加できるようになったりするようなので、今後の進化に期待です。

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

昨日のポストに引き続きAzureADの管理者アカウントの話です。

タケさんより、AADSyncに仕込む管理者アカウントをFederationユーザにしたらどう？というコメントを頂きましたので、どうなるのかちょっと試してみました。
※昨日のコメント欄を見ていただければわかると思いますが、ws-trust/saml-ecpなどのActiveEndpointのことをすっかり忘れていましたので、当然FederationユーザはAADSyncやPowerShellでは使えないと思い込んでいました。タケさんありがとうございました。


結果、もともとの課題（シングルテナントに複数のドメインを定義し、各ドメイン毎にAADSyncを入れてオンプレADと同期、ただしドメイン間でユーザ情報の閲覧などはさせたくない）については解決は出来なかったのですが、管理者アカウントの制御を含め別の使い方も出来そうなので、簡単にまとめておきます。

構築したのは下図のような環境です。

AADSyncやPowerShellなどMicrosoft Online Serviceサインインアシスタント経由の通信はAzure Active Directory（AzureAD）上に登録したドメインに設定されたActiveUriへws-trustやSAML（ECP）で通信して認証されるので、ActiveUrlだけをインターネットに公開し、Webブラウザ経由でアクセスされるPassiveUriは.localドメインなど社内ネットワークからのみアクセスできるアドレスを設定します。
この設定により、AADSyncなどに設定するAzureAD管理者アカウントとパスワードを知っていてもW社外ユーザは、社内にあるIdPに到達できないため、Webアプリケーションは使えない、という環境が作れます。

具体的な設定ですが、一旦は.localドメインでAD FSを構築し、AzureADとSSO設定を行った後、「Set-MsolDomainFederationSettings」コマンドレットでActiveLogOnUriプロパティのURIを外部公開しているURIに変更する、という方法をとりました。

設定した結果はこんな感じです。

> Get-MsolDomainFederationSettings -DomainName example.com

ActiveLogOnUri         : https://adfs.example.com/adfs/services/trust/
                         2005/usernamemixed
FederationBrandName    : eIdentity
IssuerUri              : http://adfs.eidentity.local/adfs/services/trus
                         t
LogOffUri              : https://adfs.eidentity.local/adfs/ls/
MetadataExchangeUri    : https://adfs.eidentity.local/adfs/services/trust/mex
NextSigningCertificate :
PassiveLogOnUri        : https://adfs.eidentity.local/adfs/ls/
SigningCertificate     : MIIC9DCCAdygAwIBAgIQSjWgIWhJdKVN1NL85LCH3zANBgkqhkiG9w
                         0BAQsFADA2MTQwMgYDVQQDEytBREZTIFNpZ25pbmcgLSBhZGZzLWFh

ActiveLogOnUriのみ外部公開ドメインになっていて、後は.localになっているのがわかります。
これで、AADSyncに設定する管理アカウントにFederationユーザを設定しても問題なく認証が通るようになります。

ただ、昨日のポストでも書いたように、
・PowerShellが使えるのでGet/Set-MsolUserコマンドレットなどでユーザ一覧は参照・更新可能
・Synchronization Service ManagerのConnector SpaceやMetaverseでユーザ一覧を参照可能
・当然カスタムルールを書けば他ドメインのユーザを更新や削除も可能
なので、シングルテナント・マルチドメインの環境でドメイン単位でセキュリティ境界を作るのは困難なのは変わりません。

[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での同期に支障が出るので対策とはならない。

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