【Office365】Windows Server 2016 ADFSの証明書認証を構成する

皆さんお久しぶりです。Miyaです。

最近はお仕事の方が忙しく、Blogの更新が滞っていました。が、つい最近AD FSについて振り返る機会があたったので、整理した内容を記事にまとめてみました。

最近ではパススルー認証やSeamlessSSOの登場、安くて分かり易いサービス型の認証プロパイダーの登場により、Office365と言えばAD FS!!という常識が崩れてきてはいますが、実際にはまだまだ認証構成としては主軸と私は考えます。

特にグローバルで活躍されている大規模組織ではグループ統合基盤としてAD FSを採用するケースが多いですね。

今回は、AD FSが持つMFA(Multi Factor Authentication)のサービスの一つである「証明書認証」について、手順も交えつつ解説していきたいと思います。

スポンサーリンク:

証明書認証とは?

証明書認証とはMFAの一つで、従来のID/PASSの認証方式に加え、クライアント証明書の提示を要求する極めて強固な認証方式です。

無線LANのEAP-TLSと同様のイメージです。組織の証明局から発行された、[クライアント証明書]をコンピュータにインストールしておき、AD FSがユーザーの認証要求に対して証明書の提示を要求する認証フローになります。

証明書認証

クライアント証明書を各コンピューターに配布や更新/失効管理などなど、運用設計は必要になりますが、その強固な認証方式と、証明書をインストール出来るコンピューター端末を限定できる環境であることを前提にデバイス制限として利用できる優れた機能だと私は考えます。

証明書認証

Office365などのSaaSを利用していく上でメリット/デメリットでもある、どこからでも使える状況を良しとしない日本文化では受け入れやすい認証方式ではないでしょうか。

証明書認証の必要性

Office365 + AD FSのフェデレーションIDを構成している環境では、AD FSのクレームルール言語で記述されたアクセス制御によって、利用者がサインイン出来る環境を限定することが出来ました。

よく聞くのが社内NWからの認証要求しか受け付けないルールです。そのため、コンピュータを社外に持ち出した時はVPN経由でOffice365にアクセスする運用が一般的でしたね。

証明書認証

このルールの意図としては、Office365のリソースに私有端末からアクセスさせないようにするためでしたが、いちいちVPNを張らないといけないという手間が在り、ユーザビリティの低下を招きます。

そんな課題に対してのアプローチの一つとして選択されがちなのが証明書認証です。

先ほどの図のアクセスルールから、「クライアント証明書がインストールされた端末はどこからでも接続OK」のルールに書き換えてあげることで、社外からでもVPN要らずで接続でき、尚且つクライアント証明書がインストールされていない私有端末からは接続出来ない環境を構成することが出来ます。

証明書認証

セキュリティを担保しつつ、利便性の向上を狙える証明書認証ですが、AD FS以外にもサードパーティの認証プロパイダーで同等のサービスが安値で提供されていることから、小~中規模の企業ではこちらを採用するケースが多いです。NextSet、HDEOne、OSGなんかが有名ですよね。

本記事では、AD FSによる証明書認証の構成手順を紹介します。細かなアクセス制御ポリシーについては、本記事と一緒にまとめるとボリュームが増すことから別記事にまとめる予定です。

前提条件

証明書認証を構成するための前提条件です。本記事では下記に記載された環境が構成済みであることを前提に構成手順を紹介していきます。

フェデレーションID/AD FS環境であること

本ブログでは、AD FSによるフェデレーションIDの構成手順を過去に乗せているので、良ければ参考にしてください。
参考:Windows Server 2016 AD FS + Office365のフェデレーションIDの構成①
参考:Windows Server 2016 AD FS + Office365のフェデレーションIDの構成②

Office365のADAL(Oauth2.0)対応

証明書認証に限らずADAL(Azure Active Directory Authentication Library)と呼ばれる先進認証を利用するにはサーバー側でADAL機能をEnableにしなければなりません。

現在は、テナントを新規作成すると既定でEnableになっているのですが、ちょっと前まではDisableでしたので、現設定を確認し、必要に応じて設定変更しておきましょう。
参考:Exchange Online で先進認証を有効または無効にする
参考:Skype for Business Online: Enable your tenant for modern authentication

★Exchange Online
まずは、PowerShellから下記コマンドでExchange Onlineに接続しましょう。

下記コマンドで、Exchange OnlineのADALを有効化にし、設定の確認コマンドで”True”と表示されていればOKです。

★Skype for Business Online
Skype for Businessに接続するためには、別途モジュールをインストールする必要がありますので、こちらからモジュールのダウンロード&インストールをしましょう。

インストールが済みましたら、下記コマンドでSfBOnlineに接続します。

下記コマンドでADALを有効にし、設定の確認コマンドで”Allowed”と表示されていればOKです。

以上で、サーバー側の構成は完了です。

ポート条件

次に証明書認証を構成するためのポート要件です。AD FSで証明書認証を構成すると、クライアントから証明書を提示する時にクライアント→AD FS/WAPへ49443/TCPのInboundが発生します。
参考:AD FS Requirements – Network requirements

In addition, if client user certificate authentication (clientTLS authentication using X509 user certificates) is required and the certauth endpoint on port 443 is not enabled, AD FS 2016 requires that TCP port 49443 be enabled inbound on the firewall between the clients and the Web Application Proxy.

>>certauth endpointを有効にしていない場合、AD FS/WAPともにInboundの49443を許可しろ。と記載があります。

ちなみに、Certauth Endpointというのは、以前ブログでも紹介した、代替えホスト名のことを指します。
参考:Windows Server 2016 AD FS 証明書認証を代替ホスト名でバインドする

送信元Anyからの49443を許可する必要があるので、組織のセキュリティルールに違反するのであれば、代替ホスト名でバインドしましょう。

OfficeのADAL対応

こちらはクライアント側の要件になります。OutlookなどのOffice製品からもブラウザのように証明書認証させたい場合、ADALに対応したバージョンにアップグレードする必要があります。

Office 2016の場合は既定でADAL対応であるため、特に追加構成は必要ありませんが、Office 2013はADAL対応のために必要なKBを適用させておくのと、レジストリを修正する必要があります。

各々のファイルバージョンの要件は以下リンク先に要件が記載されています。クイック実行形式かMSI形式かを判断した上で適切な対応をしましょう。
参考:Office クライアントで Office365 先進認証を使用する

レジストリは二つのキーを新規作成し、値1を入力しておきましょう。

レジストリキー タイプ
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1

それぞれのレジストリの値と認証動作の対応関係が下記サイトにまとめられているのでご参考ください。
参考:Office 2013 クライアント アプリと Office 2016 クライアント アプリでの先進認証のしくみ

証明書認証の構成手順

さて、前ふりが長くなってしまいましたが、いよいよ証明書認証の構成手順に移りたいと思います。

証明機関はプライベート or パブリックのいずれでも構成可能ですが、今回はWindowsの証明機関の役割を使った比較的お手軽な構成としております。よければお試しあれ。

Windows 証明機関の設定

Windowsの役割・機能から「証明機関」をインストールしておきましょう。

証明書を発行するための「Active Directory証明機関」と、利用者がWEBブラウザからクライアント証明書を要求するために「証明機関 Web 登録」の機能をインストール、構成しておきます。

証明書認証

尚、「証明機関 Web 登録」からクライアント証明書を要求する際は、Web登録サイトをhttps化しておく必要があるので、IISから証明書をバインドしておきましょう。

証明書認証

インストールおよび構成が完了したら、[サーバーマネージャー]→[ツール]→[証明機関]から、証明機関の管理コンソールを起動します。この管理コンソールでは証明機関の管理設定や、発行した証明書の失効操作などが可能です。

Windowsの証明機関では、既定でいくつかの証明書テンプレートが用意されており、Office365の証明書として[ユーザー]テンプレートが使えます。

ですが、証明書の有効期限を変更、秘密鍵のエクスポートを禁止、などのカスタマイズをするために、本記事では新しく「Office365 証明書」テンプレートを作成していきます。

管理コンソールから[証明書テンプレート]を右クリック→[管理]をクリックします。

証明書認証

既定で用意されている[ユーザー]テンプレートを右クリック→[テンプレートの複製]でコピーします。

証明書認証

[全般]タブでは、テンプレートの表示名を設定出来ます。利用者が証明書を要求する際に表示される名前ですので、分かり易く「Office365 証明書」としておきます。

その下の有効期限では、利用者がクライアント証明書を発行してから、使用できる期間を設定することが出来ます。Windowsの証明機関では証明書の更新運用などが下手くそであることから5~10年などで設定するケースが多いです。

証明書認証

[要求処理]タブでは、証明書の秘密キーのエクスポートさせないよう設定しておきます。Windowsの場合、インストールした証明書は証明書ストアやInternetOptionsからエクスポートすることが出来るため、ちょっと知識のある人が触ると、簡単に証明書の使いまわしが出来てしまいます。

そこで、証明書ストアから証明書の秘密キーをエクスポートさせないよう構成しておき、使いまわしを阻止します。

証明書認証

[サブジェクト名]では、クライアント証明書に含めるサブジェクト名を構成します。Office365のログイン名(=UPN)が含まれている必要があるため、ここではActive DirectoryからユーザーオブジェクトのUPN属性を取得&構成します。

証明書認証

これらの設定が完了、[OK]で閉じると、Office365用の証明書テンプレートが新規作成されていることが確認できます。

証明書認証

テンプレートを作成したら、利用者から発行できるよう設定しておきます。

[証明書テンプレートコンソール]を×閉じし、[証明書テンプレート]を右クリック→[新規作成]をクリックします。先ほど作成した「Office365 証明書]を選択し、[OK]をクリックします。

証明書認証

証明書認証

以上で、「Office365 証明書」テンプレートの作成が完了しました。

次に、Active Directory証明機関から発行される証明書全般に関する設定をしていきます。

管理コンソールの[<証明書機関名>]を右クリック→[プロパティ]をクリックします。

証明書認証

[拡張機能]タブから、[CRL配布ポイント(CDP)]と[機関情報アクセス(AIA)]の”http://~~”を選択し、下記二つにチェックをしけましょう。

証明書認証

何故含める必要があるかと言うと、社外NWからWAP経由で証明書認証する場合、ユーザーが提示したクライアント証明書が正しいものであるかどうかを検証するのは実はWAPになるからです。

CRLとは、失効されたクライアント証明書のシリアル番号をリスト化したファイルで、AD FS/WAPはこれをもとにユーザーが提示したクライアント証明書が失効されていないかを検証します。

証明書認証

既定の設定では、CRLの場所(CDP)はLDAPパスのものが含まれており、社内NWからのアクセスのように、AD FSがクライアント証明書の検証する場合においては、LDAP検索出来るのですが、DMZに配置されるWAPからイントラネットのActive Directoryに対してLDAPすることは無いかと思います。

そのため、http形式でCDP,AIA情報を証明書に含めてあげる必要があります。これは同時に、WAP→証明機関の通信において、HTTPをPermitしておく必要があります。

証明書認証

次に、AD FS/WAPの証明書ストアに、証明機関のルート証明書をインポートしておきましょう。

ルート証明書をダウンロードする方法はいくつかありますが、Web登録サイト(https://<ホスト名>/certsrv)から簡単にダウンロード出来ます。

証明書認証

また、WAPが証明書情報の検証する場合、http://<証明機関名>/~~~の名前でアクセスするので、名前解決ができるようHOSTSに記述しておきましょう。
※WAPが内部DNSに対して名前解決できる環境であれば不要です。

以上で、証明機関関連のセットアップは完了です。

AD FSの設定

証明機関での設定が完了したら、次はAD FSで証明書認証するための設定をしていきます。

AD FSの管理コンソールを起動して、[認証方法]→[多要素認証]→[編集]から、[Certificate Authentication]にチェックしましょう。

証明書認証

上記の設定で、多要素認証として証明書認証の機能がONになったのですが、既定のアクセス制御ポリシーでは、多要素認証を要求するよう構成されておりません。

Windows Server 2016のAD FSではよくあるシナリオに基づいていくつかのテンプレートが用意されています。まずは無条件で証明書認証を要求するテンプレート「Permit everyone and require MFA」を適用してみましょう。

[証明書利用者信頼]から[Microsoft Office365…]を右クリック→[アクセス制御ポリシー]をクリックしましょう。

証明書認証

ここでは、利用者からのクレームに対して許可/拒否を決定するためのルールを記述できます。Windows Server 2012R2以前は、クレームルール言語と呼ばれる形式でルールを書いていました。

よくある一例を挙げると、「Active Syncを除く、社外からのアクセス拒否」であれば、下記のようなルールを記述する必要がありました。

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy“]) &&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.ActiveSync”]) &&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~“<出口のグローバルIP>”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny“, Value = “true”);

Windows Server 2016でも、既定は↑のようなクレームルール言語で記述する方式なのですが、2016からは「アクセス制御ポリシー」と呼ばれるポチポチで構成できる便利な機能が搭載されました。折角なのでそれを使うとしましょう。

先ほどのアクセス制御ポリシーの編集画面の左下にある、[アクセス制御ポリシーの使用]をクリックします。
クリックすると、旧方式であるクレームルール言語は利用出来なくなります。本番環境では慎重に操作しましょう。

[Permit everyone and require MFA]を選択し、[適用]をクリックすることで、全てのユーザーに証明書認証を要求するアクセス制御ポリシーが割り当てられます。

証明書認証

以上で、AD FS側の証明書認証の設定は完了です。

クライアント証明書のインストール

サーバー側の設定が一通り完了したので、次は端末にクライアント証明書「Office365 証明書」をインストールしていきましょう。

クライアント端末から、https://<ホスト名>/certsrvで証明機関のWeb登録サイトにアクセス、ログインします。

[証明書を要求する]をクリックします。

証明書認証

[証明書の要求の詳細設定]をクリックします。

証明書認証

[このCAへの要求を作成し送信する]をクリックします。

証明書認証

証明書テンプレートは先の手順で作成した「Office365 証明書」を選択し、[送信]します。既定のテンプレートである[ユーザー]も選択可能であることから、必要に応じて削除しておきましょう。

証明書認証

証明書がインストールされると、ユーザーアカウントの証明書ストアにクライアント証明書がインストールされています。

以上で、クライアント証明書のインストールは完了です。

実際に、社外/社内からOffice365へログインすると、証明書の提示が要求されているのが確認出来ます。適切な証明書が選択し、そのままログインが完了すると成功です。

また、AD FSのサービス名(接続名)がローカルイントラネットとして登録されている環境であれば、自動的に証明書を選択→ログインが完了するので、シームレスに証明書認証できるのでお勧めです。

証明書がインストールされていなかったり、ログインユーザーと証明書のサブジェクト名が異なっている、もしくは失効されている場合は、アクセスが拒否されます。

アクセス制御ポリシーのカスタマイズ

先の手順では、既定で用意されたアクセス制御ポリシーのテンプレートを使用しましが、アクセス制御のルールとしては貧弱であることから、自身でアクセス制御ポリシーを作成する必要があります。

先ほど簡単に紹介しましたが、Windows Server 2012R2以前で証明書認証とアクセス制御を利用するには、クレームルール言語でアクセス規則を記述していく必要がありました。

Windows Server 2016からはGUIから簡単に構成できる「アクセス制御ポリシー」が搭載され、かなり簡単に構成できるよう改善されています。(逆にクレームルールを触ってきた者からすると分かりにくいですが…)

[アクセス制御ポリシー]→[アクセス制御ポリシーの追加…]から自作のアクセス制御ポリシーを作成することが出来ます。

証明書認証

アクセス制御ポリシーを詳細にカスタマイズするにはそれなりの知識が必要になってきます。

クレームルールの記述はなくなったとしても考え方は変わらず、クレームをもとにアクセス制御ポリシーを構成しなければならないので、クレームの中身をある程度把握しておき、それらを上手く組み合わせていく必要があります。

本記事にアクセス制御ポリシーの詳細を記載するには、ボリュームが膨れ上がるので、別記事で取り上げさせていただきます。

証明書認証の課題

ここでは、証明書認証の構成における課題を取り上げています。Windows証明機関特有の課題が多いので、場合によってアプライアンス製品の証明機関の導入を推奨します。

モバイル端末への証明書配布が出来ない

Windows証明機関のWeb登録サイトでは、Android、iOSへ証明書を配布することが出来ません。

そのため、OutlookやOneDrive、その他認証を必要とするアプリケーションから証明書認証させる場合、別の証明機関を導入する必要があります。

証明書の有効期限を通知する仕組みがない

今回のような証明書認証では、クライアント証明書を運用していく必要があり、運用の一つに証明書の更新があります。

証明書の有効期限を1年とした場合、利用者は有効期限が切れる前に、新しい証明書を発行し、インストールする必要があります。

通常、利用者はクライアント証明書の有効期限を意識することは無いので、気づかぬうちに「Office365へ認証できなくなった!」といった状況に陥るかと思います。

Windowsの証明機関には、発行された証明書の有効期限が迫った時に、それを利用者に通知する機能がありません。

そのため、手動で管理するか、有効期限を長期的に延ばすか、通知機能が搭載された証明機関を導入する必要があります。

失効運用がかなり煩雑である

Windowsの証明機関の管理コンソールから、発行された証明書や失効された証明書が確認出来ますが、正直使い物になりません。

例えば、利用者が端末を紛失した場合、その証明書が第三者によって利用されてはいけないことから、[発行した証明書]から失効する必要があるのですが、管理コンソールから目的のクライアント証明書を探し当てるには利便性が悪すぎます。

ADALキャッシュによるAD FSのバイパス

OutlookなどのOfficeアプリケーションのADAL認証では、認証に成功するとAzureADからアクセストークン/リフレッシュトークンが配布され、Windowsの資格情報マネージャーにキャッシュします。
参考:Office 製品の Office 365 モダン認証フローと認証キャッシュについて

証明書認証

これらのアクセストークン/リフレッシュトークンが有効期限内の場合、AD FSをBypassして直接AzureADにトークンを渡すため、結果として認証が発生せずOffice365へアクセスすることが出来ます。

既定でアクセストークンは1時間、リフレッシュトークンは90日間の有効期限があり、OAuth2.0ではアクセストークンの有効期限が切れてもリフレッシュトークンによってアクセストークンは更新される仕組みであるため、実質90日間はAD FSをBypassする認証フローになるわけです。
参考:Azure Active Directory における構成可能なトークンの有効期間 (パブリック プレビュー)

これが何故問題かというと、社外からのアクセスは証明書認証、社内からのアクセスは証明書認証しないルールを設けることが多いかと思います。

この時、証明書がインストールされていない端末でも、社内NWからはOffice365へアクセス可能な状況なため、ID/PASSで認証され、AzureADからは90日有効なトークンを受け取りキャッシュします。

ということは、次にこの端末を持ち出し、外部からOffice365へアクセスするときには、AD FSをBypassすることから、90日間は証明書認証せずに直接Office365へアクセス出来る状況となります。

リフレッシュトークンの期間を変更することも出来るのですが、いまだにプレビューかつ、現在は公開している手順での変更は推奨されていないため、明確な対策がありません。

トラブルシューティングは難しい

証明書認証のトラブルシューティングは、関連するシステムが多いことからトラブルシューティングが難しいです。

AD FS/WAP/証明機関/クライアント端末に着目する必要があり、クライアント端末が起因しているケースは特にやっかいですね。

私も証明書認証の導入支援は何度かやってきましたが、これらのトラブルにかなり苦戦したことがあります。それらの対処法についてはまたの機会にご紹介できればと思います。

おわりに

いかがでしたでしょうか?証明書認証の魅力は伝わりましたでしょうか?笑

証明書認証はデバイス制限に繋がることから、人気の機能ではありますが、認証フローの理解、アクセス制御ポリシーの仕組みなどなど、あらゆる知識がないと運用していくには中々難しい存在です。

本記事を通して少しでも証明書認証への理解が深まれば幸いです。次回は、AD FSのアクセス制御ポリシーを証明書認証を絡めた形でご紹介していきたいと思います。

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

スポンサーリンク