皆さんこんにちは。国井です。
ADFSテキスト全文公開チャレンジの16回目は第5章から証明書認証についてです。
■ ■ ■
第 5 章では、安全に ID 連携を実装するために利用可能な様々なオプションについて解説します。
クラウドサービスを中心としたワークスタイルでは、ファイアウォールのようなネットワーク中心のセキュリティ対策ではなく、オンプレミス/クラウドを問わず利用される ID 中心のセキュリティ対策が重要とされています。資格情報を複数回入力することがないシングルサインオンは、それ自体が強力なセキュリティ対策と言えますが、さらに強化していくために利用可能な機能について、この章では以下の 3 点を取り上げます。
■多要素認証
資格情報だけでなく、物理的なデバイスを利用して本人確認を行うことにより、なりすましを防いで認証を強化します。
■デバイス認証
あらかじめ登録されたデバイスを利用してサインインを行った時だけ認証・認可を許可する方法です。
■条件付きアクセスによるデバイス認証
Azure AD の条件付きアクセスを利用して、あらかじめ登録されたデバイスよる接続のみを許可する方法です。
注釈
デバイス認証はWindows 8.1までのデバイスをターゲットとした方法なので、ここでは割愛します。
ADFS サーバーによる ID 連携では、シングルサインオンを実現できることを本書では解説してきましたが、サインイン自体は従来通りユーザー名とパスワードを利用していました。ところがユーザー名とパスワードによるサインインでは第三者にその内容が知られてしまった場合、不正アクセスの可能性が高まります。
こうした問題に対処するため、ADFS ではユーザー名とパスワードに追加の認証要素を加えた、多要素認証をサポートしています。多要素認証では、携帯電話やデバイスにインストールされた証明書など、物理的にデバイスを所有していることを前提とした認証方法であり、ユーザー名とパスワードのように知っていれば誰でもサインインできるようなものに比べて、より安全にサインインすることができます。
Office 365 (Azure AD) で多要素認証を実装する場合、ADFS サーバーで多要素認証を実装する方法と、Azure AD で多要素認証を実装する方法があり、いずれかの方法で多要素認証を実装することができます。
■ADFS サーバーと Azure AD の多要素認証の違い
ADFS サーバーによる多要素認証と Azure AD による多要素認証は、多要素認証に使用可能な認証要素が異なるほか、多要素認証を利用する条件設定の方法が異なります。Azure AD ではユーザーを単位として多要素認証の使用/不使用を設定しますが、ADFS サーバーの場合にはクレーム ルールを使用して多要素認証利用のための条件を細かく設定できる点が異なります。
次のページから認証要素と多要素認証利用の条件設定について解説します。
ADFS と Azure AD の多要素認証では、多要素認証に利用する認証要素は異なり、ADFS では証明書、Azure AD ではモバイルアプリ、携帯電話による通話、ショートメッセージ (SMS) をそれぞれ利用することができます。
■証明書
信頼されたルート証明機関に登録された認証局から発行されたユーザー証明書を保有するデバイスであることを確認し、追加の認証とする方法です。証明書はデバイスにインストールして利用するため、証明書を利用した多要素認証はデバイス認証の一環として利用することがあります。
■モバイルアプリ
Azure Authenticator と呼ばれるスマートフォン向けのアプリを利用し、アプリに表示されるメッセージに応答することで、追加の認証とする方法です。
■通話
あらかじめ登録した電話番号に通話を行い、ガイダンスに従って＃を押すことで、追加の認証とする方法です。
■SMS
あらかじめ登録した電話番号に SMS を送信し、SMS に記載された番号を入力することで、追加の認証とする方法です。
以上の方法のほか、ADFS サーバーでは拡張プロバイダー用の API が用意されており、追加のプロバイダーを開発することにより、任意の方法で多要素認証を実装することができます。また、Azure AD では ADFS 用の拡張プロバイダーとして、モバイルアプリ、通話、SMS が利用できるプロバイダーを提供しており、組み合わせて利用することにより、ADFS サーバーからモバイルアプリ、通話、SMS のいずれかを利用した多要素認証を実装することも可能です。詳しくは後のページで解説します。
注釈
ADFSと共に多要素認証を利用する方法として、もともとこのテキストではAzure MFA Serverについて解説が書かれていましたが、現在では利用できなくなってしまったので、Azure MFA Serverなしで利用可能な「証明書」についてのみ後続で解説します。
ADFS サーバーで多要素認証を実装する場合、多要素認証を行うために必須となる ADFS サーバーの設定のほか、証明書による多要素認証を行う場合に必要となる設定、多要素認証プロバイダーを利用する場合に必要となる設定がそれぞれあります。
①多要素認証の有効化
ADFS サーバーで多要素認証を有効にするには、有効化の設定が必要です。有効化の設定は ADFS サーバー全体もしくは証明書利用者信頼の単位で行うことができます。
②多要素認証実行の条件
Azure AD による多要素認証はユーザー単位での設定ですが、ADFS による多要素認証は多要素認証を行う条件を細かく定義することができます。
③認証局の準備
④ユーザー証明書の発行
証明書を利用して多要素認証を行う場合、事前に多要素認証を利用するデバイスに対してユーザー証明書を配布しておく必要があります。
⑤多要素認証プロバイダーの有効化
Azure AD の多要素認証プロバイダーを利用して多要素認証を行う場合、Azure AD の多要素認証プロバイダーを有効化し、オンプレミスにインストールする MFA Server コンポーネントをダウンロードしておきます。
(※証明書認証を行う場合は不要なので、後続のページでは解説を割愛します)
次のページから個々の項目について、具体的な設定を確認します。
証明書認証で使用する認証局
多要素認証で証明書認証を選択する場合、認証局には Active Directory 証明書サービスの他、様々な認証局を利用することができます。本手順では、Active Directory 証明書サービスのエンタープライズ CA とスタンドアロン CA の場合に分けて解説しますが、Active Directory 証明書サービス以外の認証局を利用する場合はスタンドアロン CA の手順を行ってください。
ADFS サーバーで多要素認証を行う場合、最初の設定として多要素認証の有効化を行います。多要素認証の有効化は ADFS 管理ツールの [サービス] – [認証方法] から設定します (Windows Server 2012 R2 の場合は [認証ポリシー] または [証明書利用者信頼ごと] を展開し、多要素認証の編集画面から設定)。
有効化するときは、多要素認証の実行方法と多要素認証の実行条件を指定します。
多要素認証の実行方法では、証明書認証または Azure MFA (MFA Server) のいずれかを選択します。
一方 Windows Server 2016 の場合、実行条件はアクセス制御ポリシーの中で定義します。アクセス制御ポリシーのアクセスを許可する条件として多要素認証を行う条件を定義し、条件に合致する場合の挙動として「Multi-Factor Authenticationを要求する」を選択します。
(Windows Server 2012 R2 の場合は多要素認証の実行方法を設定する画面と同じ画面で設定します)
ADFS サーバーではトークン発行に関わる通信は、すべて TCP 443 を使用していますが、証明書認証に関わる通信だけは TCP 49443 という特別なポート暗号を使用して通信を行います。そのため、外出先から Web アプリケーション プロキシを経由して接続するようなケースでは、Web アプリケーションプロキシサーバーが TCP 49443 による通信を受信できるようにファイアウォール等の設定を行っておく必要があります。
Windows Server 2016 の ADFS サーバーでは、証明書認証を行うために TCP 49443 を使わないように構成することができるようになりました。これを代替ホスト名バインドと呼びます。証明書認証の代替ホスト名バインドでは、フェデレーションサービス名とは別に証明書認証用に定義された FQDN を用意しておき、その名前で証明書認証の処理を行うように構成します。
このような処理方法を採用することによって、代替ホスト名バインドを利用する場合には、ADFS サーバーの SSL 通信証明書の名前に、フェデレーションサービス名と証明書認証用の代替 FQDN の 2 つの名前が登録された証明書を取得する必要があります。証明書認証用の代替 FQDN には次の名前を使用します。
certauth.<フェデレーションサービス名>
また、既定では証明書認証に TCP 49443 を利用するように構成されているため、これを変更するために次のコマンドレットを実行します。(ADFS サーバーの FQDN にはフェデレーションサービス名ではなく、Active Directory ドメイン名を含む FQDN を指定します。)
Set-AdfsAlternateTlsClientBinding `
-Member <ADFS サーバーの FQDN> -Thumbprint ‘<証明書の拇印>’
証明書による多要素認証を実行する場合、ユーザー証明書をあらかじめデバイスにインストールしておく必要があります。証明書はどの認証局から発行されたものであっても、ADFS サーバーの多要素認証で利用することは可能ですが、利用する認証局の情報は ADFS サーバーの証明書ストア内の NTAuth に事前に登録しておく必要があります。次のコマンドを実行することで登録されます。(root.cer ファイルは認証局のルート証明書です)
certutil -enterprise -addsotre “NTAuth” root.cer
Windows Server の認証局サービスである、Active Directory 証明書サービスでは、エンタープライズ CA を選択することで、NTAuth に自動的に登録されるため、certutil コマンドによる登録は不要です。
エンタープライズ CA を選択した場合、ドメイン参加のクライアント コンピューターにはグループポリシーを通じて、自動的にユーザー証明書を発行するように構成することが可能です。ただし、自動発行するためには証明書サービスに実装されている証明書テンプレートは既定のユーザー証明書テンプレートではなく、Windows Server 2003 以降のバージョンで構成された証明書テンプレートを利用する必要があるため、必ず既定のユーザー証明書テンプレートを複製し、Windows Server 2003 以降のバージョンで構成された証明書テンプレートを作成し、証明書を自動発行するよう、アクセス許可を割り当ててください。
エンタープライズ CA の場合、ドメインに参加していないコンピューターやデバイスに対して証明書を発行することが困難です。iOSやAndroidなどのモバイルデバイスに証明書を発行することをメインに考えているのであれば、Active Directory 証明書サービスのスタンドアロン CA など、エンタープライズ CA以外の認証局の利用を検討してください。
エンタープライズ CA 以外の認証局を利用して証明書を発行する場合、証明書はクライアント認証を用途とする OID = 1.3.6.1.5.5.7.3.2 となる証明書を発行してください。証明書発行要求を作成するときは以下の文字列を作成し、テキストを保存します。
[NewRequest]
Subject=”E=<ユーザーの UPN>,CN=<ユーザー名>,CN=Users,DC=exampleXX,DC=com”
KeyUsage=0xa0
Exportable=FALSE
KeyLength=2048
MachineKeySet=FALSE
SMIME=FALSE
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2
[Extensions]
2.5.29.17=”{text}”
_continue_ = “upn=<ユーザーの UPN>”
作成したファイルは Certutil コマンドを利用して認証局に提出する発行要求ファイルとして利用できます。発行要求ファイルを作成するコマンドは以下のとおりです。
certutil -new 発行要求テキストファイル名 発行要求ファイル名
証明書発行要求ファイルの作成
証明書発行要求ファイルのフォーマットは使用する認証局によって異なります。本書ではActive Directory 証明書サービスのスタンドアロン CA を利用することを前提としていますが、他の認証局を利用する場合はそれぞれの認証局でのフォーマットに従ってください。
その他、認証局に求められる要件として、証明書に CRL の発行場所情報である CDP (CRL 配布ポイント) の情報が記載されていること、CDP は物理的にアクセスできる場所にあること、証明書認証を開始する前までに CRL が既に公開されていることが前提条件となります。
証明書認証によって、特定の認証局から発行された証明書を保有しているかを確認することでアクセス制御を行いましたが、クレームルールを活用すれば、ユーザーが保有する証明書の内容を検証し、特定の証明書種類を持つユーザー (デバイス) だけをアクセスさせるように制御することができます。その場合、次のルールに従ってクレーム ルールを作成してください。
■受け付け変換規則の作成
発行承認規則でアクセス制御を行うためには受け付け変換規則で使用するクレームを定義する必要があります。利用可能なクレームの一覧は ADFS 管理ツールの [要求記述] からも確認できるように、証明書のサブジェクト、サブジェクトの代替名、拇印などを利用できます。
■発行承認規則の作成
発行承認規則で受け付け変換規則であらかじめ指定したクレーム種類を利用して規則を作成できます。記述方法は一般的な発行承認規則と同じように利用できます。なお、証明書認証はクレームルールの評価よりも先に行うため、証明書認証に失敗したユーザーはクレーム ルールによる評価を行うことはありません。
編集後記
デバイス認証やAzure MFA Serverを利用した多要素認証など、ADFSと共に利用可能な認証要素が少なくなると時代も変化しているんだなと感じます。
私的にとても残念だなと思ったのは、証明書だけでADFSの認証が完了できるという便利さを多くの人に理解してもらえなかった点です。Azure ADで「パスワードレス」という言葉が流行っていますが、ADFSでは4年も前から既に実装されていたんですよね。
