Microsoft Kerberos Constrained Delegation ソリューション
多くの組織は、現在 ASA SSO 機能によって提供されるもの以上の認証方式を使用して、クライアントレス VPN ユーザを認証し、ユーザの認証クレデンシャルを Web ベースのリソースにシームレスに拡張することを望んでいます。スマート カードおよびワンタイム パスワード（OTP）を使用したリモート アクセス ユーザの認証に対する要求が大きくなっていますが、SSO 機能ではこの要求を満たすには不十分です。SSO 機能では、認証が必要になると、従来のユーザ クレデンシャル（スタティックなユーザ名とパスワードなど）をクライアントレス Web ベースのリソースに転送するだけであるためです。
たとえば、証明書ベースの認証方式にも OTP ベースの認証方式にも、ASA が Web ベースのリソースへの SSO アクセスをシームレスに実行するために必要な従来型のユーザ名とパスワードが含まれていません。証明書を使用して認証する場合、ASA が Web ベースのリソースに達するためにユーザ名とパスワードは必要ないので、この認証方式は SSO ではサポートされません。これに対し、OTP にはスタティックなユーザ名が含まれていますが、パスワードはダイナミックであり、VPN セッション中に後で変更されます。一般に、Web ベースのリソースはスタティックなユーザ名とパスワードを受け入れるように設定されるため、OTP も SSO でサポートされない認証方式になっています。
Microsoft の Kerberos Constrained Delegation（KCD）は、ASA のソフトウェア リリース 8.4 で導入された新機能であり、プライベート ネットワーク内の Kerberos で保護された Web アプリケーションにアクセスできるようにします。この利点により、証明書ベースおよび OTP ベースの認証方式を Web アプリケーションにシームレスに拡張できます。SSO と KCD が独立しながら連携することにより、多くの組織では、ASA でサポートされるすべての認証方式を使用して、クライアントレス VPN ユーザを認証し、ユーザの認証クレデンシャルを Web アプリケーションにシームレスに拡張できます。
KCD の機能
Kerberos は、ネットワーク内のエンティティのデジタル識別情報を検証するために、信頼できる第三者に依存しています。これらのエンティティ（ユーザ、ホスト マシン、ホスト上で実行されるサービスなど）は、プリンシパルと呼ばれ、同じドメイン内に存在している必要があります。秘密キーの代わりに、Kerberos では、サーバに対するクライアントの認証にチケットが使用されます。チケットは秘密キーから導出され、クライアントのアイデンティティ、暗号化されたセッション キー、およびフラグで構成されます。各チケットはキー発行局によって発行され、ライフタイムが設定されます。
Kerberos セキュリティ システムは、エンティティ（ユーザ、コンピュータ、またはアプリケーション）を認証するために使用されるネットワーク認証プロトコルであり、情報の受け手として意図されたデバイスのみが復号化できるようにデータを暗号化することによって、ネットワーク伝送を保護します。クライアントレス SSL VPN ユーザに Kerberos で保護された Web サービスへの SSO アクセスを提供するように KCD を設定できます。このような Web サービスやアプリケーションの例として、Outlook Web Access（OWA）、SharePoint、および Internet Information Server（IIS）があります。
Kerberos プロトコルに対する 2 つの拡張機能として、プロトコル移行および制約付き委任が実装されました。これらの拡張機能によって、クライアントレスまたは SSL VPN リモート アクセス ユーザは、プライベート ネットワーク内の Kerberos で認証されるアプリケーションにアクセスできます。
プロトコル移行機能は、ユーザ認証レベルでさまざまな認証メカニズムをサポートし、後続のアプリケーション レイヤでセキュリティ機能（相互認証や制約付き委任など）用に Kerberos プロトコルに切り替えることによって、柔軟性とセキュリティを向上させます。制約付き委任では、ドメイン管理者は、アプリケーションがユーザの代わりを務めることができる範囲を制限することによって、アプリケーション信頼境界を指定して強制適用できます。この柔軟性は、信頼できないサービスによる危険の可能性を減らすことで、アプリケーションのセキュリティ設計を向上させます。
制約付き委任の詳細については、IETF の Web サイト（http://www.ietf.org）にアクセスして、RFC 1510 を参照してください。
KCD の認証フロー
次の図に、委任に対して信頼されたリソースにユーザがクライアントレス ポータルによってアクセスするときに、直接的および間接的に体験するパケットおよびプロセス フローを示します。このプロセスは、次のタスクが完了していることを前提としています。
-
ASA 上に設定された KCD
-
Windows Active Directory への参加、およびサービスが委任に対して信頼されたことの確認
-
Windows Active Directory ドメインのメンバーとして委任された ASA
図 1. KCD プロセス 
 （注） |
クライアントレス ユーザ セッションは、ユーザに設定されている認証メカニズムを使用して ASA により認証されます（スマートカード クレデンシャルの場合、ASA はデジタル証明書の userPrincipalName を使用して、Windows Active Directory に対して LDAP 許可を実行します）。 |
-
認証が成功すると、ユーザは ASA クライアントレス ポータル ページにログインします。ユーザは、URL をポータル ページに入力するか、ブックマークをクリックして、Web サービスにアクセスします。この Web サービスで認証が必要な場合、サーバは ASA クレデンシャルの認証確認を行い、サーバがサポートしている認証方式のリストを送信します。
（注）
クライアントレス SSL VPN の KCD は、すべての認証方式（RADIUS、RSA/SDI、LDAP、デジタル証明書など）に対してサポートされています。次の AAA のサポートに関する表を参照してください。http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/access_aaa.html#wp1069492
-
認証確認時の HTTP ヘッダーに基づいて、ASA はサーバで Kerberos 認証が必要かどうかを判断します（これは SPNEGO メカニズムの一部です）。バックエンド サーバとの接続で Kerberos 認証が必要な場合、ASA は、ユーザに代わって、自身のサービス チケットをキー発行局に要求します。
-
キー発行局は、要求されたチケットを ASA に返します。ASA に渡される場合でも、これらのチケットにはユーザの認可データが含まれています。ASA は、ユーザがアクセスする特定のサービスのサービス チケットを KCD に要求します。
（注）
ステップ 1 ～ 3 では、プロトコル移行が行われます。これらのステップの後、Kerberos 以外の認証プロトコルを使用して ASA に対して認証を行うユーザは、透過的に、Kerberos を使用してキー発行局に対して認証されます。
-
ASA は、ユーザがアクセスする特定のサービスのサービス チケットをキー発行局に要求します。
-
キー発行局は、特定のサービスのサービス チケットを ASA に返します。
-
ASA は、サービス チケットを使用して、Web サービスへのアクセスを要求します。
-
Web サーバは、Kerberos サービス チケットを認証して、サービスへのアクセスを付与します。認証が失敗した場合は、適切なエラー メッセージが表示され、確認を求められます。Kerberos 認証が失敗した場合、予期された動作は基本認証にフォールバックします。
KCD のデバッグ
次のコマンドは、KCD 固有のデバッグ メッセージの出力を制御するために使用します。バージョン 9.5.2 よりも前で行われていたように、ADI の syslog 発行レベルを制御するためではありません。
debug webvpn kcd
Active Directory での Windows サービス アカウントの追加
ASA での KCD 実装にはサービス アカウントが必要です。これは、コンピュータの追加（ドメインへの ASA の追加など）に必要な権限を持った Active Directory ユーザ アカウントです。ここでの例では、Active Directory ユーザ名 JohnDoe は、必要な権限を持ったサービス アカウントを示します。Active Directory でのユーザ権限の実装方法については、Microsoft サポートに問い合わせるか、http://microsoft.com を参照してください。
KCD の DNS の設定
この項では、ASA で DNS を設定するために必要な設定手順の概要を示します。ASA での認証委任方式として KCD を使用する場合は、ASA、ドメイン コントローラ（DC）、委任しているサービスの間でホスト名解決と通信をイネーブルにするために、DNS が必要です。
手順
| ステップ 1 |
ASDM から、 に移動し、DNS のセットアップを設定します。
|
| ステップ 2 |
適切なインターフェイスで DNS ルックアップをイネーブルにします。クライアントレス VPN の配置には、社内ネットワーク（通常は内部インターフェイス）を介した DNS ルックアップが必要です。 |
Active Directory ドメインに参加するための ASA の設定
この項では、ASA を Active Directory ドメインの一部として動作させるために必要な設定手順の概要を示します。KCD では、ASA が Active Directory ドメインのメンバーであることが必要です。この設定により、ASA と KCD サーバ間の制約付き委任トランザクションに必要な機能がイネーブルになります。
手順
| ステップ 1 |
ASDM から、 に移動します。 |
| ステップ 2 |
[New] をクリックして制約付き委任用の Kerberos サーバ グループを追加し、次の項目を設定します。
|
| ステップ 3 |
[OK] をクリックして設定を適用し、リモート アクセス ユーザの代わりにサービス チケットを要求するように Microsoft KCD サーバを設定します。 |
Microsoft Kerberos の要件
kcd-server コマンドを機能させるために、ASA はソース ドメイン（ASA が常駐するドメイン）とターゲットまたはリソース ドメイン（Web サービスが常駐するドメイン）間の信頼関係を確立する必要があります。サービスにアクセスするリモート アクセス ユーザの代わりに、ASA は独自のフォーマットを使用して、ソース ドメインから宛先ドメインへの認証パスを横断し、必要なチケットを取得します。
このように認証パスを越えることは、クロスレルム認証と呼ばれます。クロスレルム認証の各フェーズにおいて、ASA は特定のドメインのクレデンシャルおよび後続ドメインとの信頼関係に依存しています。
フィードバック