Cisco Clean Access (NAC アプライアンス) Server インストレーション アドミニストレーション ガイド Release 4.1(1)
Active Directory Single Sign-On(AD SSO)の設定
Active Directory Single Sign-On(AD SSO)の設定
発行日;2012/01/10 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 4MB) | フィードバック

目次

Active Directory Single Sign-On(AD SSO)の設定

概要

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

CAS と AD サーバの通信

AD SSO の設定手順の概要

設定の前提条件

設定手順の概要

AD SSO 認証サーバの追加

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

必要な TCP ポート

代替 UDP ポート

CAS での AD SSO の設定

AD サーバの設定と KTPass コマンドの実行

CAS ユーザの作成

サポート ツールのインストール

ktpass.exe コマンドの実行

KTPass コマンドの実行例

AD(Kerberos)対応の Agent ベース Windows SSO のイネーブル化

AD SSO サービスの起動確認

GPO 更新のイネーブル化

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

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

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

参照スクリプト

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

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

トラブルシューティング

Active Directory Single Sign-On(AD SSO)の設定

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

この章の内容は、次のとおりです。

「概要」

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

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

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

「CAS での AD SSO の設定」

「AD サーバの設定と KTPass コマンドの実行」

「AD(Kerberos)対応の Agent ベース Windows SSO のイネーブル化」

「AD SSO サービスの起動確認」

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

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

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

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

概要

Cisco NAC アプライアンスを設定して、すでに Windows ドメインにログインしている Clean Access Agent(CAA)ユーザの認証を自動的に行うことができます。AD SSO では、Windows システムで AD にログインするユーザに対して、Agent からログインすることなく、自動的にポスチャ評価/Clean Access 認証が行われます。Cisco NAC アプライアンスでは、Windows Vista/XP/2000 クライアント マシンについては Single Sign-On(SSO)を、Windows 2000/2003 サーバについては AD をサポートしています。 表10-1 を参照してください。

 

表10-1 Windows の Active Directory(AD)SSO のサポート

Active Directory(AD)サーバ
クライアント マシン 1

Windows 2000 Server SP4

Windows 2003 Enterprise SP1

Windows 2003 Enterprise R2

Windows 2003 Standard SP1 2

Windows 2000 SP4

Windows XP(Home/Pro)SP1、SP2 以降

Windows Vista

1.AD SSO を使用するには、CAA がクライアント システムにインストールされている必要があります(たとえば、CCA では AD SSO 用の Linux Kerberos クライアントを使用できません)。

2.SP1 のない Windows 2003 はサポートされていません。


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


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


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


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

Windows SSO は、すでにバックエンド Kerberos Domain Controller(AD サーバ)で認証されたユーザを CCA が自動的に認証するための機能です。図10-1に、Kerberos チケット交換の一般的なプロセスを示します。

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

 

CAS が AD SSO 用に設定されている場合、図10-1のように「ネットワーク サービス」コンポーネントが変更されます。一般的な手順は次のとおりです。

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

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

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

クライアントの CAA が、CAS と通信するための CAS ユーザ名により、クライアントに Service Ticket(ST; サービス チケット)を要求します。

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

AD がクライアントに ST を付与し、クライアントが Agent にこの ST を付与します。

Agent と CAS との通信が可能になります。

CAS がパケットを送り返し、クライアントを相互認証します。

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

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

CAS と AD サーバの通信

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

CAS は、root ドメインの AD サーバへのユーザ ログイン トラフィックのみ読み取ります。図10-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 サーバの設定と KTPass コマンドの実行を参照)は、cca-eng-test.cca-eng-domain.cisco.com サーバ上でのみ実行する必要があります。

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

 

AD SSO の設定手順の概要

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

設定の前提条件

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

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

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

最新バージョンの ktpass.exe(リリース 5.2.3790.0 以降)がインストールされていること。

各 AD サーバの IP アドレス(Unauthenticated ロールのトラフィック ポリシーを設定するため)。そのドメインを管理するすべての AD サーバについて、CAS のトラフィックを許可する必要があります。たとえば、ユーザがドメイン内の複数の AD サーバにログインできる場合、Unauthenticated ロールのために、複数のすべての 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 Domain Name(Windows 2000 以上)。これは、AD サーバの CLI 設定と CAS 設定の両方に必要です。


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


クライアント システムに CAA がインストールされていること。

設定手順の概要


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

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

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

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

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

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

ステップ 4 「AD サーバの設定と KTPass コマンドの実行」

CAS が通信する Windows 2000/2003 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 を選択します。

図10-3 AD SSO

 

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

ステップ 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 ドメイン コントローラにクレデンシャルを送信します(図10-1を参照)。マシンがサービス チケットを受信すると、Agent はこれを使用して、CAS によってクライアント認証を有効化します。CAS が認証を有効化するときのみ、ユーザのネットワーク アクセスが許可され、CAA によるユーザ ログインを別途行う必要はありません。

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


) AD SSO トラフィックに断片化パケットが含まれていると考えられる場合は、「IP ベースのローカル トラフィック ポリシーの追加/編集」の指示に従って、IP FRAGMENT オプションをイネーブル化します。


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

必要な TCP ポート

AD サーバで Kerberos が使用されている場合、次の TCP ポートを CAS 上でオープンする必要があります。

TCP 88(Kerberos)

TCP 135(RPC)

TCP 389(LDAP)または TCP 636(SSL 対応 LDAP)

TCP 1025(RPC) -- 非標準

TCP 1026(RPC) -- 非標準

代替 UDP ポート

AD サーバで Kerberos が使用されているかどうか不明な場合、次の UDP ポートをオープンする必要があります。

UDP 88(Kerberos)

UDP 389(LDAP)または UDP 636(SSL 対応 LDAP)


) 通常、LDAP プロトコルでは、TCP/UDP ポート 389 でのトラフィック送信時に、プレーンテキストを使用します。LDAP 通信のために暗号化が必要な場合、代わりに TCP/UDP ポート 636(SSL 暗号化対応 LDAP)を使用します。


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


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

ステップ 2 Untrusted ->Trusted のドロップダウンセットで、 Add Policy リンクをクリックします。Add Policy フォーム(図10-4)が表示されます。

図10-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,389,1025,1026

ステップ 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 の順番に進みます。

図10-5 AD SSO

 

ステップ 2 Enable Agent-Based Windows Single Sign-On with Active Directory (Kerberos) のチェックボックスはまだクリックしないでください。このサービスのイネーブル化は、「AD サーバの設定と KTPass コマンドの実行」が完了したあとに行います。このページの別のフィールドについては、設定して、以下のように 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 サーバの名前と完全に一致しなければなりません(図10-7を参照)。

図10-6 AD SSO -- Single Active Directory Server

 

図10-7 Control Panel > System > Computer Name | Full computer name

 

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

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

 

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

CCA-ENG-DOMAIN.CISCO.COM
 

ステップ 5 Account Name for CAS に、AD サーバで作成した CAS のユーザ名を入力します。例: casuser
CAS ユーザ アカウントを使用すると、CAS で AD サーバにログインできます。

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


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



注意 CAS アカウントのパスワードには、アポストロフィや一重引用符などの特殊文字は使用しないでください。CAS での DHCP やSSO の動作が停止する可能性があります。この問題を解決するには、パスワードを変更して CAS を再起動します。

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

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


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



 

AD サーバの設定と KTPass コマンドの実行

AD サーバの設定には、GUI と CLI インターフェイスの両方が使用されます。

「CAS ユーザの作成」

「サポート ツールのインストール」

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

CAS ユーザの作成

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


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

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

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

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

 

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

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

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

図10-10 CAS ユーザの設定

 

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

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

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

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

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


注意 CAS アカウントのパスワードには、アポストロフィや一重引用符などの特殊文字は使用しないでください。CAS での DHCP やSSO の動作が停止する可能性があります。この問題を解決するには、パスワードを変更して CAS を再起動します。

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

 

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

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

 

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

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

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

 


 

サポート ツールのインストール

Windows 2000/2003 サーバのサポート ツールの一部として、 ktpass.exe ツールが利用できます。KTPass 実行ファイルは、デフォルトではインストールされておらず、インストレーション CD からインストールする必要があります。

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


ステップ 1 Windows Server インストレーション CD を、AD サーバ マシンの CD ドライブに挿入します。

ステップ 2 CD の \SUPPORT\TOOLS フォルダをブラウズします(図10-14)。

Windows 2000 の場合、サポート ツールは (CD)/SUPPORT/TOOLS/Setup.exe です。

Windows 2003 の場合、サポート ツールは (CD)/SUPPORT/TOOLS/Suptools.msi です。

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

 

ステップ 3 サポート ツールの実行ファイルまたは MSI ファイルをダブルクリックして、インストールします。デフォルトでは、サポート ツールは C:\Program Files\Support Tools にインストールされます(図10-15)。

図10-15 サポート ツール-- ktpass.exe

 


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



 

ktpass.exe コマンドの実行


) KTPass が正しく動作するよう、最新バージョンの ktpass.exe を取得し、インストールしてください。

シスコでは、KTPass 実行ファイルのリリース 5.2.3790.0 以降を使用するよう推奨しています。


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

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

Linux では、DES(一般的な暗号化タイプ)はサポートされていますが、Microsoft 固有の AD 用デフォルト暗号化(RC4 など)はサポートされていません。CAS は Linux マシンであるため、AD へのログイン時、互換性のために、CAS ユーザによってデフォルト暗号化ではなく DES が使用されるように、 ktpass.exe コマンドを実行する必要があります。

サポートされている Windows サーバのバージョン一覧については、 表10-1「Windows の Active Directory(AD)SSO のサポート」(p.10-2) を参照してください。


ktpass.exe の実行時は、大文字と小文字の入力規則に従う必要があります(図10-16を参照)。

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

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

図10-16 Control Panel > System > Computer Name | Full computer name

 

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

コマンドの実行後に、次の出力が表示されなければなりません。

Account <CAS user> has been set for DES-only encryption


 

ktpass.exe を実行する手順は、次のとおりです。


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

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

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

ktpass.exe -princ <CAS_username> / <AD_DomainServer> @< 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 オプションを指定する場合、このコマンド構文を使用します。

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

C:\Program Files\Support Tools> ktpass.exe -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.exe -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) オプションを指定する場合、このコマンド構文を使用します。

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

C:\Program Files\Support Tools> ktpass.exe -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
 

コマンドの出力は、次のようになります(図10-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)である ktpass.exe -princ casuser/cca-eng-domain.
cisco.com@CCA-ENG-DOMAIN.CISCO.COM
は、管理ドメイン内の AD サーバが CAS から渡されたユーザ クレデンシャルを適切に解決できることを保証する上での鍵となります。


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

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

 

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

 

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

 

表10-2 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 コマンドの実行例

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

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

 

AD(Kerberos)対応の Agent ベース Windows SSO のイネーブル化

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

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


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

図10-20 AD 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 の順番に進みます(図10-21)。

図10-21 AD SSO サービスの起動確認

 

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


) 次の SSH コマンドを使用して、CAS が TCP ポート 8910(Windows SSO で使用)にリスト表示されていることを確認することもできます。netstat -a | grep 8910.


GPO 更新のイネーブル化

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

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

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


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


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


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

図10-22 Agent ログイン--一般的なセットアップ

 

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

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

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

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


 

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

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

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

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

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

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

 

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

導入
オプション

インバンド

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

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

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

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

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


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


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

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

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

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

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

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

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

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

ping が可能なのは、Clean Access のログイン成功後に到達可能な 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 error level 1 goto CHECK
@echo on
netuse L:\\192.168.88.128\Scripttest
 

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


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


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

 

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

ステートメント
意味

: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 error level 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
 

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

 

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

ステートメント
意味

@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 error level 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 ルックアップ サーバを設定する手順は、次のとおりです。


ステップ 1 User Management > Auth Servers > Lookup Server の順番に進みます。

図10-23 ルックアップ サーバ(LDAP)

 

ステップ 2 Server Type の設定は、 LDAP Lookup になっています。


) LDAP ルックアップ サーバ フォームの場合、すでに AD SSO 認証サーバにロールが割り当てられているため、Default Role ドロップダウン メニューはありません。LDAP ルックアップに失敗した場合、ユーザは AD 認証サーバのデフォルト ロールにマッピングされます。


ステップ 3 Provider Name -- このルックアップ サーバの一意の名前を入力します。

ステップ 4 Server URL -- LDAP ルックアップ サーバの URL を入力します。書式は次のとおりです。

ldap://<directory_server_name>:<port_number>
 

ポート番号を指定しない場合、389 が規定値となります。

ステップ 5 Server version -- LDAP バージョン。サーバのバージョンを自動的に検出するには、 Auto (デフォルト)のままとします。サポートされているタイプには、Version 2 と Version 3 があります。

ステップ 6 Search(Admin) Full DN (必須) -- LDAP 管理者、または検索権限のある LDAP ユーザの完全なドメイン名(DN)を入力します。たとえば、CCA-ENG-DOMAIN.CISCO.COM のドメインの場合、Search DN は次のようになります。

CN=<username>, CN=Users, DC=CCA, DC=ENG, DC=CISCO, DC=COM
 

ステップ 7 Search(Admin) Password (必須) -- LDAP 管理者、または検索権限のある LDAP ユーザのパスワードを入力します。

ステップ 8 Search Base Context -- ユーザの検索を行うベース コンテキスト(LDAP ツリーの root)。次の例を参考にしてください。

CN=Users, DC=CCA, DC=ENG, DC=CISCO, DC=COM
 

ステップ 9 Search Filter -- 認証される属性。LDAP ツリーのベースで任意のユーザと照合される検索属性。次の例を参考にしてください。

CN=$user$   または

uid=$user$   または

sAMAccountName=$user$

ステップ 10 Referral -- デフォルトは Manage(Ignore) です。照会エントリを管理する(LDAP サーバは照会エントリを普通のエントリとして返す)か、ハンドル(Handle(Follow))として返すかを設定します。

ステップ 11 DerefLink -- デフォルトは OFF です。 ON の場合、検索結果として返されるオブジェクト エイリアスは参照解除されます。つまり、エイリアス自体ではなく、エイリアスが参照する実際のオブジェクトが検索結果として返されます。

ステップ 12 DerefAlias -- Always(デフォルト)、Never、Finding、Searchingから選択できます。

ステップ 13 Security Type -- デフォルトは None です。LDAP サーバへの接続で SSL を使用するかどうかを設定します。


) LDAP サーバで SSL を使用する場合、Administration > CCA Manager > SSL Certificate | Import Certificate で CAM に証明書を必ずインポートしてください。


ステップ 14 Description -- (任意)必要に応じて、LDAP ルックアップ サーバの説明を入力します。

ステップ 15 Add Server をクリックします。

ステップ 16 ルックアップ サーバが追加されたら、それに合わせて AD SSO 認証サーバを設定します。

a. User Management > Auth Servers > List の順番に進みます。

b. 設定した AD SSO 認証サーバの Edit ボタンをクリックします。

c. Edit フォームで、 LDAP Lookup Server ドロップダウン メニューから該当するルックアップ サーバを選択します。

d. Update Server をクリックします。


) LDAP ルックアップ サーバの設定が完了すると、マッピング規則に従ったロール マッピングが、他の LDAP サーバの場合と同様に設定されます。詳細については、『Cisco NAC Appliance - Clean Access Manager Installation and Administration Guide, Release 4.1(1)』の「Map Users to Roles Using Attributes or VLAN IDs」を参照してください。



 

トラブルシューティング

全般

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

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


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


KTPass コマンド

KTPass コマンド(例:「AD_DomainServer」)の「/」と「@」の間に入力した AD ドメイン名(複数サーバの場合)または単一 AD サーバ名が、 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 の時刻])。Kerberos はクロックのタイミングが重要な要素で、最長クロック スキューは 5 分(300 秒)です。

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

次の項目が正しいことを確認します。AD サーバの CAS ユーザ名、CAS パスワード(一重引用符のような特殊文字は使用しないでください。)、CAS(大文字)の Active Directory Domain(Kerberos Realm)、CAS の AD サーバ(FQDN)。

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

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

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

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

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


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


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

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

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


) AD SSO をサポートするには、CAA 4.0.0.1 以降を使用する必要があります。



) CAS/CAA では、クライアント PC での複数 NIC の使用をサポートしていません。Wired NIC を ON にする場合、クライアント PC の Wireless NIC を OFF にする必要があります。


Kerbtray

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

CAS ログ ファイル


) CAS 上の該当するログ ファイルは、/perfigo/logs/perfigo-redirect-log0.log.0 です。


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.
 

次のエラーは、クライアントと CAS 間で発生する通信の問題を示しています。クライアント PC の時刻と AD サーバの時刻が同期化されていません(このエラーと、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))