【Azure AD】パスワードリセットのログ

皆さん、こんにちは。国井です。

今日は完全な備忘録です。
2014年7月に「クラウドからActive Directoryのパスワードを変更する方法」という投稿で、
Azure Active Directory Premiumを利用することで、Microsoft Azure のユーザー用ポータル画面であるアクセスパネルからパスワードをリセットし、オンプレミスのActive Directoryのパスワードをリセットさせることができると紹介しました。

そのパスワードリセット機能を利用した場合、ディレクトリ同期ツールを使ってAzureユーザーのパスワードをオンプレミスADユーザーに同期しますが、この同期は3時間に1回のタイミングで行われる同期ではなく、別のプロセスによって行われています。そのため、miisclient.exeのOperationsログからはパスワードが同期されたことを確認できません。

そこで、パスワードの同期はイベントビューアからアプリケーションログを使って確認します。

image

image

パスワード同期が始まったことはPasswordResetServiceソースのID31001、同期完了はID3002でそれぞれ確認できます。

誰かの役に立てれば幸いです。

 

 

ディレクトリ同期を今すぐ実行する方法 – AADSync版

皆さんこんにちは、国井です。

2014年10月に「ディレクトリ同期を今すぐ実行する方法 – 2014年版」という投稿をさせていただき、
Start-OnlineCoexistenceSyncコマンドレットが有効だという話をさせていただきました。

ところが、前回の投稿でも登場したAADSyncでは、Start-OnlineCoexistenceSyncコマンドレットがなくなり、DirSyncで行っていたディレクトリ同期を今すぐ実行する方法が利用できなくなりました。

では、AADSyncツールではどうやってディレクトリ同期を今すぐ実行するか?

その答えはタスクスケジューラにありました。

[タスクスケジューラ]管理ツールからAADSyncのタスク(Azure AD Sync Scheduler)を開き、右ペインの[実行]をクリックすれば、いつでも実行開始できます。

image
([トリガー]タブを見ると、3時間ごとに同期タスクを実行するように設定されていることがわかりますね)

また、[操作]タブを見ると、c:\program files\microsoft azure ad sync\binフォルダーにある
DirectorySyncClientCmd.exeが同期実行のプログラムになっていることが確認できます。

image

 

つまり、DirectorySyncClientCmd.exeを実行すれば、ディレクトリ同期を今すぐ実行できることがわかります。

Office 365管理者のためのディレクトリ同期ツール入門(3)

みなさん、こんにちは。国井です。

今回はOffice 365管理者のためのディレクトリ同期ツール入門の第3回目として
ディレクトリ同期ツールを使ってディレクトリの同期が一部のユーザーだけで行われるように構成する方法について紹介します。

まずは前回も紹介したスライドから。

image10[1]

前回も、その前も、Active Directory Connector MA(ADMA)とWindows Azure Active Directory MA(AzureMA)がディレクトリ同期ツール内に作られ、メタバースを経由して同期が行われることを紹介しました。
そして今回、ADMAでフィルターを設定し、同期しないオブジェクトがメタバースに書き込まれないように構成することで、一部のユーザーだけがOffice 365(Microsoft Azure Active Directory)へ同期される方法を
いくつか見たいと思います。

 

■その1:同期されるドメインのフィルター

同期を行うActive Directoryドメインが複数ドメイン(シングルフォレスト–マルチドメイン)構成の場合、一部のドメインユーザーだけが同期されるように構成することができます。その場合、ADMAのプロパティを開いて、[Configure Directory Partitions]から該当するドメインにチェックをつけます。
これだけで同期対象となるドメインを絞り込むことができます。

MIIS023

 

■その2:同期されるOUのフィルター

同期を行うActive Directoryドメインの中から一部のOUだけを対象に同期させたい場合には該当するOUだけを選んで同期させることができます。その場合、ADMAのプロパティを開いて、[Configure Directory Partitions]から[Containers]をクリックして、該当するOUにチェックをつけます。

MIIS026

 

■その3:同期されるユーザーのフィルター

同期を行うActive Directoryドメインの中から特定の属性を持つユーザーだけを対象に同期させたい場合、同期対象となる属性とその値を設定することができます。
その場合、ADMAのプロパティを開いて、[Configure Connector Filter]から[Data Source Object Type]の[User]をクリックして、Filterを設定します。Filterには同期させたくない属性とその値を設定します。

MIIS027

ディレクトリ同期を使っていて、Administratorユーザーがなんで同期されないの?ディレクトリ同期ツールをインストールすると作られるMSOL_の名前で始まるユーザーがなんで同期されないの?という疑問を持った方も多いと思いますが、それはこのフィルターが設定されているからです。

たとえば、Administratorの場合、isCriticalSystemObject属性がTrueと設定されています。そのため、フィルターの設定により同期されません。また、MSOL_の名前で始まるユーザーもsAMAccountName属性がMSOLで始まる場合には同期されないようにフィルター設定が施されています。そのため、同期されないのです。このように、デフォルトでは15個のフィルターが設定されていますが、管理者がフィルター設定を増やせば、もっと様々な条件をもとに同期するユーザーを絞り込むことができます。

他にもフィルターする方法はいろいろ考えられますが、大きなところとしては以上の3つが使われる可能性の高いフィルターといえます。みなさんの会社のニーズに合わせてぜひ活用してみてください。

2014年の投稿もこれで終了です。
それでは、よいお年をお過ごしください。
Hoping you enjoy a happy new year!

 

■参考サイト
Office 365 Directory Synchronization In-Depth
http://www.messageops.com/documentation/office-365-documentation/office-365-directory-synchronization-in-depth

Active Directory Filtering for Office 365 Directory Synchronisation (Dirsync)
http://netwovenblogs.com/2014/12/02/moving-from-on-premise-to-office-365windows-azure-part-4/

FIM2010 Terminology and Glossary
http://technet.microsoft.com/en-us/library/ee534910(v=WS.10).aspx

Office 365管理者のためのディレクトリ同期ツール入門(2)

みなさん、こんにちは。国井です。

前回、Office 365管理者のためのディレクトリ同期ツール入門の第1回目としてディレクトリ同期ツールのUIツールであるmiisclient.exeの起動方法と簡単な見方を紹介しました。

今回はディレクトリ同期ツールによる同期がどのような流れで行われているか見てみましょう。

まずは前回も紹介したスライドから。

image

Active Directory Connector MA(ADMA)とWindows Azure Active Directory MA(AzureMA)がディレクトリ同期ツール内に作られ、メタバースを経由して同期が行われることを紹介しましたが、具体的にどのようなルートで同期が行われるかについてもMAでは定義されています。

MAで定義されている同期の(基本)ルートは次のとおりです。

1.Active DirectoryからADMAのCSへ同期
(図の1-1に当たるImportという処理で実現しています)

2.ADMAのCSからメタバースへ同期
(図の1-2に当たるSynchronizationという処理で実現しています)

3.Azure ADからAzureMAのCSへ同期
(図の2-1に当たるImportという処理で実現しています)

4.AzureMAからメタバースへ同期
(図の2-2に当たるSynchronizationという処理で実現しています)

5.メタバース内のデータをAzure ADと同期
(図の3に当たるExportという処理で実現しています)

以上がディレクトリ同期の流れになります。
Active DirectoryとAzure ADのそれぞれからImportとSynchronizationを実行し、メタバースにデータを格納しているのはそれぞれのディレクトリに格納されている情報を把握し、差分だけをエクスポートできるようにするためです。

これらの処理は3時間に一度、自動的に行われているため、私たちは意識することがありませんが、これを手動で行いたいとなったら、どのような操作を行えばよいでしょうか?

この点について、続いて見てみましょう。

まずは前回も紹介した、miisclient.exeを起動し、Management Agentsを開き、
Active Directory Connectorを右クリックして、Runをクリックします。

image

すると、Run Profile一覧が表示され、ImportやSynchronizationなどが選択できることが確認できます。

MIIS012

ImportとSynchronizationは同時に行うプロファイルが用意されているので、これを利用すれば便利ですが、すべてのオブジェクトを対象にインポートや同期を行うFull~と前回実行時からの差分だけをインポート/同期するDelta~があることに注意してください。

このことを踏まえて、前の図の1-1~3までを順番に実行すれば、手動でディレクトリ同期を実行することができます。

【コラム】ディレクトリ同期ツール/FIMのトレーニングの現状

一般的にマイクロソフトが提供する製品やサービスに対応するトレーニングは
Microsoft Universityコースとして認定トレーニングプロバイダ(CPLS企業)から提供されます。
しかし、ディレクトリ同期ツールをつかさどるForefront Identity Manager (FIM)の
トレーニングは本稿執筆時点では日本語版も、英語版で提供する企業もありません。

一方、FIMはインストールや初期設定から苦労させられる面倒な製品ですし、
お使いになる機会がありましたら、時間やコストを削減するためにも
一度トレーニングを受けていただきたいのです。

そのため、もしトレーニングを通じてしっかりベースを学習したいということでしたら、
クリエ・イルミネート社と一緒にトレーニングをアレンジメントさせていただくことができますので、気軽に私のメールアドレス(画面右上に書いてあります)またはクリエ・イルミネート社までお問い合わせください。

同期の実行結果はmiisclient.exeのOperationsメニューから確認できます。
それぞれの項目をクリックし、左下ペインを参照すれば、ImportやSynchronizationなどの処理によって、どれだけのオブジェクトの同期が行われたかを確認できますし、リンク(下の図で言うとAdds 6と書かれた部分)をクリックすれば具体的に同期されたオブジェクトを確認することができます。

MIIS002

ただし、オブジェクト一覧は以下のように表示され、私たちの見た目にわかる名前で表示してくれるわけではないので、あてずっぽうで適当なオブジェクトをダブルクリックし、

MIIS020

お目当てのオブジェクトが同期されているか、見つけるしかありません。。

image

最後はちょっと面倒でしたが、
ここまでのことができれば、トラブルが発生したときにトラブルシューティングの一環として、自分で、手動で、同期の処理を行うことができるようになり、「ディレクトリ同期ができない→途方に暮れる」だけではない、対策が自分でとれるようになるのです。

今日はここまでにしましょう。

次回は同期のフィルター設定を確認する予定です。

Office 365管理者のためのディレクトリ同期ツール入門(1)

 

みなさん、こんにちは。国井です。
今日はOffice 365 Advent Calendarに参加しております。

今日の内容はディレクトリ同期ツールです。
Office 365でActive DirectoryとOffice 365(Azure AD)の間でID情報を同期させる際、Office365のサイトからダウンロードして利用可能なディレクトリ同期ツールと呼ばれるツールを使います。ところが、このツール、実はマイクロソフトが提供しているディレクトリ同期サーバー製品である、Forefront Identity Manager(FIM)の簡易版であることをご存知でしたでしょうか?

ディレクトリ同期ツールは3時間に1回の割合で自動的にActive DirectoryのID情報をAzure ADへ同期してくれるので、メンテナンスフリーだと思うかもしれませんが、実際にトラブルに遭遇した場合、どこに問題の原因があるのか、自分である程度は調べられるようになりたいですよね。
そのようなときには、FIMの基本的なところをおさえておくと、役立つかもしれませんので、
実際の画面を見ながら基本を確認しておきましょう。

 

■FIMの処理概要
まず、FIMには3つの代表的なコンポーネントがあります。
それは、
・Management Agent (MA)
・Connector Space (CS)
・メタバース
の3つです。

image

Active DirectoryからAzure ADへ同期する場合、2つのディレクトリどうしを直接結んで同期しているわけではなく、メタバースと呼ばれるFIMが持つデータベースにいったん格納されます。

Active DirectoryとAzure ADでは対応する同じ属性名があるとは限りません。そのため、メタバースを一度経由することで、スキーマの違いを吸収しているのですね。

それから、Active Directoryに格納されているデータをメタバースに格納するとき、
Azure ADに格納されているデータをメタバースに格納するとき、それぞれ中間データベースにいったん格納します。このテンポラリとなるデータベースのことをConnector Space (CS)と呼んでいます。

また、Active Directoryの場合で言うと、Active DirectoryからCSを経由して最終的にメタバースにデータを格納する際、どのようなデータを格納すればよいか?や、Active Directory以外では使われない、グローバルグループ、ドメインローカルグループなどのグループ属性はメタバースにどのような属性として保存すればよいか?などの同期のためのルールを定めたものをManagement Agent(MA)と呼びます。

ディレクトリ同期ツールは、このようにインストールすることにより、メタバースの作成、MAの作成、MA内のCSの定義、同期フローの定義(これについては後で説明します)、などの設定を全部自動的に行ってくれるのです。だからみなさん、「ディレクトリ同期ツールのインストールが長い!」などと文句を言うはやめてあげてください。

 

■ディレクトリ同期ツール(FIM)の起動とインターフェイスの確認
簡単ですが、仕組みが確認できたら、続いてディレクトリ同期ツールを起動します。
ツールはc:\program files\Microsoft Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exeを実行すると利用できます。

MIIS001

実行するときに注意してほしいのは、インストール後、すぐに実行しないこと。
実行直後はmiisclient.exeにアクセスする権限が割り当てられていないので、
インストールが終わったら、一度サインアウト/サインインをしましょう。

その後、起動すると以下のような画面が表示されます。(FIMでも同じ画面です)
画面上部に
Operations, Management Agents, Metaverse Designer, Metaverse Search, Joinerのボタンがあります。これが大まかにメニューだと思ってください。

まず、Operationsメニュー。
Operationsメニューでは、過去のディレクトリ同期の結果が確認できます。ログの時刻を見てもらうと、おおよそ3時間ごとに同期が実行されていることが確認できます。

MIIS002

続いて、Management Agentsメニュー。
名前のとおり、MAが登録されている箇所です。画面には、
Windows Azure Active Directory Connector(Azure MA)とActive Directory Connector(AD MA)の2つがありますが、
前の図で説明すると、Azure MAはメタバースからAzure ADまでの同期を担当し、
AD MAはActive Directoryからメタバースまでの同期を担当しています。

image

次はMetaverse Designer。
Metaverse Designerはメタバースのスキーマを定義するところです。ディレクトリ同期ツールとしてFIMを使っている場合には、ほとんど設定変更することはないでしょう。

image

Metaverse Searchは名前のとおり、メタバースに登録されたID情報を検索するために使います。Scope by Object Typeからpersonと選んでいただいて検索すると、メタバースに登録されたユーザーの一覧が表示されます。検索結果はdisplayname属性で表示されますが、displayname属性を持たないユーザーがいると、画面に表示されません。だけど、空欄をダブルクリックすると、そのユーザーのプロパティが表示される不思議。

image

最後はJoinerです。JoinerはDisconnector Typeと呼ばれるID情報を表示できるところで、
「Active Directoryの国井ユーザーはAzure ADのKuniiユーザーとみなす」のような2つのIDの関連付けをFIMは行うことで同期を行うのですが、Joinerに表示されるのは関連付けがされていないIDの一覧になります。普通の管理では使うことはあまりないですね。

image

 

■メタバースとCSに登録されたオブジェクトの参照
画面は戻って、Metaverse Searchの検索結果について。
Metaverse Searchで検索したユーザーですが、検索結果のdisplaynameをダブルクリックすると、メタバースに登録されたユーザーの属性情報が確認できます。

image

さらに、Connectorsタブをクリックすると、経由したCS(MA)の名前が表示されます。このケースでは、Active Directory ConnectorとWindows Azure Active Directory Connectorをそれぞれ経由したということがわかります。

image

そして、CSの名前をダブルクリックすると、CSに登録されていた時点でのユーザーの属性情報が確認できます。メタバースと同じように見えますが、よく見ると、CSに保存されていたuserAccountControl属性はメタバースに入ると、消えてなくなっていることが確認できます。

image

このようにFIMの管理画面を見ると、ディレクトリ同期が正常に行えているか、そして同期ができていない場合には、どこに問題があるのか?ということを探るきっかけを色々と与えてくれます。

今日は長くなってしまったので、ここまでにしましょう。続きは次回の投稿で。

 

明日のOffice 365 Advent CalendarはADFS/Office365トレーニングの主催会社として、いつもお世話になっている沼口さんです。お楽しみに。

Azure ADアカウントを利用したADFSのクレームベース認可

こんにちは、国井です。

ADFSでクレームベース認証(認可)を行う場合、Active Directoryユーザーで認証を済ませていることが前提でした。つまり、ADFSを利用する場合、Active Directoryは必須だったわけです。
(だからこそ、ADFS = Active Directoryフェデレーションサービスと呼んでいたわけですね)

ところが、Windows Server 2012 R2 の次のバージョンからADFSの認証に利用するディレクトリサービスとして、 Active Directory以外のディレクトリサービスが利用できることが発表されました。
これにより、とても選択肢が広がると思います。

しかし、現行のバージョンのADFSでも、実はActive Directoryを使わなくても、
サインイン認証を済ませて、ADFSからトークンを発行できるのをご存知でしたか?

本来はActive Directoryにサインインしたユーザーに対してトークンを発行していましたが、

image

Microsoft Azure Active Directory(Azure AD)で認証を行えば、ADでサインインしていないユーザーでもADFSからトークンが発行できるのです。

image

こんな感じで、認証画面でADとAzure AD、どちらでサインインするか選べるのです。

image

Azure ADでサインインしたユーザーを使ってADFS経由でサービスにアクセスできるようになれば、
私たちのサービス利用の選択肢も広がってくるというものです。
では、設定を見てみましょう。

 

ADFSサーバー側の設定

ADFSサーバー側では[要求プロバイダー信頼]を設定します。

ADFS管理ツールから[要求プロバイダー信頼]-[要求プロバイダー信頼の追加]をクリックします。

image

[要求プロバイダー信頼の追加ウィザード]が起動します。

image

[データソースの選択]で、[オンラインまたはローカルネットワークで公開されているプロバイダーについてのデータをインポートする]を選択し、フェデレーションメタデータとして、https://login.windows.net/<Azure ADドメイン名>/Federationmetadata/2007-06/Federationmetadata.xmlと入力します。

image

[表示名の指定]で、表示名となる名前を適当に入力します。

FSAzure004

ウィザードの残りの画面はすべてそのままで完了します。

image

FSAzure006

[要求規則の追加]画面が表示されるので、要求規則を追加します。

FSAzure007

[規則テンプレートの選択]で、[カスタム規則を使用して要求を送信]を選択します。

FSAzure008

[規則の構成]で、クレームルール言語を利用して規則を記述します。今回は、クレームルール言語として、すべてのクレームをそのまま発行するように、とりあえずc:[]=>Issue(claim=c);と書きました。
そのほか、[要求規則名]に適当な名前を入力して完了します。

FSAzure009

[OK]をクリックして完了です。

FSAzure010

(2014年11月17日追記)
証明書利用者信頼から要求変換規則を開き、要求規則として、受け付け変換規則と同じ
c:[]=>Issue(claim=c);を設定しておいてください。
これでADFS側の設定は完了です。

image

 

Azure側の設定

Azure AD側ではADFSサーバーとの間での信頼関係を設定します。
事前にMicrosoft Azure管理ポータルからAzure ADドメインが操作できるよう、ドメインの登録をしておいてください。 (具体的な登録方法はSEの雑記さんの「Azure のサブスクリプションを起点として Windows Azure Active Directory のディレクトリ同期を設定」を参考にしていただくと良いでしょう。)
その上で、ドメインのアプリケーションを追加します。

image

追加ボタンを押すと出てくる[実行する作業を選択してください]から[組織で開発中のアプリケーションを追加]をクリックします。

image

[アプリケーション情報の指定]で、適当な名前を付けて次へ進みます。

image

[アプリケーションのプロパティ]で、
サインオンURLに

https://<ADFSサーバー名>/adfs/ls/

アプリケーションIDに

http://<ADFSサーバー名>/adfs/services/trust

をそれぞれ入力します。

 

image

ここまでで設定は完了。では、サインインを試してみましょう。
(今回は証明書利用者信頼に Windows Indetity Foundation SDKの
サンプルWebサイトを登録しています。)
WebサイトのURLを入力してアクセスすると、サインイン先の選択画面が表示されます。
この画面で、Azure ADを選択すると、

image

Azureのサインイン画面に推移し、Azure ADのユーザー名とパスワードの入力を求められます。

image

サインインが完了すると、Webページにアクセスできました。

無題

(2014年11月17日追記)
証明書利用者信頼に規則を追加しておくのを忘れたため、トークンにクレームが何も入っていないという状態が起きました。そりゃそうですよね。ああ、恥ずかしい!

ところが、Windows Identity Foundation SDKのサンプルページを見るとわかりますが、
トークンに何もクレームが入っていない!のです。
Azure ADでサインインしたユーザーに、どうやってクレームを追加するか?
この部分についてはもうちょっと調べてみたいと思います。

■ ■ ■

なお、Active Directoryで認証してから、Azure ADの属性情報を要求規則の中で使いたいというニーズもあるでしょう。その場合には、ADFSのクレームにSQL Serverデータベースを使う方法でも紹介したように属性ストアを設定します。
ただし、デフォルトで選べる属性ストアにAzure ADはありません。そのため、Visual Studioでdllファイル(ライブラリ)を作りこんであげる必要があります。この点についてはマイクロソフトのWebサイトで手順が紹介されています。

■How to create a Custom Attribute Store for Active Directory Federation Services 3.0
http://blogs.technet.com/b/cloudpfe/archive/2013/12/27/how-to-create-a-custom-attribute-store-for-active-directory-federation-services-3-0.aspx

Using Windows Azure Active Directory as an Attribute Store in AD FS
http://blogs.technet.com/b/cloudpfe/archive/2014/03/25/using-windows-azure-active-directory-as-an-attribute-store-in-ad-fs.aspx

ただ、この中で紹介されているMicrosoft.WindowsAzure.ActiveDirectory.GraphHelperという名前空間、名前が変わってしまって今では使えなくなっているようなのですよね。。

今日はここまで。

ディレクトリ同期を今すぐ実行する方法 – 2014年版

こんにちは、国井です。
2012年2月に「Office 365ディレクトリ同期を今すぐ実行」という投稿をさせていただき、
多くの方に見ていただきました。

最近、Office 365 (Azure Active Directory)とActive Directoryの間で実行する
ディレクトリ同期ツールによるディレクトリ同期を今すぐ実行する方法が変わったようなので、
備忘録代わりに乗せておきます。

 

ディレクトリ同期を今すぐ実行する場合、Start-OnlineCoexistenceSyncコマンドレットを実行しますが、このコマンドレットが

Import-Module DirSync

から呼び出されるようになりました。

ですので、次の2つのコマンドレットを実行すれば今すぐ同期が行えます。

image

結果はMIISClientツールから確認してみましょう。

image

大図↓

image

既定の3時間という間隔を待たず、すぐに実行されていることがわかります。