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

リモートワークが続き、お取引先のお客様とMicrosoft Teamsでやり取りすることが多くなりました。しかし、お取引先の会社にとっては私は社外の人間。
私がお取引先の会社のTeamsでやり取りしようとすると、社外の人間をお通しするための設定をしなければなりません。ところがこの設定、なかなか嫌われるんですよね。しかも「社外」の定義にも色々あってわけわからん、という声を聞くので私なりにまとめてみました。
正直、私自身もこの闇を解明しきったわけではないので、間違っているところはあるかもしれないです(というか多分あるはずなので、ご指摘くださいｗ)。

Teamsの会議に社外の人間を招き入れる場合、匿名アクセス、外部アクセス、ゲストアクセスの3種類があるので、ここから見ていきましょう。

匿名アクセス

匿名アクセスは文字通り匿名でのアクセスです。Teamsで[予定表]から新しい会議を作成した場合、Teams会議に参加するためのリンクを生成され、あらかじめ指定したメールアドレスに送信されますが、このリンクをクリックすれば誰でも(指定したメールアドレスじゃなくても)会議に参加できます。
余談ですけど、私がオンライントレーニングを行うときにも使うことがあるのですが、匿名で入ってくる人は参加時に自分の名前を自由に設定して入れるので、本当の参加者なのか？というのがわからないんですよね。

もちろん会議に入室するときには会議を開く人が承認しないと入れないので(設定で承認なしでも入れるようにすることも可能)、zoom bombingみたいな攻撃は防げます。
2020年8月25日追記
承認された匿名ユーザーが別の匿名ユーザーを承認できるようになっているそうです。
シモヤマさんありがとうございます！
匿名アクセスをブロックするときはTeams管理センターの会議 > 会議設定から[匿名ユーザーが会議に参加できます]をオフにしてください。

外部アクセス

外部アクセスはTeamsやSkype for Business、Skypeのアカウントを持っている他社のユーザーによるアクセスです。他社のAzure ADユーザーはもちろんのこと、マイクロソフトのサービスにアクセスするためのアカウントを持っているユーザーということのようです。
匿名アクセスと異なる点は認証を行ったユーザーだけが会議に参加できる点がです。そのため、匿名アクセスをブロックし、外部アクセスを有効にしている場合は事前に自身のAzure ADユーザーでサインインしていないとTeams会議に参加できなくなります。

ちなみに外部アクセスをブロックするときは
Teams管理センターの組織全体の設定 > 外部アクセスから設定をオフにしてください。

ゲストアクセス

ゲストアクセスは自社のAzure ADのゲストユーザーとして登録済みのユーザーによるアクセス方法です。ゲストアクセスの場合は外部アクセスと比べてTeams上でできることが大きく増えるので、定期的なコラボレーションを行う場合はゲストアクセスを利用すべきと思います。
外部アクセスとゲストアクセスの違いはこちらで解説しています。

ゲストユーザーは予定表から設定する[新しい会議]で参加者を登録する方法と、チームのメンバーとしてユーザーを登録して会議を設定する方法のどちらも利用できることも特徴のひとつです。

ちなみにゲストアクセスをブロックするときはTeams管理センターの組織全体の設定 > ゲストアクセスから設定をオフにしてください。

ゲストアクセスとはAzure AD B2Bのゲストユーザーを事前に作っておき、そのユーザーアカウントを使って接続することです。そのため、Teams管理センターで許可するように設定していたとしても、Azure AD管理センターからゲストユーザーそのものの利用を無効にしてしまえば、結局ゲストアクセスはできなくなる点にも注意してください。

Azure ADのゲストユーザーの無効化設定はAzure AD管理センター画面からユーザー設定 > 外部ユーザー設定 で定義できます。

■【参考情報】Microsoft Teams でのゲスト アクセスを承認する
https://docs.microsoft.com/ja-jp/microsoftteams/teams-dependencies

制限を設定してみた

匿名アクセス、外部アクセス、ゲストアクセスの3種類があることをここまで見てきましたが続いて特定の制限を設定したらどうなるか見てみましょう。
Teams管理センターで設定した内容は設定が反映されるまで時間がかかるので、全部のパターンを試せませんでしたが、ちょろっと設定してみたらこんな感じになりました。

上記のパターンの場合、どこの会社のユーザーであれAzure ADユーザーであれば会議に参加できました。ただし、会議は予定表から設定する[新しい会議]で参加者を登録すること、InPrivateブラウズを使っていないことが条件としてありました。

上記のパターンの場合、会議を作成するユーザーが所属するAzure ADディレクトリにゲストユーザーとしてユーザーが登録されている場合に限り、会議に参加できました。
ゲストユーザーはAzure AD管理センターからゲストユーザーを作っただけではダメで、きちんと招待メールのリンクをクリックして招待の承諾を受けていることが条件になります。
招待の承諾についてはこちらに解説がありました。

また、面白かったのは外部アクセスに相当するユーザーがこの状態のときに無理やりアクセスしようとすると、主催者の承認待ちを表すメッセージが表示されたまま、そこから先に何も起きない点です。外部アクセスは×なわけだから承認待ちとか言わないでダメと言ってくれればいいのに。意地悪な人ね。

Teamsアプリから会議に参加

実際に使っていて不思議だったのはTeamsアプリから会議に参加するときです。
Teamsのアプリで画面右上に自分が今、どのディレクトリに接続しているか？というのがわかると思うのですが(下画面参照)
これでどこを選択しているかによって、接続状況が変わったりします。
例えば、AとBという2つのテナントがあって、自分のテナントがAだとしましょう。
テナントBに私のゲストユーザーを作ってもらったら、テナントAのユーザー(私)はテナントBのTeamsでゲストアクセスの扱いで会議ができるようになります。しかし、私のTeamsの下画面で(ゲスト)と表示されているほう(つまりテナントB)を選択していると、テナントBの会議に参加するときに匿名アクセス扱いされてしまうのです。

会議に参加するのにTeamsのサインアップは必要？

不要です。そのために匿名アクセスがあるのですから。では匿名アクセスが無効になっている場合はサインアップしたらアクセスできるようになるか？と言われれば答えはYESです。
なぜなら
https://www.microsoft.com/ja-jp/microsoft-365/microsoft-teams/group-chat-software?rtc=1

にアクセスして、サインアップを行うとTeamsのライセンスが付与されると同時にサインアップに使われたアカウントはマイクロソフトアカウントになるからです。
マイクロソフトアカウントでサインインしてTeams会議に参加するユーザーは「外部アクセス」に当たりますから、外部アクセスが有効なテナントであれば、アクセスできるようになります。

匿名アクセス、外部アクセス、ゲストアクセス、どれを認めるか？

やっと今日の本題です。
最近、Teamsで会議を行うときに匿名アクセス、外部アクセス、ゲストアクセスのどれをどのように認めるか？という話が出てくるのですが、全部OKとしている会社を除くと次の3つのケースがあるようです。それぞれの私の所感も含めてどうぞ。

ケース1：会社のリソースに社外の人間を入れたくない

Office 365のテナントという会社の境界に社外の人間を入れたくない、というケースです(匿名、外部、ゲスト、全部ダメというパターン)。このケースの場合、理由を聞くと論理的な答えが返ってくることは少なく、「なんとなく」という答えが返ってくることが多いんですよね。
この答えに至る背景にはネットワークを境界とするセキュリティの考え方があるんですよね。この場合は考え方から変えてもらうしかないんだけど、このままではコロナ禍で社外の人と会議もできなくなるはずなので、どこかで方針転換されるんじゃないかと願っています。

ケース2：Teamsでの会議のみ可

テレワーク前提のこの時世なので外部アクセス(匿名？)としてのTeams会議は認めます。
だけど、ゲストアクセスは認めないという運用です。
外部アクセスとゲストアクセスの違いは前に紹介したサイトにも出ていますが、ゲストアクセスができないと、ファイルを共有できないなどの問題が出てきます。
これを使う理由ってわからないでもないんですよね。だって会議は映像と音声だけなので、録画していない限り、情報が漏えいする心配は少ない。だけどファイルのような永続的に残り続けるものはリスクがあるから共有したくない。
だけど、このルールを会社で作ってしまったものだから、後でファイルを共有する必要が出てくると「じゃあ後でメール添付でお送りしますね」となるのです。それでもってPPAPやられたら、もう最悪。PPAPの問題はいっぱいあるけど、現実的な一番の問題はウイルス対策機能をすり抜けてしまうことです。「暗号化しなければならないから」という、あなたの会社のエゴを押し通したお陰で、受け取る側は迷惑していることにいい加減気づいてほしいものです。

ケース3：相手テナントへのゲストアクセスは認めない

自分の会社をA社としましょう。A社のユーザーとB社のユーザーで会議をするときに、A社のテナントにB社のユーザーをゲストユーザーになることは認めますが、B社のテナントにA社のユーザーをゲストユーザーにすることはA社のポリシー的にNGというパターン。

自分の会社のテナントにゲストユーザーが増える分には自分の会社で状況が把握できるからいいけど、相手の会社のテナントに自分の会社のゲストユーザーが作られたら、その管理(特にログ管理)はもう自分たちでできなくなるから許さん！という理屈なのでしょう。
理屈はわかります。だけど逆の立場からしてみると「自分の会社のためなら相手の会社など、どうでもよい」と言っているように聞こえてならないのです。
#と言いつつ「うちのポリシーなので」と言われれば、なんでも言われた通りにする、業界の底辺にいる私ｗ(ホントに「だめだこりゃ」というポリシーを押し付けられたときは笑って過ごして次から一緒に仕事しませんけどね)
サイバーセキュリティ経営ガイドラインでも経営者が認識すべき3原則に「自社は勿論のこと、ビジネスパートナーや委託先も含めたサプライチェーンに対するセキュリティ対策が必要」とあるように「自分の会社でコントロールできないからダメ」ではなく、サプライチェーン全体でのセキュリティ対策の徹底を目指して信頼できるパートナーを作っていくのが本来のあるべき姿と思うのです。

参考までに、A社のテナントにB社のユーザーをゲストユーザーとして追加した場合、
B社のユーザーはB社のテナントで一度サインインを行い、OAuth2.0を使ってA社のアプリ(この場合はTeams)にアクセスします。このとき、OAuth2.0でID連携をするのが初めてであれば、相手のテナントに受け渡しをするユーザープロファイルの情報については画面で確認できますので、リスク範囲はある程度把握できるようになっています。

■ ■ ■

ここまで私が遭遇した3つのパターンを見てきましたが、どうして外部ユーザーやゲストユーザーを認めないという発想になるかといえば、境界型防御の考え方に基づいてTeamsを利用しているからなのではないかと思うのです。
すべての会社で、外部アクセスやゲストアクセスを認めるべきだと言うつもりはないですが、盲目的に境界型防御の発想で「外の人間はダメ」という考えを改める時期に来ているのではないでしょうか。

この辺の考え方についてはMSさんで提供しているAzure AD Webinar Season4 「Azure AD アーキテクチャ概要 – Azure AD を設計するためのガイドライン」などが役に立ちますので、参考にされると良いと思います。

The post Teamsの外部・ゲストアクセスを許可したくない、あなたへ first appeared on Always on the clock.

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

今日は趣向を変えて、私がオンライン研修で行っているライブ配信の環境について紹介したいと思います。なんで、こんな話をしようと思ったかというと私が犯した失敗を誰かに繰り返してほしくないと思ったからです。

私は普段、Microsoft 365に関わるトレーニングコースを教室で提供させていただいているのですが、コロナ禍でオンラインでも提供する機会が増えるようになりました。お金をいただいて配信をするわけだから、配信機材はちゃんとしたものを用意しようと考えたのですが、今思えば知識がないのにこの発想を持ったことが「沼にはまる」きっかけだったように思います。

4月17日 まずはマイクでしょ

教室のトレーニングでは皆の前に立つトレーナーの存在を人間の五感を使って認識するのに対して、オンライントレーニングの場合は映像と音声だけで認識します。つまり映像と音声は重要な要素になるわけです。
なので映像が汚ければ話を聞きたいと思わないでしょうし、
音声が聞き取りづらければ話を聞きたいと思わないでしょう。

というわけで、まずは音声の環境から手を付けることになりました。
コンデンサーマイクというのが良いらしいという噂を聞きつけ、Blue MicrophonesのYeti Casterというのを購入しました。

机の上のスペースを取らないので便利だな、ぐらいにしか考えていなかったのですが、吊り下げ式のマイクはインパクト十分！トレーニングだけでなく、Zoomミーティングなどでもアイスブレイクに相当役立ちました。

4月18日 雑音が気になる

私の自宅は幹線道路沿いにあり、爆音で音楽を鳴らす車などいるとマイクが拾ってしまいます。ということで吸音材というのを買って、部屋中に張り巡らせてみました。

しかし、マイクには指向性の設定というのがあり、それを設定すれば解決できる問題だったということを吸音材を買ってから気が付きました…

4月20日 家のインターホンが気になる

自宅でトレーニングをしていると、人が喋っている最中にピンポーンって音が鳴るのが気になるようになりました。そこで、自宅の玄関からON AIRと表示させてインターホンを押さないようにしてみました。

だけどネオンサインなんて宅配の人は誰も見てないのよね..

4月24日 ウェブキャスティングミキサーを購入

ウェブキャスティングミキサーとは何か？もわかっていないのに、YAMAHA AG03が良いらしいという噂は不思議と耳に入るものです。
たまたま在庫があるお店を見つけたので、何も考えずに購入してみました。

ところが、YAMAHA AG03とマイクの間はXLRと呼ばれる規格のケーブルで接続しなければならず、前に買ったBlue MicrophonesのYeti というマイクはUSB接続しかできない！
お陰でせっかく買ったYAMAHA AG03は、しばらく自宅の押し入れの肥やしとなるのでした。

4月29日 映像も良くしよう

配信に使っているPCはデスクトップPCなのでカメラがありませんでした。
そこで、ロジクールのウェブカメラを購入しました。

このカメラ自体は「映像がキレイですね」ってお褒めいただくこともしばしばで買ってよかった代物です。しかし問題だったのは35000円近くも支払ってしまったことです..

5月6日 手書きで説明、さあどうする？

教室のトレーニングならホワイトボードは定番ですが、ではオンラインでは？
Microsoft Whiteboardアプリ×タブレットというのが多くの人の答えだと思うのですが、
ライブ感を出したいとか、変な欲を出しちゃったんですよね..
よく行く動物病院の先生が電子ノートを使っているのを見て、これだと思い購入。

しかし、電子ノートに書いてカメラに見せるという芸当は照明が反射して見えない！ということがわかり、箱を開けてから1分で使用を断念しました..
ちなみに現在はWACOMのタブレットを購入してMicrosoft Whiteboardアプリで手書きの解説をしています。

5月24日 スマートなイヤホンが欲しい

オンライン配信をしているときの音はスピーカーから出してしまうとハウリングを起こすので、皆さんヘッドホンやイヤホンをすることが多いと思いますが、装着している感じを出したくなかったんですよね。でっかいヘッドホンを装着していると、それだけで威圧感を相手に与えるかなと思ったのです。
見た目に装着している感を出さないこと、
連続使用時間が1日の研修(6時間)に耐えられること、
ワイヤレスであること、
以上の理由から我らがマイクロソフトのSurface Earbudsにしてみました。

ネットの評判には賛否両論あるようですが、私は買ってよかったと思います。
ちなみにSurface Earbudsを買った後で、デスクトップPCがBluetoothを使えなかったことに気が付いたことはナイショです。

5月31日 噂のATEM miniを購入

ZoomやTeamsでのオンライン配信をするとき、画面共有でPowerPointをしばらく出し続けていると、ふと不安になることがあります。それはお客さんが「いま喋っているのは国井ではなく、国井のボーカロイドではないだろうか？」と思い始めるのではないかと。
なので、画面共有しているときも国井が喋ってますよ感を出すために、画面にワイプを入れたいなと思ったのです。そこで、ワイプを簡単に入れられるATEM miniなる文明の利器があると聞いたので、US Amazonから取り寄せてみました。
(今なら簡単に買えるのにね)

しかし、また問題発生です。ATEM miniとカメラの接続はHDMI接続なのです。一般に販売されているウェブカメラはUSB接続なので、
ウェブカメラとATEM miniは接続できないことが判明しました。(そのくらい調べとけよ！)

6月1日 ATEM miniに接続するカメラを用意する

幸い自宅には昔買ったソニーのハンディカムとGo Pro Hero8がありました。これをなんとかATEM miniに接続できないかと考えてみました。
最初はGo Pro Hero8での接続を試してみたのですが、Go Pro Hero8にはHDMI接続端子がなく、メディアモジュラーと呼ばれるアタッチメント(9500円)を購入しなければなりませんでした。

しかも買ってきて試してみたところ、充電スピードよりも放電スピードのほうが速く、6時間の研修には耐えられず息絶えておりました。ということで、ATEM miniにはハンディカムを取り付けて、ハンディカムをウェブカメラ代わりに使うことになりました。

6月3日 映したい映像を共有できない

ATEM miniはYouTubeライブなどの配信をATEM miniから直接配信できるという触れ込みですが、私がやりたいのは普通にZoomやTeamsの会議のときの画面共有でワイプを入れること。

こんな感じの構成で、配信側PCと書いてあるデバイスのモニター(セカンドモニター)画面とカメラの映像をミックスさせて、ATEM miniでワイプの映像を作り、それをWebカメラとして配信側PCに送り出すという構成です。
つまりWebカメラの映像がそのまま画面共有になるということです。
だけどWebカメラの映像って、参加者全員で等分割に表示されてしまうのです。
そうではなくて、私のWebカメラの映像だけ大きく表示したい。
と思っていたら、Zoomには「スポットライトビデオ」という機能で自分のWebカメラの映像を最大表示にする設定があるのですね。
このことに気が付くまでに1か月もかかりました..
Teamsにも同様の機能が欲しいところです。
(※ATEM mini経由で画面共有すると、本来の画面共有と比べて解像度が低くなるという現象が起こるようで.. ここまで頑張ったのは一体何だったんだという感じです)

8月3日 YAMAHA AG03使えない問題にメスを入れる

YAMAHA AG03はXLRケーブルでしかマイクに接続できないことがわかり、
しばらく放置していましたが、XLR端子での接続ができるマイクを新しく調達しました。
それまでBlue Microphonesを使い続けてとても気に入っていたので、Blue Microphones Yeti Proというのを買ってみました。

早速開封してXLRケーブルを差し込もうとしたら刺さらない！
XLRの端子には3ピンと5ピンがあることをこのとき初めて知るのでした..

8月5日 端子の変換コネクター

Yeti ProのマイクについているXLR端子は5ピン、これに対してYAMAHA AG03の端子は3ピン、ということで5ピンから3ピンへ変換するコネクターを買って対応しました。

やっとつながり、ウェブキャスティングミキサーを通してマイクを利用してみると、明らかに音質のクオリティが上がり、ゲイン(ボリューム)を絞り込んでもはっきりと音が出ていることがわかりました。そして何よりも、ボリューム調整が手元で簡単にできるので、マイクミュートのままでしゃべり始めるミスをしなくなるというのが最大の特徴だったりします。

まとめ

私なりにスペックを調べて買っているつもりなのですが、調査が甘く「これ良い！」と思ったら、3秒後にはポチってるという病的な性格がこうした災いを引き起こす原因だったかなと思います。ですが、相当に高い授業料ではありますが、限られた条件の中で「私らしさ」というのを追求していくのも悪くないなと思いました。私の失敗が参考になれば幸いです。

The post オンライン研修のライブ配信環境について first appeared on Always on the clock.

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

私は主にトレーニングという立場からAzure ADに触れ、様々なお客様と触れているのですが、本当にこの数年で浸透してきたなという印象です。
あるサービスが出始めたばかりの頃、アーリーアダプターが騒いでいるレベルの頃は「〇〇ができる」みたいな話で盛り上がるわけですが、Azure ADのように多くの企業で使われるようになってくると「〇〇ができる」の話だけでなく、もっと現実的な部分にフォーカスされていくわけです。Azure ADという観点で言えば、そのうちのひとつに「監査ログ」があるでしょう。

Azure ADには誰がいつアクセスしたかを表すサインインログと、管理者がどういう管理作業を行ったかを表す監査ログがあり、監査ログを参照すれば、適切な管理作業が行われているか？不正アクセスによる設定変更がないか？などを追跡できるわけです。では、その監査ログをどうやって見るか？みたいな話になるとあんまり情報がないんですよね…
ということで、今回はAzure ADの監査ログにフォーカスしてみたいと思います。

監査ログを見る方法

Azure AD管理センターから[監査ログ]をクリックするとご覧になれます。
無償版Azure ADだと過去7日間、有償版Azure ADだと過去30日間のログを参照できます。

上の画面だと過去7日間に絞ってログを出してますが、
画面上部(上ペインと言えばいいのかな)ではログ一覧、その中から特定のログをハイライトすると、画面下部(じゃあ下ペインということで)にその詳細が確認できます。

上ペインでは日時の他、どういう操作を行ったかについての概要(例えば、カテゴリでUserManagement、アクティビティでUpdate userとあれば、ユーザーの更新を行ったんだなということがわかります)が確認できます。
また、アクターとターゲットというのが画面右側にありますが、アクターによってターゲットに対する操作を行ったというみかたをします。ですから、adminユーザーがsuser04ユーザーに対する操作を行ったという意味です。

アクターって誰？

IMEの変換候補に芥川賞が登場するアクターですが、
アクターは誰(何)によってAzure ADに対して変更が加わったかを表すものなので、不正アクセスの可能性を見極めるのであれば重要な要素になると思います。Azure AD管理センター画面から操作を行ったり、Azure AD PowerShellを使ってスクリプト処理で操作を行ったりすれば、その操作は明示的に管理者でサインインしていますから、アクターは必ずユーザーになります。一方、管理者が関係することなく処理が完結するものに関しては、アクターはユーザー以外になります。いくつか例を挙げてみましょう。

■セルフサービスでパスワードをリセットした
この場合、アクターはfim_password_service@support.onmicrosoft.comになります。SSPRという機能がパスワードをリセットするのでそうなります。
ただし、パスワードをリセットしたのは自分なので、fim_..ユーザーがアクターであるログの前に自分自身がアクターのログも一緒に出力されます。

■動的ユーザーグループのメンバーが追加・削除された
Microsoft Approval Managementというアクターが処理を行うそうです。

■Teamsからゲストユーザーを追加した
Microsoft B2B Admin Workerがアクターになります。関連するログも一緒に出るのでゲストユーザーを追加すると複数のログが出力されます。

■Teamsで追加したゲストユーザーが初めてアクセスした
Microsoft Invitation Acceptance Portalがアクターになります。ゲストユーザーを作ったタイミングではメールアドレスしかユーザーのプロパティに入っていませんでしたが、
初めてアクセスし、ゲストユーザーとしてのRedeemの処理を行うと、いつRedeemしたか？などの属性がゲストユーザーのプロパティの中に追加されるようになります。
その一部始終が監査ログでは記録されるのですね。ちなみにゲストユーザー自身がアクターのログも一緒に出力されます。

■Teamsでチームの設定を変更した
Microsoft Teams Servicesがアクターになります。Teamsのチームの実態はOffice 365グループですが、Azure ADから操作すれば管理者ユーザーがアクターになるし、Teamsから操作すればMicrosoft Teams Servicesがアクターになるのです。

■デバイスを登録した
Azure ADへのデバイス登録はDevice Registration Services、Intuneへのデバイス登録はMicrosoft Intuneがアクターになります。なお、登録されたデバイスは定期的にAzure ADやIntuneと通信しますので、OSバージョンが変わったなどのプロパティ変更が生じれば、アクティビティがUpdate deviceのログが出力されます。

ログの詳細を見る

繰り返しになりますが、ログ一覧から特定のログをクリックすると下ペインにその詳細が表示されます。例えば、上の画面でカテゴリーがUserManagement、アクティビティがUpdate userのログをクリックしましたが、このとき下ペインでは次のようなメッセージが出ています。

さらに[変更されたプロパティ]タブをクリックすると具体的に変更した箇所がわかります。

これを見ればAccountEnabled属性がTrueからFalseに切り替わっているので、ユーザーを無効化したことがわかります。

Microsoft Authenticatorを使うと監査ログが増える現象について

多要素認証、特にMicrosoft Authenticatorを利用するように構成している企業ではカテゴリーがUserManagement、アクティビティがUpdate userのログが大量に発生しているのではないかと思います。これは多要素認証を設定しているユーザーがMicrosoft Authenticatorを使ってサインインをするたびにデバイストークンが生成され、その結果が監査ログに出力されるためです。

多要素認証の設定はユーザーのプロパティなので、デバイストークンが変わるたびにユーザーのプロパティが変わる → 監査ログに出力される、というメカニズムなんですね。

Log Analyticsから監査ログを見る

最後に監査ログをLog Analyticsにエクスポートし、その結果を確認してみましょう。
Azure AD管理センター画面から[診断設定]項目をクリックし、AuditlogsをLog Analyticsワークスペースにエクスポートする設定を行います。
※設定の詳細はこちらからもご覧になれます。

設定が完了したら、Azure AD管理センター画面から[ログ]をクリックすると、
Log Analyticsから監査ログに対するクエリが実行できるようになります。例えば、先ほど出てきた多要素認証の実行結果を参照したいということであれば、次のようなクエリを書いて実行すると、

AuditLogs
| where InitiatedBy contains “fim_password_service@support.onmicrosoft.com”
| where TargetResources contains “StrongAuthenticationPhoneAppDetail”

ご覧のような結果を確認できます。

個人情報満載なので、結果画面の詳細まではお見せできないですが、こんな感じで監査ログを利用できますよ。

■ ■ ■

最後になりますが、監査ログにはAzure ADの監査ログとMicrosoft 365の監査ログがあり、
Microsoft 365の監査ログはOffice 365セキュリティ/コンプライアンス管理ポータルからアクセスできます。
https://protection.office.com/unifiedauditlog

こちらはMicrosoft 365のリソースに誰がいつアクセスしたかについて追跡するもので、
Azure ADの監査ログと名前は同じなのに見えるログは全く違うという人騒がせなツールです。これについてはまた別の機会に触れたいと思います。

The post Azure ADの監査ログ first appeared on Always on the clock.

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

The post Microsoft 365関連コースの新しいスケジュールがリリースされました first appeared on Always on the clock.

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

Windowsコンピューターの電源を入れて、サインイン画面でユーザー名とパスワードを入れて、、サインインが完了するとコマンドプロンプトの画面が勝手に立ち上がること、ありませんか？これが1990年代だったら「ウイルスだ！」とか言って大騒ぎしたと思うのですが、今は2020年代。Windowsが内部的な処理で、ログオンスクリプト(？)でコマンドプロンプトを立ち上げることだってあるでしょう。

しかし、それが何かよくわからないから怖い。
そんなもんだから、あれは絶対ウイルスだ！とか言って根拠のない心配をする人もいるでしょう。そんなときはMicrosoft Defender ATP改めMicrosoft Defender for Endpointを使って、白黒つけましょう！

コンピューター起動時の状況をMDATPのタイムラインで追跡

MDATPにオンボーディングされたデバイスのログはアラートの有無にかかわらず、Microsoft Defender Security Centerのポータル画面にデバイスごとのタイムラインに表示されます。タイムラインでコンピューターを起動した日時のログを見てみると、cmd.exe を実行しているログを見つけることができました。

cmd.exeは何をしているのか？

cmd.exeのログが確認できたら、クリックして詳細を参照します。すると、cmd.exeからOneDriveSetup.exeを削除する操作を行っていることが確認できました。つまり、ゴミを消したってこと？？

続いて別のログを見てみると、今度はrmdirコマンドを実行してフォルダーを削除していることが確認できました。

さらに別のログを見てみましょう。
こちらはcmd.exeからconhost.exeを呼び出して実行していることがわかります。
conhost.exeはcmd.exeの実行をお助けするプログラムなので、これも問題ないことがわかります。(conhost.exe自体がマルウェアに置き換わっているのでは？という疑う方はconhost.exeのリンクをクリックするとexeファイルについているデジタル署名の情報なども同時に確認できます)

以上を踏まえると、Windows 10を起動した時に出てくるコマンドプロンプトはメンテナンスタスクを実行しただけだったということがわかりました。

ということで、今日はMDATPのタイムラインの見かた、使い方を紹介しながら、
あるあるな疑問にお答えしてみました。

コンピューターで怪しいと思う動作があるなら、その動作が発生した日時を控えておき、MDATPのタイムラインで調べていけば、色々なことが明らかになって疑問や不安が解消できるのではないかと思います。

■ ■ ■
マルウェアの存在が広く知られるようになった2000年頃、コンピューターで何かあるとなんでもマルウェアのせいにする人いましたよね？プリンターで印刷したら、間違ったプリンタードライバーが入っていたみたいで、アラビア語みたいな文字が紙にびっしり印刷されたのを見て「先輩、プリンターがウイルスに感染しました！」って。
こんなとき、MDATPがあったら論理だてて説明できたんだけどな。

The post Windowsサインイン時に登場するコマンド画面をMDATPで追跡 first appeared on Always on the clock.

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

Windows 10のデバイス管理形態にAzure AD参加というのがあり、このデバイス登録を行うと、Windowsの起動時にAzure ADのアカウントを使ったサインインができるようになります。
Active Directoryドメイン参加の時はWindowsのサインイン時にADアカウントを利用していたわけですから、Active Directoryドメイン参加のAzure AD版、そんな感じの管理形態です。

ADドメイン参加をやめてAzure AD参加を利用しましょうという話の時によく出てくるのが

ドメイン参加のサーバーにアクセスできなくなるのでは？

という話です。
ところが、Azure AD参加しているデバイスはWindowsのサインイン時にAzure AD Connectで同期されたユーザーでサインインしていれば、自動的にADドメインのユーザーとみなしてアクセスを認めます。

しかしこの話、何かおかしくありませんか？
だってActive Directoryの認証・認可をするときはADのDNSサーバーにアクセスしてドメインコントローラーの場所を見つけて認証を開始.. のようなプロセスがあるはずなのに、
Azure AD参加デバイスはAD用のDNSサーバーなど全く使っていません。
じゃあ、どうやってADにアクセスして認証しているのでしょうか？

そこで、今回はAzure AD参加デバイスにWireSharkをインストールしてアクセスをしてみました。さらにWindows Serverを2台用意して、1台をドメインコントローラー(192.168.1.175)、もう1台をファイルサーバー(192.168.1.176)にしてみました。
Azure AD参加しているクライアントコンピューター(192.168.1.6)でWireSharkを実行して、ファイルサーバーの共有フォルダー(\\fs16\adfs)にアクセスした様子をパケットキャプチャしてみました。
共有フォルダーにアクセスするときは認証画面など一切出てくることなくアクセスできましたが、裏の動きはどうなっているのでしょうか？見てみましょう。

まずWireSharkのConversationsという機能を使ってクライアントがどのようなIPと通信しているか確認しました。すると全くドメインコントローラーとの通信は発生していないことがわかりました。

次に名前解決について。\\fs16というUNCパスを指定していますが、どうやって名前解決しているのでしょうか？
192.168.1.6 <==> 192.168.1.176 でフィルターをかけてパケットを見てみると、最初のやり取りでLLMNR(UDP5355)というパケットのやり取りがあることがわかります。
LLMNRとは通信相手となるコンピューターの名前解決を行うプロトコルで、確かWindows Vistaあたりから実装された名前解決方法です。

名前解決が終わるとファイル共有へのアクセスを行うべく、SMBプロトコル(TCP445)を使った通信を開始します。

そして認証プロセスは.. ご想像のとおりNTLMを利用していることがわかります。NTLM認証の場合、Kerberosプロトコルを使った認証と異なり、ドメインコントローラーと直接通信しなくても認証自体が完了できてしまいます。
事実、一連の通信ではAzure AD参加デバイスとドメインコントローラー間の通信は一切発生していません。

最後にドメインコントローラーのイベントビューアを見てみます。すると、NTLM認証が発生したタイミングでセキュリティログに下のようなイベントを残していました。
きちんとAzure AD参加デバイスでWindowsサインイン画面で入力したユーザー名と同名のActive Directoryドメインのユーザーと認識し、サインインが成功していることがわかります。

Azure AD参加デバイスがWindowsサインインするときはAzure ADに登録されたユーザー名でサインインしますが、そのユーザーがAzure AD ConnectによってActive Directoryから同期されたユーザーの場合、Active Directoryドメインに参加しているサーバーへのアクセスはNTLMを利用して透過的に認証し、シングルサインオンアクセスを実現していることがわかりました。
ただし、このときに気を付けたいのはNTLMv2認証を利用してアクセスをしている点です。
Active Directoryでは認証のベストプラクティスとしてKerberosを使え！NTLMを排除せよ！という考えがあり、グループポリシーでNTLM認証をブロックするように設定している会社もあるかと思います。
しかし、これを実装していると、NTLMによるサインインはブロックされてしまうのでご注意ください。

The post Azure AD参加デバイスからADドメイン参加デバイスにアクセス first appeared on Always on the clock.

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

突然ですけど多要素認証使ってますか？
これだけ多要素認証(MFA)が重要だ！と言われる世の中になると、会社の中でも利用を徹底させたいという機運になるでしょう。昔はMFAの設定などユーザー単位でしか有効化・無効化できなかったけど、今では色々な設定オプションがあり、結局誰にMFAが適用されているのか、わかりにくかったりします。
私が思いつくだけでも、ざっとこんな感じです。

・ユーザー単位でMFA有効
・セキュリティ既定値の設定でMFA有効
・条件付きアクセスでMFA有効
・パスワードレス認証でMFA有効(MFAというか、デバイスベースの認証？？)

なので、うちの会社でMFAが有効になっているか？を調べようと思ったら、
上記のパターンを全部調べなければなりません。
ですので、MFAの適用を設定から確認するのではなく、
結果から確認するというアプローチをとるようにしています。
そして結果から確認するのであればサインインログから調べていくのが良いでしょう。

サインインログでMFAの状況を確認

Azure AD管理センターの[サインイン]ログでは幸いなことに個々のログに認証の要件というのがあって、その中で多要素認証か単一要素認証か、がわかるようになっています。

さらに個別のログから[認証の詳細]タブをクリックすると、多要素認証の中でも何を使って認証したかを確認できます。

例えば、上の画面ではWindows Hello for Business(WHfB)を使って認証したことがわかります(アプリケーションがWindows Sign inですから、おそらくAzure AD参加しているデバイスでWHfBを使ったのでしょうね)

その他、
MFAで電話で通話した場合であれば[認証方法]欄(Authentication Method)にPhoneCallと
入りますし、
MFAでMicrosoft Authenticatorを使った場合であれば[認証方法]欄にMobile App Notificationと入ります。

それからパスワードレスでMicrosoft Authenticatorを使っている場合、[認証方法の詳細]欄(AuthenticationDetails)にPasswordless phone sign-inと入ります。

見にくいログをなんとかしたい

ただ、サインインログの画面のクエリはざっくりとしたものしか書けなくて、このレベルのクエリを設定しようと思ったら、CSVファイルに吐き出してからExcelでクエリを実行するか、
Log AnalyticsへエクスポートしてKQLでクエリを書くかのいずれかになります。
ここではKQLでクエリを書いてみましたので、確認してみましょう。

■多要素認証を利用したサインインであるか？
この場合はAuthenticationRequirementを見ればわかります。
projectを使って日時とユーザー名を一緒に表示してみます。

SigninLogs
| project TimeGenerated, UserDisplayName, AuthenticationRequirement

結果はこんな感じで見えます。

SigninLogs
| where AuthenticationDetails contains “Mobile”
| project TimeGenerated, UserDisplayName, AuthenticationDetails

結果はこんな感じで見えます。
このとき、注目したいのはAuthenticationDetailsが0と1に分かれてログが出ており、0のログにはauthenticationMethodにCloudOnlyPasswordと出ていて、1のログにはMobile App notificationと表示されていることがそれぞれ確認できます(なんで分けているのだろうか？)。

SigninLogs
| where AuthenticationDetails contains “WindowsHelloForBusiness”
| project TimeGenerated, UserDisplayName, AuthenticationDetails

結果はこんな感じで見えます。こっちも0と1に分かれてログが出ています。

SigninLogs
| where AuthenticationRequirement contains “multiFactorAuthentication”
| where AuthenticationDetails contains “Passwordless”
| project UserPrincipalName, AuthenticationDetails

パスワードレスのサインインの場合もAuthenticationDetailsは2段に分かれてログが出力され、片方(0と書かれた部分)にPasswordless phone sign-in、
もう片方(1と書かれた部分)にMFA requirement satisfied by strong authenticationという特徴的なメッセージが残ります。

MFA requirement satisfied by strong authenticationのメッセージも前述のサイトにMFAが不要なケースのメッセージとして記載されていました。よく考えたら、パスワードレスサインインってそれ自体が既にMFAをやってるようなものですよね。

会社の中でのMFAの利用状況から話が飛んで、どのような類のMFAを使っているか？までを調べることになってしまいましたが、参考になることがあればうれしいです。

【参考】サインイン レポートを使用して Azure Multi-Factor Authentication イベントを確認する
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/howto-mfa-reporting

The post MFAの見える化 first appeared on Always on the clock.

皆さんこんにちは。国井です。
Azure ADにセキュリティの既定値群(セキュリティデフォルト)と呼ばれる設定がリリースされ、MFAを適用する条件付きアクセスポリシーがAzure AD Premiumのライセンスがなくても利用できるようになっています。

公式ドキュメントでは以下の設定を強制するように構成されると書いてあります。

すべてのユーザーに対して Azure Multi-Factor Authentication への
登録を必須にします。
管理者に多要素認証の実行を要求します。
レガシ認証プロトコルをブロックします。
必要に応じてユーザーに多要素認証の実行を要求します。
Azure portal へのアクセスなどの特権が必要な作業を保護します。

だけど、レガシー認証とかまだブロックして欲しくない(というか心の準備ができていない)会社はいっぱいあるだろうし、何よりセキュリティデフォルトが有効だと自社で独自の条件付きアクセスの設定が使えない！

ということで条件付きアクセスを使おうと思っている会社では、Azure ADを使い始めるとき、まず最初にこの設定を無効にしておきましょう。

私などはトレーニングでMicrosoft 365の無料試用版を取得する機会が多いのですが、
その都度、セキュリティデフォルトを無効化するのが面倒くさい。
なんとかPowerShellとかで設定できないものかと思ったのですが、Microsoft Graphを利用することで実現できるようです。

あらかじめAzure ADの[アプリの登録]からアプリを作成し、シークレットを生成しておきます。(この時生成されるシークレットは後で使いますので、記録しておきましょう)

それからアプリの登録を作成したら生成されるクライアントIDもテナントIDと共に控えておきましょう。

次にアプリの登録を利用してidentitySecurityDefaultsEnforcementPolicyリソースにアクセスできるよう、アクセス許可を割り当てておきましょう。
[アプリの登録] – [APIのアクセス許可] を開いて、アプリケーションのアクセス許可としてMicrosoft GraphのPolicy.Read.AllとPolicy.ReadWriteConditionalAccessを割り当てます。ここまでできたら、最後に管理者の同意を割り当てて設定は完了です。

あとは最後の大仕事として、アプリの登録を利用するようなPowerShellスクリプトを作成して、identitySecurityDefaultsEnforcementPolicyの設定を変更できるようにしましょう。

$TenantID = “テナントIDを入れる”
$ClientID = “アプリケーションIDを入れる”
$Secret = “クライアントシークレットを入れる”

#パラメーターの指定
$oAuthUri = “https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token”
$url = “https://graph.microsoft.com/beta/policies/identitySecurityDefaultsEnforcementPolicy”

$body = @{
client_id     = $ClientId
scope         = “https://graph.microsoft.com/.default”
client_secret = $secret
grant_type    = “client_credentials”
}

#アクセストークンの取得
$authResponse = Invoke-WebRequest -Method Post -Uri $oAuthUri -ContentType “application/x-www-form-urlencoded” -Body $body -ErrorAction Stop
$token = ($authResponse.Content | ConvertFrom-Json).access_token
$authHeader = @{‘Authorization’=”Bearer $token”}

#セキュリティデフォルトの設定変更(無効化)
$body = (@{“isEnabled”=”false”} | ConvertTo-Json)
$authHeader = @{‘Authorization’=”Bearer $token”;”Content-Type” = “application/json”}
$res = Invoke-WebRequest -Headers $AuthHeader -Uri $url -Method Patch -Body $body

以上の設定によりセキュリティデフォルトの設定を無効にできます。
だけど、これだったらGUIから設定したほうが早かったですね。。

The post 条件付きアクセスとAzure ADのセキュリティの既定値 first appeared on Always on the clock.

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

最近、お問い合わせページからいただいているお問い合わせが私のメールアドレスに転送されないという事象が発生していることにしばらく気が付かず、久しぶりに問い合わせページを見たら、たくさんお問い合わせをいただいておりました。無視するつもりはなかったんですけど.. ごめんなさい。今日はそのお問い合わせでいただいていた内容と同じ内容のご質問を何人かの方からいただいていたので、そのQ&Aということで進めていきます。

■ ■ ■

弊社で開催しているEMSトレーニングでは、Active Directory × GPOによるデバイス管理からAzure AD × Microsoft Intuneによるデバイス管理に切り替えて運用したいというお客様がいらしており、その中でもよく話題にあがるのがGPOで設定していたWindows UpdateのパラメーターをどうやってIntuneに切り替えるか？です。

Intuneでは[Windows 10 更新リング]というポリシーがあり、このポリシー設定を通じてWindows 10のWindows Updateの設定を変更します。ところが[Windows 10 更新リング]というポリシー、設定が適用されたことは確認できるのですが、各デバイスでの設定後の値を見ることはできません。

例えば、更新プログラムを自動でインストールするように設定されているか？
アクティブ時間は何時から何時までか？などの現在の設定を知りたいという場合には
各クライアントコンピューターのログ (レポート) を参照する必要があります。

クライアントレポートを参照する

レポートは
設定アプリ > アカウント > 職場または学校にアクセスする > 情報 > レポートの作成
から参照できます。ただし、[レポートの作成] ボタンをクリックしない限り、
レポートは生成してくれません。

[レポートの作成] ボタンをクリックするという操作はMdmDiagnosticsTool.exeというコマンドがつかさどっているので、これを利用して自動実行してしまいましょう。

MdmDiagnosticsTool.exe -out <保存先フォルダー>

こうして生成されたログファイル群の中からMDMDiagReport.htmlファイルを見てみましょう。

字が小さくて申し訳ないのですが、Managed policiesのカテゴリにUpdateというエリアがあり、その中でそれぞれの設定項目の中の現在の値(Current Value)が確認できることがわかります。そもそも設定項目がわからないという方は公式サイトに記載がありますので、ご参照ください。

余談ですけど、VMwareのWorkspace ONEでもOMA-URIベースの設定を行うことができるようになっており、Policy Builderというのを使うとそれぞれの設定項目の名称を簡単に調べられたりします。例えば、品質更新プログラムのロールバックを行う設定項目の名前を調べたい場合、UpdateカテゴリにアクセスしてRollback > Quality Update > ADD と選択すると、画面右側にOMA-URIの値が生成されます。この時のRollback/QualityUpdateと書かれた部分が設定項目になります(当たり前ですけど、Intuneの全設定項目をカバーしているわけではないので、後述するActiveHoursEnd項目はありません)。

話を戻しますが、設定が完了するとアクティブ時間の終了時刻はDefault Valueの17時に対して、Current Valueでは22時に設定が変わっていることがわかります(ブラック起業かよ！)。

遠隔からコマンドを実行する

レポートが生成できることがわかると次に問題になるのはMdmDiagnosticsTool.exeを遠隔から実行したい！ということになりますが、PowerShellスクリプトをIntuneから実行するように構成すればよい話だと思います。
また、生成されたレポートファイルの保存場所としてAzureストレージを利用すれば各クライアントからのレポートを一か所に集約することができるでしょう。
やり方は… って思案していたら、既に実践されている方がいらしたのでこちらも参考にしてみてください。

The post Microsoft Intuneで設定したWindows Updateのパラメーターを調べる first appeared on Always on the clock.

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

先日いただいたご質問で
条件付きアクセスで多要素認証を設定しているときに
アプリケーションパスワードを設定していたらアクセスできるのか？
というのがあり、みんなにも共有しておこうかなと思い、投稿してみました。

結論から言うと「アクセスできない」になるのですが、どのようなログ出力になるのか？であったり、どう対処すべきかであったりも含めて共有していこうと思います。

■ ■ ■

前提条件は次の通りです。

Exchange OnlineにiPhoneの標準メーラーを使ってExchange Onlineに接続
→ 多要素認証が使えないので、アプリケーションパスワードでアクセス

このような状況の時に、
Azure AD Identity Protectionでサインインするユーザーがリスクユーザーとして判定されている場合、条件付きアクセスで多要素認証を強制するように設定してみました。
iOSデバイス側でアプリケーションパスワードを利用してサインインしてみると
サインインは失敗する(失敗の仕方については後述)のですが、このときに管理者サイドではそのことをどうやって把握できるのか確認してみましょう。

結果の確認

条件付きアクセスによるアクセス制御の結果はAzure AD管理センターの[サインイン]で確認できます。サインインログの一覧から該当のログを参照すると、次のように表示されます。
状態は「成功」だけど条件付きアクセスは「失敗」という表示になっています。
ログには「単一要素認証」って表示されますが、これはアプリケーションパスワードを利用しているからなのでしょう。

他のタブを開いてみましょう。[条件付きアクセス]タブ。
ここではどの条件付きアクセスポリシーに引っかかってブロックされたかが確認できます。
ただし、この画面だけでは多要素認証をやらなかったのか？
それともアプリケーションパスワードをつかったからなのか？はわかりません。

もうちょっと進めてみましょう。次に[認証の詳細]タブ。こちらは予想通りの結果です。

ところが、[認証の詳細]タブに表示される内容は多要素認証を使っている場合、
下の画面のように2行にわたって認証の詳細が表示されます。
つまり、多要素認証を使っていなかったり、アプリケーションパスワードを使っている場合は
多要素認証にならないので、[認証方法]に表示される内容がひとつになるのですね。

ちなみに上の図は[結果の詳細]欄にMFA required in Azure ADと書かれていますが、
これは多要素認証に失敗した場合であって、成功した場合はMFA completed in Azure ADと表示されます。

参考までに、、ですが、多要素認証を利用した場合、サインインログは2つ表示されます。
ひとつは 状態 = 中断、条件付きアクセス = 成功
もうひとつは状態 = 成功、条件付きアクセス = 成功のログです。
後者のログはご覧のような形で表示されます。

ここまでの話をまとめると、多要素認証を設定している場合のログは次のようになります。

・アプリケーションパスワードの場合はログに「単一要素認証」と表示される

・多要素認証にトライしたけど失敗した場合は[認証の詳細]タブに
MFA required in Azure ADと表示される

・多要素認証に成功した場合は[認証の詳細]タブに
MFA completed in Azure ADと表示される

クライアント側の動作

続いてiOS側を見てみましょう。iOS標準メーラーからアプリケーションパスワードを利用して認証を完了させると、認証エラーのメッセージが出てこない代わりにご覧のようなメールだけを受信します。

メール内のリンクをクリックするとApp Storeへリダイレクトされ、Outlookアプリのダウンロード画面が表示されます。つまり、iOS12よりも前の標準メーラーでは先進認証ができない(多要素認証が使えない)から黙ってOutlookアプリを使え！ということなのですね。
以前にも書きましたが、iOS12以降の標準メーラーはExchange ActiveSyncの代わりに先進認証を使うようになっていますので、多要素認証を使うようになり、アプリケーションパスワードを利用した認証はしなく(できなく)なります。

The post 条件付きアクセス×多要素認証におけるアプリケーションパスワード first appeared on Always on the clock.

皆さんこんにちは。国井です。
このブログでは様々なトピックを取り上げて、色々な方にアクセスしていただいたおかげで10年以上が経過しました。その間にもテクノロジーは進化し、わかりやすいところで言えばADFSサーバーからAzure ADへの変化があったわけです。

ところが私が過去に執筆したADFSに関する投稿は未だに一定のアクセス数があり、
今あるADFSサーバーに対峙している方もまだまだ多いのではないかと思います。
ニーズが少なくなったと考え、かつて開催していたADFSトレーニングはもう終了をやめてしまいましたが、もし必要な方がいたらと思い、今日はかつて提供していたADFSトレーニングのテキストを公開してみることにしました。

とはいえ300ページを超える大作なので、分割して提供していこうと思います。
※演習操作手順書については前提条件となる環境によって手順が異なるので、ここでは(一部)割愛してお届けします。

■ ■ ■

目次

第1章 ID 連携の概要

第 1 章では、デジタルアイデンティティの概要と ID 連携の必要性について解説します。ID 連携を実現するためにマイクロソフトが提供するソリューション、ADFS (Active Directory Federation Services) と Azure AD の概要について解説します。

コンピューター システムの世界では、人やモノなどを識別する情報として、ユーザー名やコンピューター名などの情報が存在します。このような、人やモノを識別する情報をデジタルアイデンティティ (ID) と呼んでいます。

デジタルアイデンティティには、人やモノを識別する情報に付随する情報が含まれます。例えば、ユーザー名の場合、ユーザー名に付随する情報として、部署名、役職、事業所、電話番号などの情報がありますが、これらの情報もデジタルアイデンティティに含まれます。

デジタル アイデンティティを正しく確認できることで、コンピューターシステムでは、一人ひとりに合わせた適切なサービスを提供できるのです。

私たちがコンピューター システム上に存在する、様々なアプリケーションを利用する際、特定の利用者だけにアプリケーションを利用できるように ID の確認を行います。それが認証と承認です。

認証とは「本人確認」のことであり、コンピューターシステムの世界では一般にユーザー名とパスワードを利用して本人確認を行います。認証というと、ユーザーの認証が有名ですが、実際にはコンピューターの認証やサービスの認証など、様々な ID を対象に認証を行うことができます。
認証を通じて「本人確認」を行うことにより、誰かになりすましたユーザーであるか？、どこかのコンピューターになりすましたコンピューターではないか？など、「なりすまし」を防止する効果があります。

Active Directory の場合、ドメインをひとつの管理単位として認証と承認を行っています。Active Directory の認証と承認では、Kerberos (ケルベロス) と呼ばれる認証・承認のシステムを採用し、認証に成功すると、認証成功のあかしとしてドメインコントローラーから TGT と呼ばれるチケットが発行されます。

Active Directory で行った認証の結果に基づいて、クラウドや業務提携を結ぶ別組織への認可を行う仕組みを提供するのが ADFS サーバーです。ADFS サーバーでは認可を行うために使用する ST チケットの代わりに、クラウド等で汎用的に利用可能な「トークン」と呼ばれるデータを利用します。
Active Directory ドメインコントローラーと ADFS サーバーは次のような方法で連携し、クラウドや業務提携を結ぶ別組織への認証・認可を実現します。

① ユーザーはドメインコントローラーで認証
通常のサインインと同じように、ユーザー名とパスワードを入力してドメインコントローラーで認証を行います。

② 認証結果に基づき、ADFS でユーザーにトークンを発行
Active Directory で行われた認証の結果に基づき、ADFS サーバーに対してトークンの要求を行います。ADFS サーバーは要求を行うユーザーに合わせて、名前やメールアドレスなどの情報 (クレーム) を含めたトークンを発行します。
また、トークンを発行するときには、あらかじめ条件を設定し、条件を満たさないユーザーからのトークン発行要求に対して、トークン発行そのものを拒否する認可機能を備えています。

③ トークンをアプリに提示して最終的なアクセス許可レベルを決定
トークンを取得したユーザーはアプリに対してトークンを提示し、アクセス許可を得ます。どのようなアクセス許可が割り当てられるかはトークンの中に含まれるクレームの情報に基づいてアプリが決定します。

以上のような流れで処理を行うことによって、次のようなメリットが得られます。

認証と認可を行う組織を別々にできる

ADFS サーバーを利用することによって、認証を行うサーバーと認可を行うサーバーを別々のサーバーにすることができます。つまり、認証サーバーと認可サーバーを異なる組織に配置して運用することが可能です。

クレーム情報をもとに認可が行える

ドメインの場合、ユーザーやグループを基準にアクセス許可を割り当てていました。ドメインで発行されるチケットにユーザーやグループの情報が含まれていたからです。しかし、ADFS サーバーを利用する場合、トークンに含まれる情報 (クレーム) は自由に決められます。そのため、アプリが求める情報をトークンに含まれるように構成したり、部署名や役職などをクレームに入れて部署名や役職名をもとにしたアクセス許可を設定したりすることができるようになります。このように ADFS サーバーを利用した認証・認可はクレーム情報をもとに処理されることから、「クレーム ベース認証」と呼ばれることがあります。

組織間でシングルサインオンが実装できる

クレーム ベース認証は認証と認可を行う組織を別々にできます。そのため、自分の組織で 1 度だけ認証を行い、その認証結果をもとに別の組織で認可を行う、組織間でのシングル サインオンが実装できるメリットがあります。

クレーム ベース認証では、ID 情報を認証側だけに持たせて運用する方法と、認証側・認可側の両方に持たせる方法があります。

クレームベース セキュリティ

クレーム ベースセキュリティの場合、認可サーバー側で ID 情報を持ちません。認可サーバーでは、トークンに含まれる ID 情報を使って、ID を識別します。ADFS サーバーを利用する多くのアプリケーションではクレーム ベース セキュリティの方法で、認証サーバーと認可サーバー間の連携を実現しています。

ID 連携

ID 連携の場合、認証サーバーと認可サーバーの両方でID 情報を持ちます。認証サーバーで認証した結果に基づいてトークンを渡すことで、認可サーバーにおける特定の ID で認証を済ませたとみなします。この方法で連携する場合、認証サーバーと認可サーバーで同じ ID 情報を持たなければならないため、Microsoft Forefront Identity Manager (FIM) などを利用して、ディレクトリ サービスに格納されている ID 情報を同期します。このとき、ID 情報を同期し、認可のサーバーに ID 情報を登録するプロセスを「プロビジョニング」と呼びます。

ADFS サーバーで発行されるトークンは 1 つ以上のクレームから構成されています。クレームとはユーザーなどの特徴を表す情報で、クレーム ベース認証では、名前、メールアドレス、電話番号などの様々な情報を扱うことができます。

クレーム ベース認証で扱われるユーザー情報は、認証サーバーに格納されている情報を活用することができます。例えば、Active Directory ドメインを認証サーバーとして利用していれば、Active Directoryユーザーのプロパティに登録されている属性情報をクレームとして利用できます。

1 つ以上のクレームから構成されるトークンは、ADFS から発行された後に改ざんされることのないよう、トークン全体に対してデジタル署名を施します。このとき、デジタル署名に使われる証明書を「トークン署名証明書」と呼びます。

前のページで ID 連携を利用することで、認証側で認証したユーザーと認可側で保有するユーザーを関連付けて、シングルサインオンを実現できることを解説しました。

では、2つのディレクトリに格納されているユーザーはどのように関連付けるのでしょうか？

ID 連携で 2つのディレクトリに格納されているユーザーを関連付けるときは、あらかじめキーとなるクレームを決めておき、そのクレームの値が同じであるかをチェックすることで、2 つのユーザーが同一のユーザーであると判断します。

クラウドで提供されるアプリで ID 連携を実装する場合、Google Apps や Salesforce では
NameIdentifier クレームに含まれるユーザー名 (メールアドレス形式) が 2つのディレクトリで同一であることをチェックします。

ID 連携のためのプロビジョニング

2つのディレクトリにある ID を連携させるためには、プロビジョニングを行い、2 つのディレクトリに同じ ID を持つ必要があります。Office 365 では、後述するディレクトリ同期ツールによって、2つのディレクトリでの同期を実現しますが、その他のアプリでは何かしらの方法で ID 同期を行う仕組みを持つ必要があります。

編集後記

ADFSトレーニングは2017年8月の開催を最後に開催していないのですが、会計で言うところの減価償却も終わっただろうし、有償で受講していただいた方にお届けしてから3年以上も経過するので、もう良いだろうと思い、公開することにしました。
Advent Calendarっぽく25回に分割してお届けしますので、ゆっくりと読み進めてもらえれば嬉しいです。

<続く>

The post ADFSトレーニングテキスト全文公開チャレンジ(1) first appeared on Always on the clock.

皆さんこんにちは。国井です。
前回からスタートしたADFSトレーニングテキスト全文公開チャレンジ。
Advent Calendar風に毎日公開していこうかなと思っているのですが、
第2回は「第1章 ID連携の概要」から後半部分の「ID連携とは」をお届けします。

■ ■ ■

ADFS サーバーを利用して ID 連携を実装する場合、アクセスするアプリが自社内にあるのか、またはクラウドなどの領域外にあるのかによって認証・認可のステップは異なります。

自社内にあるアプリにアクセスする場合、Active Directory で認証を行った後、同じく自社内にある ADFS サーバーが認可を行った結果としてアプリのためのトークンを発行し、そのトークンを持って直接アプリにアクセスします。そして、アプリはトークンの内容に基づいて最終的なアクセスの可否を決定 (認可) します。

それに対して、領域外にあるアプリにアクセスする場合、異なる領域で利用可能なトークンを発行した上でアプリにアクセスする必要があります。そこで、ADFS サーバーでは、異なる領域のトークンを発行するサーバー(トークンを発行するサーバーを STS と呼びます。詳しくは後述します。) にアクセスするためのトークンを発行します。
以上のような動作によってアクセスの可否を決定するため、ADFS サーバーとアプリでの認可に加えて、STSでの認可も同時に行うことができます。

次のページから、領域外にあるアプリにアクセスする場合を例に、具体的にそれぞれのサーバーにアクセスする際の処理について解説します。

ADFS を利用して ID 連携機能を実装した場合、以下のような動作で認証と認可の処理を行います。

① アプリケーションにアクセスすると、セキュリティ トークンを要求される
クライアント コンピューターから ID 連携を利用したアプリケーション (APP サーバー) に接続すると、トークンが必要であることをクライアントに通知 (リダイレクト) します。

② 認可側の ADFS サーバーにアクセスし、認証先を指定される
トークンが必要であることを知ったクライアント コンピューターは①で得た情報をもとに認可側の ADFS サーバーに接続します。ここで、クライアント コンピューターが認証を行う先を紹介します。もし、複数の認証先が存在する場合には、クライアントコンピューターから選択することも可能です。

③ 認証側の ADFS サーバーにアクセス
②の結果、どこで認証を行うか決定したら、クライアントコンピューターは認証を行う場所にある ADFS サーバーに接続します。すると、トークンを取得するために事前に認証を行うよう、認証用のエンドポイント (Web ページ) にリダイレクトします。

④ 認証側の ADFS サーバーで認証を要求
クライアント コンピューターは ADFS サーバーの認証用ページにアクセスすると、認証を開始します。あらかじめ決められた認証方法に基づいて、認証を行います。

⑤ 認証 & 属性値の取得
クライアント コンピューターから④で入力した資格情報は認証側の ADFS サーバー経由で認証システムに送信され、正しい資格情報であることを確認します。ADFS では、認証システムに Active Directory を利用するため、Active Directory に対して資格情報の確認を行います。認証が成功すると、その結果をもとに、メールアドレスや姓名など、ユーザーの属性値を Active Directory から取得します。属性値の取得は Active Directory からだけでなく、SQL Server や LDAP ディレクトリから取得することも可能です。

⑥ 認証結果をもとに特定のクレームが含まれるトークンを発行
⑤で入手した属性値をもとに、ADFS サーバーはユーザーのためのトークンを発行します。
資格情報の確認 (認証) は Active Directory が行ったのに対して、トークンの発行は ADFS サーバーが行う、というように、認証とトークンの発行は別々のサーバー役割によって行われている点に注目してください。

⑦ 認可側の ADFS サーバーにアクセスし、トークンをもとに認可を行う
認証トークンが発行されると、クライアント コンピューターはトークンを持って、認可側の ADFS サーバーにアクセスします。すると、ADFS サーバーは認証トークンを確認し、アクセス可否を判断します。また、ADFS サーバーであらかじめ定義されたルールに基づき、認証トークン内のクレームは必要に応じて書き換えられ、認可トークンとして利用できるようにします。

⑧ 認可側の ADFS サーバーで発行されたトークンを利用してアクセス
認可トークンを受け取ったクライアント コンピューターは、認可トークンを持って、アプリケーションサーバーにアクセスします。すると、アクセスに必要な権限を持ったユーザーとみなし、アプリケーションへのアクセスを許可します。

以上のように、ADFS サーバーでは ID 連携の方式に基づく、認証と認可を行うことにより、異なる組織にあるアプリケーションにアクセスできるようになります。
このとき、認証側と認可側に ADFS サーバーをそれぞれ配置することで、ID 連携における、認証と認可を別々の場所で行うことができます。

前のページでは、ID 連携の動作詳細について確認しました。一連の動作の中で利用された資格情報とトークンについて、整理しましょう。

Windows 認証に使用した資格情報
手順④で行われた認証は Active Directory に対する認証です。この認証に成功すると、資格情報をもとにトークンを作成するための作業に入ります。

認証側 ADFS サーバーで発行されるトークン
Windows 認証を行った後、認証側 ADFS サーバーに対してトークンの要求を行います。ここで要求・発行されるトークンは、ID 連携で使われる、認証トークンになります。

認可側 ADFS サーバーで発行されるトークン
認証トークンを持って、認可側の ADFS サーバーにアクセスし、アクセスを認可された場合、新たなトークンが発行されます。このトークンは認可トークンになります。

前のページで 3 つの資格情報とトークンについて解説しましたが、そのうち、ADFS サーバーが発行するトークンとして認証トークンと認可トークンがありました。このように、ID 連携の中でトークンを発行するサービスを STS (Security Token Serivces) と呼びます。ADFS を利用している場合、ADFS サーバーがトークンを発行する機能を持っているため、ADFS サーバーは STS であると言えます。

また、ID 連携で認証と認可を行う場合、認証を行う側と認可を行う側に分かれて、それぞれ処理が行われていました。ADFS では、認証を行う側のシステム/ネットワーク全般を Claim Provider (CP)、認可を行う側のシステム/ネットワーク全般を Relying Party (RP) と呼びます。

なお、STS、CP、RP という名称については、ADFS における呼び方であり、ID 連携の規格のひとつである、SAML2.0 では異なる呼び方をします。詳しくは、「WS-Federation / SAML とは」のページを参照してください。

このテキストでは、ADFS における呼び方で名称を統一します。

RP 側の STS がCP側のSTSで発行した認証トークンの内容を解釈し、認可トークンを発行するとき、どのCP側のSTSから発行された認証トークンでも扱ってよいわけではありません。RPが信頼したCPから送られてきた認証トークンだけを扱うようにしなければ、悪意のある第三者が作成した認証トークンを疑いもせずにRPが処理してしまう可能性があるからです。

RPが適切なCPで発行された認証トークンだけを扱えるようにするために、STSでは信頼関係という設定を行います。信頼関係はSTSどうしで設定するもので、信頼関係を設定することで、決められたCPとRPの組み合わせで認証と認可を行うように定義できます。

クレーム ベース認証を行う際、利用可能な認証先が複数存在する場合、ユーザーはどこで認証を行うか選択することができると解説しました。このとき、利用可能な認証先の単位を「レルム (Realm)」と呼びます。複数のレルムの中から認証先をユーザーが選択すると、選ばれたレルムは CP として ID 連携の中で動作するようになります。

Active Directory ベースの認証と承認の仕組みを利用すると、承認の仕組みはアプリケーションの中で実装されます。アプリケーションの中で、誰にどのようなアクセス (権限) を割り当てるかを定義していたため、具体的な設定はアプリケーションによってまちまちでした。

一方、クレーム ベース認証 (ID 連携) を使ってアクセス制御 (認可) を行う場合、ADFS サーバーで認可トークンを発行するタイミングで行います。そのため、アプリケーションは認可のための仕組みを一切持つ必要がありません。つまり、アプリケーションと認可機能は独立して実装できます。

クレーム ベース認証を利用するアプリケーションは、認可を行わない代わりに、認可トークンを受信し、解釈できなければなりません。マイクロソフトでは Windows Identity Foundation (WIF) というコンポーネントを提供し、トークンの解釈とトークン内のクレームの識別を実現しています。WIF は ASP.NET または WCF アプリケーションと共に利用することができます。

WIF には実行環境を提供する WIF そのものと、WIF を利用した開発環境を提供する WIF SDK があります。WIF はアプリケーションがクレームを識別できるようにするためだけでなく、ADFS そのものの実行基盤にも活用されます。そのため、アプリケーションを実行するサーバーと、ADFS を実行するサーバーでそれぞれ必要となります。一方、WIF SDK はクレーム対応アプリケーションを開発する環境でインストールして利用します。

Visual Studio を利用して WIF アプリケーションを作成するには、Windows Identity Foundation SDK 3.5 以上が前提条件になりますので、事前にインストールしてください。

■ ■ ■

編集後記

このテキストを初めて作ったのは2012年頃で、まだID連携の必要性が世間で理解されていない頃でした。
当時は「ブラウザーにパスワードをキャッシュすればよいのに、わざわざサーバーをインストールする意味がわからない」などと言われたものです。
最後に今は亡きWIF(現.NET Framework内のコンポーネント)の説明を入れましたが、WIFが..というよりはADとクレームベースではアクセス制御の仕組みが違うんだよ、ということを知ってもらいたくて、あえて残しておきました。
明日もお楽しみに。

<続く>

The post ADFSトレーニングテキスト全文公開チャレンジ(2) first appeared on Always on the clock.

皆さんこんにちは。国井です。
3日目にして早くも公開するのを忘れそうになりましたｗ 今日は第2章「ADFSのインストールと初期設定」からADFSのコンポーネントについて解説します。

■ ■ ■

第 2 章では、ADFS サーバーをインストールする環境として活用する Azure 仮想マシンと仮想ネットワークの概要、そして ADFS をインストールするために必要な前提条件や効果的なインストール方法について確認します。

自組織とクラウドサービス間で ID 連携を行う場合、それぞれの環境に STS を用意する必要があります。このとき、クラウドサービスでは Azure AD、自組織では ADFSサーバーを利用して STS の機能を提供します。

ADFS サーバーを実装する場合、ADFS サーバー以外にも、ADFS サーバー用のデータベースサーバー、トークンを発行するユーザーを識別するために使用する Active Directory ドメインサービス、外部からのトークン発行要求を受け付ける Web アプリケーションプロキシが必要になります。以下に、それぞれのコンポーネントの特徴について紹介します。

■Active Directory
Windows Server 2016 の ADFS では Active Directory だけでなく、OpenLDAP 等のサード パーティー製ディレクトリ サービスを利用することもできますが、一般的には Active Directory を利用して認証機能を実装します。

■ADFS サーバー
ADFS サーバーはオンプレミスの STS (IdP/CP) として動作します。ADFS サーバーは負荷分散装置を利用することで、2台目以降のサーバーを実装し、高可用性構成を実装することも可能です。

■ADFS サーバー用データベース
ADFS サーバーで使用するデータベースには SQL Server または組み込みのデータベース (WID) を利用できます。SQL Server を利用する場合には SQL Server のクラスタリング機能で、WID の場合には ADFS サーバーの機能で複数台のサーバーによるデータベースの提供が可能です。

■Web アプリケーションプロキシ
Webアプリケーションプロキシはインターネットから ADFS サーバーへのアクセスを受け付ける、ADFSのプロキシ サーバーとして動作します。また、Webアプリケーションプロキシは ADFS サーバーと同じく、Web サービスとして提供されるため、負荷分散装置を利用することで高可用性構成を実装することも可能です。

■Azure AD Connect
Azure AD に対するプロビジョニングを行う役割としてマイクロソフトの Web サイトより提供されるAzure Active Directory Connect (Azure AD Connect) を利用します。Azure AD Connect は新規または既存のサーバーにインストールして利用することができ、インストールが完了すると自動的に Azure AD に対するディレクトリの同期を実行します。AAD Connect は複数のサーバーにインストールすることはできますが、複数のサーバーで同時にサービスを実行することができません。そのため、ステージングモードを利用して、アクティブなサーバー以外ではサービスを実行しないように構成します。また、アクティブなサーバーで障害が発生した時には、手動でアクティブなサーバーを切り替える必要がある点にも注意してください。

Microsoft Azure における仮想マシンの実装方法が確認できたら、続いて ADFS サーバーで必要となるコンポーネントについて確認します。ADFS サーバーでは以下のコンポーネントを使用します。

■証明書の定義
ADFS ではトークンの署名や通信の暗号化などに証明書を利用します。そのため、それぞれの通信等で必要となる証明書を事前に用意しておきます。

■フェデレーションメタデータの定義
フェデレーション メタデータとは、ADFS サーバー等で利用可能なサービス コンポーネントを定義した XML ファイルです。ADFS サーバーでは、セットアップを行うことにより、自動的に生成されます。

■RP の信頼関係構築
STS 信頼を設定し、クラウドサービス (Azure AD) との間で ID 連携が行えるよう、構成します。

■クレームルールの定義 (CP と RP で実装)
クレーム ルールとは、トークンの中で扱うクレームの情報を定義するためのコンポーネントです。

次のページから、それぞれのコンポーネントについて、詳しく解説します。

ADFS では、次の 3 種類の証明書を利用します。既定では、自己署名の証明書が実装されていますが、必要に応じて認証局から発行された証明書に変更して、利用することができます。

■SSL 証明書
ADFS サーバーとクライアントコンピューターの間で行われる通信を SSL 暗号化するために必要な証明書で、ADFS サーバーに証明書を実装し、利用します。ADFS サーバーを外部からのアクセスを受け付けるように構成する場合、SSL 証明書には公的な認証局から発行された証明書を利用する必要があります。

■トークン署名証明書
ADFS サーバーで作成されたトークンを悪意の第三者によって改ざんされることを防ぐためにトークンはデジタル署名されます。デジタル署名を行うときに利用される証明書がトークン署名証明書です。トークン署名証明書は ADFS サーバーに証明書を実装し、利用します。

■トークン暗号化解除証明書
クライアントから送られる認証関連情報を暗号化する際、ADFS サーバーはトークン暗号化解除証明書を利用してクライアントが施した暗号化を解除します。

フェデレーション メタデータには、エンドポイントの定義、クレームベース認証を行うために利用可能なクレーム情報、証明書の公開キーが含まれており、ADFS を利用するときには、フェデレーションメタデータを参照し、どのようなクレーム ベース認証が可能であるか識別します。

■エンドポイントの定義
エンドポイントは、ADFS のサービスを利用するための「接続口」としての役割を果たします。フェデレーション メタデータでは、エンドポイントの場所が記されているため、クライアントコンピューターはADFS サーバーに接続し、クレーム ベース認証を行うために必要な様々なサービスを利用することができます。

■クレームベース認証を行うために利用可能なクレーム情報
トークンに追加するクレームの情報は、あらかじめフェデレーションメタデータで定義した情報だけが登録可能です。

■証明書の公開鍵
ADFS サーバーに接続し、通信するためには様々な証明書を利用します。そのときに必要な証明書の公開鍵の情報がフェデレーションメタデータには記載されています。

これらの情報が含まれるフェデレーション メタデータは、STS の信頼関係を設定するときに使用します。ADFS サーバーで信頼する相手のフェデレーション メタデータをインポートすることにより、フェデレーション メタデータに記された STS とのクレーム ベース認証や ID 連携が実現できるようになります。また、フェデレーション メタデータは WS-Federation パッシブ プロファイルまたは SAML 2.0 Web SSO プロファイルで使用します。

ADFS サーバーの各種サービスに接続するためのエンドポイントは、すべて Web サービスとして提供されており、それぞれ別々の URL が提供されています。ADFS エンドポイントは、ADFS 管理ツールの [サービス] – [エンドポイント] から確認できます。

編集後記

今回はADFSサーバーのコンポーネントについて解説をしました。Active Directoryドメインコントローラーの他、ADFSサーバー、ADFSプロキシ、Azure AD Connectのサーバーが必要になり、さらにADFSサーバーとADFSプロキシは冗長化のために2台ずつ用意するという、シングルサインオンだけで何台サーバー用意するんだ！と言いたくなるような構成ですね。冗長化については別のトレーニングコースで扱っていたため、このコースでは詳細について触れないのですが、このあたりの情報は当時は本当に少なく、みんな苦労したものです。今でも苦労されている方がもしいらしたらコメントやTwitterなどで反応をいただければ追記するかもしれません。ではまた明日！

The post ADFSトレーニングテキスト全文公開チャレンジ(3) - ADFSのコンポーネント first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの4日目はSTS信頼についてです。次回の内容が大きな内容になるので、今回は少なめの公開です。ぱっと読めるのでお付き合いください。

■ ■ ■

ADFS サーバーで、信頼関係を設定する場合、CP と RP で利用するリソースに対して、個別に信頼関係を設定します。以下では、具体的に信頼関係を設定すべき相手を解説しています。

■CP が利用する Active Directory ドメインの定義
ADFS では、トークンを発行する前に行われる認証に Active Directory を利用します。CP の [要求プロバイダー認証] に Active Directory ドメインを登録し、ADFS サーバーと Active Directory 間の信頼関係を設定します。[要求プロバイダー認証] には、既定で ADFS サーバーが参加する Active Directory ドメインが登録されています。

■CP が利用する RP の定義
CP で発行され認証トークンを、クライアントを通じて受け渡しする RP の定義を行います。CP の [証明書利用者信頼] で RP の ADFS サーバーを登録し、CP が RP を信頼する信頼関係を定義します。CP と RP が同一の ADFS サーバーの場合には、この設定は不要です。

■RP が利用する CP の定義
CP で発行され認証トークンを、RP が受け取れるようにするための定義を RP で行います。RP の [要求プロバイダー認証] で CP の ADFS サーバーを登録し、RP が CP を信頼する信頼関係を定義します。CP と RP が同一の ADFS サーバーの場合には、この設定は不要です。

■RP が利用するアプリケーションの定義
RP で発行された認可トークンを提示する先となるアプリケーションサーバーを定義します。RP の [証明書利用者信頼] で アプリケーション サーバーを登録することで、RP とアプリケーションサーバー間の信頼関係が確立されます。

CP として利用している ADFS サーバーに RP となるレルムを定義する場合、ADFS 管理ツールの [証明書利用者信頼] から新しい信頼を設定します。新しい信頼の設定方法には以下の 3 つの方法があります。

■自動設定
Office 365 (Azure AD) を RP として証明書利用者信頼を設定する場合、Office 365で用意されたコマンドレット (コマンドレットの詳細については次の章で解説します) が用意されており、コマンドレットを実行することで自動的に設定されます。

■フェデレーションメタデータを登録して信頼を設定
[証明書利用者信頼の追加ウィザード] で RP となるレルムで公開されているフェデレーション メタデータを指定します。フェデレーションメタデータはクラウドで公開されている URL を指定して定義する方法と、XML ファイルを証明書利用者信頼に登録する方法があります。

■識別子と STS のエンドポイントを登録して信頼を設定
RP でフェデレーションメタデータが公開されていない (もしくは存在しない) 場合、RP で事前に定義された識別子と、RP でトークンの受け渡しを行う STS のエンドポイント (URL 形式) をそれぞれ指定します。識別子は一般に URL の形式もしくは URN の形式で記述します。なお、URN の形式は大文字・小文字を区別することに注意してください。

編集後記

CPとRPの信頼関係の設定について今回は解説しました。ADFSサーバーでは要求プロバイダー信頼と証明書発行信頼という謎な日本語訳のメニューがありました。これらのメニューは英語版のADFSだとClaim Provider TrustとRelying Party Trustとはっきり書いてあるので、なんだCPとRPのTrust(信頼関係)の設定なんだ！とすぐにわかるようになっています。日本語訳してくれなかったら皆がこれほど理解に苦しむこともなかったのに。。

The post ADFSトレーニングテキスト全文公開チャレンジ(4)–STS信頼 first appeared on Always on the clock.

皆さんこんにちは。国井です。
Advent Calendar風にお届けしてきたADFSトレーニングテキスト全文公開チャレンジですが、しっかり土日は公開せずにお休みさせていただきました。
週も明けて改めて続きを公開していきます。今回はADFSサーバーのインストールと必要な要素についてです。

■ ■ ■

ADFS のインストールを行うときには、次のステップで実装します。

■認証局環境の実装
前のページで解説した 3 種類の証明書が利用できるよう、環境を整えます。

■データベースの準備
ADFS のデータベースには、OS 標準で用意されている WID (Windows Internal Database) または SQL Server を利用できます。SQL Server を利用する場合には、ADFS サーバーをインストールする前にインストールしておかなければなりません。

■サービスアカウントの作成
ADFS サービスを実行するためのサービスアカウントを用意します。ADFS ではグループの管理されたサービスアカウントを利用することを推奨しており、事前に作成しておくことをお勧めします。

■ADFS のインストール
Windows Server 2016 の [役割と機能の追加] から ADFS を追加します。ADFS の役割の追加後に実行可能な [フェデレーション サービスの構成] を実行し、ADFS の初期設定を行います。

■フェデレーションサービス名の構成
ADFS の名前を意味するフェデレーションサービス名は ADFS サーバーのインストールと共に自動的に設定されますが、必要に応じて変更します。

ADFS で利用する証明書を実装するときには、以下の点に注意してください。

■証明書の名前をフェデレーションサービス名と同じにする
SSL による通信を行う際、クライアントコンピューターは SSL 通信を行うホスト名として、フェデレーション サービス名 (ADFS サーバー名ではない！) を指定します。そのため、SSL 通信を行うための証明書をはじめ、ADFS サーバーで使用する、すべての証明書はフェデレーションサービス名と一致している必要があります。

■証明書の発行要求や入れ替えに IIS は利用できない
Windows Server 2012 R2の ADFS サーバーより、IIS を伴わずに ADFS がインストールされるようになりました。そのため、SSL 証明書は IIS 管理ツールからインストールしたり、証明書の発行要求を行ったり、入れ替えをしたり、することができません。

証明書のインストールと入れ替えには ADFS 管理ツールを使用します。また、証明書の発行要求には別のサーバーにインストールされた IIS を利用するか、certreq.exe コマンドを利用する方法が一般的です。

・certreq.exeによる証明書発行要求 (CSR) の作成
Certreq.exe -new certreq.inf certreq.csr

・certreq.exeによる証明書の作成
Certreq.exe -accept certreq.cer

■証明書の有効期間に伴う証明書の書き換え (トークン署名証明書)
証明書には有効期間があります。有効期間が近づいたら書き換えを行い、期限切れにならないように構成します。トークン署名証明書には、既定で自己署名証明書が使われており、証明書の有効期間は Get-ADFSProperties コマンドレットによって 365日に設定されています。そして、365日後に ADFS が利用できなくなることを防ぐため、ADFS サーバーではロールオーバーと呼ばれる機能を実装し、有効期間が近づいたら証明書の書き換えを行い、証明書の延長を行います。ところが、証明書の書き換えには異なる証明書の鍵を利用して行われるため、フェデレーションメタデータに記載された鍵情報が変わってしまい、結果としてフェデレーション メタデータの再発行をしなければなりません。

このような問題を解決するためには、2 つの方法があります。
ひとつは、商用認証局から発行された証明書を利用することです。トークン署名証明書にはSSL 証明書と同じ証明書を利用することができるため、SSL 証明書の入れ替えのタイミングでトークン署名証明書を入れ替えるように運用することができます。また、商用認証局の証明書は同じ鍵で証明書の延長ができるというメリットがあります。

もうひとつは、Set-ADFSProperties コマンドレットで証明書の有効期間を長く設定することです。次のコマンドレットを実行することで、有効期間を 10 年に延ばすことが可能です。

Set-ADFSProperties -CertificateDuration 3650
Update-ADFSCertificate –Urgent

■証明書の有効期間に伴う証明書の書き換え (SSL 証明書)
トークン署名証明書と同じく、SSL 証明書にも有効期間があり、有効期間が近づいたら書き換えを行います。SSL 証明書には公的な認証局から発行された証明書を利用するため、一般には証明書の鍵を書き換えずに有効期間だけを書き換えることができます。このことはフェデレーションメタデータの再発行を必要しないことを意味します。
一方、SSL 証明書にはトークン署名証明書のようなロールオーバー機能がないため、手動で書き換えを行わなければなりません。書き換え操作は新しい証明書を ADFS サーバーにインストールした後、それぞれの ADFS サーバーで次のコマンドレットを Windows PowerShell から実行します。

Get-ChildItem cert:\LocalMachine\My | fl
#1 台目の ADFS サーバーでの実行コマンドレット
Set-AdfsSslCertificate -Thumbprint <Thumbprint>
#2 台目以降の ADFS サーバーでの実行コマンドレット
Set-AdfsCertificate -CertificateType Service-Communications `
-Thumbprint <Thumbprint>
Restart-Service adfssrv –Force

<Thumbprint> 欄には Get-ChildItem cert:\LocalMachine\My | fl コマンドレットで確認した、新しい証明書の Thumbprint の値が入ります。
一方、Web アプリケーションプロキシでは、新しい証明書をインストールした後、それぞれのサーバーで次のコマンドレットを Windows PowerShell から実行します。

Get-ChildItem cert:\LocalMachine\My | fl
Set-WebApplicationProxySslCertificate -Thumbprint <Thumbprint>
Get-WebApplicationProxyApplication | `
Set-WebApplicationProxyApplication `
-ExternalCertificateThumbprint <Thumbprint>

Certreq.exe で使用する要求ファイルの作成

Certreq.exe で CSR を作成するためには CSR に含まれる内容を事前に inf ファイルとして作成しておく必要があります。inf ファイルはメモ帳を開いて、以下のような書式で記述します。

[NewRequest]
Subject = “C=JP,ST=Tokyo,L=Shinagawa-ku,O=adfs,CN=fs1.adfs.jp”
Exportable = TRUE
KeyLength = 2048
MachineKeySet = TRUE
SMIME = FALSE

認証局によって、決められた記述方法を定義している場合があります。詳しくは認証局にお問い合わせください。

証明書の入れ替え時のエラー

上記の方法によって証明書の入れ替えても、Office 365の一部サービスでは証明書入れ替えが正しく反映されない場合があります (KB2973873)。
こうした問題には、Windows PowerShell から「netsh http show sslcert」コマンドを使用して設定を反映させます。

Get-ChildItem cert:\LocalMachine\My | fl
netsh
HTTP
DELETE SSLCert IPPORT=0.0.0.0:443
ADD SSLCert IPPORT=0.0.0.0:443 Certhash=<Thumbprint> Appid={5d89a20c-beab-4389-9447-324788eb944a}

ADFS サーバーで利用するデータベースには、WID (Windows Internal Database) と SQL Server のいずれかを選択できます。WIDを選択した場合、WID は ADFS サーバーのインストールとともにインストールされるので、事前準備は必要ありません。しかし、SQL Server を利用する場合は ADFS サーバーのインストール中にデータベースを選択するため、SQL Server 自体を事前にインストールしておく必要があります。また、データベースとして WID を選択した場合、SAML Token Replay Detection と SAML Artifact Resolution を利用できない、マスター データベースを持つ ADFS サーバー (最初にインストールした ADFS サーバー) でしか ADFS 管理ツールを利用できない、といった制約があります (ただし、Office 365の実装では使用しません)。

しかし、ADFS サーバーのデータベースに格納される情報は ADFS サーバーの構成情報だけであり、トークンに関わる情報は格納されることはありません。そのため、ADFS 管理ツールから変更を行わなければ、データベースの内容が変更されることもないので、データベースへの I/O を考慮に入れたり、高頻度でのバックアップを行う必要はないでしょう。

データベースサーバーの冗長構成を実装する場合、WID では 2 台以上の WID を利用した ADFS サーバーを実装することで、1 台目の ADFS サーバーが持つ WID データベースから定期的にレプリケーションを行います。一方、SQL Server を利用する場合、SQL Server 自身で利用可能な冗長構成を活用します。

編集後記

ADFSサーバーのインストールって本当面倒ですよね。インストールそのものはウィザードを実行すればよいだけなんだけど、前提条件として行わなければならない要素や設定が多く、実装に困らされたものです。特にトークン署名証明書の有効期間が1年という問題は何も知らずにインストールすると1年後に誰もサインインできなくなるというトラブルを引き起こします。だから証明書の有効期間を延ばしておくというのはセオリーなんだけど、そういうことって当時は情報がなかったのですよね。
今回はインストールと言いつつ、インストールそのものの手順にたどり着けなかったですが、次回はきちんとお伝えしますので、お楽しみに。

The post ADFSトレーニングテキスト全文公開チャレンジ(5) – ADFSのインストール(前編) first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの第6回目はADFSサーバーのインストールについてです。
前回は前提条件の話でしたが、今回はインストールそのものの話が登場します。
早速どうぞ！
■ ■ ■

ADFS サーバーのコンポーネントは Windows Server 2016 の役割として提供されます。そのため、役割を追加し、初期構成を行うことで、追加でコンポーネントをダウンロードすることなく、ADFS サーバーを利用するために必要な設定は完了します。

一方、マイクロソフトでは Office 365 (Azure AD) との ID 連携を簡単に実装できるようにするため、Azure Active Directory Connect (Azure AD Connect) と呼ばれるツールを提供し、Azure AD Connect のウィザードに沿ってインストールすることもできます。Azure AD Connect を利用する場合、1 回のウィザードで複数台のADFS サーバーを同時にインストールできるだけでなく、後述する Web アプリケーションプロキシも同時にインストールできるため、Azure AD との組み合わせで ADFS サーバーを利用するときは有効なツールといえます。

Azure AD Connect のウィザードで ADFS サーバーや Web アプリケーションプロキシをインストールする場合、遠隔からインストール操作を行うことになります。そのため、遠隔からインストールするために必要な権限を割り当てておく必要があります。ドメイン管理者としての権限があれば ADFS サーバーをインストールすることができますが、Web アプリケーションプロキシとなるサーバーはワークグループのサーバーであるケースがあるため、その場合には次の設定を行ってください。

■Azure AD Connect を実行するサーバーで次のコマンドレットを実行します

Set-Item WSMan:\localhost\Client\TrustedHosts `
-Value <Web アプリケーションプロキシサーバー> -Force

■Web アプリケーションプロキシとなるサーバーで次のコマンドレットを実行します

Enable-PSRemoting -force

なお、2 台以上の ADFS サーバーを設置して運用する場合、クライアントからのアクセスを受け付けるためにハードウェアの負荷分散装置またはネットワーク負荷分散 (NLB) を利用します。このとき、クライアントからの ADFS サーバーへのアクセス要求は機械的に分散されるため、どちらの ADFS サーバーに接続しても同じような STS としての処理ができるよう、サーバーファーム内の各サーバーには同じ証明書を実装してください。

ADFS をインストールすると、フェデレーションサービスの名前が設定され、既定では ADFS サーバーの FQDN がフェデレーションサービスの名前として設定されます。ところが 2台以上のサーバーで ADFS を構成する場合、2 台で 1 つのフェデレーション サービス名を構成しなければならないため、既定の名前から変更する必要があります。フェデレーション サービスに関する設定は ADFS 管理ツールの [ADFS] を右クリックし、[フェデレーション サービスのプロパティ] を開いて設定します。

■フェデレーションサービスの表示名
レルムを選択する画面や、Web アプリケーション プロキシを経由してアクセスするときの画面に表示される名前がフェデレーション サービスの表示名です。表示名は単なるラベルなので、ユーザーにとってわかりやすい名前を設定すると良いでしょう。

■フェデレーションサービス名
1 台以上の ADFS サーバーで構成されるフェデレーション サービスに対して設定する、システム上の名前です。この名前は SSL 証明書に設定された FQDN と一致している必要があります。つまり、クライアントコンピューターから ADFS サーバーにアクセスするときの FQDN にはフェデレーションサービス名を利用します。そのため、フェデレーションサービス名は名前解決ができるように、DNSサーバーにレコードを登録しておく必要があります。

■フェデレーションサービスの識別子
他のサーバー/サービスからフェデレーションサービスを識別するために使用する識別子です。この名前は ID 連携を行う相手から見て一意である必要があります。一般には SSL 証明書の FQDN を含む URL (http://<FQDN>/adfs/services/trust) に設定します (URL は一意であればよく、実在する必要はありません)。

ADFS を利用してクレームベース認証を行う場合、組織内から認証を要求される場合と、組織外 (インターネット上) から認証を要求される場合があります。そのいずれの要求にも応えられるようにするためには、ADFS サーバーにインターネットからアクセスできるようにする必要があります。

ただし、ADFS サーバーはトークンを発行する STS としての役割を持つため、インターネットからの直接アクセスを許可すると、攻撃者からの攻撃によってサービスを乗っ取られる可能性があります。そのため、インターネットからのアクセスを実現するためには、ADFS サーバーへの代理アクセスを実現する Web アプリケーション プロキシを DMZ に設置し、Web アプリケーション プロキシ経由で ADFS サーバーにアクセスさせるような運用を行います。

Web アプリケーションプロキシを利用してインターネットからのクレーム ベース認証を受け付けるように構成した場合、これまでのバージョンの ADFS で提供していた ADFS プロキシとは異なり、ADFS サーバーに対する単なる代理接続だけでなく、認証・認可に関わる、すべての通信に対するプロキシとして動作します。その結果、イントラネットのアクセスに対する認証が集約され、一度の認証で、ADFS に関連するアクセスはもちろんのこと、イントラネット内のすべてのリソースにアクセスできるようになります。

ADFS サーバーとともに組織内に ADFS プロキシを実装することによって、インターネットからの安全なクレーム ベース認証が実装できます。ただし、クライアントからのアクセスを受け付ける場合、ADFS サーバーにアクセスしても Web アプリケーション プロキシにアクセスしても、同じサーバーに接続しているかのように見せる必要があるため、次の点に注意する必要があります。

■Web アプリケーション プロキシと ADFS サーバーで同じ FQDN で名前解決できるようにする
Web アプリケーション プロキシと ADFS サーバーを同じサーバーであるように見せるためには、同じ FQDN で名前解決できるようにします。

■Web アプリケーション プロキシと ADFS サーバーで同じ証明書を利用する
Web アプリケーション プロキシと ADFS サーバーのどちらにアクセスしても、同じサーバーと通信しているように見せるためには、同じ SSL 証明書を使って通信を行います。なお、Web アプリケーション プロキシは STS として動作しないため、トークン署名証明書の実装は不要です。

■Web アプリケーション プロキシと Web サーバーで同じ証明書を利用する
SSL 通信を行う Web サーバーを Web アプリケーション プロキシ経由で公開している場合、Web アプリケーションプロキシを Web サーバーのように見せる必要があるため、Web サーバーと同じ証明書を Web アプリケーション プロキシに実装します。

Web アプリケーションプロキシと ADFS サーバーで同じ FQDN を設定した場合、外部からのアクセスには Web アプリケーション プロキシへ、Web アプリケーション プロキシからのアクセスには ADFS サーバーへ、それぞれアクセスできるように名前解決を行う必要があります。このような名前解決を実現する場合、次のいずれかの名前解決方法を実装します。

■Web アプリケーション プロキシの DNS サーバーアドレスとして内部の DNSサーバーを指定

■Web アプリケーション プロキシで Hosts ファイルを構成

Hosts ファイルを使用する場合、Hosts ファイルに ADFS サーバーのコンピューター名 (FQDN) と IP アドレスを登録しておくことで、ADFS サーバーへ要求の転送ができるようになります。一方、DNSサーバーで名前解決を行う場合、イントラネットと DMZ で別々の DNSサーバーを用意し、外部からのユーザーは DMZ の DNSサーバー、Web アプリケーションプロキシはイントラネットの DNS サーバーを利用するように構成します。

Web アプリケーションプロキシの役割を利用する場合、サーバー マネージャーの [役割と機能の追加] から [リモート アクセス] の役割を追加します。役割を追加すると、Web アプリケーション プロキシの構成ウィザードを実行することができるため、ウィザード内で利用する ADFS サーバーや証明書を指定します。ADFS サーバーに追加された Web アプリケーション プロキシは [リモート アクセス管理ツール] 画面のほか、
Get-AdfsWebApplicationProxyRelyingPartyTrust コマンドレットを利用して確認することができます。

Web アプリケーションプロキシを通じてインターネットに公開する社内のアプリケーションは、[リモート アクセス管理ツール] から登録します。公開の設定を行う際、公開された社内アプリケーションにアクセスする場合、Web アプリケーション プロキシによる認証 (事前認証) を行ってから社内アプリケーションへのアクセスを許可する方法と、Web アプリケーションプロキシによる認証を行わないで (パススルー) 社内アプリケーションへのアクセスを許可する方法のうち、いずれかを選択することができます。このうち、事前認証を選択すると、ADFS を活用したクレームベース認証と、トークンを利用した社内アプリケーションへのアクセスが実現します。

編集後記

今さらADFSサーバーをインストールする手順の解説って、どれだけ需要があるんだろう？と思いながら載せてみました。証明書の実装だったり、名前解決の設定であったり、結構な落とし穴があることを改めて振り返ってみて思い出しました。これから構築する人がどれだけいるかわかりませんが、今さらこんな落とし穴にはまらないよう、誰かの役に立てば幸いです。

The post ADFSトレーニングテキスト全文公開チャレンジ(6) – ADFSのインストール(後編) first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの7回目ですが、クレームルールの概要について解説します。
クレームルールはアクセス制御の話でよく登場しますが、ここではクレームルールとは？という話からスタートします。

■ ■ ■

クレーム ルールはクレームを定義するための規則で、主な規則として、受け付け変換規則、発行承認規則、発行変換規則があります。

■受け付け変換規則
受け付け変換規則は、[要求プロバイダー信頼] から設定可能な規則で、認証用データベースや CP から取得する属性情報を定義するために利用します。受け付け変換規則にはあらかじめ、10 個の規則が用意されていますが、ADFS が内部的な処理を行うために用意されている規則であり、誤って削除すると ADFS によるトークン発行ができなくなるので注意してください。

誤って受け付け変換規則を削除した場合
デフォルトで用意されている受け付け変換規則を再度作成する PowerShell スクリプトが提供されているため、スクリプトを実行し、復元してください。
http://jorgequestforknowledge.wordpress.com/2013/10/07/restoring-the-default-acceptance-transform-rules-for-the-ad-cp-trust-in-adfs-v3-0/

■発行承認規則 (アクセス制御ポリシー)
発行変換規則は、[証明書利用者信頼] から設定可能な規則で、トークンの内容をもとに認可の許可/拒否の基準を定義します。

■発行変換規則 (要求発行ポリシー)
発行変換規則は、[証明書利用者信頼] から設定可能な規則で、受け付け変換規則で作成したトークンに含まれるクレームをどのように扱うかを定義するために使われます。受け付け変換規則から送信されたクレームの内容は、単純に付け替えする (パススルー) だけでなく、一部の文字列を変換したり、クレームの値を異なるクレームの値として利用するなどの変換が可能です。
それぞれの規則の中では、「ルール」を作成することができます。ルールでは、特定のデータベースから属性情報を取得したり、取得した属性情報をもとにアクセスを許可する、などの規則を定義します。

ルールは、それぞれの規則の中で 1 つまたは複数作成することができ、ルールの集合を「ルール セット」と呼びます。ルールセット内の各ルールは、ルールの内容に関わらず最後まで処理します。例えば、Administratorsグループ以外のユーザーに対してクレームの追加を拒否するルールがあった場合、Administrators グループ以外のユーザーは、該当するルールに記載されているクレームを追加することはありませんが、トークンそのものの発行を拒否したわけではなく、残りのルールは継続して処理され、クレームが追加されます。

受け付け変換規則では、クレームにセットする属性値をデータベースから取得するためのルールを作成します。そのため、次のような要求規則テンプレートが主に利用されます。

■[LDAP 属性を要求として送信] 要求規則テンプレート
認証に使用した Active Directory から、認証したユーザーの属性値を取得するためのルール用テンプレートです。このテンプレートでは、電子メールアドレス (mailaddress 属性) や名前 (name 属性) などを Active Directory から収集できます。収集する Active Directory の属性情報は一覧から選択するだけでなく、属性名を直接入力して収集することも可能です。また、Active Directory から UPN として取得した属性値はそのまま UPN としてクレームに追加できるばかりでなく、UPN 属性値を mailaddress の属性値としてクレームに追加するなどの操作も可能です。
もし、Active Directory データベースに該当する属性値が存在しない場合、空の属性値でクレームが追加されるわけではなく、クレームそのものが発行されません。

■[グループ メンバーシップを要求として送信] 要求規則テンプレート
認証に使用した Active Directory から、認証したユーザーが所属するグループの情報を取得するためのルール用テンプレートです。所属するグループの情報をそのままクレームに追加できるばかりでなく、グループの名前を異なる名前に変換してクレームにセットすることも可能です。

発行承認規則では、クレームの内容からリソースへのアクセスを許可または拒否するためのルールを作成します。そのため、次のような要求規則テンプレートが主に利用されます。

■[入力方向の要求に基づいてユーザーを許可または拒否] 要求規則テンプレート
受け付け変換規則で作成されたクレームの内容から、特定の条件に基づいて許可または拒否を判定するために使うテンプレートです。属性と属性値の条件を指定し、条件に一致する場合のみアクセスを許可するように定義します。

■[入力方向の要求をパススルーまたはフィルター処理] 要求規則テンプレート
受け付け変換規則で作成されたクレームの内容から、特定の条件に基づいて許可または拒否を判定するために使うテンプレートです。[入力方向の要求に基づいてユーザーを許可または拒否] テンプレートと同じく、属性と属性値の条件に基づいてアクセスの許可 / 拒否を判定しますが、このテンプレートの場合には、特定の属性のプレフィックスが特定の文字列であるか、電子メールアドレスのサフィックスが特定の文字列であるか、などの細かな条件を設定できるメリットがあります。

■[すべてのユーザーを許可] 要求規則テンプレート
受け付け変換規則で作成されたクレームの内容に関わりなく、すべてのユーザーによるアクセスを許可するときに使うテンプレートです。リソースにアクセスさせるために特に条件を設ける必要がないときに利用します。

発行変換規則は受け付け変換規則から送信されたクレームを、どのようなクレームとして扱うかを定義するためのルールを作成します。そのため、次のような要求規則テンプレートが主に利用されます。

■[入力方向の要求をパススルーまたはフィルター処理] 要求規則テンプレート
受け付け変換規則から送信されたクレームをそのまま利用するときに使うテンプレートです。また、このテンプレートではクレームに特定の文字列が含まれる時だけパススルーするように構成することも可能です。

■[入力方向の要求を変換] 要求規則テンプレート
受け付け変換規則から送信されたクレームを違う属性として扱う場合に使うテンプレートです。例えば、受け付け変換規則で UPN として設定されたクレームを発行変換規則では電子メールアドレスとしてクレームにセットするように指示することができます。また、このテンプレートでは、属性を変換するだけでなく、属性値を変換することも可能です。例えば、title クレームに「課長」と入っている場合、「課長」を「manager」に変換して、RP 側のクレームとしてセットすることができます。

トークンの中に組み込むクレームとして利用する属性情報は、あらかじめ ADFS 管理ツール [サービス] – [要求記述] で定義されています。クレームとして利用する属性は [要求記述] から追加してカスタマイズすることが可能です。
要求記述で定義されている個々の属性には、URL が設定されていますが、定義されている場所を表しているだけで、実際にアクセスすることはありません。そのため、インターネットへのアクセス経路を確保する必要はありません。
新規に要求記述を追加するときは、URL を指定する必要がありますが、単純に定義している場所 (URL) を指定するだけなので、http://<組織のFQDN>/claims/<属性名>/ などとしておくと良いでしょう。

編集後記

トークンの中に含まれる情報である、クレームをどうやってカスタマイズするかを定義するクレームルール。
クレームルールと言われれば何をする設定なのか想像がつくけど、ADFSサーバーのUIでは「要求規則」って言うんですよね。わかりにくい。。
ただ、説明はわかりやすくしたつもりなので、参考になれば幸いです。

The post ADFSトレーニングテキスト全文公開チャレンジ(7) - クレームルール first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの8回目は第3章に入って、Office 365との連携について見ていきます。

■ ■ ■

第 2 章では、ADFS サーバーの実装方法を確認しました。第 3 章では、ID 連携機能を活用して Office 365 にアクセスできる様子について確認します。

Exchange や SharePoint 等のサービスをクラウド上で提供する Office 365 では、認証・認可の部分にAzure AD を活用しています。そのため、前の章でも解説したように Azure AD に直接ユーザーを作成して運用することも、Azure AD を STS としての活用することで ID 連携を実装することもできます。

それでは、Office 365 と Azure AD の組み合わせで利用できる、3 種類のサインイン方法について確認します。

1 つ目は「クラウド ID」とも呼ばれる、Office 365 経由で Azure Active Directory (Azure AD) に登録されたユーザーをそのまま利用する方法です。この方法は、既定の Office 365 へのサインイン方法で、Office 365を利用するときは事前に Azure AD にユーザーを作成しておく必要があります。

2 つ目はオンプレミスで使用している Active Directory ユーザーを Azure AD と同期し、Azure AD に登録されたユーザー アカウントを使って Office 365 にサインインする方法です。この方法は、Azure AD に手動でユーザーを作成する必要がないだけでなく、ユーザーは Active Directory と Azure AD で同じユーザー名とパスワードが利用できるメリットがあります。

3 つ目はオンプレミスで使用している Active Directory ユーザーを Azure AD と同期し、Active Directory に登録されたユーザー情報を用いて Office 365 へアクセスする方法です。この方法では、新しく ADFS サーバーを配置し、Active Directory に登録されたユーザー情報に基づき Office 365 へアクセスするためのトークンを発行することで、ID 連携を実現します。その結果、Active Directory ドメインにサインインしているユーザーは Office 365 に改めてサインインすることなくアクセスできます。

3 種類の Office 365 の認証方法は、いつでも自由に変更することができます。そのため、Office 365の導入を行うプロジェクトの中で、いつ認証方法を変更するかについては依存要素を考慮することなく決定できるメリットがあります。しかし、パイロットの段階から ID 連携の方法を実装することはリスクが伴うため、プロジェクト後半のフェーズで実装することも検討してください。

たとえば、Office 365導入展開のプロジェクトを 3つに分割して、徐々に理想の認証方法へ変化させていく方法があります。

このプロジェクトの最初のフェーズ (パイロット導入) では、Azure AD に直接ユーザーを作成して運用します。Azure AD に直接ユーザーを作成することで、余計な手間を排除して手軽に利用開始できるメリットがあります。

2番目のフェーズ (展開) では、オンプレミスに配置された ID ストア (Active Directory) に対してディレクトリ同期を実行します。これにより、本格的な運用を開始する前に、簡単に組織のすべてのユーザーをまとめて移行でき、かつ Active Directory と同じパスワードを利用できるメリットがあります。

もし、ディレクトリ同期を行う際、既に作られたユーザーがある場合には SMTP マッチによって既存の Azure AD アカウントを移行します (SMTP マッチについて後ほど解説します)。

3番目のフェーズ (拡張) では、複数回に渡るユーザー名とパスワードの入力処理を軽減するために、ADFS サーバーを利用した ID 連携を実装します。これにより、ユーザーは1度の資格情報の入力によって、Active Directory と Office 365 の両方にアクセスできるようになります。

Active Directory ユーザーが Office 365 にシングル サインオンを行う場合、大きく分けて 3 つのアクセス方法 (パッシブ プロファイル、リッチクライアント プロファイル、アクティブプロファイル) があります。ここでは、パッシブ プロファイルと呼ばれる、Web ブラウザー経由で Office 365 のWeb サイトにアクセスするときの認証・認可処理について解説します。

① Office 365 サイトのサインイン ページで資格情報の入力を求められる
クライアント コンピューターからOffice 365 サイトのサインインページ (https://portal.office.com/) にアクセスすると、資格情報の入力を求められます。

② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力すると、シングルサインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインイン ページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアントコンピューターに要求します。

③ Windows ユーザーの Kerberos チケットをもとに ADFS サーバーでトークンを発行
トークンを要求されたクライアント コンピューターは Windows 統合認証を利用して資格情報を提示します。ADFS サーバーは Active Directory にアクセスして資格情報を確認し、問題がなければ認証トークンを発行します。

④ Azure AD にアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。

⑤ Azure AD で発行されたトークンを利用して Office 365 にサインイン
クライアント コンピューターは Azure AD で発行されたトークン (認可トークン) を利用して Office 365 にサインインします。

以上の処理の結果、ユーザーはサインイン時にパスワードを入力することなく、Office 365 にアクセスできるようになります。ドメインに参加していないコンピューターからシングル サインオン ユーザーを利用して、上記のプロセスを実行する場合、③の Kerberos チケットを ADFS サーバーに提示できないため、ユーザー名とパスワードの入力を③の時点で求められます。

Active Directory ユーザーが外出先から Office 365 のシングル サインオンを行う場合、パッシブプロファイルでも異なる処理でシングル サインオン プロセスが実行されます。

① Office 365 サイトのサインイン ページで資格情報の入力を求められる
クライアント コンピューターからOffice 365 サイトのサインインページ (https://portal.office.com/) にアクセスすると、資格情報の入力を求められます。

② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力すると、シングルサインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインイン ページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアントコンピューターに要求します。

③ Web アプリケーション プロキシにアクセスし、認証を要求
社内にいるときには Azure AD から提示された ADFS サーバーに直接アクセスすることができましたが、外出先からは社内に配置された ADFS サーバーにアクセスすることはできません。そこで、DNS サーバーによって ADFS サーバーの名前解決は Web アプリケーション プロキシ (WAP) に対して行われるように構成しておき、ユーザーはその設定に従い、WAP にアクセスします。WAP では、Active Directory ドメインの資格情報を入力し、認証を行います。

④ ユーザー認証の実施
WAP のフォーム画面から入力した資格情報は、ADFS サーバーを経由してドメインコントローラーで確認されます。

⑤ 認証トークンの発行
④で入力した資格情報が正しいものであることが確認できたら、ADFS サーバーは Office 365 にアクセスするための認証トークンを発行し、WAP 経由でクライアントに渡されます。

⑥ Azure ADにアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。

⑦ Azure AD で発行されたトークンを利用して Office 365 にサインイン
クライアント コンピューターは Azure AD で発行されたトークン (認可トークン) を利用して Office 365 にサインインします。

このように、社外からのアクセスの場合、まだ Active Directory での認証を行っていないため、WAP にアクセスした時点で Active Directory の資格情報の入力が求められます。

Office 365 のシングル サインオン環境において、Outlook アプリケーションからメールボックスにアクセスする場合、ブラウザーアクセスとは異なる方法で認証・認可が行われます。

① Outlook から Office 365 にアクセスし、資格情報を提示
Outlook を起動し、Outlook から Office 365 にアクセスするとき、Outlook は Azure AD に登録されたユーザーの資格情報を提示します。

② 資格情報の確認先をチェック
Office 365 は Outlook クライアントから提示された資格情報を確認するため、確認先を Azure AD に確認します。

③ 資格情報を提示して認証
Azure AD に登録されたユーザーがシングルサインオン ユーザーであることが確認できた場合、WAPに資格情報を提示します。

④ 認証トークンの発行
WAP に提示された資格情報を ADFS サーバー経由で Active Directory が確認し、正しいものであることが確認できると、ADFS サーバーは認証トークンを発行し、Office 365に提示します。

⑤ Azure AD にアクセスし、認証トークンをもとに認可
Office 365 は認証トークンを Azure AD に提示します。

⑥ Azure AD から認可トークンを発行
認証トークンを受け取った Azure AD は認可トークンを Office 365 に対して発行します。

⑦ アプリケーションからのアクセスを開始
認可トークンは最終的にクライアント コンピューターに渡され、その認可トークンを利用してアプリケーションからのアクセスが開始できるようになります。

アクティブ プロファイルの場合、クライアント コンピューターから送信された資格情報をもとに、トークンの発行に関わる処理をすべてクラウド (Azure AD/Office 365) 主導で行われます。この方法では、Windows資格情報の確認を Azure AD 経由で行うため、インターネットから ADFS サーバーへのアクセス要求を受け付けられるようにするため、WAP を用意していることが特徴です。
また、WAP へのアクセスは Office 365から HTTPS プロトコルを使って行われるため、WAP には Office 365 が許可する SSL 証明書を利用していることが前提となります。
一方、Windows 資格情報は Outlook クライアントから送信されます。そのため、ユーザーが Office 365 にアクセスするために毎回ユーザー名やパスワードを入力しないようにするため、Outlook 自身に資格情報を保存 (キャッシュ) しておく必要があります。

Office 2013 / Office 2016 または Office 365 ProPlus (以降、Office 365 ProPlus と省略) では、アプリケーションを通じて行われる認証・認可部分にActive Directory Authentication Library (ADAL) と呼ばれるコンポーネントを利用し、Office 365 ProPlus アプリケーション経由での認証・認可にパッシブ プロファイルを使うようになりました。このような ADAL を利用した認証方式を先進認証 (Modern Authentication) と呼びます。ここでは、先進認証を利用して Office 365 にアクセスするときの認証・認可処理について解説します。

① Office 365 サイトで認証を要求される
Office 365 ProPlus から Office 365 サイトにアクセスすると、トークンを保有していないため、認証を要求されます。

② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力 (または Office 365 ProPlus によりキャッシュされているユーザー名を提示) すると、シングル サインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインインページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアント コンピューターに要求します。

③ Windows ユーザーの Kerberos チケットをもとに ADFS サーバーでトークンを発行
トークンを要求された Office 365 ProPlus は Windows 統合認証を利用して資格情報を提示します。ADFS サーバーは Active Directory にアクセスして資格情報を確認し、問題がなければ認証トークンを発行します。一方、ドメインに参加していないコンピューターや Active Directory で認証していないコンピューターの場合はサインインページが表示され、資格情報の入力を求められます。

④ Azure AD にアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは ADFS サーバーから発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。このとき、Azure AD から発行されるトークンには、アクセス トークンとリフレッシュ トークンの 2 種類があります。

⑤ Azure AD で発行されたトークンを利用して Office 365 にアクセス
クライアント コンピューターは Azure AD で発行されたトークンのうち、アクセス トークンを利用して Office 365 にアクセスします。

以上の処理の結果、ユーザーは Outlook を含む、すべての Office アプリケーションから Office 365 にアクセスするときに、パスワードを入力する必要がなくなり、トークンを利用してアクセスできるようになります。また、アクセストークンは有効期間が 1 時間に設定され、その有効期間が切れるとリフレッシュ トークンを使って Azure AD からアクセス トークンを再取得します。リフレッシュ トークンは 14 日間有効で継続利用することにより最大で 90 日間有効なトークンで、Office アプリケーションを終了してもコンピューター内にキャッシュされます。そのため、リフレッシュ トークンが有効な限り、ADFS を利用した再認証を行わない点に注意してください。

編集後記

ADFSの接続先クラウドアプリNo1のOffice 365との連携方法にいよいよ入ってきました。
Office 365への接続方法にはブラウザーからの接続とアプリからの接続があり、どちらの方法で接続するかによってSSOの方法も違っていたりします。
アプリの接続の場合、レガシー認証と先進認証の2つのパターンがあり、レガシー認証(Office 365 と ADFS サーバーによる ID 連携 (Outlook アクセスの場合)の項目で解説した接続方法)は2021年中にサービスを終了することを既に発表しています。
そのため、会社の中でレガシー認証が使われていないかを確認し、来るべき時に向けて先進認証に切り替えていく作業が今の段階から必要になります。
これについては別の投稿で解説していますので、参考にしてみてください。

The post ADFSトレーニングテキスト全文公開チャレンジ(8) – ADFSのコンポーネント first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの9回目はOffice 365とADFSを連携させるための具体的な方法について解説します。

■ ■ ■

Office 365 の各サービスへのシングルサインオンを実現する場合、ADFS サーバーを利用した ID 連携の他、Azure AD ディレクトリと Active Directory の間でのプロビジョニング (ID 同期) が必要になります。Azure AD では Azure AD ディレクトリと Active Directory の間での ID 同期のためのツールとして、Azure Active Directory Connect (AAD Connect) ツールを無償で提供しており、これを利用することにより、ID 連携に必要なプロビジョニングの部分を実現します。

また、外部から Office 365 にアクセスする場合や、Outlook アプリケーションからメールボックスにアクセスするときは、Web アプリケーションプロキシ経由で ADFS サーバーにアクセスし、トークンを取得する必要がある点にも注意してください。

ブラウザー アクセスによる Office 365 へのシングルサインオンを実現するには、以下の設定が必要になります。

① Active Directory の設定 : Office 365 に登録されたドメイン名を持つメールアドレスまたは UPN の登録
Office 365 のシングルサインオンを行うためには、Active Directory のドメイン名が Office 365 で使用するドメイン名と同じでなければなりません。もし、異なるドメイン名を Active Directory に設定している場合、代替 UPNサフィックスを設定するか、Office 365 のドメイン名と同じドメイン名を使用するメールアドレスをユーザーに登録することで対処します (メールアドレスの登録によるシングル サインオンの設定方法については「Alternate Login ID」の項で解説します)。

② ADFS サーバーの設定 : ADFS サーバーとしての設定
ADFS サーバーそのものを利用するための設定を行います。具体的には、ADFS サーバーのインストールや証明書の実装などが含まれます。

③ ADFS サーバーの設定 : Azure AD の登録
④ ADFS サーバーの設定 : フェデレーション ドメインの登録
ADFS サーバーが利用する Azure AD の登録を行います。Azure AD の登録にはフェデレーションドメインの名前を指定して行うため、フェデレーション ドメインの登録を行うことで自動的に Azure AD は登録され、その結果、ADFS サーバーに証明書利用者信頼 (RP) が自動的に設定されます。Azure AD の登録設定は PowerShell コマンドレットを通じて行います。

⑤ Office 365 の設定 : ディレクトリ同期のアクティブ化
Office 365 でシングルサインオンを行う場合、Active Directory に登録されたユーザーを Azure AD にあらかじめ同期させておく必要があります。同期の設定に先立ち、Office 365 では同期を許可する設定を行っておきます。

⑥ Active Directory の設定 : ディレクトリ同期ツールによる同期
Active Directory 内のユーザーやグループの情報を同期します。同期は Active Directory から Azure AD ディレクトリに向けて一方向に行われます。

⑦ 同期したユーザーのアクティブ化
Active Directory との間で同期したユーザーは、同期完了時点ではまだ利用可能な状態ではありません。アクティブ化の操作を通じてユーザーアカウントは初めて Office 365 で利用可能な状態となります。
社外から Office 365 にアクセスする場合、次の設定が追加で必要になります。

⑧ WAP のインストール・初期設定
社外から ADFS サーバーにアクセスし、トークンを発行するには、WAP を経由する必要があります。そのため、事前に WAP をインストールし、初期設定を済ませておきます。

⑨ DNS レコードの登録
WAP にアクセスするための URL は社内から ADFS サーバーにアクセスするときの URL と同じでなければならなりません。そこで、ADFS サーバーと同じ URL に対する IPアドレスが WAP の IPアドレスとなるように外部 DNS サーバーにレコードを登録します。
一方、社内から ADFS サーバーを経由して、Office 365 にアクセスする場合、ADFS サーバーそのものの DNS レコードのほか、利用するサービスに合わせた DNS レコードを登録する必要があります。
Outlook アプリケーションから Office 365 にアクセスする場合、社外からのアクセス方法の設定に加えて、次の設定が追加で必要になります。

⑩ 公的認証局から発行された証明書
アクティブ プロファイルでは、Office 365 から WAP に SSL 通信するため、Office 365で利用可能な証明書、つまり公的認証局から発行された証明書を WAP に実装しなければなりません。Skype for Business から Office 365 にアクセスする場合、シングルサインオンの利用の有無にかかわりなく、必要な DNS レコードを登録する必要があります。

次のページから個々の項目について、具体的な設定を確認します。

Azure Active Directory Connect による Office 365 SSO 環境の構築
マイクロソフトでは、2015 年 6 月に Azure Active Directory Connect (AAD Connect) と呼ばれるツールを新しく提供しました。AAD Connect は Office 365のシングルサインオン環境を構築するために必要な設定を自動的に行うものです。本ページで解説した手順のうち、②,③,④,⑥,⑧の手順をウィザードを通じて実行することができます。

Azure AD では、既定で登録されドメイン名 (.onmicrosoft.com の形式のドメイン名) とは別にオリジナルのドメイン名を設定できます。Azure AD でドメイン名を設定すると、Azure AD のユーザー名も「ユーザー名＠ドメイン名」の形式で設定できるため、組織で普段使用しているメールアドレスとユーザーサインイン名を同じにできるメリットがあります。

Azure AD で新しくドメイン名を登録する場合、Office 365 管理センターまたは Azure 管理ポータル画面から設定できます。ドメイン登録はインターネットにおけるドメイン名を所有している組織だけが登録できるよう、ドメイン登録を行う際に、DNS サーバーへの TXT レコードの登録が求められます。そのため、Azure AD の管理者は、自身のドメインの DNS サーバーへのアクセスができること、そして DNS サーバーへのレコード登録の方法を事前に確認してください。

Office 365 管理者アカウントのアドレス
シングルサインオンの設定はドメインの単位で行います。そのため、新しく作成したドメイン名をシングルサインオンできるように構成すると、そのドメイン名を持つユーザーはシングルサインオンを強制されます。Office 365 の契約時に作成される管理者アカウント (全体管理者) はシングルサインオン ユーザーとして構成できますが、ADFS サーバーなどのシングルサインオン環境にトラブルが発生すると、全体管理者もサインインできなくなります。そのため、最初の全体管理者アカウントのアドレスには、オリジナルのドメイン名を設定せず、既定で設定される onmicrosoft.com ドメインを利用することをお勧めします。

Active Directory のユーザーアカウントを利用して Office 365 のサインインを行う場合、Active Directory ユーザーのユーザー プリンシパル名 (UPN) と、Office 365 に登録されたユーザー名 (メールアドレス) は同一のものでなければなりません。UPN は Active Directory ドメイン名に基づいて決定されるため、ドメイン名に .local のようなインターネットでは利用できない名前を設定していると、UPN と Office 365 のユーザー名は同一にはなりません。

この問題を解決するために、Active Directory では代替 UPNサフィックスを利用します。代替 UPN サフィックスを利用すると、本来のドメイン名の代わりとなるドメイン名を設定できるため、Office 365 と同一の名前を設定できるようになります。

例えば、example.local ドメインに yamada ユーザーが存在する場合、このユーザーの UPN は yamada@example.local となります。しかし、Office 365 で example.com ドメインを利用する場合、yamada ユーザーのユーザー名は yamada@example.com となり、Active Directory の UPN とは異なるものになります。ここで、代替 UPN サフィックスで example.com を設定しておくと、yamada ユーザーの UPN を yamada@example.local から yamada@example.com に変更できるようになります。この結果、yamada ユーザーのユーザー名は Active Directory と Office 365 で同一の名前となります。

サインインアカウントと SMTP アドレス
Office 365 では、管理ポータルからユーザーを作成した場合、作成したユーザー名 (サインイン アカウント) がそのまま Exchange Online のSMTP アドレスになりますが、ディレクトリ同期によって作成されたユーザーの場合、onmicrosoft.com ドメインのアドレスがプライマリ SMTP アドレスとなり、ディレクトリ同期によって作成するユーザーのアドレスはプライマリ SMTP アドレスにはなりません。そのため、同期ユーザーのアドレスをプライマリ SMTP アドレスに明示的に指定する場合、メールアドレス (mail) 属性に UPNと同じアドレスを設定するか、proxyaddresses 属性に「SMTP:<UPN>」(SMTP は大文字)と入力し、設定します。

前のページでも解説したように、Office 365 でシングル サインオンを実行するときには、オンプレミスにADFS サーバーを配置する必要があります。Office 365 における ADFS サーバーは、CP としてのみ動作するため、連携して動作する証明書利用者信頼 (RP) を別途指定しなければなりません。Office 365 のための証明書利用者信頼の設定は、「Windows PowerShell 用 Windows Azure Active Directory モジュール」というツールを使って行う必要があります。

Windows PowerShell 用 Windows Azure Active Directory モジュールは、Office 365 のサイトからダウンロードすることができます。モジュールをインストールするときは、同じく Office 365 のサイトからダウンロード・インストール可能なディレクトリ同期ツール、もしくはマイクロソフト Web サイトからダウンロード・インストール可能な 「Microsoft Online Services サインイン アシスタント」ツールをインストールしておく必要があります。

Windows PowerShell 用 Windows Azure Active Directory モジュールをインストールしたコンピューターには、デスクトップにショートカットが作成されるので、このショートカットから Windows PowerShell を実行します。次のコマンドレットを実行することで、自動的に証明書利用者信頼の設定が施されます。

■Azure AD への接続のためのコマンドレット

$Cred = Get-Credential
Connect-MsolService -Credential $cred

■シングルサインオンのために使用する ADFS サーバーの指定

Set-ADFSContext -Computer <ADFSサーバー名>

■シングルサインオンのために使用するドメイン名の指定

Convert-MsolDomainToFederated -DomainName <ドメイン名>

Convert-MsolDomainToFederated コマンドレットを実行すると、Office 365 で使用するドメイン名のうち、シングルサインオンに使用するドメイン名を定義することができます。なお、Convert-MsolDomainToFederated コマンドレットで定義可能なドメイン名は事前に Azure AD に登録されたドメインだけです。ドメイン所有者の確認が完了すると、Office 365 の管理者コンソールに表示されるドメイン名一覧でその旨確認できます。

複数の Active Directory ドメインをフェデレーション ドメインとして利用する
フェデレーション ドメインの登録は Convert-MsolDomainToFederated コマンドレットを利用して行うことをここまでで学習しました。このとき、複数の Active Directory ドメインで、複数の代替 UPN サフィックスを利用して同期を行い、複数のフェデレーション ドメインとして ID 連携を行う場合、それぞれのコマンドレットの実行時に、-supportmultipledomain オプションを付けて実行します。

Office 365 では、ADFS サーバーで発行されたトークンをもとに、Azure AD に登録されているユーザーとのマッピングを行います。そのため、Active Directory ユーザーの情報は Azure AD にコピー (同期) させる必要があります。ユーザー情報の同期には、Office 365のサイトからダウンロード・インストール可能なディレクトリ同期ツールを利用します。

ディレクトリ同期ツールは、64 ビット版のセットアッププログラムだけが提供されており、ドメインコントローラーを含む、任意の 64 ビット版Windows Server OS にインストールすることができます。ディレクトリ同期ツールをインストールすると、初回起動時に Active Directory のドメイン管理者と Azure AD の管理者アカウントの資格情報の提示を求められます。入力した資格情報はディレクトリ同期ツールの中で保存され、2 回目以降のディレクトリ同期のために使われます。

ディレクトリ同期ツールを実行すると、Active Directory ドメインに保存されているユーザー情報が Azure AD に同期されます。同期は (現時点では) Active Directory から Azure AD に対して一方向に行われるため、ディレクトリ同期ツールで同期されたユーザーの情報は Office 365 から変更することができません。

また、ディレクトリ同期ツールではアカウントの同期を行いますが、Azure AD に同期されたユーザーに対する Office 365のライセンスの関連付けは行いません。そのため、ディレクトリ同期の完了後、必要に応じて同期ユーザーへのライセンス割り当てを Office 365 管理ポータルなどから行ってください。

SQL Server を利用してディレクトリ同期ツールをインストール
ディレクトリ同期ツールはデータベースとして SQL Server Express を利用します。SQL Server Express の最大データベース サイズは 2GB であり、ディレクトリ同期ツールで扱う ID の数として 50000 アカウントが上限とされています。そのため、50000 アカウントを超えて同期を行う必要がある場合、SQL Server Express ではなく、SQL Server を利用して同期を行うようにインストールする必要があります。AAD Connect からインストールする際に既存の SQL Server を利用してディレクトリ同期ツールをインストールするように選択できます。

ブラウザーから Office 365 サイトにアクセスし、シングル サインオンを行う場合、Active Directory における認証結果 (Kerberos チケット) をもとに (つまり Windows 統合認証を利用して) ユーザーのトークンを発行します。そのため、Kerberos チケットをブラウザーの操作によって自動的に Office 365 サイトに送信し、認証が行えるようにする必要があります。

Kerberos チケットを利用して、自動的にサインインが行えるようにするには、Internet Explorer の [ローカル イントラネット] から ADFS サーバーのエンドポイント URL (https://<フェデレーション サービス名>/adfs/ls/) を登録する必要があります。

サインインユーザーとは異なるユーザーで Office 365 にサインインする
トラブルシューティングなどの目的で Windows にサインインしたユーザーとは異なるユーザーで Office 365 にサインインする場合、ブラウザーのローカルイントラネットの設定を行わないでください。ローカルイントラネットの設定を行わない場合、Office 365にサインインするタイミングで認証ダイアログが表示されるので、そこで現在サインインしているユーザーとは異なるユーザーでサインインすることができます。

Internet Explorer 以外のブラウザーから Office 365 にサインインする
Internet Explorer 以外のブラウザーを利用してサインインする場合、あらかじめ ADFS サーバーでシングルサインオンを許可するよう、設定する必要があります。ADFSサーバーでの SSO 許可設定は、ブラウザー種類とバージョンの単位で行う必要があり、PowerShell の以下のコマンドレットを実行し、登録します。

■Firefox や Google Chrome (Mozilla/5.0) を SSO 用ブラウザーとして登録

$old=(Get-AdfsProperties).WIASupportedUserAgents
$new=$old+”Mozilla/5.0″
Set-ADFSProperties -WIASupportedUserAgents $new

外出先から Office 365 にアクセスする場合や Outlook アプリケーションから Office 365にアクセスする場合、ADFS サーバーの代わりに WAP にアクセスしてシングルサインオン プロセスを開始します。そのため、これらのアクセス方法をサポートする場合には、事前に WAP をインストールしておく必要があります。

WAP 経由でのトークン発行プロセスは、ADFS サーバーにアクセスするときと同じ証明書を利用する必要があります。そのため、WAP をインストールする前に ADFSサーバーに実装した SSL 証明書と同じ証明書を WAP に実装してください。

なお、WAP では外部に公開する証明書利用者信頼を明示的に指定する必要がありますが、Azure AD の証明書利用者信頼を公開する場合、その設定は不要です。WAPのインストールが完了すれば、自動的に ADFS サーバーへのトークンの発行要求は転送されるように動作します。

Office 365 では、ブラウザーからアクセスする場合、Outlook からアクセスする場合、Skype for Businessからアクセスする場合と、様々なシングル サインオン方法があります。そのため、どのようなアプリケーションからアクセスを行うかによって、必要となる DNS レコードも異なります。ここでは、それぞれのケースにおいて必要な DNS レコードについて確認します。

■社内からブラウザーでアクセスする場合
ADFS サーバーにアクセスするためのレコード (A レコード) が社内 DNS サーバーに作られていれば、シングルサインオンが実現します。なお、NLB などによって ADFS サーバーを複数台立てて運用しているときには、負荷分散用 IP アドレスを Aレコードに登録してください。

■社内から Skype for Business (SfB) でアクセスする場合
社内からリッチクライアント プロファイルでアクセスする場合も基本的にパッシブプロファイルと同じです。ただし、SfB Online 関連のレコードは社内の DNS サーバーで名前解決するため、社内の DNS サーバーに SfB Online 関連のレコードも一緒に登録してください。

■社外からSkype for Business またはブラウザーでアクセスする場合
社外からアクセスする場合、WAP のアドレスを外部 DNS サーバーに A レコードとして登録します。また、SfB を利用している場合は SfB Online 関連レコードも外部 DNS サーバーに登録してください。

■Outlook でアクセスする場合
Outlook からシングルサインオンを実行する場合、WAP のアドレスを社内 DNS サーバーと外部 DNS サーバーに それぞれ A レコードとして登録します。また、Exchange Online 関連レコードも、それぞれの DNS サーバーに登録してください。

編集後記

Advent Calendar風に12月25日までゆっくりと公開していこうと思ったのですが、分量が多すぎて、ここまでは年内に公開が終わらなさそうです。そのため、今日は少しボリュームを増やしてみました。読みにくいなどの意見があれば、分割して公開しますので、ご意見などお寄せください。

The post ADFSトレーニングテキスト全文公開チャレンジ(9) – Office365連携環境の構築ステップ first appeared on Always on the clock.

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの10回目となる今回はAzure AD Connectを利用したID連携のための環境づくりについて解説します。

■ ■ ■

Active Directory と Azure AD の間でのディレクトリ同期を担当する Azure Active Directory Connect ツールは、同期元となる Active Directory ドメインと同期先となる Azure AD ディレクトリをそれぞれ自由に指定することができ、次のようなパターンでの同期設定ができます。

■1つのドメイン (フォレスト) から 1 つの Azure AD ディレクトリへ同期

■複数のドメイン (フォレスト) から 1 つの Azure AD ディレクトリへ同期

一方、AAD Connect では複数の Azure AD ディレクトリを同期先として指定することはできません。複数の Azure AD ディレクトリを同期先として使用する場合には、マイクロソフトが有償で提供するディレクトリ同期製品である、Microsoft Identity Manager (MIM) を利用する必要があります。

ディレクトリ同期ツールには、いずれもマイクロソフトのディレクトリ同期製品である Microsoft Identity Manager (MIM) のエンジンが使われており、ディレクトリ同期を実行すると MIM のコンポーネントを利用して Active Directory と Azure AD の同期が行われます。
ディレクトリ同期ツールは Active Directory と Azure AD の間で直接同期を行っているわけではなく、ディレクトリ同期ツールの中に作成されるメタバース (Metaverse) と呼ばれるデータベースに一旦格納し、それから同期処理を行います。
メタバースは様々なディレクトリ データベースからディレクトリ固有の情報を取り除き、汎用的な情報だけを保存することで、他のディレクトリデータベースへスムーズな同期を実現します。たとえば、Active Directory におけるユーザー名を表す sAMAccountName 属性は、他のディレクトリ データベースでは使われることの無い、Active Directory 固有の情報です。こうした情報はメタベースに格納する際に sAMAccountName 属性から username 属性に変換するなどの処理を施してから格納します。このような処理を行うとき、変換処理を行う前のデータを格納する場所としてコネクタスペース (CS) が用意されています。
一方、Active Directory からメタバースへデータを格納する際、一時的な領域として用意されているコネクタ スペースへのデータ格納処理を Import、コネクタスペースからデータを変換し、格納する処理をSynchronization と呼んでいます。
メタバースにデータを格納するための処理として使われる、コネクタスペースや格納処理を表すImport/Synchronization はすべて Management Agent (MA) と呼ばれる設定で定義されます。ディレクトリ同期ツールでは、Active Directory とメタバースをつなぐ MA として Active Directory Connector があらかじめ用意されています。
メタバースに格納されたデータは最終的に Azure AD に同期しますが、メタバースから Azure AD への書き込み処理は Windows Azure Active Directory Connector MA で定義されている Export 処理によって実現します。

スタートメニューから Synchronization Service を実行し、[Management Agents] タブをクリックするとメタバースにつながる MA を 2 つ確認することができます。ひとつが Active Directory につながる Active Directory Connector、もうひとつが Azure AD につながる Azure AD Connector です。それぞれの MA による Import、Synchronization、Export の各処理は既定で 30 分おきに実行され、その結果は miisclient.exe の [Operations] タブで確認することができます。それぞれの MA の処理は次の順序で行われるため、[Operations] タブを確認することで、正しくディレクトリ同期が行われているか確認できます。[Operations] タブを確認すると、同期処理が次のような順序で行われていることが確認できます。

① Active Directory Connector の Delta Import Delta Sync
② Windows Azure Active Directory Connector の Delta Import Delta Sync
③ Windows Azure Active Directory Connector の Export

①～③の処理結果をクリックすると、左下ペインにメタバースまたは Azure AD に登録されたオブジェクトの数やそれぞれのオブジェクトに関する情報をクリックして確認できるため、同期時にどのようなオブジェクトが同期されたかも同時に確認できます。

AAD Connect による同期対象のカスタマイズを行う方法には、Synchronization Service ツールを利用する方法と、Synchronization Rules Editor ツールを利用する方法があります。

■Synchronization Service ツール
Synchronization Service ツールでは、同期するドメインまたは OU の限定ができます。Synchronization Service ツールの Active Directory Connector MA のプロパティから [Configure Directory Partitions] をクリックして設定します。[Select Directory Partitions] 欄でフォレスト内で同期対象とするドメインを選択、または [Containers] 欄でドメイン内で同期対象とする OU を選択することができます。
補足：現在では、Azure AD Connectのセットアップウィザード内で同期対象OUは選択できるようになっています。

■Synchronization Rules Editor ツール
Synchronization Rules Editor ツールでは、ユーザーやグループなど、同期すべき対象に対して 2 つのディレクトリ間でどのようにマッピングさせるかを定義しています。マッピング設定は、メタバースに登録する方法を定義している Inbound (Inbound Synchronization Rule : ISR) と Outbound (Outbound Synchronization Rule : OSR) の 2 つから構成されており、それぞれのマッピング ルールにはディレクトリ間のオブジェクトをどのような属性をキー属性としてマッピングするかを定義する Provision ルールと、その他の属性をどのようにマッピングするかを定義する Join ルールがあります。

AAD Sync で同期対象を一部のユーザーまたはグループに限定したい場合、Active Directory MA のInbound ルールを作成し、同期対象を属性の単位で定義できます。

SyncRulesEditor.exe を利用してディレクトリ同期対象のカスタマイズを行う場合、既定のルールではなく、必ず新規に Inbound – Join ルールを作成し、条件設定を行います。
SyncRulesEditor.exe では、Active Directory MA からメタバースへ同期する際に、CloudFiltered = Trueの値を設定することで、Azure AD への同期が抑制されます。そのため、ルール作成時に、Transformations項目で CloudFiltered = Trueの値を設定します。
一方、CloudFiltered = Trueの値を適用するオブジェクトの指定は ルール内のScoping Filter 項目から行います。Scoping Filter の中で「同期させたくない」オブジェクトの条件を指定します。例えば、ユーザーの description 属性に NOSYNC という値が設定されている場合には同期しないという条件を設定するのであれば、Scoping Filter で description equal NOSYNC となるように設定します。

SyncRulesEditor.exe によるルール作成を行う際、CloudFiltered = True を設定する Transformations 項目から直接条件を設定することも可能です。Transformations 項目から条件を設定するときは、IIF 関数を利用します。IIF 関数とは、条件と条件を満たすときに設定する値を同時に設定できる関数で、次のような要領で記述します。

IIF(条件, 条件に合致するときの値, 条件に合致しないときの値)

CloudFiltered 属性の値として、IIF 関数を利用し、条件には同期させないオブジェクトの情報を入力し、条件に合致するときの値に TRUE、条件に合致しないときの値に NULL を設定します。以上を踏まえ、SUPPORT_338945a0 ユーザーが同期されないように構成する場合、次のような IIF 関数式を書きます。

IIF([sAMAccountName] = “SUPPORT_338945a0”, True, NULL)

IIF 関数で複数の条件を設定するときは || を使います。sAMAccountName 属性が存在しない場合 (IsPresent([sAMAccountName])=False と記述)、または SUPPORT_338945a0 ユーザーの場合には同期されないように構成するときは、次のような IIF 関数式を書きます。

IIF(IsPresent([sAMAccountName]) = False || [sAMAccountName] = “SUPPORT_338945a0”, True, NULL)

その他、IIF 関数内の条件部分には次のような式を記述することができます。

■department (部署属性) が 営業 ではない場合

[department] <> “営業”

■PhysicalDeliveryOfficeName (事業所属性) に 東京または大阪の場合

[PhysicalDeliveryOfficeName] = “東京” || [PhysicalDeliveryOfficeName] = ”大阪”

■sAMAccountName の最初から 4 文字が AAD_ の場合

Left([sAMAccountName], 4) = “AAD_”

■sAMAccountName に } という文字が含まれる場合

InStr([sAMAccountName], “}”) > 0

■sAMAccountName の最初から 4 文字が CAS_ でかつ後続に } という文字が含まれる場合

Left([sAMAccountName], 4) = AAD_ && InStr([sAMAccountName], “}”) > 0

■特定の OU (ou=sales,dc=example,dc=com) に含まれる場合

Right([distinguishedName], 26) = “ou=sales,dc=example,dc=com”

ディレクトリ同期ツールではなく、Azure AD に直接ユーザーを作成した場合、既定でそのユーザーは Active Directory ユーザーと関連付けられず、別々のユーザーとしてみなされます。
もし、Azure AD に作成したユーザーを後から Active Directory ユーザーと関連付けを行いたい場合、SMTP マッチと呼ばれる関連付けを行います。SMTP マッチはディレクトリ同期を行う際、Azure AD と AD ユーザーの次の値が同じであれば、自動的に関連づけを行います。

■Azure AD ユーザー：Exchange Online のプライマリ SMTP アドレス
■AD ユーザー：ユーザーの mail 属性または proxyAddresses 属性

Exchange Online のプライマリ SMTP アドレスは Office 365 管理ポータルから [管理] – [Exchange] をクリックして Exchange 管理センターに移動し、該当するユーザーのプロパティから [電子メールオプション] で確認できます。[電子メール オプション] 画面に複数の SMTP アドレスが登録されている場合、SMTP: または smtp: でアドレスが表示されますが、プライマリ SMTP アドレスは SMTP: で始まる値で表示されます。

これまで、ADFS サーバーを利用した ID 連携の方法について解説しました。実際の運用では ADFS サーバーを複数台のサーバーで運用することにより、継続してサービスを利用できるように構成できますが、万が一 ADFS サーバーが全く利用できなくなった場合には、ID 連携を利用せずに、ディレクトリとパスワードを同期する運用に切り替えることができます。
ID 連携から同期 ID に切り替える操作は Azure AD PowerShell の以下のコマンドレットを実行します。

Set-MsolDomainAuthentication -Authentication Managed `
-DomainName <ドメイン名>

Azure AD PowerShell では Convert-MsolDomainToStandard コマンドレットを別途用意していますが、このコマンドレットは ADFS サーバーが動作している前提で利用するため、ADFS サーバーに障害が発生したときの運用には向きません。

また、フェデレーション ID から同期 ID に切り替わるとき、マイクロソフトが公表する情報に基づくと、2～3 時間程度の待ち時間が発生します。そのため、切り替わるのに要する時間よりも早く ADFS サーバーの復旧が可能であれば、同期 ID に切り替えるよりもサーバーの復旧を行うべきでしょう。
ADFS サーバーも、ディレクトリ同期ツールも、永続的に使用不能になった場合、同期 ID からクラウド ID に切り替える選択肢があります。しかし、クラウド ID への切り替え処理には最大 72 時間を要する上、ディレクトリ同期ツールが実行できなくても同期された ID は引き続き利用可能なため、クラウド ID への切り替えではなく、ディレクトリ同期ツールの再構築による対応を行うことをお勧めします。
もし、同期 ID からクラウド ID への切り替えを行う場合、Office 365 管理ポータルの [ユーザーとグループ] からディレクトリ同期の [非アクティブ化] をクリックして、処理を行います。

ADFS サーバーやディレクトリ同期ツールを含む SSO 環境のディザスタ リカバリーを行う際、あらかじめ遠隔地に DR サイトを用意しておき、障害発生時に DR サイトに切り替えて、引き続きサービスを提供する運用方法があります。
SSO 環境で DR サイトへの切り替えを行う場合、これまでに登場した、次のテクノロジーを組み合わせることによって切り替えができますので、手順をメンバーで共有したり、自動化させたりしながら、すばやく切り替えられるようにしてください。

■ドメインコントローラーの切替
ADFS サーバーがトークンを発行する際、Active Directory ユーザーの認証も同時に行うため、DR サイトからでもドメインコントローラーにアクセスできる必要があります。そのため、DR サイトにも追加のドメイン コントローラーを 1 台用意してください。

■ADFS サーバーの切替
現在使用している ADFS サーバーからセカンダリとして構成している ADFS サーバーへ切り替える場合、セカンダリの ADFS サーバーから PowerShell の以下のコマンドレットを実行します。

Set-ADFSSyncProperties -Role PrimaryComputer

ADFS サーバーが組み込みのデータベースを利用して運用されている場合、ADFS サーバー間では 5 分に一度、データベースの複製を行います。しかし、データベースの内容には ADFS 管理ツールで設定した内容しか含まれないため、直近で管理ツールから設定変更を行っていない限り、複製されていないことが別のトラブルを引き起こすことは考えられないでしょう。
また、クライアントコンピューターからの名前解決要求に対して DR サイトの ADFS サーバーが処理を受け付けられるよう、フェデレーションサービス名の DNS レコードを書き換えてください。

■Web アプリケーション プロキシの切替
現在使用しているWeb アプリケーション プロキシを別の Web アプリケーション プロキシへ切り替える場合に、Web アプリケーション プロキシ サーバー上で行う操作はありません。ただし、Web アプリケーションプロキシが正常に動作するためには、名前解決が正しく行われる必要があります。具体的には次の2つの点に注意してください。

1 つは Web アプリケーション プロキシが ADFS サーバーにアクセスする際の名前解決です。DR サイトに切り替えて運用している場合、Web アプリケーション プロキシがアクセスする ADFS サーバーは DR サイトの ADFS サーバーになります。DR サイトの ADFS サーバーにアクセスできるよう、Hosts ファイル等を書き換えておいてください。
もう 1 つはクライアントコンピューターが Web アプリケーション プロキシ にアクセスする際の名前解決です。一般に外部に公開されている DNS サーバーに Web アプリケーション プロキシの IP アドレスが登録されていますが、この情報を DR サイトの Web アプリケーション プロキシをポイントするように設定変更します。

■ディレクトリ同期ツールの切替
ディレクトリ同期ツールはステージングモードを有効にしておくことで、待機系のサーバーをあらかじめ用意しておくことができます。もし DR サイトにステージングモードのサーバーを実装している場合、ステージングモードを無効にして、ディレクトリ同期が開始できるように構成してください。なお、本番系と待機系では設定を同期する機能がないため、もし SyncRulesEditor.exe などで設定を変更している場合、その設定は手動で待機系にも同じ設定を施しておいてください。

編集後記

Azure AD ConnectとADFSサーバーの冗長構成について解説しました。
Azure AD Connectは今でも通用する話でADFSを使わない人でも役立てる場面もあるのではないかと思います。
どうでもいいことですが、このころはAzure Active Directory Connectの短縮名って、AAD Connectか、Azure AD Connectか、など揺れていましたね。明日もお楽しみに！

The post ADFSトレーニングテキスト全文公開チャレンジ(10) – Azure AD Connect first appeared on Always on the clock.