2015年2月26日木曜日

[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を手放せない最大の理由です)





2015年2月7日土曜日

[Windows10/AAD]クラウド・ドメイン参加を試す

Windows 10からの新機能としてAzure Active Directory(AzureAD)のアカウントでPCにログインできる「クラウド・ドメイン参加(Cloud Domain Join)」があります。

先日リリースされたTechnical Preview Build 9926からクラウド・ドメイン参加が出来るようになっている様なので試してみます。

◆準備事項
 クラウド・ドメイン参加するためには、AzureADのテナント側で「デバイスの登録(Device Registration)」を有効にしておく必要があります。
 管理ポータルからAzureADの構成メニューを開き、デバイスの登録より「ワークプレース参加の有効化」を行います。


◆PC側の設定
 早速設定していきます。
 PCのキッティング時(OOBE)からAzureADアカウントでログインさせることも可能らしいのですが、何故かうまく行かなかったので、一旦別のマイクロソフトアカウントでPCにログインします。
 スタートメニューから[Settings]を開き、[システム]、[バージョン情報]の順で画面を開きます。



すると、[クラウドに接続する]というリンクが存在するので、迷わずクリックすると「クラウド体験ホスト」というウィンドウが起動してきます。

しばらくするとサインイン画面になります。


ここでおもむろにAzureADのアカウント(onmicrosoft.comのアカウント)を入れると、見慣れたAzureADのサインイン画面が表示されます。


正常にサインインしたら、クラウド体験ホストを閉じてPCを再起動します。

PCが起動してきたらサインイン画面で「別のユーザ」を選択します。

「他のユーザ」を選択するとAzureADへのサインイン画面となるのでAzureADのIDとパスワードを入力してサインインします。


うまく行くとデスクトップが立ち上がってきます。


スタートメニューに表示される名前もちゃんとAzureADから取得できています。

とりあえずここまでです。
単にPCへのログインだけなので、これでOffice365などPCへのログインで使ったAzureADアカウントでログインするアプリケーションへのシングルサインオンが出来るか?というと「できません」。
あくまでPCへAzureADのアカウントでログインするだけです。



やっぱりブラウザを立ち上げると再度ログインする必要があります。。。


まだ管理面は見れていないので、AzureAD側で何が出来るかは今後見ていく必要がありそうです。

ちなみにクラウド接続がうまく行くと、AzureADのユーザプロファイルから該当アカウントのデバイス情報が見れます。
デバイス紛失などの場合はここで無効化などできるはずです。


[Office365/ADFS/AAD]クラウドIDのアクセス制御にAD FSを利用する

タイトルだけを見ると一体何をしようとしているのか良くわからないと思いますが、Office365フォーラムに質問が上がっていたので、こんなケースもあるかも知れないなぁ、ということで動きを検証してみました。


◆実現したい環境の概要
・Office365をクラウドID(Azure Active Directory上のユーザ)で使いたい
 ※ローカルのActive Directoryユーザを使いたくない
・Azure Active DirectoryだとクライアントIPやブラウザ種別などでアクセス制御が出来ないのでActive Directory Federation Services(AD FS)のクレームルールでの制御を行いたい

いざ実現しようとすると色々と課題があります。



そこで、Office365(AzureAD)⇒AD FS(アクセス制御用)⇒AzureAD(認証用)というフェデレーションの連鎖をさせて実現できるか確認してみます。

こんな環境です。


かなりややこしい構成です。



◆結果は、、、、曲がりなりにも動いた!
まずは結論から。
「一応」動きました。。。。が、ユーザビリティに少々難ありかと。(ある程度工夫で何とかなりますが)

フローを追って確認してみます。
①Office365にアクセスする
 まずはOffice365にアクセスします。https://portal.office.comへブラウザでアクセスし、ログイン画面を表示させます。



②AD FSのドメイン名のユーザ(ダミー)をログインIDに入れる
 Office365(AzureAD)のレルム・ディスカバリ機能でAD FSへリダイレクトされます。



③AD FSのレルム選択画面でAzureADを選択する
 あらかじめAD FSに外部IdPを設定してあるとローカルのAD DSで認証するか、外部IdP(今回はAzureAD)で認証するかを選択できます。ここでAzureADを選択すると再度AzureADのログイン画面へ遷移します。


 ※ちなみにAzureADからAD FSへの遷移はajaxで制御されています。通常フローだとAzureADのログイン画面に入れたユーザ名がそのままAD FSに引き継がれるので便利なのですが、AD FSのログイン画面で別のユーザ名(AzureADのonmicrosoft.comユーザ)を入れる必要があるので、アドレスバーに表示されるURLのGETパラメータのusername=xxxという部分を手動で消してあげる必要があります。この部分の省力化方法は後で紹介します。


④AzureADユーザ(onmicrosoft.comユーザ)で認証する
 今度はAD FSにリダイレクトするためのダミーユーザではなく、AzureAD上の実ユーザでログインするため、ユーザ名にonmicrosoft.comドメインのユーザ名を入力します。するとAzureAD上の自分のテナントの認証画面へ遷移します。



⑤ログインする
 自分のテナントのログイン画面に遷移したらクラウドIDでログインします。



⑥AzureAD⇒AD FS⇒Office365(のIdPであるAzureAD)へ戻る
 認証が終わるとAzureADでAssertionが発行され、AD FSへ戻されます。次にAD FSはAzureADから受け取ったAssertionをOffice365(のIdPであるAzureAD)向けのAssertionに変換・発行し直してAzureADへ戻し、AzureADでの認証プロセスが完了します。
 この時、Office365のIdPとしてのAzureADはAD FSのユーザで認証されますが、前段階ですでにクラウドID(onmicrosoft.comユーザ)でログオンしていますので、すでに認証済みとして扱われ、改めてログインし直すか聞かれます。ここでログインし直す選択をするとログアウトからやり直すので、永遠に2重ログイン状態を繰り返してしまいますので、AD FSユーザでのログインはあくまでアクセス制御のためと割り切って、クラウドIDでのログイン継続を選択します。



⑦Office365へのログイン
 ライセンスを付与していないので画面ショットは単なるプロファイル表示画面になっていますが、無事にOffice365へアクセスできます。




これで一連の流れは完了です。
ここまで出来れば、AD FSの部分でアクセス制御ルールを設定してあげればOKです。上記フローの⑥の部分でアクセス制御が挟まるので、アクセス拒否されるとこんな画面が出てきます。




◆どうやって実現するか?
まずは環境設定です。
AzureAD、AD FSそれぞれに下記の設定を行います。

対象設定箇所設定内容設定方法
AzureADアプリケーション設定Office365を登録Office365の設定を行えば自動的に設定される
AD FSを登録ws-federationで連携するWebアプリケーションとして登録する
ドメイン設定AD FSとID連携するドメインを設定Office365のPowerShellで設定する
ユーザ設定ダミーユーザ(AD FS連携用ユーザ)PowerShellなどで登録する
実ユーザ(ログインするユーザ)PowerShellなどで登録する
AD FSRP設定Office365(AzureAD)を登録Office365のPowerShellで設定する
IdP設定AzureADを登録AzureADのFederationMetadataを使って登録する



順番に設定内容を見ていきます。
・AzureAD/アプリケーション設定
 Office365は自動的に登録されるので、AD FSを登録します。
 AzureADのアプリケーション設定で「組織で開発中のアプリケーションを追加」します。


 アプリケーションの種類は「WEBアプリケーションやWEB API」を選択します。


 以下の通りサインオンURLとアプリケーションID/URIを設定します。
 ・サインオンURL:AD FSのPassiveログインURL
 ・アプリケーションID/URI:AD FSのサービスID



・AzureAD/ドメイン設定
 こちらは通常のOffice365でAD FSとID連携用ドメインを設定する手順で設定を行います。

・AzureAD/ユーザ設定
 ・ダミーユーザ(AD FS連携用ユーザ)
  このユーザは実際にOffice365を利用するためのユーザではないので適当に作成すればOKです。
  作成した後、Get-MsolUserコマンドレットなどでImmutableIdおよびUserPrincipalNameの値を確認、メモしておきます。実際にログインに使うAzureAD上のユーザのSAML Assertionの中にこのダミーユーザのImmutableIdとUserPrincipalNameの値が必要となるためです。

 ・実ユーザ(ログインするユーザ。onmicrosoft.comユーザ)
  このユーザで実際にOffice365を使います。先にも書いたように、AzureADでこのユーザを認証した後、AD FSにSAML Assertionを渡すのですが、AD FSでこのユーザの属性(クレーム)と先に作成したダミーユーザのImmutableIdとUserPrincipalNameを一致させることで紐づけ(Federation)をさせます。
  そのため、このユーザの属性にダミーユーザのImmutableIdとUserPrincipalNameを設定します。
  今回は名にImmutableId、姓にUserPrincipalNameを設定しました。(この属性がOffice365のプロファイルに表示されてしまうので、本来はスキーマを拡張して利用者に見えない属性を使った方が良いと思います)



  また、このユーザでAzureAD上に登録してあるアプリケーションとしてのAD FSへアクセスするために、先に登録したAD FS(アプリケーション)へのアクセス権を割り当てます。



・AD FS/RP設定
 Office365とのID連携設定をすると自動的にRPとして「Microsoft Office 365 Identity Platform」が登録されるので、こちらのクレームルールを変更します。
 もともとあるのはActive Directoryから属性をとってきてNameID、ImmutableId、UserPrincipalNameを発行するルールなので、潔くすべて削除します。
 そして、以下の3つのルールを設定します。


 ・NameID発行(AzureADのユーザの名に入っているImmutableIdの値を発行)

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

 ・UserPrincipalName発行(AzureADのユーザの姓に入っているUserPrincipalNameの値を発行)

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"]
 => issue(Type = "http://schemas.xmlsoap.org/claims/UPN", Issuer = c.Issuer, Value = c.Value, ValueType = c.ValueType);

 ・ImmutableId発行(AzureADのユーザの名に入っているImmutableIdの値を発行)

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"]
 => issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Issuer = c.Issuer, Value = c.Value, ValueType = c.ValueType);

 アクセス制御をする場合はここで設定をしておきます。


・AD FS/IdP設定
 次にAD FSのIdPとしてAzureADを登録します。
 AzureADがFederationMetadataを公開しているので、URIを設定するだけで簡単に設定できます。
 設定するURIは「https://login.windows.net/[テナントID]/federationmetadata/2007-06/federationmetadata.xml」です。AzureADのアプリケーション設定のページでエンドポイントは確認できます。


 次に、AzureADから取得した属性(クレーム)を受け取る設定です。特に何も考えずにすべての属性をパススルーします。


 こんなルールです。

c:[]
 => issue(claim = c);



これですべての設定が完了しました。
先のフロー通りに動きます。


◆ちょっとした工夫
画面遷移を紹介しましたが、何度もレルムを選択したりするのは、かなり不便です。
そこで、最初のOffice365⇒AD FSへのレルム選択を自動化するために以下のURLをユーザにBookmarkしてもらうといきなりAD FSのログイン画面にたどり着きますので、かなり画面遷移がすっきりします。先の画面遷移の③からいきなり始まりますので、username=xxxをアドレスバーから手動で消す必要もなくなります。

 ブックマークするURL
  https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https:%2F%2Fportal.office.com%2F&whr=example.net

◆Assertionの中身
細かい話ですが、ログインまでの間で以下のようなAssertionが飛んでおり、各ポイントで必要に応じて処理をします。
・AzureAD(実ユーザでログイン)⇒AD FS
<Subject>
   <NameID+Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ixxxxxxxxxxxxxxxxx0ZM</NameID>
   <SubjectConfirmation+Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"+/>
</Subject>

<AttributeStatement>
   <Attribute+Name="http://schemas.microsoft.com/identity/claims/tenantid">
      <AttributeValue>2cxxxxxxxxxxxxxxxxxxxxxbfff</AttributeValue>
   </Attribute>
   <Attribute+Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
      <AttributeValue>baxxxxxxxxxxxxxxxxxxxba2ac2</AttributeValue>
   </Attribute>
   <Attribute+Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
      <AttributeValue>nobunagao@xxxx.onmicrosoft.com</AttributeValue>
   </Attribute>
   <Attribute+Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
      <AttributeValue>nobunagao@example.net</AttributeValue>
   </Attribute>
   <Attribute+Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
      <AttributeValue>QDibxxxxxxxxxfIENg==</AttributeValue>
   </Attribute>
   <Attribute+Name="http://schemas.microsoft.com/identity/claims/displayname">
      <AttributeValue>ADFS/AADテスト</AttributeValue>
   </Attribute>
   <Attribute+Name="http://schemas.microsoft.com/identity/claims/identityprovider">
      <AttributeValue>https://sts.windows.net/2c6xxxxxxxxx1bfff/</AttributeValue>
   </Attribute>
</AttributeStatement>



・AD FS⇒AzureAD(ダミーユーザ情報)
 クレーム変換ルールでImmutableId、UPNに必要な値が代入されています。
<saml:AttributeStatement>
   <saml:Subject>
      <saml:NameIdentifier+Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">QDxxxxxxNg==</saml:NameIdentifier>
      <saml:SubjectConfirmation>
         <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>
      </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Attribute+AttributeName="UPN"+AttributeNamespace="http://schemas.xmlsoap.org/claims">
      <saml:AttributeValue>nobunagao@example.net</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute+AttributeName="ImmutableID"+AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05">
      <saml:AttributeValue>QDxxxxxxNg==</saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>





いかがでしょうか?
色々とトリッキーなことをしているので、実用性は?ですがクラウドIDを使う場合にアクセス制御をしたい、という要件はあると思います。
今後はAzureAD側でのアクセス制御が実装されてくる日が来るかも知れませんね。

2015年2月5日木曜日

[FIM]カスタム管理エージェントのトレースログを出力する

久しぶりにForefront Identity Manager(FIM)の話題です。
ID管理システムを構築する際、管理対象のすべてのシステムを製品に含まれる管理エージェントでまかなえることは稀だと思います。
FIMの場合、カスタムで管理エージェントを開発するためのECMA2というフレームワークが提供されており、各種システムとの柔軟な接続性を確保することができます。

カスタムで管理エージェントを開発する際、避けて通れないのがデバッグとトレース(ロギング)です。
デバッグについては別途紹介したいと思いますので、今回はトレースについてのポイント(TIPS)を少し紹介します。

トレースを行う方法も色々とあると思いますが、最近はプリセットのアダプタ群も対応しているEvent Tracing for Windows(ETW)を使うのが主流です。
(昔はMicrosoft.MetadirectoryServices.Loggingなんていうのもありましたが、最近はあまり使っていないような・・・。一応今でもあります、念のため)

 ETWトレース
  https://msdn.microsoft.com/ja-jp/library/vstudio/ms751538(v=vs.100).aspx
 Microsoft.MetadirectoryServices.Logging
  https://msdn.microsoft.com/en-us/library/microsoft.metadirectoryservices.logging.logging.aspx


ETWを使う場合、アプリケーション構成ファイル(hogehoge.exe.config)にSourceとListenerを記載すればモジュールに手を入れることなく、イベントログやテキストファイルなどへ柔軟にトレースを出力することが出来ます。
この時に注意すべきなのが、管理エージェントをFIM Sync(miisserver.exe)のプロセス内で動かすのか、別プロセスとして動かすのかによって使われるアプリケーション構成ファイルが異なる、ということです。


ここで「Run this management agent in a separate process」にチェックが入っているとFIM Sync(miisserver.exe)ではなく、独立したプロセス(dllhost.exe)で管理エージェントが実行されます。つまり、この場合はmiisserver.exeではなくdllhost.exeが使うアプリケーション構成ファイルにETWの設定をする必要があるのです。


それぞれの実行プロセスと構成ファイルは以下の通りです。

管理エージェント実行方法実行プロセス名アプリケーション構成ファイル
FIM Sync内miisserver.exeC:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miisserver.exe.config
別プロセスdllhost.exeC:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\dllhost.exe.config




尚、設定する内容は同じなので、両方に同じことを書いておけばどちらのモデルで実行してもログの取り忘れはなくなるので、とりあえず両方に設定しておくのが良いかも知れません。



以下、具体的な設定方法です。

◆管理エージェント側
<必要な準備>
①#define TRACEを定義するか、コンパイルオプションに/d:TRACEを付けていること
②System.Diagnosticsをusingで定義
③TraceSourceオブジェクトインスタンスを生成

こんな感じで書きます。
#define TRACE
using System;
using Microsoft.MetadirectoryServices;
using System.Diagnostics;

namespace FimSync_Ezma
{
    public class EzmaExtension :
    IMAExtensible2CallExport,
    IMAExtensible2CallImport,
    IMAExtensible2GetSchema,
    IMAExtensible2GetCapabilities,
    IMAExtensible2GetParameters
    {
        // trace
        TraceSource traceSource = new TraceSource("sampleMA",SourceLevels.All);

※testma部分がアプリケーション構成ファイル内のSource Nameになります。SourceLevelについてはお好みで。

<トレース出力の例>
実際にトレースを出力したい箇所では以下のように書きます。
traceSource.TraceEvent(TraceEventType.Information, 0, "hogehoge");
traceSource.Flush();



◆アプリケーション構成ファイル側
テキストファイルに出力する例です。
initializeDataに対象ファイル名を記載します。
<system.diagnostics>      
   <sources>
       <source name="sampleMA" switchValue="All">
           <listeners>
               <add name="sampleMA"
                    type="System.Diagnostics.TextWriterTraceListener"
                    initializeData="c:\Logs\sampleMA_dllhost.log">
               <filter type="" />
               </add>
               <remove name="Default"/>
           </listeners>
       </source>
   </sources>
</system.diagnostics>





switchValueで出力レベルが変更できますので、開発中やデバッグ中は構成ファイル側でログレベルを上げておいて、平常時はレベルを落とすことで性能やディスク容量への影響を減らすことが出来ますので、うまく調整をしていきましょう。

2015年1月20日火曜日

[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メンバに追加できるようになったりするようなので、今後の進化に期待です。

2015年1月17日土曜日

[AzureAD]管理者アカウントでAzureにサインアップする

AzureAD上に作成(もしくはオンプレミスADから同期)したユーザに全体管理者ロールを与えておき、そのユーザで別のAzureサブスクリプションへサインアップするとどうなるのか?を試してみました。

前々回のポストで全体管理者としてアサインしたユーザが他のユーザ情報を参照・編集してしまうのを防ぐには、という話題で初期状態で管理ポータルへアクセス出来ないので、、ということを紹介しました。
ただし、その管理者アカウントでAzureサブスクリプションを新規にサインアップしてしまえば管理ポータルにアクセスできてしまうので、やはり注意が必要です。
これを防ぐには前回のポストで紹介したようにWebアプリケーションの認証を行う際にIdPへネットワーク的にアクセスできないように構成するなど別の対策が必要になります。

実際にどうなるのかを試してみます。(かなり当たり前な結果ばかりですが)
全体管理者アカウントでサインアップして管理ポータルにアクセスすると以下のような状態になります。


最初から自分が管理者となっているAzure Active Directory(AzureAD)のディレクトリが見えています。

開いてみると、当然全ての操作が可能です。


柔軟に色々なことができるAzureADのアイデンティティ管理ですが、何をしたら何が起きるかをしっかり把握しておかないと危ないので、しっかり把握しておくことが大切です。

尚、当該のアカウントに多要素認証設定をしておくと最初からアカウントの管理メニューに追加の認証に関する項目が出てきます。(ちなみにこのユーザ、OpenAMで認証するように構成してあるユーザなので、ポータルにアクセスすると、OpenAMにリダイレクトされ認証された後、AzureADの多要素認証が実行されます)


2015年1月16日金曜日

[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でユーザ一覧を参照可能
・当然カスタムルールを書けば他ドメインのユーザを更新や削除も可能
なので、シングルテナント・マルチドメインの環境でドメイン単位でセキュリティ境界を作るのは困難なのは変わりません。