Cisco NAC アプライアンス Clean Access Server コンフィギュレーション ガイド リリース 4.9
Active Directory シングル サインオン(AD SSO)の設定
Active Directory シングル サインオン(AD SSO)の設定
発行日;2012/05/08 | 英語版ドキュメント(2012/04/25 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

Active Directory シングル サインオン(AD SSO)の設定

概要

AD SSO に対する Cisco NAC アプライアンス Agent と AD サーバの互換性

Windows SSO プロセス(Kerberos チケット交換)

CAS と AD サーバの通信

AD SSO の設定手順の概要

設定要件

設定手順の概要

AD SSO 認証サーバの追加

Unauthenticated ロールのためのトラフィック ポリシーの設定

AD SSO の実装をサポートする TCP ポートと UDP ポート

AD サーバのポリシーの追加

CAS での AD SSO の設定

AD SSO に対する AD サーバでの CAS ユーザの設定

CAS ユーザの作成

KTPass のインストールおよび実行

AD SSO の展開をサポートする正しいバージョンの ktpass.exe のインストール

ktpass.exe コマンドの実行

KTPass を使用しない AD SSO の設定

Windows 7 クライアント環境での AD SSO の設定

既存の AD サーバでの追加アルゴリズムのイネーブル化

各 Windows 7 クライアント マシンでの手動による DES のイネーブル化

FIPS 140-2 準拠の AD SSO に対する Active Directory の設定

前提条件

FIPS 140-2 準拠の Windows 環境の設定

ユーザ プロファイルの設定

AD(Kerberos)を使用した Agent ベース Windows SSO のイネーブル化

アクティブな AD SSO サービスの確認

GPO 更新のイネーブル化

ログイン スクリプトのイネーブル化(任意)

スクリプト使用を許可するための遅延の導入

ネットワークベースのスクリプトを IP アドレス変更ありのアウトオブバンド モードで使用

参照スクリプト

Delete コマンド付きの遅延スクリプト

AD SSO の LDAP ルックアップ サーバの追加(任意)

LDAP ルックアップ サーバの設定

LDAP ルックアップを使用した Cross-Forest グループ マッピング

トラブルシューティング

一般

KTPass コマンド

CAS で AD SSO サービスを開始できない

AD SSO サービスは開始するが、クライアントで SSO が実行されない

Kerbtray

CAS ログ ファイル

「Integrity check on decrypted field failed」エラー

Active Directory シングル サインオン(AD SSO)の設定

この章では、Cisco NAC アプライアンスでの Active Directory(AD)Single Sign-On(SSO; シングル サインオン)の設定方法について説明します。

次の内容について説明します。

「概要」

「AD SSO の設定手順の概要」

「AD SSO 認証サーバの追加」

「Unauthenticated ロールのためのトラフィック ポリシーの設定」

「CAS での AD SSO の設定」

「AD SSO に対する AD サーバでの CAS ユーザの設定」

「Windows 7 クライアント環境での AD SSO の設定」

「FIPS 140-2 準拠の AD SSO に対する Active Directory の設定」

「AD(Kerberos)を使用した Agent ベース Windows SSO のイネーブル化」

「アクティブな AD SSO サービスの確認」

「GPO 更新のイネーブル化」

「ログイン スクリプトのイネーブル化(任意)」

「AD SSO の LDAP ルックアップ サーバの追加(任意)」

「トラブルシューティング」

概要

すでに Windows ドメインにログインしている Agent ユーザを自動的に認証するよう Cisco NAC アプライアンスを設定できます。AD SSO を使用すると、Windows システムで AD にログインしているユーザに対して、Agent からログインすることなく、自動的に認証とポスチャ評価が行われます。


) AD SSO から Cisco NAC アプライアンスにログインするユーザは、FIPS 140-2 に準拠するために、Windows Vista または Windows 7 を実行していて、最新の Cisco NAC Agent(バージョン 4.7.1.15、4.8.0.32、または4.9.0.33)をクライアント マシンにインストールしている必要があります。Windows XP クライアントで AD SSO を実行した場合、FIPS 140-2 準拠要件を満たしません。



) Cisco NAC Web Agent は AD SSO 機能をサポートしていません。


AD SSO に対する Cisco NAC アプライアンス Agent と AD サーバの互換性

Cisco NAC アプライアンスでは、Windows 7/Vista/XP クライアント マシンについては SSO を、Windows 2000/2003/2008 サーバについては AD をサポートしています。互換性の詳細については、『 Support Information for Cisco NAC Appliance Agents, Release 4.5 and Later 』を参照してください。


) すべての導入タイプ(L2 および L3、インバンドおよびアウトオブバンド)について AD SSO を設定できます。OOB の場合、クライアント ポートは、Windows ドメイン認証の前に、認証 VLAN に設定されます。


AD SSO では、Cisco NAC アプライアンスは、ユーザを Kerboros によって 認証 しますが、 許可 は LDAP によって行います。Cisco NAC アプライアンスは、クライアント マシン ログインのキャッシュ済みクレデンシャルまたは Kerberos チケットを利用し、バックエンド Windows 2000/2003/2008 サーバの AD によってユーザ認証を行います。ユーザ認証の完了後、LDAP を使用して AD 内の個別のルックアップとして、許可(ロールのマッピング)が行われます。

CAM の Auth Test 機能を使用して、Cisco NAC アプライアンスにおける AD SSO の認証をテストすることもできます。詳細については、『 Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9 』の「Auth Test」を参照してください。


) LDAP ユーザ アカウントは、属性を探すための「Search DN/Password」を提供できるだけの権限を持っている必要があります。


Windows SSO プロセス(Kerberos チケット交換)

Windows SSO は、バックエンド Kerberos Domain Controller(Active Directory サーバ)で認証済みのユーザを自動的に認証する、Cisco NAC アプライアンスの機能です。図 8-1 に、Kerberos チケット交換の一般的なプロセスを示します。


) AD SSO は、CAS および Cisco NAC Agent が 16 kB より大きい Kerberos チケットを AD ドメインと交換する場合に、Cisco NAC アプライアンスで停止します。


図 8-1 Kerberos チケット交換の一般的なプロセス

 

CAS で AD SSO が設定されている場合、図 8-1に示す「ネットワーク サービス」コンポーネントが置き換えられます。一般的な手順は次のとおりです。

Windows ユーザと CAS の両方が AD サーバ上にアカウントを持っています。

ユーザが Windows AD にログイン(またはキャッシュ済みのクレデンシャルを使用)します。

クレデンシャルが AD に送信されます。AD が認証を行い、ユーザに Ticket Granting Ticket(TGT; チケット認可チケット)を付与します。

クライアント マシンの NAC Agent が、NAC Agent と CAS との通信を可能にするよう、Windows ユーザに、AD からの Kerberos Service Ticket(ST; サービス チケット)があるか問い合わせます。

クライアントが、AD に ST を要求します。

AD は新しい ST をクライアントに送信し、クライアントはこの ST を NAC Agent に提供します。

NAC Agent は、この ST を、認証プロセスの一部として CAS に提示し、CAS との通信を確立します。

CAS はパケットを返送し、クライアントを AD SSO プロセスの一部として相互認証します。

CAS がこの情報を使用してクライアントを Cisco NAC アプライアンスに登録し、SSO 認証が行われます。

その他のユーザ ロールをマッピングするため(認証とポスチャ評価のため)、LDAP ルックアップ サーバに属性マッピングを設定することができます。


) Cisco NAC Appliance Release 4.5(1) から、CAS からの応答を監視するデフォルトのタイムアウト設定が 60 秒に変更されました。これは、Cisco NAC アプライアンス システムに返送されるまでの応答に時間がかかった場合の AD SSO の動作に影響を与えることがあります(たとえば、AD SSO プロセスが完了するまでに 2 分かかった場合、60 秒のタイムアウトが経過すると、CAM は、AD ドメインと通信する CAS から来るべき応答がないと見なしてタイムアウトし、自動的に次の CAS に移ります。2 分間で AD SSO プロセスが完了した後で CAS を確認すると、サービスが実際に動作していることがわかります。)信頼性の高い AD SSO 動作を確実に行えるようにするには、ネットワーク DNS サーバが機能しており、Active Directory サーバとともにアクセスできることを確認することもお勧めします。


CAS と AD サーバの通信

図 8-2 に、CAS で AD SSO のために AD サーバと通信するための一般的なセットアップ例を示します。

CAS は、root ドメインの AD サーバへのユーザ ログイン トラフィックだけを読み取ります。図 8-2 に示すように、sales ドメイン(sales-name-domain.cisco.com)と engineering ドメイン(cca-eng-name.domain.cisco.com)は、別の CAS によって設定されています。cca-eng ドメインを例に取ると、CAS ユーザは、cca-eng-test.cca-eng-domain.cisco.com AD サーバでの作成および設定だけが必要です。

cca-eng-domain.cisco.com のユーザは、ドメイン内のどの AD サーバにもログインできます。また、KTPass コマンド(「AD SSO に対する AD サーバでの CAS ユーザの設定」を参照)は、cca-eng-test.cca-eng-domain.cisco.com サーバ上でだけ実行する必要があります。

図 8-2 AD サーバでの CAS ユーザ アカウントの設定

 

AD SSO の設定手順の概要

管理者は、AD SSO の設定を行うにあたって、事前に AD サーバのネットワーク構成を十分理解しておく必要があります。

設定要件

AD SSO を設定するには、以下の項目が必要になります。

FIPS 140-2 に準拠し、AD SSO をサポートできるよう、KTPass のバージョン 6.0.6001.18000 の Windows Server 2008 Enterprise SP1(32 ビット)を使用する 必要があり ます。また、クライアント マシンは Cisco NAC Agent のバージョン 4.7.1.15、4.8.0.32、または 4.9.0.33 がインストールされた Windows Vista または Windows 7 を実行している必要があります。

設定する AD サーバ(ドメイン コントローラ)の数。通常、CAS は 1 台の AD サーバに対応しますが、CAS を AD ドメイン全体に関連付けることもできます。

AD サーバのための Windows 2000 または Windows 2003 サーバ用インストレーション CD。これは、KTPass コマンドにサポート ツールをインストールするために必要です。KTPass コマンドは、CAS がログインする AD サーバ(ドメイン コントローラ)でだけ実行する必要があります。

適切なバージョンの ktpass.exe がインストールされていること(Cisco NAC アプライアンスと AD SSO の展開をサポートする KTPass の正しいバージョンを確認するには、『 Support Information for Cisco NAC Appliance Agents, Release 4.5 and Later 』を参照してください)。

各 AD サーバの IP アドレス(Unauthenticated ロールのトラフィック ポリシーを設定するため)。そのドメインを管理するすべての AD サーバについて、CAS のトラフィックを許可する必要があります。たとえば、ユーザがドメイン内の複数の AD サーバにログインできる場合、Unauthenticated ロールのために、複数のすべての AD サーバへのトラフィックを許可する必要があります。


) OOB 配置では、ワークステーションにより「最も近い AD サーバ」を見つけるために ICMP(ping)が使用され、認証 VLAN の場合はサイトで参照されているすべての AD サーバとサービスで成功し、サイトとサービスがまだ設定されていない場合はすべての AD サーバで成功することが必要です


CAS と単一 AD サーバとの間の接続をセットアップする場合、(CAS 設定のために)CAS がログインする AD サーバの FQDN。

CAS 上で AD サーバの FQDN を解決するために CAS で正しく設定されている([Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Network] > [DNS])DNS サーバ設定。

CAM、CAS、AD サーバの日付と時刻が、それぞれ 5 分以内で同期化されていること。AD サーバと CAS の時刻は、300 秒クロック スキュー以内で同期させる必要があります(Kerberos は時間的要素が重要)。

Kerberos フォーマットの Active Directory ドメイン名(Windows 2000 以上)。これは、AD サーバの CAS 設定と CLI 設定の両方に必要です。


) KTPass コマンドのホスト主要名(<AD_DomainServer>)が、AD サーバの [Full computer name]([Control Panel] > [System] > [Computer Name] | [Full computer name])と完全に一致する必要があります。詳細は「ktpass.exe コマンドの実行」を参照してください。


クライアント システムに Agent がインストールされていること。Agent の配布とインストールの詳細については、『 Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9 』の「Distributing the Agent」の章を参照してください。

設定手順の概要


ステップ 1 「AD SSO 認証サーバの追加」

CAM では、AD SSO の新しい認証サーバを追加し、ユーザのためのデフォルト ロールを指定します。

ステップ 2 「Unauthenticated ロールのためのトラフィック ポリシーの設定」

クライアント認証トラフィックを CAS と AD サーバとの間で通過させるため、CAS のポートをオープンします。

ステップ 3 「CAS での AD SSO の設定」

CAS 管理ページから、AD サーバ設定、CAS ユーザ アカウント設定、ユーザのドメインに対応する CAS の認証サーバ設定を設定します。

ステップ 4 「AD SSO に対する AD サーバでの CAS ユーザの設定」

CAS が通信する Windows 2000/2003/2008 AD サーバで CAS アカウントを追加し、CAS の Linux オペレーティング システムをサポートするための暗号化パラメータを設定します。

ステップ 5 「AD(Kerberos)を使用した Agent ベース Windows SSO のイネーブル化」

ステップ 6 「アクティブな AD SSO サービスの確認」

ステップ 7 「GPO 更新のイネーブル化」

ステップ 8 「ログイン スクリプトのイネーブル化(任意)」

ステップ 9 「AD SSO の LDAP ルックアップ サーバの追加(任意)」

任意で、認証後にユーザを複数のロールにマッピングするための LDAP ルックアップ サーバを設定します。

ステップ 10 必要に応じて、「トラブルシューティング」を参照してください。


 

AD SSO 認証サーバの追加

CAM で AD SSO 認証サーバを作成し、AD サーバをユーザ用のデフォルト ロールとセカンダリ LDAP ルックアップ サーバ(設定されている場合)にマッピングするための手順は、次のとおりです。


ステップ 1 [User Management] > [Auth Servers] > [New] の順番に進みます。

ステップ 2 [Authentication Type] ドロップダウン メニューで、[Active Directory SSO] を選択します。

図 8-3 Active Directory SSO

 

ステップ 3 ドロップダウン メニューで [Default Role] を選択します。ユーザをロールにマッピングするためにそれ以外のルックアップが必要でない場合、AD SSO で認証を行っているすべてのユーザはデフォルト ロールに割り当てられます。ポスチャ評価と Nessus スキャンをこのロールに対して設定する必要があります。

ステップ 4 認証プロバイダーのリストで AD SSO 認証サーバを示す [Provider Name] を入力します。プロバイダー名には、スペースや特殊文字を使用しないでください。

ステップ 5 ユーザをデフォルト ロールに割り当てる予定で、ルックアップの追加が不要な場合、[LDAP Lookup Server] ドロップダウン メニューをデフォルトの [NONE] 設定のままにすることができます。Windows ドメインの SSO ユーザを複数のロールにマッピングする場合、LDAP ルックアップ サーバを使用して(設定方法は、「AD SSO の LDAP ルックアップ サーバの追加(任意)」を参照)CAM で第 2 レベルのルックアップを実行する必要があります。この場合、[LDAP Lookup Server] ドロップダウンから、設定済みの LDAP ルックアップ サーバを選択してください。

ステップ 6 [Add Server] をクリックします。


) AD SSO ユーザの場合、[Online Users] および [Certified Devices] ページの [Provider] フィールドに [AD_SSO] と表示され、[User/User Name] フィールドにユーザ名とユーザのドメイン(例:user1@domain.name.com)が表示されます。



) [Auth Test] 機能は、SSO 認証プロバイダー(AD SSO、VPN SSO など)をテストするのには使用できません。



 

Unauthenticated ロールのためのトラフィック ポリシーの設定

Windows マシンにログインするドメイン内のユーザは、Kerberos チケット交換の最初の処理を実行するために、root ドメイン コントローラにクレデンシャルを送信します(図 8-1 を参照)。マシンがサービス チケットを受信すると、Agent はこれを使用して、CAS によってクライアント認証を有効化します。CAS が認証を有効化するときだけ、ユーザのネットワーク アクセスが許可され、Agent によるユーザ ログインを別途行う必要はありません。

図 8-2 に示すように、CAS は、AD サーバへの認証時に、ユーザ マシンのログイン クレデンシャルを読み込むよう設定されています。認証トラフィックを CAS と AD サーバとの間で通過させるため、CAS のポートをオープンする必要があります。管理者は AD サーバで使用するポートに応じて、TCP ポートまたは UDP ポートをオープンすることができます。


) AD SSO トラフィックに断片化されたパケットが含まれている可能性がある場合、『Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9』の「Add IP-Based Policy」のガイドラインに従って、[IP FRAGMENT] オプションをイネーブルにする必要がある場合があります。


AD サーバの信頼できる側の IP アドレスでこれらのポートを許可するため、Unauthenticated ロールのトラフィック ポリシーを設定します。これにより、クライアントが AD サーバに認証され、GPO とスクリプトが実行可能になります。シスコでは、AD サーバと DMZ AD サーバに Cisco Security Agent(CSA)をインストールすることを推奨しています。

AD SSO の実装をサポートする TCP ポートと UDP ポート

次のリストは、AD SSO を Cisco NAC アプライアンス ネットワークで実装するときにオープンすべきポートの初期リストです。このリストに含まれていない AD サービスをサポートするためには、他のポートのオープンも必要になります。

 

表 8-1 AD SSO をサポートするために推奨されるポート

アクション
プロトコル
信頼できない
信頼できる
目的または説明
推奨される TCP ポート

許可

TCP

*:*

IP アドレス DC ポート 88

Kerberos

許可

TCP

*:*

IP アドレス DC ポート 135

EpMap

許可

TCP

*:*

IP アドレス DC ポート 139

Netbios-ssn

許可

TCP

*:*

IP アドレス DC ポート 3891

LDAP

許可

TCP

*:*

IP アドレス DC ポート 445

MS-DC/SMB

許可

TCP

*:*

IP アドレス DC ポート 636

SSL を使用した LDAP

許可

TCP

*:*

IP アドレス DC ポート 1025

MS-AD

許可

TCP

*:*

IP アドレス DC ポート 1026

MS-AD

推奨される UDP ポート

許可

UDP

*:*

IP アドレス DC ポート 88

Kerberos

許可

UDP

*:*

IP アドレス DC ポート 123

NTP

許可

UDP

*:*

IP アドレス DC ポート 137

Netbios-ns

許可

UDP

*:*

IP アドレス DC ポート 389

LDAP

許可

UDP

*:*

IP アドレス DC ポート 636

SSL を使用した LDAP

その他のポート

許可

ICMP 要求

*:*

IP アドレス DC

ping

許可

IP フラグメント

*:*

IP アドレス DC

IP パケット フラグメント

1.LDAP を使用して AD サーバに接続する場合は、デフォルト ポート 389 ではなく、TCP/UDP ポート 3268(デフォルトの Microsoft グローバル カタログ ポート)を使用することをお勧めします。これにより、単一ドメイン環境と複数ドメイン環境の両方で、すべてのディレクトリ パーティションのより効率的な検索が可能になります。


) 一般に、LDAP プロトコルは TCP または UDP ポート 389 でトラフィックを送信するときにプレーン テキストを使用します。LDAP 通信で暗号化が必要な場合は、代わりに、TCP/UDP ポート 636(SSL 暗号化を使用した LDAP)を使用してください。

LDAP を使用して AD サーバに接続する場合は、デフォルト ポート 389 ではなく、TCP/UDP ポート 3268(デフォルトの Microsoft グローバル カタログ ポート)を使用することをお勧めします。これにより、単一ドメイン環境と複数ドメイン環境の両方で、すべてのディレクトリ パーティションのより効率的な検索が可能になります。


AD サーバのポリシーの追加

AD サーバにポリシーを追加する手順は、次のとおりです。


ステップ 1 [User Management] > [User Roles] > [List of Roles] > [Policies [Unauthenticated Role]] の順番に進みます。Unauthenticated ロール用の IP トラフィック ポリシー フォームが表示されます。

ステップ 2 方向ドロップダウンが [Untrusted ->Trusted] に設定されている状態で、[Add Policy] リンクをクリックします。[Add Policy] フォーム(図 8-4)が表示されます。

図 8-4 AD サーバへの CAS のためのトラフィック ポリシーの設定

 

ステップ 3 次のフィールドは、デフォルトのままにします。

[Action]:Allow

[State]:Enabled

[Category]:IP

[Protocol]:TCP 6

[Untrusted (IP/Mask:Port)]:* / * / *

ステップ 4 [Trusted (IP/Mask:Port)] に、次のように入力します。

AD サーバの IP アドレス

サブネット マスクとして 255.255.255.255(AD サーバの場合のみ)

ポート(複数のポート番号をカンマで区切る)

例: 10.201.152.12 / 255.255.255.255 / 88,135,1025,1026,3268


) LDAP を使用して AD サーバに接続する場合は、デフォルト ポート 389 ではなく、TCP/UDP ポート 3268(デフォルトの Microsoft グローバル カタログ ポート)を使用することをお勧めします。これにより、単一ドメイン環境と複数ドメイン環境の両方で、すべてのディレクトリ パーティションのより効率的な検索が可能になります。


ステップ 5 (任意)[Description] に説明を入力します。

ステップ 6 [Add Policy] をクリックします。


) テストを行う場合、まず AD サーバおよび DC への完全なアクセスを行い、AD SSO が動作してから上記のようにポートを制限することを推奨します。クライアント PC にログインするときは、(ローカル アカウントではなく)Windows ドメイン クレデンシャルを使用してドメインにログインするようにしてください。



 

CAS での AD SSO の設定

ユーザのドメインに合わせて CAS を設定する手順は、次のとおりです。


ステップ 1 [Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Authentication] > [Windows Auth] > [Active Directory SSO] の順番に進みます。

図 8-5 Active Directory SSO

 

ステップ 2 [Enable Agent-Based Windows Single Sign-On with Active Directory (Kerberos)] のチェックボックスはまだオンにしないでください。このサービスのイネーブル化は、「AD SSO に対する AD サーバでの CAS ユーザの設定」が完了したあとに行います。このページの別のフィールドについては、設定して、以下のように [Update] をクリックすることができます。


) AD サーバの設定が完了するまでは、次のメッセージが表示されます。
「Error: Could not start the SSO service.」Please check the configuration.


ステップ 3 [Account for CAS on] では、CAS アカウントを [Single Active Directory Server] に作成するか、[Domain (All Active Directory Servers)] 内の複数のサーバに作成するかを指定します。


) [Active Directory Server (FQDN)] フィールドに入力した名前が、DNS により CAS で解決できるようにしてください。CAS で AD サーバの FQDN を解決できるよう、[CAS(Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Network > DNS])で DNS サーバを正しく設定する必要があります。


a. CAS アカウントを [Single Active Directory Server] に作成するよう指定する場合、AD サーバの完全修飾ドメイン名を [Active Directory Server (FQDN)] フィールドに入力します(例: cca-eng-test.cca-eng-domain.cisco.com 。このフィールドには IP アドレスは入力できません。AD サーバの [Control Panel] > [System] > [Computer Name] | [Full computer name] に表示される AD サーバの名前と完全に一致しなければなりません(図 8-7 を参照)。

図 8-6 AD SSO - Single Active Directory Server

 

図 8-7 [Control Panel] > [System] > [Computer Name] | [Full computer name]

 

b. [Domain (All Active Directory Servers)] オプションを選択した場合、[Active Directory Server (FQDN)] フィールドは非表示になります(図 8-8)。DNS は、プライマリ ドメイン コントローラに指定された AD ドメインを自動的に解決します。プライマリ ドメイン コントローラにアクセスできなくなった場合、セカンダリ ドメイン コントローラにアクセスします。この場合、ドメインだけを指定し、AD サーバの完全な FQDN は指定しないようにします。KTPass コマンドの構文も、[Single Active Directory Server] オプションを指定したか [Domain (All Active Directory Servers)] オプションを指定したかによって変わります。詳細については、「ktpass.exe コマンドの実行」を参照してください。

図 8-8 AD SSO - Domain(All Active Directory Servers)

 

ステップ 4 [Active Directory Domain] に、KDC/AD サーバのドメイン名を 大文字で 入力します(図 8-7 を参照)。[Active Directory Domain] は、「Kerberos Realm」と同じです。例:

CCA-ENG-DOMAIN.CISCO.COM
 

ステップ 5 [Account Name for CAS] に、AD サーバに作成した Clean Access Server ユーザ名を入力します(例: casuser )。
CAS ユーザ アカウントを使用して、CAS で AD サーバにログインできます。

ステップ 6 [Account Password for CAS] に、AD サーバの CAS ユーザのパスワードを入力します。


) パスワードでは大文字と小文字が区別されます。CAS 側では、文字数に制限はなく、標準文字が使用できます。このパスワードは、KTPass コマンドを使用して作成されたマッピングの基礎となるため、Windows サーバ側の制約事項(パスワード ポリシーなど)に従ってください。


ステップ 7 [Active Directory SSO Auth Server] ドロップダウンで、CAM で設定した AD SSO サーバを選択します。このフィールドでは、CAM で作成された認証プロバイダーを CAS にマッピングします(デフォルト ロール、設定されている場合はセカンダリ LDAP ルックアップ サーバと一緒に)。

ステップ 8 [Update] をクリックします。


) CAS の起動時に、CAS から AD サーバに到達できない場合、AD SSO サービスは開始されません。この場合、[Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Authentication] > [Windows Auth] > [Active Directory SSO] の順番に進み、[Update] ボタンをクリックして AD SSO サービスを再起動する必要があります。



 

AD SSO に対する AD サーバでの CAS ユーザの設定

AD SSO を、KTPass を実行して設定するか、実行しないで設定するかを選択できます。どちらの場合も、次のセクションに従って CAS ユーザを作成し、暗号化を設定する必要があります。

「CAS ユーザの作成」

次のいずれかを使用して暗号化を指定します。

「KTPass のインストールおよび実行」

「KTPass を使用しない AD SSO の設定」

CAS ユーザの作成

CAS ユーザを作成する手順は、次のとおりです。


ステップ 1 AD サーバマシンに、管理者としてログインします。

ステップ 2 [All Programs] > [Admin Tools] > [Active Directory Users and Computers] の順番に進み、Active Directory 管理コンソールを開きます。

ステップ 3 [Active Directory Users and Computers] ウィンドウの左側のペインで、CAS を設定するドメインにナビゲートします(例: cca-eng-domain.cisco.com

図 8-9 AD サーバでの新規ユーザの作成

 

ステップ 4 [Users] フォルダを右クリックします。表示されるメニューで、[New] > [User] を選択します(図 8-9)。

ステップ 5 最初の [New Object - User] ダイアログで(図 8-10)、次のように CAS ユーザ用のフィールドを設定します。

[First name] フィールドに、CAS で使用する名前を入力します(例: casuser )。入力すると、自動的に [Full name] フィールドと [User logon name] フィールドに読み込まれます。[User logon name] は、1 つの単語でなければなりません。ユーザ アカウントの場合、First name = Full name = User name となるようにしてください。

図 8-10 CAS ユーザの設定

 

ステップ 6 [Next] をクリックします。2 番めの [New Object - User] ダイアログが表示されます。

ステップ 7 2 番めの [New Object - User] ダイアログで(図 8-11)、次のように設定します。

[Password] および [Confirm Password] フィールドに、それぞれ CAS ユーザのパスワードを入力します。

[Password never expires] オプションにチェックが付いていることを確認します。

[User must check password at next login] オプションにチェックが付いていないことを確認します。

図 8-11 CAS ユーザのパスワードの設定

 

ステップ 8 [Next] をクリックします。[New Object - User] の確認ダイアログが表示されます(図 8-12)。

図 8-12 CAS ユーザ プロパティの確認

 

ステップ 9 CAS ユーザのプロパティを確認し、[Finish] をクリックして終了します。または、修正する必要がある場合、[Back] をクリックします。

ステップ 10 CAS ユーザが AD ドメインに追加されました(図 8-13)。

図 8-13 追加された CAS ユーザ

 


 

KTPass のインストールおよび実行

ここでは、次の 2 つの手順を説明します。

「AD SSO の展開をサポートする正しいバージョンの ktpass.exe のインストール」

「ktpass.exe コマンドの実行」

AD SSO の展開をサポートする正しいバージョンの ktpass.exe のインストール

ktpass.exe ツールは、Windows 2000/2003/2008 Server サポート ツールとして、Microsoft サポート サイト( http://support.microsoft.com/ )から入手できます。KTPass の実行ファイルは、デフォルトでは Windows Server 2000/2003 にインストールされません。したがって、Windows Server 2000/2003 環境で設定している場合、インストールの前に Microsoft Support サイトから実行ファイルを取得する必要があります。Cisco NAC アプライアンスと AD SSO の展開をサポートする ktpass.exe の正しいバージョンを確認するには、『 Support Information for Cisco NAC Appliance Agents, Release 4.5 and Later 』を参照してください。


) KTPass が正しく動作するよう、『Support Information for Cisco NAC Appliance Agents, Release 4.5 and Later』の AD SSO のサポートに関する表に従い、正しいバージョンの ktpass.exe を取得し、インストールしてください。
Windows Server 2008 では KTPass バージョン 6.0.6001.18000 を使用する必要があります。クライアント マシンでは、FIPS 140-2 に準拠し、AD SSO をサポートできるようにするため、Windows Vista または Windows 7 を実行し、適切なバージョンの Cisco NAC Agent をインストールする必要があります。


Windows 7 クライアント認証における AD SSO をイネーブルにするため、シスコでは次のバージョンの Windows AD Server と KTPass をテストしました。

 

表 8-2 Windows 7 クライアントに対する Windows AD Server と KTPass のバージョンの互換性

Windows AD Server のバージョン
KTPass のバージョン

Windows 2008 Server SP22 3

6.0.6002.18005

Windows 2008 Server R22

6.1.7600.16385

Windows 2008 Server Enterprise SP14

6.0.6001.18000

Windows 2003 Server

5.2.3790.1830

2.Window Server 2008 SP2 サーバでは、KTPass を実行する前に Windows Update を実行する必要があります。Windows ホットフィックス KB951191 がインストールされていることを確認してください。この Windows Update が実行されていないと、CAS の AD SSO サービスは起動しないことがあります。これは Windows 2008 SP2 に使用される KTPass バージョン(6.0.6002.18005)に適用されます。Windows 2008 R2 Enterprise に使用されるバージョンは 6.1.7600.16385 です。

3.AD システムが Windows Server 2003 からのアップグレードに基づいている場合、Cisco NAC アプライアンスを Windows 7 で SSO モードで動作させるため、ドメインの機能を Windows Server 2008 レベルに上げる必要があります。レベルを上げないと Cisco NAC アプライアンス ネットワークに自動でログインできません。

4.2003 の機能レベルで実行するサーバ。

ktpass.exe ツールをインストールする手順は、次のとおりです。


ステップ 1 Web ブラウザを開き、 http://support.microsoft.com/ を表示します。

ステップ 2 Microsoft 社の Web サイトの Windows Server 2000/2003/2008 サポート ツールのセクションを探します。

図 8-14 Windows 2003 Server のサポート ツール

 

ステップ 3 [Download] ボタンをクリックします。

ステップ 4 次のいずれかを実行します。

[Save] をクリックして、Windows Server 2000/2003/2008 サポート ツールの自己解凍実行ファイルをローカル マシンに保存します。

[Run] をクリックして、Windows Server 2000/2003/2008 サポート ツールのローカル マシンへのインストールを開始します。

自己解凍ファイルを起動するか [Run] をクリックすると、 Windows Support Tools Setup Wizard が自動的に起動します。

図 8-15 Windows Server 2003 サポート ツールのインストール

 

ステップ 5 インストールが完了したら、Windows エクスプローラを開いて C:¥Program Files¥Support Tools ディレクトリ(またはセットアップ ウィザード セッションで指定した別のディレクトリ)に移動し、 ktpass.exe コンポーネントがファイル リストに表示されることを確認します(図 8-16を参照)。

図 8-16 サポート ツール:ktpass.exe

 

ステップ 6 次の「 ktpass.exe コマンドの実行」の指示に従い、 ktpass.exe コマンドを実行します。


ktpass.exe コマンドを Windows エクスプローラでダブルクリックしないでください。このコマンドは、コマンド ツールから実行する必要があります。



 

ktpass.exe コマンドの実行

ここでは、SSO を実行するWindows 7 以外のクライアント マシンで KTPass 実行ファイルを実行する方法について説明します。Windows 7 クライアント マシン用の環境を設定している場合は、「Windows 7 クライアント環境での AD SSO の設定」を参照してください。

CAS が単一の AD サーバと通信するよう設定されている場合、CAS 内で設定した AD サーバ上で KTPass コマンドを実行する必要もあります。

CAS を AD ドメイン全体と関連付ける場合、AD ドメイン内の任意の単一 AD サーバ(すべての AD サーバではなく)上で KTPass コマンドを実行する必要があります。KTPass コマンド オペレーションの情報は、自動的に AD ドメインの他のメンバーに伝播されます。

サポートされている Windows サーバのバージョンの一覧については、『 Support Information for Cisco NAC Appliance Agents, Release 4.5 and Later 』を参照してください。


ktpass.exe の実行時は、以下の大文字と小文字の入力規則に従う必要があります。

コマンドの「/」と「@」の間に入力されたコンピュータ名(例:「AD_DomainServer」)が、AD サーバの [Control Panel] > [System] > [Computer Name] | [Full computer name] に表示される AD サーバの名前と完全に一致しなければなりません。

「@」の後に入力されたレルム名(例:「AD_DOMAIN」)は、必ず 大文字 でなければなりません。AD サーバの [Control Panel] > [System] > [Computer Name] | [Domain] で表示されるドメイン名は、KTPass コマンドに入力する場合、大文字に変換する必要があります。(図 8-19を参照)。

ktpass.exe の実行後に警告が表示されないことを確認してください。

コマンドの実行後に、次の出力が表示されなければなりません。
Account <CAS user> has been set for DES-only encryption


 

Windows 7 クライアント マシン以外で ktpass.exe を実行するには、次の手順を行います。


ステップ 1 コマンド プロンプトを開き、C:¥Program Files¥Support Tools¥ に移動します。このフォルダに ktpass.exe コマンドがあることを確認します。

ステップ 2 次のいずれかのコマンドを入力します。

Active Directory ドメインが 1 台のサーバだけで構成されている場合

ktpass -princ <CAS_username> / <AD_DomainServer> . <AD_Domain> @ <AD_DOMAIN> -mapuser <CAS_username> -pass <CAS_password> -out c:¥ <CAS_username> .keytab -ptype KRB5_NT_PRINCIPAL +DesOnly

「CAS での AD SSO の設定」で [Account for CAS on Single Active Directory Server] オプションを指定する場合、このコマンド構文を使用します。

次の例を参考にしてください(図 8-17 も参照)。

C:¥Program Files¥Support Tools> ktpass -princ casuser/cca-eng-test.cca-eng-domain.cisco.com@CCA-ENG-DOMAIN.CISCO.COM -mapuser casuser -pass Cisco123 -out c:¥casuser.keytab -ptype KRB5_NT_PRINCIPAL +DesOnly

Active Directory ドメインが複数台のサーバで構成されている場合

新しいサーバをすでに存在する複数台のサーバのドメインに追加するときには、ktpass コマンドを再度実行する必要はありません。これには、2008 サーバを既存の 2003 ドメイン機能レベルで実行している複数台のサーバのドメインに追加する場合も含まれます。

ktpass -princ <CAS_username> / <AD_Domain> @ <AD_DOMAIN> -mapuser <CAS_username> -pass <CAS_password> -out c:¥ <CAS_username> .keytab -ptype KRB5_NT_PRINCIPAL +DesOnly

「CAS での AD SSO の設定」 [Account for CAS on Domain (All Active Directory Servers)] オプションを指定する場合、このコマンド構文を使用します。

次の例を参考にしてください(図 8-17 も参照)。

C:¥Program Files¥Support Tools> ktpass -princ casuser/cca-eng-domain.cisco.com@CCA-ENG-DOMAIN.CISCO.COM -mapuser casuser -pass Cisco123 -out c:¥casuser.keytab -ptype KRB5_NT_PRINCIPAL +DesOnly
 

コマンドの出力は、次のようになります(図 8-18 も参照)。

Targeting domain controller: cca-eng-test.cca-eng-domain.cisco.com
Successfully mapped casuser/cca-eng-test.cca-eng-domain.cisco.com to casuser.
Key created.
Output keytab to c:¥casuser.keytab:
Keytab version: 0x502
keysize 97 casuser/cca-eng-test.cca-eng-domain.cisco.com@CCA-ENG-DOMAIN.CISCO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0xbc5120bcfeda01f8)
Account casuser has been set for DES-only encryption.

) 「Successfully mapped casuser/cca-eng-test.cca-eng-domain.cisco.com to casuser」という応答表示で、casuser アカウントのマッピングが正しく行われたことを確認します。

上記の例では、Service Principal Name(SPN)である casuser/cca-eng-domain.cisco.com@CCA-ENG-DOMAIN.CISCO.COM は、管理ドメイン内の AD サーバが CAS から渡されたユーザ クレデンシャルを適切に解決できることを保証するうえでのキーとなります。


ステップ 3 実行したコマンドとその出力を、テキストファイルに 保存 します(CAS ユーザのパスワードを保存する必要はありません)。これは、トラブルシューティングのために TAC サポートが利用します。

図 8-17 ktpass.exe コマンドの実行

 

図 8-18 ktpass.exe コマンドの出力

 

表 8-3 に、パラメータの詳細を示します。

 

表 8-3 ktpass.exe のパラメータ

パラメータ
説明
-princ

SPN の識別子

SPN の文字列全体は、次のような構成となります。
<CAS_username>/[<AD_DomainServer>|<AD_Domain>]@<AD_DOMAIN>

<CAS_username>

ユーザ名

<AD_DomainServer>

単一 AD サーバ用の FQDN マシン名。このパラメータは、[Control Panel] > [System] > [Computer Name] | [Full computer name] の AD サーバの 名前 と完全に一致(大文字と小文字を区別)する必要があります。

<AD_Domain>

CAS がユーザ クレデンシャルの認証に使用する AD ドメインの名前。このパラメータは、[Control Panel] > [System] > [Domain] の AD サーバの ドメイン と、大文字と小文字を含め完全に一致する必要があります。

<AD_DOMAIN>

ドメイン名(大文字のみ)

-mapuser

CAS ユーザをドメインにマッピングします。

-pass

CAS ユーザのパスワード

-out

このユーザ用のキー タブ(証明書と同様)を生成するため、「c:¥ <CAS_user_name> .keytab」キーを出力します。

c:¥ <CAS_user_name> .keytab

必要なパラメータ

-ptype

主要タイプ(必要なパラメータ)

KRB5_NT_PRINCIPAL

提供される Principal はこのタイプです。デフォルトでは、AD サーバはこのタイプを使用しますが、使用しない場合もあります。

+DesOnly

DES 暗号化用のフラグ


 

KTPass コマンドの実行例

図 8-19 に、KTPass コマンドの実行のために、CAS ユーザ アカウント プロパティと AD サーバのコンピュータ名からパラメータが抽出される方法を示します。この図の値は、一例として示しているだけで、この章の設定例の手順に対応するものではありません。

図 8-19 KTPass の実行例:サンプル値

 

KTPass を使用しない AD SSO の設定

次に、Windows Server 2003 と Windows Server 2008 両方の、それぞれの完全機能レベルで動作する Active Directory エントリで、KTPass を実行せずに AD SSO ユーザ アカウントを設定する際に必要なプロセスについて一通り説明します(この方法は、2003 ドメイン機能レベルで動作する Server 2008 AD はサポートしていません。)


) Server 2008 AD エンティティに接続するよう設定された AD SSO ユーザ アカウントは、FIPS 140-2 準拠ではありません。


次の手順は、暗号化タイプの DES のみに適用されます。


ステップ 1 「CAS ユーザの作成」で作成した Active Directory アカウントの [Properties] ダイアログを開きます。

ステップ 2 新しいユーザ アカウントに対して DES 暗号化を要求するには、[Account] タブをクリックして、[Account] オプションにある [Use DES encryption types for this account](Server 2003)または [Use Kerberos DES encryption types for this account](Server 2008)オプションをイネーブル(オン)にし、 [OK] をクリックします(図 8-20 および図 8-21 を参照。)


) DES 暗号化を Windows 7 クライアント マシンに設定するには、 各 Windows 7 クライアント マシンでの手動による DES のイネーブル化を参照してください。


図 8-20 Server 2003 の例:アカウントの [Properties]

 

図 8-21 Server 2008 の例:アカウントの [Properties]

 

ステップ 3 AD サーバで DOS プロンプトを開き、 ldp.exe と入力します(図 8-22 の後ろ側の図を参照)。さらに、 Ldp アプリケーション ウィンドウが開きます。


ldp.exe ファイルのローカル コピーがない場合、Microsoft Windows Server Resource Kit の Support Tools から入手できます。


ステップ 4 [Ldp] ウィンドウで、[Connection] > [Connect] コマンドを使用して Active Directory ドメイン コントローラに接続し、ドメイン コントローラの IP アドレスまたはドメイン名を入力します(図 8-22 および図 8-23 を参照)。たとえば、[Connect] ダイアログで、 10.201.150.11 または child.2k8.com と入力します。

図 8-22 Ldp アプリケーション接続 > [Connect]:Server 2003 の例

 

図 8-23 Ldp アプリケーション接続 > [Connect]:Server 2008 の例

 

ステップ 5 ドメイン コントローラに接続したら、[Connection] > [Bind] コマンドを使用して、AD ドメインを管理者としてバインドします(図 8-24 および図 8-25 を参照)(ユーザ アカウントの作成に使用した ID と同じ ID を指定できます)。

図 8-24 [Connection] > [Bind]:Server 2003 の例

 

図 8-25 [Connection] > [Bind]:Server 2008 の例

 

ステップ 6 [View] > [Tree] コマンドで既知のドメイン サフィックスのリストを表示し、表示されるプルダウン メニューを展開します(図 8-26)。

ステップ 7 [DC=cca,DC=cisco,DC=com] を選択して [OK] をクリックします。

図 8-26 「DC=cca,DC=cisco,DC=com」ツリー ビュー

 

ステップ 8 [DC=cca,DC=cisco,DC=com] ツリーを展開して、[CN=Users,DC=cca,DC=cisco,DC=com] をダブルクリックします(図 8-27)。

図 8-27 ツリー ビューの展開

 

ステップ 9 ステップ 1で作成したユーザ アカウントを探して、そのアカウント エントリを右クリックし、[Modify] をクリックします(図 8-28 を参照)。そのアカウントの [Modify] ダイアログボックスが開きます。

図 8-28 ユーザ アカウント エントリの変更

 

ステップ 10 [Attribute] フィールドで userPrincipalName を指定し、 <username> / <FQDN> @ <REALM> 値を入力します。たとえば、 ccasso_des_NoKT/dcroot.cca.cisco.com@CCA.CISCO.COM図 8-29 を参照)と入力します。


) Active Directory ドメインに複数台のサーバがある場合、この値は <username>/<AD_domain>@<AD_DOMAIN> になります
(例:casuser_des_NoKT/qa-test1.cca.cisco.com@QA-TEST1.CCA.CISCO.COM)。


ステップ 11 [Replace] 操作を選択して [Enter] をクリックし、変更を完了します。

図 8-29 userPrincipalName 属性の変更

 

ステップ 12 属性フィールドで servicePrincipalName を指定し、 <username> / <FQDN> と入力します。たとえば、 ccasso_des_NoKT/dcroot.cca.cisco.com 値を入力します(図 8-30 を参照)。

ステップ 13 [Add] 操作を選択して [Enter] をクリックし、追加を完了します。

図 8-30 servicePrincipalName 属性の追加

 

ステップ 14 [Entry List] の表示に、2 行変更内容が表示されていることを確認し、[Run] をクリックします。

ステップ 15 完了すると、 Ldp アプリケーション ウィンドウの下部に、「Modified <userDN> 」と、エラーが発生せずに表示されます。

Modified
“CN=ccasso_des_NoKT,CN=Users,DC=cca,DC-cisco,DC=com”.
 

ステップ 16 確認するには、アプリケーション ウィンドウの左側のユーザ アカウント名をダブルクリックして、変更がそのユーザ アカウント エントリに示されているか確認します。


 

Windows 7 クライアント環境での AD SSO の設定

リリース 4.7(1) よりも前に AD SSO を設定した管理者はアップグレード後、Windows 7 クライアントを限定的にしかサポートできません。Windows 7 クライアント マシンではデフォルトで DES 暗号化がディセーブルになるため、Cisco NAC Agent がインストールされた未変更の Windows 7 クライアント マシンでもユーザに手動ログイン ダイアログが表示されます。

Cisco NAC アプライアンス ネットワークで AD SSO による Windows 7 クライアント マシンの認証をイネーブルにするには、次のいずれかのオプションを実行します。

オプション 1(推奨)

Microsoft Active Directory サーバで追加アルゴリズムをイネーブルにして、Windows 7 での AD SSO を許可します( 既存の AD サーバでの追加アルゴリズムのイネーブル化を参照)。

オプション 2(小規模クライアント グループのテストにのみ推奨)

Windows 7 クライアント マシン上で DES アルゴリズムをイネーブルにし、CAS の既存の AD SSO DES サービス アカウント設定により通信できるようにします( 各 Windows 7 クライアント マシンでの手動による DES のイネーブル化を参照)。

既存の AD サーバでの追加アルゴリズムのイネーブル化


ステップ 1 「AD SSO 認証サーバの追加」の指示に従って、新しい AD SSO サービス アカウントを作成します。元の DES 暗号化システムとこのマルチアルゴリズム オプションを簡単に切り替えられるようにするため、現在の AD SSO アカウントは変更しないことを推奨します。

ステップ 2 この新しいサービス アカウントで複数のアルゴリズムを使用できるようにするため、KTPass を実行します( 表 8-2 を参照)。

完全機能レベルの Windows 2008 Server の場合:

ktpass -princ newadsso/[adserver.]domain.com@DOMAIN.COM -mapuser newad.sso -pass PasswordText -out c:¥newadsso.keytab -ptype KRB5_NT_PRINCIPAL -crypto All
 

2003 サーバ機能レベルの Windows 2008 Server の場合:

CAM の場合

ktpass -princ newadsso/[adserver.]domain.com@DOMAIN.COM -mapuser newadsso -pass PasswordText -out c:¥newadsso.keytab -ptype KRB5_NT_PRINCIPAL
 

) 次の手順を実行する前に、CAM の /perfigo/control/tomcat/conf/krb.txt ファイルのコピーをバックアップしておくことを強くお勧めします。


前述の ktpass コマンドを実行したあと、CAM にある 2 つのファイルを次のように手動で変更します。

CAM の CLI で、 /perfigo/control/tomcat/conf/krb.txt に移動し、次の行を追加します。

[libdefaults]
kdc_timeout = 20000
default_tkt_enctypes = RC4-HMAC
default_tgs_enctypes = RC4-HMAC
permitted_enctypes = RC4-HMAC
 

/perfigo/control/bin/starttomcat に移動します。

CATALINA_OPTS を検索します。

CATALINA_OPTS の値に、 -DKRB_OVERRIDE=true を追加します。

例:

Old value: CATALINA_OPTS="-server ..."
New Value: CATALINA_OPTS="-server ... -DKRB_OVERRIDE=true"

) この変更を既存の HA ペアに適用している場合、HA プライマリ CAM と HA セカンダリ CAM の両方で、HA 対応 CAM のペアのアップグレードと同様に上記の更新を実行する必要があります。詳細については、『Release Notes for Cisco NAC Appliance, Version 4.9』を参照してください。


service perfigo stop および service perfigo start コマンドを入力して、CAM を再起動します。

CAS の場合

ktpass -princ newadsso/[adserver.]domain.com@DOMAIN.COM -mapuser newadsso -pass PasswordText -out c:¥newadsso.keytab -ptype KRB5_NT_PRINCIPAL
 

) 次の手順を実行する前に、CAS の /perfigo/access/tomcat/conf/krb.txt ファイルのコピーをバックアップしておくことを強くお勧めします。


前述の ktpass コマンドを実行したあと、CAS にある 2 つのファイルを次のように手動で変更します。

CAS の CLI で、 /perfigo/access/tomcat/conf/krb.txt に移動し、次の行を追加します。

[libdefaults]
kdc_timeout = 20000
default_tkt_enctypes = RC4-HMAC
default_tgs_enctypes = RC4-HMAC
permitted_enctypes = RC4-HMAC
 

/perfigo/access/bin/starttomcat に移動します。

CATALINA_OPTS を検索します。

CATALINA_OPTS の値に、 -DKRB_OVERRIDE=true を追加します。

例:

Old value: CATALINA_OPTS="-server ..."
New Value: CATALINA_OPTS="-server ... -DKRB_OVERRIDE=true"

) この変更を既存の HA ペアに適用している場合、HA プライマリ CAS と HA セカンダリ CAS の両方で、HA 対応 CAS のペアのアップグレードと同様に上記の更新を実行する必要があります。詳細については、『Release Notes for Cisco NAC Appliance, Version 4.9』を参照してください。


service perfigo stop および service perfigo start コマンドを入力して、CAS を再起動します。

完全機能レベルの Windows 2003 Server の場合:

ktpass -princ newadsso/[adserver.]domain.com@DOMAIN.COM -mapuser newadsso -pass PasswordText -out c:¥newadsso.keytab -ptype KRB5_NT_PRINCIPAL
 

ステップ 3 「AD(Kerberos)を使用した Agent ベース Windows SSO のイネーブル化」の指示に従って、CAM の AD SSO サービス アカウントを新しいサービス アカウントに変更します。

a. CAM Web コンソールにログインし、[Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Authentication] > [Windows Auth] > [Active Directory SSO] に移動します。

b. AD SSO アカウント名とパスワードを変更します。

c. [Enable Agent-Based Windows Single Sign-On with Active Directory (Kerberos)] のチェックボックスをオンにします。

d. [Update] をクリックします。


 

各 Windows 7 クライアント マシンでの手動による DES のイネーブル化


ステップ 1 管理者として Windows 7 クライアント マシンにログインします。

ステップ 2 [Start] > [Control Panel] > [System and Security] > [Administrative Tools] > [Local Security Policy] > [Local Policies/Security] > [Options] に移動します。

ステップ 3 [Network security] > [Configure encryption types allowed] を選択し、[Local Security Settings] タブで最後のオプション([Future encryption types])以外の各オプションに対応するチェックボックスをオンにして、最後のオプション以外のすべてのオプションをイネーブルにします。


 

FIPS 140-2 準拠の AD SSO に対する Active Directory の設定

ここでは、Windows Server 2008 環境が FIPS 140-2 準拠の Cisco NAC アプライアンスと通信するよう設定する方法について説明します。この項では、次の項目について説明します。

前提条件

FIPS 140-2 準拠の Windows 環境の設定

前提条件

FIPS 140-2 に準拠し、AD SSO をサポートできるよう、KTPass のバージョン 6.0.6001.18000 の Windows Server 2008 を使用する 必要があります 。また、クライアント マシンは Cisco NAC Agent のバージョン 4.7.1.15、4.8.0.32、または 4.9.0.33 がインストールされた Windows Vista または Windows 7 を実行している必要があります。ユーザがこのシステムにすでに Active Directory ドメインを設定していることを前提にしています。

Clean Access Manager と Clean Access Server は FIPS モードで設定し、Cisco NAC アプライアンス リリース 4.7(0) 以降を実行している必要があります。

FIPS 140-2 準拠の Windows 環境の設定

FIPS 140-2 準拠の AD SSO と Cisco NAC アプライアンス システムに対して Windows 環境を設定するには、次の手順を実行します。


ステップ 1 AD システムが Windows Server 2003 からのアップグレードに基づいている場合、Cisco NAC アプライアンスを FIPS モードで動作させるため、ドメインの機能を Windows Server 2008 レベルに上げる必要があります(図 8-31 を参照)。レベルを上げないと Cisco NAC アプライアンス ネットワークに接続できません。

図 8-31 ドメインの機能レベルの更新

 

ユーザ プロファイルの設定

ステップ 2 Windows でユーザを作成します。この手順の例では、「fipsy」という名前を使用します。

図 8-32 新規ユーザの作成

 

ステップ 3 [Password never expires] オプションがオンになっていることを確認し、他のユーザ オプションはオフのままにします(特に最初のログインでパスワードの変更が 必要ないようにします )。

図 8-33 新規ユーザの設定

 

ステップ 4 ユーザのプロパティを開き、ドメインを含むようにユーザ名を変更します(図 8-34 を参照)。

図 8-34 ユーザのプロパティ

 

ステップ 5 アカウント オプションを指定します(図 8-35 を参照)。

図 8-35 アカウント オプションの指定

 

ステップ 6 クライアント マシンで管理者権限があることを確認し、CMD プロンプトを開きます。CMD プロンプトに ktpass と入力して、KTPass を利用できるかどうかを確認します。KTPass が利用できない場合、 ¥Windows¥System32¥ ディレクトリに移動し、もう一度試します。


) 通常、Windows 2008 Server では、KTPass はデフォルトで利用できます。


ステップ 7 次のように KTPass コマンドを実行します。

ktpass -princ fipsy/nac-ad-1.nacdevteam.local@NACDEVTEAM.LOCAL -mapuser fipsy -pass Pass1234
-out c:¥fipsy.keytab -ptype KRB5_NT_PRINCIPAL -crypto AES128-SHA1
 

ステップ 8 AD SSO に対して Clean Access Server を設定します(「CAS での AD SSO の設定」を参照)。


 

AD(Kerberos)を使用した Agent ベース Windows SSO のイネーブル化

AD サーバの設定が完了したら、最後の手順を実行します。

AD を使用した Agent ベースの Windows SSO をイネーブル化する手順は、次のとおりです。


ステップ 1 [Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Authentication] > [Windows Auth] > [Active Directory SSO] の順番に進みます。

図 8-36 Active Directory SSO

 

ステップ 2 [Enable Agent-Based Windows Single Sign-On with Active Directory (Kerberos)] のチェックボックスをオンにします。

ステップ 3 [Update] をクリックします。


) [Active Directory SSO] ページの各フィールドの詳細については、「CAS での AD SSO の設定」を参照してください。



 

アクティブな AD SSO サービスの確認

「AD SSO の設定手順の概要」の設定がすべて完了したら、AD SSO サービスが CAS 上で起動されていることを確認します。

[Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Status] の順番に進みます(図 8-37 を参照)。

図 8-37 AD SSO サービスの起動確認

 

Active Directory SSO が、 Started というステータスでリスト表示されていることを確認します。


) SSH コマンド netstat -a | grep 8910 を使用して、CAS の信頼できるインターフェイス(eth0)が TCP ポート 8910(Windows SSO で使用)で待ち受けていることを確認することもできます。


GPO 更新のイネーブル化

ユーザがまだ Cisco NAC アプライアンスによって認証されていない(または認証 VLAN 上にある)場合、Windows ドメイン コントローラへのアクセスは制限され、そのため、完全なグループ ポリシーの更新が終了しないことがあります。また、グループ ポリシーの次のリフレッシュは、デフォルトでは 90 分ごとに行われます。GPO 更新を正常に行うため、管理者は、[Refresh Windows domain group policy after login] オプションをイネーブル化することにより、AD SSO ログインの直後に、Agent ユーザのためのグループ ポリシーを強制的にリフレッシュすることができます。

管理者は、AD SSO のユーザ ログインの完了後に、Group Policy Object(GPO)更新を再度トリガーするよう Agent を設定できます。CAM Web コンソールで設定した場合、Agent は「gpup date」コマンドをコールして、ユーザのログイン後に GPO 更新を再度トリガーします。

ログイン スクリプトはドメイン コントローラで制御され、実行にはログイン イベントが必要です。Windows 環境でのログイン スクリプトの使用方法の詳細については、「ログイン スクリプトのイネーブル化(任意)」を参照してください。


) Microsoft Group Policy は、AD の登場後(Windows 2000 以降)に利用可能になったため、GPO トリガー更新機能が利用できるのは Windows 7/Vista/XP マシンだけです。


GPO 更新をイネーブル化する手順は、次のとおりです。


ステップ 1 [Device Management] > [Clean Access] > [General Setup] > [Agent Login] の順番に進みます。

図 8-38 Agent ログイン:一般的なセットアップ

 

ステップ 2 [User Role] ドロップダウンで、GPO 更新を適用するロールを選択します。

ステップ 3 [Operating System] ドロップダウンで、GPO 更新を適用する OS を選択します(Windows XP 以降を選択する必要があります)。

ステップ 4 [Refresh Windows domain group policy after login (for Windows)] のチェックボックスをオンにします。

ステップ 5 [Update] をクリックします


 

ログイン スクリプトのイネーブル化(任意)


注意 この手順の実行は任意であり、ここでは利便性のため参照情報を示します。Cisco Technical Assistance Center(TAC)では、Microsoft のログイン スクリプトに関する質問やトラブルシューティングをサポートしておりません。サポートについては、http://support.microsoft.com を参照してください。

ログイン スクリプトなどの GPO 更新オブジェクトは、ログインなど、トリガーとなるイベントが必要です。このイベントがないと、エラーになります。ログインの前に Windows 環境でスクリプトを実行すると、AD サーバへのドライブ マッピングまたはドライブ リソースへのアクセスができないため、エラーになります。

ネットワークベースのログイン スクリプトとローカル ログイン スクリプトは、処理方法が異なります。

ローカル ログイン スクリプトは、クライアント マシンでローカルに実行されます。スクリプトで人工的な遅延を設定した場合、正しく機能します。

ネットワークベースのスクリプトの場合、初期化のため、連続的に AD サーバにアクセスする必要があります。ネットワーク構成により、手順を組み合わせて使用することができます。通常、ネットワークベースのスクリプトは、AD サーバの %Sysvol%¥scripts フォルダにあります。

表 8-4 に、ネットワークベースのスクリプトの処理オプションを示します。

 

表 8-4 ネットワークベースのログイン スクリプトのオプション

配置
オプション

インバンド

Temporary または Unauthenticated ユーザ ロールで AD サーバ ポートへのアクセスをオープンし、スクリプト本体で遅延を規定します。

アウトオブバンド(IP 変更なし)

Temporary または Unauthenticated ユーザ ロールで AD サーバ ポートへのアクセスをオープンし、スクリプト本体で遅延を規定します。

アウトオブバンド(IP 変更あり)

組み合わせたスクリプトを使用して、ローカルに遅延を規定したスクリプトをコピーし、実行し、削除します。

(注) クライアント マシンにスクリプトが存在する場合、参照とコピーが可能なため、セキュリティの問題があります。

どのタイプの導入でも、ローカルベースまたはネットワークベースのスクリプトが正しく動作するには、人工的な遅延のスクリプトを作成して認証中に実行する必要があります。「スクリプト使用を許可するための遅延の導入」を参照してください。

ネットワークベースのスクリプトを IP アドレス変更ありのアウトオブバンドで導入して使用する場合、次のことも行う必要があります。

「delay」スクリプトの最後に delete コマンドを付加

「delay」スクリプトをクライアント マシンにコピーして起動する参照スクリプトを使用

詳細については、「ネットワークベースのスクリプトを IP アドレス変更ありのアウトオブバンド モードで使用」を参照してください。

スクリプト使用を許可するための遅延の導入

認証が完了するまでエラーとなる永続的なチェック アクションをコールすることにより、遅延を導入することができます。たとえば、ping、Telnet、nslookup など、ネットワーク接続の確立が必要なアクションを使用できます。次の例は .bat スクリプトですが、別のタイプのスクリプトも使用できます。

ping を使用する場合、次のことに注意してください。

ping が可能なのは、Cisco NAC アプライアンスのログイン成功後に到達可能な IP アドレスです。

ping に使用される IP アドレスと AD サーバが同一である必要はありません。


注意 実際の IP アドレスを持つ保護されたデバイスに ping を送信する場合、遅延スクリプトの実行中に IP アドレスを知ることができます。DOS ウィンドウを非表示にするステートメントをスクリプトに追加することができます。

必要なのは 1 つの IP アドレスだけです。

マッピングの割り当ては、ping の終了後に行われます。

例:

:CHECK
@echo off
echo Please wait...
ping -n 1 -l 1 192.168.88.128
if errorlevel 1 goto CHECK
@echo on
netuse L:\\192.168.88.128¥Scripttest
 

この例では、ping は成功するまでバックグラウンドで実行されます。成功するとループから抜け、システムは同じノードのネットワークベースのスクリプトが存在する場所を L: ドライブにマッピングし、そのスクリプトを実行します。DOS ウィンドウは、バックグラウンドに表示されます。


) DOS ウィンドウを非表示にしたり最小化したりするステートメントをスクリプトに追加することができます。


表 8-5 に、スクリプトのステートメントと意味を示します。

 

表 8-5 参照スクリプトのステートメントと意味

ステートメント
意味

:CHECK

スクリプトを開始します。

@echo off

コマンド出力だけが表示されます。

echo Please wait...

「Please wait...」というメッセージをエンドユーザに表示します。

ping -n 1 -l 1 192.168.88.128

ping ユーティリティを使用して、IP アドレス 192.168.88.128 が到達可能かどうかを確認します。

-n :ホストネームは検索しません。

1 :1 個のパケットを送信します。

-l :ODBC ドライバまたはライブラリを使用します。

1 :1 秒間待ちます。

if errorlevel 1 goto CHECK

ping ユーティリティが 192.168.88.128 に到達しなかった場合、:CHECK から再度開始します。

@echo on

デバッグ メッセージを表示します。

netuse L:\\192.168.88.128¥Scripttest

192.168.88.128 のファイル共有を L: ドライブにマッピングします。

ネットワークベースのスクリプトを IP アドレス変更ありのアウトオブバンド モードで使用

IP アドレス変更ありのアウトオブバンド モードでは、該当するネットワークベースのスクリプトをコールする前に、次の 2 つのスクリプトを作成して実行する必要があります。

スクリプトをローカルにコピーしそれを起動する参照スクリプト

実行後にネットワーク スクリプトを削除する行が追加された遅延スクリプト


注意 ネットワーク アクセスが付与されていないユーザ マシンにネットワーク スクリプトをコピーすることは、セキュリティ上の問題があります。スクリプトがユーザ マシンに存在している間、ユーザはスクリプトのコピーや参照ができてしまいます。

参照スクリプト

次の例のようなスクリプトを作成します。スクリプトの名前は「refer.bat」で、「actual.bat」という名前の遅延スクリプトをコピーしてから起動します。

@echo off
echo Please wait...
copy \\192.168.88.228¥notlogon¥actual.bat actual.bat
actual.bat
 

表 8-6 に、スクリプトのステートメントと各行の意味を示します。

 

表 8-6 参照スクリプトのステートメントと意味

ステートメント
意味

@echo off

コマンド出力だけが表示されます。

echo Please wait...

「Please wait...」というメッセージをエンドユーザに表示します。

copy \\192.168.88.228¥notlogon¥actual.bat actual.bat

IP アドレス 192.168.88.228 の AD サーバの「notlogon」フォルダからスクリプト「actual.bat」をコピーします。

actual.bat

スクリプト「actual.bat」を起動します。

Delete コマンド付きの遅延スクリプト

スクリプトの初期化を遅延させるスクリプトを作成する方法については、「スクリプト使用を許可するための遅延の導入」を参照してください。次の例に示すように、遅延スクリプトの最後に、 del コマンドと、削除するスクリプトの名前を追加します。スクリプトの名前は「actual.bat」です。


注意 エンドユーザのマシンに存在するスクリプトのローカル コピーを削除することにより、ネットワークの脆弱性を減少させることを推奨します。サンプル スクリプトの最終行では、機能の削除(クリーンアップ)を実行します。

例:

:CHECK
@echo off
echo Please wait...
ping -n 1 -l 1 192.168.88.128
if errorlevel 1 goto CHECK
@echo on
netuse L:\\192.168/88/128/Scripttest
del actual.bat

AD SSO の LDAP ルックアップ サーバの追加(任意)


) LDAP ルックアップ サーバが必要になるのは、AD SSO 認証後に AD 属性に基づいてユーザがユーザ ロールに割り当てられるようにマッピング規則を設定する場合だけです。ロールのマッピングを行わない基本 AD SSO の場合やテストの場合は、LDAP ルックアップ サーバを設定する必要はありません。


Windows ドメインの SSO ユーザを複数のユーザ ロールにマッピングする場合、CAM でマッピングを実行できるよう、セカンダリ LDAP ルックアップ サーバを設定する必要があります。そして、AD SSO 認証プロバイダーにこの LDAP ルックアップ サーバを指定します。「AD SSO 認証サーバの追加」を参照してください。LDAP ルックアップ サーバは、以下の 2 つの認証メカニズムのいずれかを使用するように設定できます。

SIMPLE :CAM および LDAP サーバは、ユーザ ID とパスワードのデータを暗号化しないで相互にやりとりします。

GSSAPI :(Generic Security Services Application Programming Interface)CAM と指定された LDAP サーバの間で渡されるユーザ ID とパスワード情報を暗号化し、プライバシーを保護します。


) GSSAPI を使用する場合に完全な DNS 機能が使用されるように、すべてのドメイン コントローラ、子ドメイン、ホストが DNS の厳密な命名規則に従っていることと、DNS の正引きと逆引きの両方が実行できることを確認してください。

Cisco NAC アプライアンスでは、GSSAPI 認証方式を使用して LDAP 認証プロバイダーと Kerberos 認証プロバイダーを 1 つずつ設定できますが、アクティブにできるのは常にいずれか 1 つだけです。詳細については、『Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9』の「Kerberos」を参照してください。


LDAP ルックアップ サーバの設定


ステップ 1 [User Management] > [Auth Servers] > [Lookup Server] の順番に進みます。[Server Type] は自動的に [LDAP Lookup] に設定されます。

図 8-39 ルックアップ サーバ(LDAP):SIMPLE 認証方式

 

LDAP ルックアップ サーバの設定ページには、LDAP 認証プロバイダーの設定ページと同じフィールドがあります。SIMPLE および GSSAPI 認証方式の設定の詳細については、『 Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9 』の「 LDAP 」を参照してください。


 

LDAP ルックアップを使用した Cross-Forest グループ マッピング


ステップ 1 2 つの AD フォレスト間の双方向トラストを設定します。

ステップ 2 CAM の Web コンソールで GSSAPI を使用する LDAP ルックアップ サーバを作成します。

ステップ 3 [Base/Realm Mapping] フィールドで、AD フォレストの基本コンテキストおよびレルム マッピングを指定します。たとえば、最初の AD フォレストのレルムが CCA.CISCO.COM で、他の AD フォレストが NAC.PERFIGO.COM の場合、基本およびレルム マッピングは次のようになります。

dc=cca,dc=cisco,dc=com/CCA.CISCO.COM

dc=nac,dc=perfigo,dc=com/NAC.PERFIGO.COM

ステップ 4 LDAP ルックアップ サーバを使用した AD SSO サーバを作成します。


 

Cisco NAC アプライアンスで [Auth Test] 機能を使用して、AD SSO 認証をテストできます。詳細については、『 Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9 』の「Auth Test」を参照してください。

[Auth Test] タブでは、ユーザ名に加えてレルム名を入力する必要があります。たとえば、ユーザ名が nacuser でレルムが NAC.PERFIGO.COM の場合、 nacuser@NAC.PERFIGO.COM と入力してください。

AD フォレストのどちらかまたは両方で利用できるユーザでテストできます。

トラブルシューティング

一般

CAM、CAS、AD サーバの日付と時刻が、それぞれ 5 分以内で同期化されていることを確認します。時刻が同期していないと、AD SSO が動作しません。AD のアカウントを削除し、時刻を同期化し、アカウントを作成しなおす必要があります。アカウントを削除してもアカウントの古いレコードが AD サーバに保存されている場合、別の名前で新しいアカウントを作成する必要がある場合もあります。

AD サーバで CAS アカウントをセットアップしているとき、CAS アカウントで Kerberos 事前認証をする必要がないようにします。

OOB 配置では、ワークステーションにより「最も近い AD サーバ」を見つけるために ICMP(ping)が使用され、認証 VLAN の場合はサイトで参照されているすべての AD サーバとサービスで成功し、サイトとサービスがまだ設定されていない場合はすべての AD サーバで成功することが 必要です

NAT 環境では、AD SSO が適切に動作するよう、CAM が NAT エントリで構成されているようにしてください。


) 古いキャッシュ済みクレデンシャルを使用していないことを確認するため、CAS で service perfigo restart を実行します。


KTPass コマンド

KTPass コマンドの「/」と「@」の間に入力した AD ドメイン名(複数サーバの場合)または単一 AD サーバ名(例:「AD_DomainServer」)が、[Control Panel] > [System] > [Computer Name] | [Full computer name] で表示されるドメインまたは単一 AD サーバの名前と完全に一致するようにしてください。詳細については、「ktpass.exe コマンドの実行」を参照してください。

KTPass コマンドの「@」の後のレルム名(例:「AD_DOMAIN」)をすべて 大文字 で入力するようにしてください。AD サーバの [Control Panel] > [System] > [Computer Name] | [Domain] で表示されるドメイン名は、KTPass コマンドに入力する場合、大文字に変換する必要があります。

CAS で AD SSO サービスを開始できない

CAS で AD SSO サービスを開始できない場合、一般的に考えられるのは、AD サーバと CAS との通信の問題です。

CAS の起動時に、CAS から AD サーバに到達できない場合、AD SSO サービスは開始されません。管理者は回避策として、[Device Management] > [CCA Servers] > [Manage [CAS_IP]] > [Authentication] > [Windows Auth] > [Active Directory SSO] の順番に進み、[Update] ボタンをクリックして AD SSO サーバを再起動する必要があります。

KTPass コマンドが正しく実行されているかどうか確認します。「ktpass.exe コマンドの実行」を参考に、フィールドの内容が正しいことを確認します。KTPass の動作が正しくない場合、アカウントを削除し、AD サーバで新しいアカウントを作成し、再度 KTPass を実行します。

CAS の時刻と AD サーバの時刻が同期されるようにします。そのためには、この 2 つで同じタイム サーバを使用します(または、実験のセットアップでは CAS の時刻を AD サーバに合わせます(AD サーバでは Windows の time サービスが動作しています))。Kerberos はクロックのタイミングが重要な要素で、最長クロック スキューは 5 分(300 秒)です。

Active Directory Domain が大文字(レルム)であることと、CAS が FQDN を DNS で解決できることを確認します(実験のセットアップでは、AD には少なくとも 1 台の DNS サーバが必要なため、AD サーバで DNS を動作させることができます)。

AD サーバの CAS ユーザ名、CAS(大文字)の Active Directory Domain(Kerberos Realm)、CAS の AD サーバ(FQDN)が正しいことを確認します。

TAC サポート事例を作成するときは、 https://<CAS-IP-address>/admin で直接 CAS にログインし、[Support Logs] をクリックし、AD 通信ロギングのロギング レベルを「INFO」に変更します。問題を作成しなおし、サポート ログをダウンロードします。サポート ログをダウンロードしたら、CAS を再起動するか、またはログ レベルをデフォルトに戻します。詳細については、『 Cisco NAC Appliance-Clean Access Manager Configuration Guide, Release 4.9 』を参照してください。

AD SSO サービスは開始するが、クライアントで SSO が実行されない

CAS で AD SSO サービスが開始されても、クライアント マシンで Windows SSO が実行されない場合、一般的に考えられるのは、AD サーバとクライアント PC 間、またはクライアント PC と CAS 間で発生する通信の問題です。以下の点を確認してください。

クライアントで Kerberos キーが使用されていないこと

クライアントが接続できるように、Unauthenticated ロールで AD サーバへのポートがオープンされていること


) テストを行う場合、まず AD サーバおよび DC への完全なアクセスを可能にし、AD SSO が動作してからポートを制限することを推奨します。クライアント PC にログインするときは、(ローカル アカウントではなく)Windows ドメイン クレデンシャルを使用してドメインにログインするようにしてください。


クライアント PC の時刻が AD サーバと同期化されていること。

CAS の信頼できるインターフェイス(eth0)が TCP ポート 8910 で待ち受けていること。クライアント PC のスニファ トレースが参考になります。

ユーザが、ローカル アカウントではなく、Windows ドメイン アカウントでログインしていること


) CAS と Agent では、クライアント マシンでの複数 NIC の使用をサポートしていません。有線 NIC をオンにする場合、クライアント マシンの無線 NIC をオフにする必要があります。


Kerbtray

Kerbtray は Microsoft Supprt Tools から入手できる無償のツールで、クライアントが Kerberos チケット(TGT および ST)を取得したことを確認するため、またクライアント マシン上で Kerberos チケットを削除するために使用できます。Service Ticket(ST; サービス チケット)は、AD サーバで作成される CAS ユーザ アカウントに関するものです。システム トレイ上のグリーンの Kerbtray アイコンは、クライアントがアクティブな Kerboros チケットを持っていることを示します。しかし、チケットが CAS ユーザ アカウントに対して正しい(有効である)ことを確認する必要があります。


) AD SSO は、CAS および Cisco NAC Agent が 16 kB より大きい Kerberos チケットを AD ドメインと交換する場合に、Cisco NAC アプライアンスで停止します。


CAS ログ ファイル


) CAS 上の該当するログ ファイルは、/perfigo/access/tomcat/logs/nac_server.log です。


CAS で AD SSO サービスが開始されない場合、次のような CAS と AD サーバ間で発生する通信の問題が考えられます。

CAS とドメイン コントローラの間でクロックの同期が取れていません。

SEVERE: startServer - SSO Service authentication failed. Clock skew too great (37)
Aug 3, 2006 7:52:48 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
 

ユーザ名が正しくありません。正しくないユーザ名「ccass」とエラー コード 6 と最後の警告に注目してください。

Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
INFO: GSSServer - SPN : [ccass/PreM-vM-2003.win2k3public.local@WIN2K3PUBLIC.LOCAL]
Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
SEVERE: startServer - SSO Service authentication failed. Client not found in Kerberos database (6)
Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer startServer
WARNING: GSSServer loginSubject could not be created.
 

パスワードが正しくない、またはレルムが無効です(大文字でない、不正な FQDN、KTPass 実行が正しく行われていない、など)。エラー コード 24 と最後の警告に注目してください。

Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
INFO: GSSServer - SPN : [ccasso/PreM-vM-2003.win2k3public.local@WIN2K3PUBLIC.LOCAL]
Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
SEVERE: startServer - SSO Service authentication failed. Pre-authentication information was invalid (24)
Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer startServer
WARNING: GSSServer loginSubject could not be created.
 

次のエラーは、クライアント PC の時刻と AD サーバの時刻が同期化されていない場合の、クライアントと CAS の間の通信上の問題を示しています(このエラーと、CAS の時刻と AD サーバの時刻が同期化されていないエラーとの違いに注意してください)。

Aug 3, 2006 10:03:05 AM com.perfigo.wlan.jmx.admin.GSSHandler run
SEVERE: GSS Error: Failure unspecified at GSS-API level (Mechanism level: Clock skew too great (37))

「Integrity check on decrypted field failed」エラー

AD SSO が動作しておらず、CAS のログに「SEVERE: GSS Error: Failure unspecified at GSS-API level (Mechanism level: Integrity check on decrypted field failed (31))」というメッセージが出力される場合は、AD の設定と KTPass コマンドのアカウント名とパスワードを確認してください。

パスワードまたはキーが正しくない場合、一般に CAS は「Integrity check on decrypted field failed」のようなエラー メッセージを返します。たとえば、このエラーは、複数の AD サーバに存在する同じアカウントに対して KTPass を実行した場合に表示されます。単一の AD サーバから新しいアカウントに対して再度 KTPass コマンドを実行することで問題が解決されます。