【Office365】AD FSのアクセス制御ポリシーを構成する

皆さんいかがお過ごしでしょうか。Miyaです。

もうすぐ6月に入るということで、昼間は蒸し暑くて仕方がないですね。かといって朝/夜は少し冷えるので風邪を引かぬよう十分にお気を付けください。

さて、今回はWindows Server 2016のAD FSで機能改善されたアクセス制御ポリシーの構成方法についてご紹介したいと思います。

前回の【Office365】Windows Server 2016 ADFSの証明書認証を構成するでは、証明書認証の構成方法について紹介しました。

既定のアクセス制御ポリシーテンプレートを利用した単純なアクセス制御でしたので、本記事では少し手の込んだアクセス制御ポリシーを作成してみたいと思います。

Windows Server 2016では、従来のようにクレームルール言語を記述する方法ではなく、GUIから簡単にアクセス制御ポリシーを構成出来るよう改善されました。しかし、考え方は以前と変わらないため、少なくともクレームについてはキチっと理解しておく必要があります。

そこで、本記事ではアクセス制御ポリシーを構成するにあたって理解しておくべき点の解説を交えて、構成方法を紹介していきたいと思います。

スポンサーリンク:

ID連携についての復習

AD FS+Office365によるフェデレーションID構成において、「トークン」、「クレーム」などのアイデンティティ業界の用語が頻繁に出てきますので、これらの役割を理解しておきましょう。

トークンやクレームは、SAMLやWS-FederationなどのID連携のためのプロトコルに登場するものであり、ここでは「そもそもID連携って?」というところから振り返ります。

通常、ログインを必要とするアプリケーションを利用する時、ユーザーIDとパスワードの組み合わせを用いた認証方法でログインします。アプリケーション毎に独立したユーザー情報を持っている場合、利用者はアプリケーション毎にアクセスするためのユーザーIDとパスワードを記憶しておく必要があり、非常に煩雑な運用となります。

アクセス制御ポリシー

オンプレミス時代、上図のような問題に対策として、Active Directoryが絶大な効果を発揮しました。

Active Directoryでは、Kerberosをつかったチケットベースの認証によって、ドメイン内の認証をActive Directoryに統合出来ることから、画期的な存在となりました。
参考:Windows Server 2016 Active Directoryの構築 Kerberosプロトコルによる認証フロー

アクセス制御ポリシー

しかし、コストパフォーマンスの高いクラウド型アプリケーション(SaaS)が人気急上昇の世の中で、Active Directoryは機能しませんでした。

Active Directoryではドメイン内の信頼されたアプリケーションへのログインチケットをユーザーに配布します。が、インターネット上のサービスもActive Directoryもお互いの情報を知っているわけがないため、そのメリットを活かすことが出来ません。

Active Directory同士であれば、異なるドメイン外であっても、信頼関係を構成することでお互いのリソースを利用出来たのですが、インターネット上にあるSaaS、ましてはパブリッククラウドの全く異なる認証基盤に対して信頼関係なんて組めるわけがありません。

このように、相手先がSaaSである場合、認証基盤の見直しが発生するのは効率が悪いことから登場したのが、SAMLやWS-Federation、OpenID ConnectなどのID連携によるアイデンティティ管理です。

WS-Federation

WS-Federationとは、数あるID連携のプロトコルの一種で、古くから使われており、AD FS⇔Office365のフェデレーションIDにおいてもこのプロトコルが使用されています。

ID連携とは、自組織の認証プロパイダーとSaaSの間で信頼関係を構成しておき、認証基盤のユーザー情報をSaaSに提供、ログインさせる方式です。

この時、自組織の認証基盤のユーザー情報を提供する役割をIDプロパイダー(IdP)と呼び、AD FSがそれに該当します。また、提供先のアプリケーションを証明書利用者信頼、もしくはRP(Relying Party)と呼びます。

アクセス制御ポリシー

IdPからRPにユーザー情報を提供する時、JSONもしくはXMLのトークンと呼ばれる形式に整形、提供します。

トークンによる認証

トークンとは、IdPがRPにユーザー情報を提供する時のデータそのものを意味します。

ユーザーがOffice365へログインする時、AD FSにリダイレクトし、Active Directoryで認証されます。

アクセス制御ポリシー

この時、AD FSは⑧で「ITBeginnerのmiyaが、Office365にアクセスするために認証されたことを証明する」を表した文字列を生成します。また、この文字列がOffice365と信頼関係を構成したAD FSによって生成されたものであるかどうかを検証するために秘密鍵でデジタル署名、ユーザーに返します。このような文字列の塊を「トークン」と呼びます。

⑨でOffice365は、ユーザーからトークンを受け取り、デジタル署名から信頼されたIdPであることを検証します。検証が成功すれば、「信頼されたIdPで認証されているからログインしていいよ」とmiyaにOffice365へのサービスチケットを提供します。結果、miyaはログイン成功するわけですね。

この時、トークンにはユーザーの認証情報の他、アプリケーションが認証/認可に必要なユーザー情報をクレームとして含めることが出来ます。

クレームとは

アクセス制御ポリシーを構成していくためには、クレームを要素に条件を組み込む必要があります。クレームという単語をよく理解しておきましょう。

クレームとは、認証に来たユーザーに関連する一つ一つの属性情報です。例えば、Office365のログインIDとなるUserPrincipalNameはクレームの一つですね。

今回の構成では、データストアとしてActive Directoryが構成されているため、miyaがOffice365にサインインしようとすると、AD FSはActive Directoryのmiyaの属性からUserPrincipalNameをクレームとしてトークンにシリアライズしているのが分かります。

アクセス制御ポリシー

クレームはその属性が何であるかを示す型(クレームタイプ)と、属性の値によって表されます。

先ほどのUserPrincipalNameを例にすると、クレームタイプは「http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn」、その値は「miya@itbeginner.biz」となります。

UserPrincipalNameなどのActive Directory情報の他、よくアクセス制御ポリシーで使われるクレームが以下です。

 

X-MS-Forwarded-Client-IP

ユーザーのアクセス元グローバルIPアドレス情報。

イントラネットからのアクセスかどうかを検証できる。

X-MS-Client-Application

クライアントのアプリケーション情報。

Exchangeへの接続では、Autodiscover,OfflineAddressBook,EWSなどが含まれる。

X-MS-Proxy

Web Application Proxy(WAP)を経由したかどうかの情報。

WAPを経由した場合、WAPのホスト名が含まれる。

X-MS-Endpoint-Absolute-Path

Passive/Active プロファイルの情報。

WEBブラウザベースの認証をパッシブプロファイル、

Officeなどのリッチクライアントの認証をアクティブプロファイルと呼ぶ。

それぞれのプロファイルで認証フローが異なることから、よく使われます。

Passiveの場合、”/adfs/ls”が含まれている。

X-MS-Client-User-Agent

クライアントのアプリケーションのバージョン情報やデバイス情報。

スマホのOSバージョン情報も含まれることから、多少のデバイス制限も可能であるが、実用性は低い。

 

Office365への認証経路

クレームについて、概ね理解できたら次はOffice365への認証フローを整理しておきましょう。

WS-Federationでは、Passive/Activeと呼ばれる二つのプロファイルがあり、それぞれで認証フローが異なります。

認証フローが異なれば、クレーム内容も異なってくるので、Office365を利用するクライアントアプリケーションを整理し、アクセス制御ポリシーの設計に落とし込む必要があります。

Activeプロファイル

Activeプロファイルは、SOAPベースのリッチクライアントを指します。ADAL未対応のOffice、iOS11を除くActiveSyncなんかがそれに該当し、馴染み深いBasic認証がそれです。

アクセス制御ポリシー

Activeプロファイルは、社内にいようがOffice365が代理でトークンを要求するので、必ずWAPを経由する認証経路であることが特徴です。

アクセス制御ポリシー

  1. ユーザーがOffice365にアクセス、認証情報を入力
  2. MFGにリダイレクト先のAD FSのURLを確認
  3. 外部DNSサーバーから、AD FSのURLを名前解決
  4. WAP経由でAD FSに認証情報を送信、ログオントークンを要求
  5. Active Directoryに接続、トークン生成に必要なユーザー情報を要求(ユーザーID/パスワードが間違えていれば、この時点で認証エラー)
  6. ログオンユーザーの属性情報をAD FSに返信
  7. WAP経由でトークンをOffice365に返信
  8. MFGにトークンを提示し、Office365のサービスチケットを取得
  9. 認証が完了。ユーザーにOffice365を提供

アクセス制御ポリシー

 

社内からの認証であることをクレームから判断するには、X-MS-Forwarded-Client-IPX-MS-Proxyを組み合わせることで可能です。

アクセス制御ポリシー

非ADALな認証であるため、一般的にはレガシー認証と呼ばれており、MicrosoftもOffice365への接続はブロックする予定とか。

Office,iOS,Androidも今ではブラウザベース(Passive)であるため、Activeの認証は少なくなってきましたが、iOS11を除くActiveSyncは未だにActiveプロファイルですね。

また、X-MS-Client-Applicationにクライアントアプリケーション情報(Autodiscover、RPC、ActiveSync…とか)が含まれるの特徴です。

アクセス制御ポリシー

Passiveプロファイル

Passiveプロファイルは、HTTPベースのWEBブラウザを指します。ブラウザは勿論のこと、ADAL対応のOffice、モバイル版はAuthenticatorアプリを使った認証が該当します。

アクセス制御ポリシー

Passiveプロファイルの場合、Activeプロファイルとは異なりユーザー自身がトークンを要求するので、社内からのアクセスはWAPを経由せず、直接AD FSにアクセスする認証経路が特徴です。

先ほどのActiveプロファイルの接続方式では、miyaがOffice365にアクセスすると、Office365がmiyaの代理としてAD FSにトークンを要求していましたが、Passiveプロファイルは、下記フローの通り、ユーザーがWAPを経由せずにAD FSに接続していることが分かります。

アクセス制御ポリシー

社外接続でも、miyaが自身でWAPを経由してAD FSに接続しているのが分かりますね。

アクセス制御ポリシー

Officeのようなリッチクライアントであっても、認証フォームがブラウザとなるため、X-MS-Client-Applicationに、Autodiscover、RPC、POP、IMAPなどの接続プロトコルが拾えません。また、X-MS-Endpoint-Absolute-Pathには/adfs/ls/が含まるため、ブラウザと同じ認証ルールが適用されます。

 

アクセス制御ポリシーの構成フロー

さて、本題のアクセス制御ポリシーの構成セクションに入っていきます。

アクセス制御ポリシーを構成する際は、まずはOffice365へアクセスするクライアントを整理しておき、それぞれ社外/社内からアクセスさせるのかどうかを纏めたマトリックスを作成しておきましょう。

マトリックスが出来たらそれぞれのアクセスパターン毎にクレームを整理し、アクセス制御ポリシーに落とし込んでいきます。

アクセス制御ポリシーを構成するのは実は簡単ですが、どこの企業も前段の設計部分が以外に時間かかっちゃいますね。

認証パターンを設計する

まずは、自社のクライアントアプリケーションをまとめておきましょう。Passive/Active、社内/社外…など実際のクライアント環境を調査し、それぞれ拒否/許可、もしくは証明書認証させるのか…などなど整理します。

アクセス制御ポリシー

今回、ITBeginnerでは上図のような認証マトリックスに従ってアクセス制御ポリシーを作成していきます。

アクセス制御ポリシーを作成

AD FSの管理コンソールを開き、[アクセス制御ポリシー]→[アクセス制御ポリシーの追加…]をクリックします。

アクセス制御ポリシー

下図のような画面の場合、左下の[アクセス制御ポリシーの使用]をクリックします。
クリックすると、クレームルール言語の規則が使えなくなるので要注意です。

アクセス制御ポリシー

[追加]から、一つの許可ルールを作成することが出来ます。拒否ルールは作成できないため、許可ルールに該当しないよう、除外を構成してあげる必要があります。

アクセス制御ポリシー

特定 ネットワークから

[特定ネットワークから]では、ユーザーがサインインするNWの場所を条件として構成することが出来ます。

[特定]をクリックすることで、[イントラネット][インターネット][IPv4 または IPv6 アドレスで指定]から選択することが出来ます。

  • イントラネット
  • イントラネットでは、直接AD FSにトークンを要求するPassiveかつ社内NWからのアクセス。
  • インターネット
  • WAP経由でのアクセス。ActiveはWAP経由になることから全てインターネットになる(はず)。
  • IPv4 または IPv6 アドレスで指定
  • X-MS-Forwarded-Client-IPの値。インターネットへの出口IPを記述しましょう。

特定 グループから

[特定グループから]では、ユーザーが所属するグループを条件として構成することが出来ます。

例えば、MFAの導入を段階的にするのであれば、MFA対象のセキュリティグループを一つ作成しておき、「そのグループに所属する人がMFAを要求する」みたいなルールが書けます。

アクセス制御ポリシー

また、証明書認証などでトラブった時ように、ルールをバイパスするグループを作成しておけば、緊急回避することも出来るので念のため構成しておくと良いでしょう。

信頼レベルが 特定 のデバイスから

AD FSのデバイス登録機能によって、登録されたデバイス情報を条件として構成することが出来ます。

AD FSでは、Device Registration Service (DRS)と呼ばれデバイス登録機能が実装されていますが、Windows Server 2016ではサポートされていないことから、Azure ADにWorkplace Join→AADConnectによる書き戻しを構成する必要があります。

上述のデバイス登録が構成されている場合は許可、などのルールを書くことが出来るため、証明書認証のようなデバイス制御を構成することが出来ますが、けっこう難易度高めです。

特定 要求が要求にある

相変わらず変な日本語ですが、これは各クレームタイプと値を条件として構成することが出来ます。

アクセス制御ポリシー

例えば、ActiveSyncはExchange Onlineの検疫で制御するので、X-MS-Client-Applicationを条件に、ActiveSync/AutodiscoverはAD FSのアクセス制御をバイパスするルールを書きます。

アクセス制御ポリシー

および Multi-Factor Authentication を要求する

AD FSの多要素認証方法で設定している認証方法に従って、MFAを要求します。

アクセス制御ポリシー

上図では、Certificate Authenticationが選択されているので、ルールに該当するユーザーは、多要素認証として証明書認証が求められます。

さっそく、つくってみる

これらの条件を上手く組み合わせて、証明書認証を要求するルールを作成しました。一つの許可ルールの中に構成されている各条件はAND条件となります。

ITBeginnerの証明書認証対象者は、[外(=WAP経由)からの接続]かつ、[Passiveプロファイル]になります。

アクセス制御ポリシー

こんな感じの要領で、認証マトリックスに従ってアクセス制御ポリシーを作成していきます。最終的にはこのようなルールで作成してみました。一つ一つの許可ルールは、それぞれOR条件で評価されていきます。

そのため、サインインしたユーザーが、これらの許可ルールに一つでも該当すれば、サインインは成功します。反対にどれにもあてはまらない場合はアクセス拒否となります。社外からのActiveSyncを除くActiveプロファイルがそれに該当します。

これらのアクセス制御ポリシーが作成できたら、認証マトリックスに従って検証して、期待通りの結果が得られればOKです。(私にはそこまでの余力が無かったので、↑のルールを検証していません。すみません…)

おわりに

いかがでしたでしょうか?GUIから構成できるアクセス制御ポリシーですが、蓋を開けてみるとそれなりの知識を要します。

それぞれのクライアントアプリケーションで認証フローやクレームタイプが異なってくるので、それらの動きを理解した上で構成すれば、アクセス制御ポリシーの幅がぐーんと広がります。

本記事を通して、理解がいただけたら幸いです。構成するにあたってつまづき等があれば、コメントまでお願いいたします。

それでは、よいOffice365ライフをっ♪

スポンサーリンク