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 認証が失敗した場合、予期された動作は基本認証にフォールバックします。
クロスレルム認証用の ASA の設定
クロスレルム認証用に ASA を設定するには、次のコマンドを使用する必要があります。
手順
| ステップ 1 |
Active Directory ドメインに参加します。（インターフェイス内で到達可能な）10.1.1.10 ドメイン コントローラ。 ntp hostname 例: |
| ステップ 2 |
ルックアップを実行します。 dns domain-lookup dns server-group 例:この例では、ドメイン名 private.net と、ユーザ名 dcuser とパスワード dcuser123! を使用するドメイン コントローラ上のサービス アカウントを示します。 |
KCD の設定
ASA を Windows Active Directory ドメインに参加させ、成功または失敗のステータスが返されるようにするには、次の手順を実行します。
手順
| ステップ 1 |
クライアントレス SSL VPN コンフィギュレーション モードに切り替えます。 webvpn |
||
| ステップ 2 |
KCD を設定します。 kcd-server |
||
| ステップ 3 |
ドメイン コントローラ名およびレルムを指定します。AAA サーバ グループは、Kerberos タイプである必要があります。 kcd-server aaa-server-group 例: |
||
| ステップ 4 |
（任意） ASA の動作を指定して削除します。 no kcd-server |
||
| ステップ 5 |
（任意） 内部状態にリセットします。 kcd-server reset |
||
| ステップ 6 |
KCD サーバが表示されていることを確認し、ドメイン参加プロセスを開始します。Active Directory のユーザ名とパスワードは EXEC モードでだけ使用され、設定には保存されません。
kcd domain-join username <user> password <pass> user：特定の管理ユーザではなく、Windows ドメイン コントローラにデバイスを追加するサービス レベル権限を持つユーザと対応します。 pass：パスワードは、特定のパスワードではなく、Windows ドメイン コントローラにデバイスを追加するサービス レベル権限を持つユーザのパスワードと対応します。 |
||
| ステップ 7 |
KCD サーバ コマンドが有効なドメイン参加ステータスを持っているかどうかを確認し、ドメイン脱退を開始します。 |
KCD ステータス情報の表示
手順
| コマンドまたはアクション | 目的 |
|---|---|
|
リリース 9.5.2 では、次のコマンドが、ADI 経由でドメイン メンバーシップを要求します。少なくとも、ドメイン参加ステータス（参加または不参加）と障害の原因（不明、サーバ到達不能、または無効な権限）が返されます（該当する場合）。 例: |
show webvpn kcd |
KCD のデバッグ
次のコマンドは、KCD 固有のデバッグ メッセージの出力を制御するために使用します。バージョン 9.5.2 よりも前で行われていたように、ADI の syslog 発行レベルを制御するためではありません。
debug webvpn kcd
キャッシュされた Kerberos チケットの表示
ASA にキャッシュされているすべての Kerberos チケットを表示するには、次のコマンドを入力します。
show aaa kerberos[username user | host ip | hostname]
例
ASA# show aaa kerberos
Default Principal Valid Starting Expires Service Principal
asa@example.COM 06/29/10 18:33:00 06/30/10 18:33:00 krbtgt/example.COM@example.COM
kcduser@example.COM 06/29/10 17:33:00 06/30/10 17:33:00 asa$/example.COM@example.COM
kcduser@example.COM 06/29/10 17:33:00 06/30/10 17:33:00 http/owa.example.com@example.COM
ASA# show aaa kerberos username kcduser
Default Principal Valid Starting Expires Service Principal
kcduser@example.COM 06/29/10 17:33:00 06/30/10 17:33:00 asa$/example.COM@example.COM
kcduser@example.COM 06/29/10 17:33:00 06/30/10 17:33:00 http/owa.example.com@example.COM
ASA# show aaa kerberos host owa.example.com
Default Principal Valid Starting Expires Service Principal
kcduser@example.COM 06/29/10 06/30/10 17:33:00
キャッシュされた Kerberos チケットのクリア
ASA のすべての Kerberos チケット情報をクリアするには、次のコマンドを入力します。
clear aaa kerberos [ username user | host ip | hostname]
-
user：特定のユーザの Kerberos チケットのクリアに使用します。
-
hostname：特定のホストの Kerberos チケットのクリアに使用します。
Microsoft Kerberos の要件
kcd-server コマンドを機能させるために、ASA はソース ドメイン（ASA が常駐するドメイン）とターゲットまたはリソース ドメイン（Web サービスが常駐するドメイン）間の信頼関係を確立する必要があります。サービスにアクセスするリモート アクセス ユーザの代わりに、ASA は独自のフォーマットを使用して、ソース ドメインから宛先ドメインへの認証パスを横断し、必要なチケットを取得します。
このように認証パスを越えることは、クロスレルム認証と呼ばれます。クロスレルム認証の各フェーズにおいて、ASA は特定のドメインのクレデンシャルおよび後続ドメインとの信頼関係に依存しています。
フィードバック