第 2 章 |
SGD のユーザー認証は、2 つの段階に分けられます。最初に、ユーザーは SGD サーバーに対して認証を実行して、SGD にログインします。これは「Secure Global Desktop 認証」として知られています。次に、ユーザーはアプリケーションサーバーに対して認証を実行して、アプリケーションを実行します。これは「アプリケーション認証」として知られています。ユーザー認証については、次のトピックで説明します。
SGD は、既存の認証インフラストラクチャーとの統合、および次の 2 つの認証機構をユーザーの認証用にサポートすることを目的として設計されています。
システム認証。SGD は、LDAP ディレクトリなど、1 つ以上の外部認証サービスに基づいてユーザーの資格の認証を試みます。使用可能なシステム認証機構の詳細は、システム認証機構を参照してください。
サードパーティー認証。外部機構がユーザーを認証し、SGD はその認証が正しいものと信頼します。サードパーティー認証のもっとも一般的な使用方法は、Web サーバー認証です。詳細については、サードパーティー認証と Web サーバー認証を参照してください。
ユーザー識別情報。SGD がユーザーを誰だと認識したか。詳細については、ユーザー識別情報を参照してください。
ユーザープロファイル。ユーザーの SGD 関連の設定。詳細については、ユーザープロファイルを参照してください。
ユーザー識別情報とユーザープロファイルは同じ場合があります。
SGD Administration Console で、ユーザー識別情報またはユーザープロファイルを使って、ユーザーセッションとアプリケーションセッションを監視できます。
ユーザーの認証方法に応じて、SGD は、ユーザーが期限切れのパスワードを使ってログインを試みたときに、パスワードを変更するようユーザーに促すことができます。詳細については、パスワードの有効期限を参照してください。
SGD 認証はグローバルです。ユーザーは、同じユーザー名とパスワードを使用して、アレイ内の各 SGD サーバーにログインできます。
SGD 管理者は、次の方法で各認証機構を個別に有効/無効にできます。
ユーザー識別情報は、SGD がユーザーを誰だと認識したかということを示します。ユーザーの識別情報を判定する規則は、認証機構ごとに異なります。
ユーザー識別情報とは、SGD が割り当てた名前のことで、「完全修飾名」と呼ばれることもあります。ユーザーの識別情報は、ローカルリポジトリ内のユーザープロファイルの名前とは限りません。たとえば LDAP (Lightweight Directory Access Protocol) 認証の場合、識別情報は、LDAP リポジトリ内のユーザーの識別名 (DN) です。
ユーザー識別情報は、ユーザーの SGD セッション、アプリケーションセッション、およびアプリケーションサーバーのパスワードキャッシュのエントリに関連付けられます。
ユーザープロファイルは、ユーザーの SGD 固有の設定を制御します。LDAP ディレクトリを使用してアプリケーションをユーザーに割り当てるかどうかに応じて、ユーザープロファイルはユーザーが SGD を介してアクセスできるアプリケーション (「Webtop コンテンツ」と呼ばれることもある) を制御することもできます。ユーザープロファイルを判定する規則は、認証機構ごとに異なります。
ユーザープロファイルは、常にローカルリポジトリ内のオブジェクトであり、「同じ名前」で呼ばれることもあります。ユーザープロファイルは、System Objects 組織に格納されているプロファイルオブジェクトと呼ばれる特殊なオブジェクトである場合があります。たとえば、LDAP 認証では、デフォルトのユーザープロファイルは System Objects/LDAP Profile となります。
次の表に、使用可能なシステム認証機構、および認証のベースを示します。
機構 | 説明 |
---|---|
匿名ユーザー | ユーザーがユーザー名とパスワードを使用せずに SGD にログインできるようにします。
すべての匿名ユーザーに、同じ Webtop コンテンツが表示されます。 匿名ユーザーの認証を参照してください。 |
認証トークン | SGD Client から有効な認証トークンが発行された場合にユーザーが
SGD にログインできるようにします。
設定に応じて、ユーザーごとに異なる Webtop コンテンツが表示される場合があります。 SGD Client が統合モードで動作する場合に使用します。統合モードを参照してください。 |
UNIX システム - ローカルリポジトリ内で Unix ユーザー ID を検索する | ローカルリポジトリ内にユーザープロファイルを持ち、SGD ホスト上に UNIX
または Linux システムアカウントを持つユーザーが SGD にログインできるようにします。
設定に応じて、ユーザーごとに異なる Webtop コンテンツが表示される場合があります。 UNIX システム認証を参照してください。 |
Windows ドメイン | 指定された Windows ドメインに属しているユーザーが SGD にログインできるようにします。
設定に応じて、ユーザーごとに異なる Webtop コンテンツが表示される場合があります。 Windows ドメイン認証を参照してください。 |
LDAP | LDAP ディレクトリにエントリがあるユーザーが SGD にログインできるようにします。
設定に応じて、ユーザーごとに異なる Webtop コンテンツが表示される場合があります。 LDAP 認証を参照してください。 |
Active Directory | Active Directory ドメインにアカウントを持つユーザーが SGD
にログインできるようにします。
設定に応じて、ユーザーごとに異なる Webtop コンテンツが表示される場合があります。 Active Directory 認証を参照してください。 |
UNIX システム - ローカルリポジトリ内で Unix グループ ID を検索する | SGD ホスト上に UNIX または Linux システムアカウントを持つユーザーが
SGD にログインできるようにします。
同じ UNIX グループのすべてのユーザーに、同じ Webtop コンテンツが表示されます。 UNIX システム認証を参照してください。 |
UNIX システム - デフォルトのユーザープロファイルを使用する | SGD ホスト上に UNIX または Linux システムアカウントを持つユーザーが
SGD にログインできるようにします。
すべての UNIX ユーザーに、同じ Webtop コンテンツが表示されます。 UNIX システム認証を参照してください。 |
SecurID | RSA SecurID トークンを持つユーザーが SGD にログインできるようにします。
設定に応じて、ユーザーごとに異なる Webtop コンテンツが表示される場合があります。 SecurID 認証を参照してください。 |
ユーザーがログインするときに、有効になっている認証機構が、表 2-1 に記載されている順序で試みられます。SGD 認証を設定すると、認証機構の試みられる順序が Administration Console に表示されます。最初の認証機構でユーザーの認証に「成功」した場合、それ以降の認証機構は使用されません。
ほとんどの状況では、SGD は、事前に設定されていれば、ユーザーのパスワードの期限切れに対応することが可能です。ユーザーが有効期限の切れたパスワードを使って SGD にログインを試みると、「期限経過パスワード」ダイアログが表示されます。このダイアログでは、次のことができます。
新規パスワードが受け付けられてから、ユーザーは SGD にログインします。
次の表は、どの認証機構が期限経過パスワードをサポートしているかを示しています。
認証機構 | 期限経過パスワードのサポート |
---|---|
Active Directory | 使用可能。詳細については、Kerberos 構成ファイルを参照してください。 |
匿名ユーザー | 使用不能。ユーザー名とパスワードを使用しないでログインします。 |
認証トークン | 使用不能。ユーザー名とパスワードを使用しないでログインします。 |
LDAP | 使用可能。詳細については、LDAP 認証とパスワードの有効期限を参照してください。 |
SecurID | ユーザーの PIN が期限切れになっているときは、「期限経過パスワード」ダイアログの代わりに新規 PIN のダイアログが表示されます。 |
サードパーティー | 使用不能。ユーザーのパスワードの有効期限切れは、SGD とは無関係に、サードパーティーの認証機構により処理されます。 |
UNIX システム | 使用可能。詳細については、UNIX システム認証と PAMを参照してください。 |
Windows ドメイン | 使用不能。 |
ユーザーがリンクをクリックしてアプリケーションを起動すると、アプリケーション用に設定されているログインスクリプトがアプリケーションサーバーに接続し、認証処理後、アプリケーションを起動します。
ログインスクリプトを実行する SGD コンポーネントとして、実行プロトコルエンジンがあります。ログインスクリプトは、SGD アプリケーションサーバーのパスワードキャッシュに格納されているユーザー名とパスワードを送信することで、アプリケーションサーバーでユーザーを認証します。ユーザーの資格情報に問題がある場合、SGD に次のような「アプリケーション認証」ダイアログが表示されます。
「アプリケーション認証」ダイアログでは、ユーザーが自身の資格情報を入力し、アプリケーションサーバーのパスワードキャッシュに格納できます。パスワードキャッシュに格納することで、次回同じアプリケーションサーバー上でアプリケーションを実行したときに資格情報の入力を要求されなくなります。
また、Shift キーを押しながら Webtop 上でアプリケーションのリンクをクリックして、SGD に「アプリケーション認証」ダイアログを強制的に表示させることもできます。
SGD では、ログインスクリプトを使って、アプリケーションサーバーへの接続の処理、アプリケーションの実行、および追加の作業を行います。
ログインスクリプトは、アプリケーションサーバー間の相違を考慮に入れて、ログインプロセス中に発生する可能性のあるエラーを検査します。処理できないエラーを検出した場合、制御をユーザーに返します。
SGD ログインスクリプトは、可能なかぎりの一般性と堅牢性を備えるように設計されています。しかし、一般的ではない状況に対処しなければならない場合もあります。たとえば、サポートされていないシステムプロンプトを使用している場合は、スクリプトが認識するプロンプトのリストに、そのプロンプトを追加できます。
SGD に付属のログインスクリプトには、「アプリケーション認証」ダイアログの表示をカスタマイズするためのコマンドとプロシージャーも含まれています。たとえば、「ユーザー名」フィールドと「パスワード」フィールドにユーザー独自のラベルを追加できます。
ログインスクリプトをカスタマイズする必要がある場合は、SGD ログインスクリプトのコピーを作成し、そのコピーで作業します。標準の SGD ログインスクリプトを変更しないでください。 には、SGD ログインスクリプトに関する詳しい参照情報が記載されています。
Administration Console では、「グローバル設定」 → 「アプリケーション認証」タブの属性に基づいてアプリケーション認証を制御します。これらの属性を使用すると、次の設定を行うことができます。
SGD は、X アプリケーションおよび文字型アプリケーション用に RSA SecurID 認証をサポートしています。
SecurID 認証を使用するときは、SGD を導入する前に、ユーザーが SecurID を使用してアプリケーションサーバーにログインできることを確認してください。SecurID 認証を使用する準備ができたら、securid.exp ログインスクリプトを使用するようにアプリケーションオブジェクトを設定します。
SecurID 認証を使用するアプリケーションサーバーにログインするとき、ユーザーはユーザー名とパスワードを入力します。「OK」をクリックすると、パスコードの入力が求められます。
Administration Console で、「グローバル設定」 → 「アプリケーション認証」タブに移動し、「パスワードキャッシュの使用」チェックボックスを選択解除します。これにより、アプリケーションサーバーへのログイン時に、SGD が SGD ログインの詳細を使用しなくなります。
デフォルトでは、SGD はアプリケーションを実行するために使用するユーザー名とパスワードをそのアプリケーションサーバーのパスワードキャッシュに格納します。また、SGD は SGD へのログインに使用するユーザー名とパスワードも格納します。
Administration Console で、アプリケーションサーバーのパスワードキャッシュを次のように管理できます。
ユーザープロファイルオブジェクトの「パスワード」タブ - 選択したユーザープロファイルのパスワードキャッシュエントリを管理できます
アプリケーションサーバーオブジェクトの「パスワード」タブ - 選択したアプリケーションサーバーのパスワードキャッシュエントリを管理できます
コマンド行では、tarantella passcache コマンド群を使用してアプリケーションサーバーのパスワードキャッシュを管理します。
Administration Console とコマンド行を使用して、パスワードキャッシュ内のエントリを一覧表示したり、削除したりすることができます。また、パスワードキャッシュ内にエントリを作成することもできます。tarantella passcache コマンドを使用すると、バッチスクリプトでパスワードキャッシュを生成できます。
パスワードキャッシュ内の各エントリには次の要素が含まれます。
アプリケーションサーバーのパスワードキャッシュ内のエントリは、暗号化鍵によって暗号化されます。アプリケーションの起動時に、パスワードは必要に応じて復号化されます。
デフォルトでは、パスワードキャッシュ用の暗号キーは決して変更されません。パスワードキャッシュ用の新規暗号化鍵を SGD サーバーの再起動時に常に生成するように SGD を設定できます。Administration Console で、「グローバル設定」 → 「セキュリティー」タブに移動し、「新規パスワード暗号化鍵」チェックボックスを選択します。または、次のコマンドを実行します。
$ tarantella config edit --security-newkeyonrestart 1 |
SGD が Microsoft Windows アプリケーションサーバー用のユーザーのパスワードをキャッシュするときは、Windows ドメイン名を使ってパスワードキャッシュエントリが作成されます。
ドメイン名は、アプリケーションサーバーオブジェクト、Windows アプリケーションオブジェクト、またはユーザープロファイルオブジェクトの「ドメイン名」属性を使って指定できます。ユーザーは「アプリケーション認証」ダイアログでドメイン名を指定することもできます。
ユーザーがアプリケーションを起動すると、SGD は次のプロセスを実行して、使用するドメイン名とパスワードキャッシュエントリを確立します。
ドメイン名がアプリケーションサーバーオブジェクトで設定されているかどうか確認する。
ドメイン名がアプリケーションオブジェクトで設定されているかどうか確認する。
ユーザーが SGD へのログイン時にドメイン名のタイプを入力したかどうかを確認する。
Windows ドメイン認証を使用している場合、ユーザーは SGD へのログイン時にドメイン名を指定できます。このためには、domain\name 形式でユーザー名を入力します。たとえば、indigo\rusty のように指定します。
ドメイン名が設定されている場合、SGD はパスワードキャッシュ内でユーザー識別情報のエントリを検索します。
ドメイン名が設定されていない場合、またはパスワードキャッシュ内にエントリが存在しない場合、「アプリケーション認証」ダイアログが表示されます。
ユーザーは、「アプリケーション認証」ダイアログの「NT ドメイン」フィールドを使用してドメイン名を設定できます。「ドメイン名」属性がアプリケーションサーバーまたはアプリケーションオブジェクトで設定されている場合、またはドメインがパスワードキャッシュにキャッシュされている場合、このフィールドは自動的に入力されます。「ドメイン名」属性がユーザープロファイルオブジェクトでのみ設定されている場合、「NT ドメイン」フィールドは自動的には入力されません。
Windows アプリケーションをはじめて起動するときにドメインを指定するようユーザーに要求するには、ユーザープロファイルオブジェクト、アプリケーションサーバーオブジェクト、およびアプリケーションオブジェクトの「ドメイン名」属性を空白にする必要があります。
ユーザーの SGD パスワードが Windows ドメインパスワードでもある場合、次の条件を満たせば、ドメイン名とパスワードをキャッシュできます。
アプリケーションの起動時に異なるロケールのユーザーをサポートするには、次の手順を実行する必要がある場合があります。
デフォルトでは、SGD に含まれるログインスクリプトは、アプリケーションサーバー上で英語のシステムプロンプトをサポートしています。SGD 管理者は、他言語のシステムプロンプトのサポートを追加できます。
このためには、vars.exp ログインスクリプトを編集して、定義されている英語プロンプトごとに翻訳を追加します。vars.exp ログインスクリプトは、SGD サーバーの /opt/tarantella/var/serverresources/expect ディレクトリにあります。すべてのプロンプトを翻訳する必要はありません。英語と異なるプロンプトだけを翻訳してください。このファイルに含まれる例を参照することをお勧めします。また、クライアントやユーザーのロケールに合わせて、変数、文字列、およびエラーメッセージセクションの翻訳を追加することもできます。
Administration Console で、アプリケーションサーバーオブジェクトの「一般」タブ → 「プロンプトのロケール」属性を、vars.exp で定義されているロケールに一致するように設定します。
入力方式はプログラムまたはオペレーティングシステムコンポーネントであり、キーボードにない文字や記号をユーザーが入力できるようにします。Microsoft Windows プラットフォームでは、入力方式は 入力方式エディタ (Input Method Editor、IME) と呼ばれます。
アプリケーションの実行中、TTA_PreferredLocale、TTA_HostLocale、または LANG (アプリケーション環境によって上書き) のいずれかの環境変数が IM を必要とするロケールに設定されている場合、SGD は IM を有効にします。IM を必要とするロケールは、vars.exp ログインスクリプトで定義されている IM_localeList 変数によって制御されます。
デフォルトでは、IM はすべての日本語、韓国語、および中国語ロケールで有効になっています。
ほかのロケールで IM を有効にするには、vars.exp を編集して、IM_localeList 変数にロケールを追加する必要があります。
Active Directory 認証では、Active Directory ドメインにアカウントを持つユーザーが SGD にログインできるようにします。Active Directory 認証はユーザーに、LDAP 認証よりも高速で、安全性および拡張性の高い認証機構を提供します。Kerberos 認証プロトコルを使用することにより、SGD は、任意のユーザーをフォレスト内の任意のドメインと照合して安全に認証できます。
Active Directory 認証は、デフォルトでは無効になっています。
SGD のログイン画面で、ユーザーはユーザー主体名とパスワードを入力します。ユーザー主体名とは、「@」記号で連結されたユーザー名とドメイン名 (たとえば、indigo@indigo-insurance.com) です。
SGD では、Kerberos プロトコルを使用してドメインの鍵配布センター (KDC) にアクセスすることで、ユーザー主体名とパスワードを確認します。
Kerberos 認証が成功した場合、SGD は、Active Directory の LDAP 検索を実行することによってユーザー識別情報を確立します。次に、SGD はユーザープロファイルを検索します。詳細については、ユーザーの識別情報とユーザープロファイルを参照してください。ユーザープロファイルの「ログイン」属性が有効になっていない場合、ユーザーはログインすることができず、ほかの認証機構が試されることはありません。ユーザープロファイルの「ログイン」属性が有効な場合、ユーザーはログインできます。
ユーザーの識別情報は、LDAP 識別情報です。Administration Console では、ユーザー識別情報は LDAP-ID (LDAP) のように表示されます。コマンド行では、ユーザー識別情報は .../_service/sco/tta/ldapcache/LDAP-ID のように表示されます。
SGD は、LDAP と SGD の命名体系の差に対応できるように、ローカルリポジトリを検索してユーザープロファイルを確立します。SGD は、一致するものが見つかるまで次の検索を行います。
LDAP 人物オブジェクトと同じ名前を持つユーザープロファイル。
たとえば、LDAP 人物オブジェクトが cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com である場合、SGD はローカルリポジトリで、dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald を検索します。
LDAP 人物オブジェクトと同じ組織単位に含まれるが、cn=LDAP Profile という名前を持つユーザープロファイル。
たとえば、dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile です。
一致するものが見つからない場合は、プロファイルオブジェクト System Objects/LDAP Profile がユーザープロファイルとして使用されます。
Active Directory 認証は、Directory Services Integration とともに使用できます。Active Directory ユーザーに割り当てられるアプリケーションは、ユーザープロファイルと LDAP 検索の組み合わせに基づいて決められます。アプリケーションがユーザーに割り当てられる方法の詳細は、第 3 章を参照してください。
Active Directory 認証を設定するには、次の設定手順を実行する必要があります。
Active Directory が正しく設定されていることを確認します。
Active Directory で Kerberos 認証が有効になっている必要があります。デフォルトでは有効になっています。
Kerberos 認証に使用される KDC の詳細を使って SGD を設定します。
Kerberos 認証用の SGD の設定を参照してください。
Active Directory 認証を使用するように SGD を設定し、Active Directory のドメインの詳細を指定します。
Active Directory 認証を有効にする方法を参照してください。
Active Directory への接続は、常にセキュリティー保護されています。セキュリティー保護された接続に SSL を使用するには、追加の設定が必要です。Active Directory への SSL 接続を設定する方法を参照してください。
Active Directory 認証を使用するには、アレイ内の「すべての SGD サーバー」を Kerberos 認証用に設定する必要があります。
Kerberos 構成に加えた変更が SGD で検出されるようにするには、SGD サーバーの再起動が必要です。または、次のコマンドを使用すると、SGD サーバーを再起動しなくても、Kerberos 構成を更新できます。
$ tarantella cache --flush krbconfig |
Administration Console で Kerberos 構成の変更を検出するためには、SGD Web サーバーを再起動する必要があります。
Kerberos 認証用に SGD を設定するには、次の節で説明しているように、システムクロックを同期化し、Kerberos 構成ファイルにいくつかのエントリを追加します。
Kerberos 認証を使用するには、時刻が Microsoft Windows サーバーの Kerberos セキュリティーポリシーおよびデフォルトドメインセキュリティーポリシーに定義されている「コンピュータの時計の同期の最長トレランス」に準拠するように、アレイ内の KDC サーバーと SGD サーバー上のクロックが同期されている必要があります。これを「クロックスキュー」と呼びます。クロックスキューを超えると、Kerberos 認証が失敗します。
時刻の同期は重要であるため、Network Time Protocol (NTP) ソフトウェアを使って時刻を同期します。または、rdate コマンドを実行します。
アレイ内の各 SGD サーバーには Kerberos 構成ファイルが存在する必要があります。SGD サーバーで使用される Kerberos 構成ファイルは、次のいずれかです。
これは、/opt/tarantella/bin/jre/lib/security/krb5.conf ファイルです。
このファイルを手動で作成するか、または既存の構成ファイルをコピーする必要があります。この構成ファイルが存在する場合は、システムのデフォルト構成ファイルの代わりに使用されます。
Kerberos 構成ファイルには、Kerberos 認証を制御するための多数のオプションが含まれています。詳細は、使用しているシステムのマニュアルを参照してください。SGD には、少なくとも次の設定オプションが必要です。
パスワードの有効期限。パスワードの有効期限が切れているときに、SGD がユーザーに新しいパスワードの入力を要求するかどうか。
ネットワークプロトコル。SGD が Kerberos 認証にユーザーデータグラムプロトコル (UDP) またはトランスミッション・コントロール・プロトコル (TCP) のどちらを使用するか。
これらの設定オプションについて以降のセクションで説明します。
少なくとも、Kerberos 構成ファイルには次のセクションが含まれている必要があります。
[libdefaults]。Kerberos 認証のデフォルトを設定します。default_realm と default_checksum を設定する必要があります。
[realms]。各 Kerberos レルムの KDC を設定します。1 つのレルムに複数の KDC を設定してもかまいません。各 KDC のエントリは、host:port の書式で指定します。デフォルトポートの 88 が使用される場合は、port を省略できます。
[domain_realm]。Active Directory のドメインを Kerberos のレルムにマッピングします。
[libdefaults] default_realm = INDIGO-INSURANCE.COM default_checksum = rsa-md5 [realms] INDIGO-INSURANCE.COM = { kdc = melbourne.indigo-insurance.com } EAST.INDIGO-INSURANCE.COM = { kdc = ad01.east.indigo-insurance.com kdc = ad02.east.indigo-insurance.com } WEST.INDIGO-INSURANCE.COM = { kdc = ad01.west.indigo-insurance.com kdc = ad02.west.indigo-insurance.com } [domain_realm] indigo-insurance.com = INDIGO-INSURANCE.COM .east.indigo-insurance.com = EAST.INDIGO-INSURANCE.COM east.indigo-insurance.com = EAST.INDIGO-INSURANCE.COM .west.indigo-insurance.com = WEST.INDIGO-INSURANCE.COM west.indigo-insurance.com = WEST.INDIGO-INSURANCE.COM |
Active Directory パスワードの有効期限が切れているときに、ユーザーに新しいパスワードの入力を要求するように SGD を設定できます。それには、次に示すように、各 Kerberos レルムのパスワード変更を処理するサーバーの詳細を Kerberos 構成ファイルに追加する必要があります。
kpasswd_server = host:port admin_server = host:port kpasswd_protocol = SET_CHANGE
kpasswd_server と admin_server の行は、パスワード変更を処理する Kerberos 管理サーバーを識別します。kpasswd_server を省略した場合は、代わりに admin_server が使用されます。デフォルトポートの 464 が使用される場合は、port を省略できます。
レルムに対するパスワードの有効期限の設定例を、次に示します。
EAST.INDIGO-INSURANCE.COM = { kdc = ad01.east.indigo-insurance.com kdc = ad02.east.indigo-insurance.com admin_server = ad01.east.indigo-insurance.com kpasswd_protocol = SET_CHANGE }
KDC または Kerberos 管理サーバーにメッセージを送信するときには、SGD では UDP または TCP プロトコルが使用されます。使用されるプロトコルは、Kerberos 構成ファイルの [libdefaults] セクションにある次の行によって決まります。
udp_preference_limit = bytes
この行には、UDP を使用して送信できる最大パケット サイズ (バイト単位) を設定します。メッセージがこのサイズより大きい場合は、TCP が使用されます。つまり、KDC または管理サーバーがパッケージが大きすぎることを検出すると、代わりに TCP が使用されます。常に TCP を使用するには、udp_preference_limit を次のように設定します。
udp_preference_limit = 1
Kerberos 認証プロセスが失敗した場合は、SGD が KDC からの応答をどの程度待機するか、および各 KDC に何回接続を試みるかを制御する KDC タイムアウトを設定できます。
KDC タイムアウトを設定するには、Kerberos 構成ファイルの [libdefaults] セクションに次の行を追加します。
kdc_timeout = time max_retries = number
kdc_timeout には、KDC からの応答の最大待機時間 (ミリ秒) を設定します。max_retries は、各 KDC への最大接続試行回数です。各レルムの KDC への接続は、Kerberos 構成ファイルの [realms] セクションに設定されている順序に従って行われます。
KDC タイムアウトと LDAP 検出タイムアウトの関係は保持することを推奨します。KDC タイムアウトを増やした場合、LDAP 検出タイムアウトも増やしてください。LDAP 検出タイムアウトを参照してください。
Administration Console で、Secure Global Desktop 認証の Configuration Wizard を表示します。
「グローバル設定」 → 「Secure Global Desktop 認証」タブに移動し、「Secure Global Desktop 認証を変更」ボタンをクリックします。
「LDAP リポジトリの詳細」手順で、Active Directory ドメインの詳細を設定します。
「URL」フィールドに Active Directory ドメインの URL を入力します。
たとえば、ad://east.indigo-insurance.com のようになります。
URL は、ad:// で始まる必要があります。入力できる URL は 1 つだけです。
SGD は、このドメイン名を使用してドメインネームシステム (DNS) 検索を実行し、グローバルカタログサーバーのリストを取得します。グローバルカタログは、SGD がユーザー識別情報とユーザープロファイルを判別するために、どの Active Directory サーバーを検索できるかを決定するために使用されます。
Active Directory へのセキュリティー保護された接続を設定します。
セキュリティー保護された接続に Kerberos プロトコルだけを使用するには、「接続のセキュリティー」の Kerberos オプションを選択し、Active Directory を検索する権限を持つユーザーのユーザー名とパスワードを「ユーザー名」フィールドと「パスワード」フィールドに入力します。
セキュリティー保護された接続に Kerberos と SSL を使用するには、「接続のセキュリティー」の SSL オプションを選択し、Active Directory を検索する権限を持つユーザーのユーザー名とパスワードを「ユーザー名」フィールドと「パスワード」フィールドに入力します。
セキュリティー保護された接続に Kerberos、SSL、およびクライアント証明書を使用するには、「接続のセキュリティー」の SSL オプションを選択し、「証明書を使用する」チェックボックスを選択します。
SSL 接続を使用するために必要な追加の設定の詳細は、Active Directory への SSL 接続を設定する方法を参照してください。
ユーザー名とパスワードを入力する場合、ユーザー名にはユーザー主体名 (sgd-ldap@indigo-insurance.com など) を指定する必要があります。Active Directory 認証に予約された特別なユーザーを作成することもできます。
「ベースドメイン」フィールドに、ドメインの一部の名前を入力します。
「Base Domain」は、ログイン時にドメインの一部だけが入力された場合に使用されます。たとえば、ベースドメインが indigo-insurance.com に設定されているときに、ユーザーが rouge@west というユーザー名でログインした場合、SGD はユーザーを rouge@west.indigo-insurance.com として認証しようとします。
「デフォルトドメイン」フィールドに、デフォルトとして使用するドメイン名を入力します。
「Default Domain」は、ユーザーがログイン時にドメインを入力しなかった場合に使用されます。たとえば、デフォルトドメインが east.indigo-insurance.com に設定されているときに、ユーザーが rouge というユーザー名でログインした場合、SGD はユーザーを rouge@east.indigo-insurance.com として認証しようとします。
SSL 接続を受け入れるように、ドメインコントローラで LDAP 署名を有効にする必要があります。
使用している Active Directory サーバーの認証局 (CA) 証明書またはルート証明書を CA 証明書のトラストストアにインポートします。
セキュリティー保護された接続に SSL を使用するには、Active Directory サーバーから提示される証明書を SGD が検証できるようにする必要があります。
場合によっては、SGD で使用している Active Directory サーバーの CA 証明書を CA 証明書のトラストストアにインポートする必要があります。サポートされる CA の確認方法および CA 証明書のインポート方法の詳細は、CA 証明書トラストストアを参照してください。
(省略可能) アレイ内の SGD サーバーごとにクライアント証明書を作成してインストールします。
Active Directory への SSL 接続にクライアント証明書を使用する場合は、アレイ内の各 SGD サーバーに、Microsoft Windows サーバーの証明書サービスを使って署名された有効なクライアント証明書が必要になります。
次の手順に従って、クライアント証明書を作成およびインストールします。
SGD サーバーのクライアント証明書の証明書発行要求 (CSR) を作成します。
SGD サーバーのクライアント証明書の CSR を作成する方法を参照してください。
Microsoft 証明書サービスを使用して SGD サーバーのクライアント証明書を作成します。
Microsoft 証明書サービスを使用してクライアント証明書を作成する方法の詳細は、使用しているシステムのマニュアルを参照してください。
Microsoft Internet Explorer で、http://WindowsServer/certsrv に移動して、ログインします。
「証明書の要求の詳細設定」ページで、「Base 64 エンコード CMC または PKCS #10 ファイルを使用して証明書の要求を送信するか、または Base 64 エンコード PKCS #7 ファイルを使用して更新の要求を送信する」をクリックします。
「証明書の要求または更新要求の送信」ページで、CSR の内容を「保存された要求」ボックスにペーストするか、CSR ファイルをブラウズします。
「証明書は発行されました」ページで、Base 64 エンコードが選択されていることを確認し、「証明書のダウンロード」をクリックします。
アレイ内の各 SGD サーバーは、Active Directory へのセキュリティー保護された接続を行うことができる必要があります。
匿名ユーザーの認証では、ユーザーがユーザー名とパスワードを使用せずに SGD にログインできるようにします。
匿名ユーザーには、SGD によってそれぞれ一時的なユーザー識別情報が割り当てられます。このユーザーの識別情報は、そのユーザーがログインしている間だけ有効になります。
SGD のログイン画面で、ユーザーは、ユーザー名とパスワードを空白にしたまま「ログイン」ボタンをクリックします。
ユーザーがユーザー名またはパスワードを入力した場合は、認証が失敗し、次の認証機構が試されます。
ユーザー名とパスワードが両方とも空の場合、ユーザーは認証されてログインします。
ユーザーはログイン時にユーザー名またはパスワードを入力しないため、SGD によって一時的なユーザー識別情報が割り当てられます。Administration Console では、ユーザー識別情報は server:number (anon) のように表示されます。コマンド行では、ユーザー識別情報は .../_dns/server/_anon/number のように表示されます。
プロファイルオブジェクト System Objects/Anonymous Profile が常にユーザープロファイルとして使用されます。すべての匿名ユーザーに、同じ Webtop コンテンツが表示されます。
匿名でログインしたユーザーは、それぞれ独立したアプリケーションセッションを使用します。アプリケーションが常に再開可能に設定されている場合でも、ユーザーがログアウトすると、アプリケーションセッションは自動的に終了します。
すべてのパスワードキャッシュエントリは、System Objects/Anonymous User Profile オブジェクトに属します。すべての匿名ユーザーが同一のアプリケーションサーバーパスワードを共有します。匿名ユーザーは、パスワードキャッシュのエントリを追加または変更することができません。つまり、SGD 管理者が tarantella passcache コマンドを使用して System Objects/Anonymous User Profile オブジェクトのアプリケーションサーバーパスワードをキャッシュしていないかぎり、匿名ユーザーはアプリケーションを起動するたびにパスワードの入力を要求されます。
LDAP 認証では、LDAP ディレクトリにエントリがあるユーザーが SGD にログインできるようにします。
SGD のログイン画面で、ユーザーはユーザー名とパスワードを入力します。ユーザー名には、次のいずれかを指定できます。
SGD は、LDAP ディレクトリを検索して、ユーザーが入力したユーザー名と一致する属性を持つ人物オブジェクトを探します。デフォルトでは、SGD は次の属性を検索します。
一致する人物オブジェクトがない場合は、次の認証機能が試されます。
人物オブジェクトが見つかった場合、ユーザーが入力したパスワードを、LDAP 人物オブジェクトと照合します。認証が失敗した場合は、次の認証機構が試されます。
認証が成功した場合、SGD はローカルリポジトリを検索してユーザープロファイルを探します。詳細は、ユーザーの識別情報とユーザープロファイルを参照してください。ユーザープロファイルの「ログイン」属性が有効になっていない場合、ユーザーはログインすることができず、ほかの認証機構が試されることはありません。ユーザープロファイルの「ログイン」属性が有効な場合、ユーザーはログインできます。
ユーザーの識別情報は、LDAP 識別情報です。Administration Console では、ユーザー識別情報は LDAP-ID (LDAP) のように表示されます。コマンド行では、ユーザー識別情報は .../_service/sco/tta/ldapcache/LDAP-ID のように表示されます。
SGD は、LDAP と SGD の命名体系の差に対応できるように、ローカルリポジトリを検索してユーザープロファイルを確立します。SGD は、一致するものが見つかるまで次の検索を行います。
LDAP 人物オブジェクトと同じ名前を持つユーザープロファイル。
たとえば、LDAP 人物オブジェクトが cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com である場合、SGD はローカルリポジトリで、dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald を検索します。
LDAP 人物オブジェクトと同じ組織単位に含まれるが、cn=LDAP Profile という名前を持つユーザープロファイル。
たとえば、dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile です。
一致するものが見つからない場合は、プロファイルオブジェクト System Objects/LDAP Profile がユーザープロファイルとして使用されます。
LDAP 認証は、Directory Services Integration とともに使用できます。LDAP ユーザーに割り当てられるアプリケーションは、ユーザープロファイルと LDAP 検索の組み合わせに基づいて決められます。アプリケーションがユーザーに割り当てられる方法の詳細は、第 3 章を参照してください。
SGD では、version 3 の標準 LDAP プロトコルがサポートされます。LDAP 認証は、LDAP version 3 に準拠する任意のディレクトリサーバーとともに使用できます。SGD は、次のディレクトリサーバーでこの機能をサポートしています。
SGD Administration Console で、Secure Global Desktop 認証の Configuration Wizard を表示します。
「グローバル設定」 → 「Secure Global Desktop 認証」タブに移動し、「Secure Global Desktop 認証を変更」ボタンをクリックします。
「LDAP リポジトリの詳細」手順で、LDAP ディレクトリの詳細を設定します。
「リポジトリタイプ」で、「LDAP」オプションを選択します。
Microsoft Active Directory サーバーを使用している場合でも、このオプションを選択してください。
「URL」フィールドに、1 つ以上の LDAP ディレクトリサーバーの URL を入力します。
たとえば、ldap://melbourne.indigo-insurance.com のように入力します。
複数の URL が存在する場合、SGD は記載されている順に URL を使用します。リスト内の最初の LDAP ディレクトリサーバーを使用できない場合に、次の LDAP ディレクトリサーバーの使用が試みられます。
LDAP ディレクトリサーバーへのセキュリティー保護された接続を使用するには、ldaps:// URL を入力します。
セキュリティー保護された接続を使用するには、LDAP ディレクトリサーバーから提示される証明書を SGD が検証できるようにする必要があります。場合によっては、SGD で使用している LDAP ディレクトリサーバーの CA 証明書を CA 証明書のトラストストアにインポートする必要があります。サポートされる CA の確認方法および CA 証明書のインポート方法の詳細は、CA 証明書トラストストアを参照してください。
LDAP ディレクトリサーバーへの接続に使用される標準ポートは、ポート 389 です。LDAP ディレクトリサーバーが別のポートを使用する場合は、そのポート番号を URL に含める必要があります。たとえば、ldap://melbourne.indigo-insurance.com:5678 のように指定します。
サーチルートを URL の最後に追加すると (例: ldap://melbourne.indigo-insurance.com/dc=indigo-insurance,dc=com)、ユーザー識別情報の検索に使用する LDAP ディレクトリの部分を制限できます。
「User Name」および「Password」フィールドに LDAP ユーザーの詳細情報を入力します。
ユーザー名は、ユーザーの識別名にする必要があります。たとえば、cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com のように指定します。
一部の LDAP ディレクトリサーバーでは匿名ログインがサポートされるため、ユーザー名やパスワードを入力する必要はありません。その他 (Microsoft Active Directory など) の場合は、LDAP ディレクトリの検索権限を有するユーザーのユーザー名とパスワードを入力する必要があります。
入力できるユーザー名とパスワードは 1 組だけであるため、このユーザーが「URL」フィールドに記載されたすべての LDAP ディレクトリサーバーを検索できる必要があります。
LDAP ディレクトリサーバー上でユーザーのパスワードの有効期限が切れている場合、SGD はユーザーに新規パスワードの入力を求めることができます。次の手順に従って、追加の設定が必要になることがあります。
Sun Java System Directory Server (以前の Sun ONE、Netscape ソフトウェア、または iPlanet Directory Server) Sun One Directory Server の場合は、次の点を確認してください。
グローバルパスワードポリシーと個別パスワードポリシーのどちらの場合でも、「User must change password after reset」オプションは使用しないでください。このオプションを使用すると、パスワードの変更が失敗します。
LDAP 認証の「ユーザー名」および「パスワード」フィールドに入力する LDAP ユーザーは、管理者特権を保持している必要があります。
Microsoft Active Directory の場合、パスワードの有効期限 (次回ログオン時にパスワードの変更をユーザーに強制することも含む) を処理できるのは、SGD サーバーと Active Directory サーバーとの間にセキュリティー保護された接続が存在するときだけです。
LDAP 認証が有効になっていると、LDAP ディレクトリ内にエントリを持つ任意のユーザーが SGD にログインできます。ただし、SGD にアクセスできる LDAP ユーザーを制限しなければならない場合もあります。
SGD にログインできる LDAP ユーザーを制限するには、LDAP ログインフィルタを設定して、LDAP 人物オブジェクトに必要な属性値が設定されているユーザーだけが SGD にログインできるようにします。このようにするには、LDAP ディレクトリと SGD に追加の設定を行う必要があります。
SGD でフィルタを適用するには、LDAP ディレクトリサーバーで人物オブジェクトの属性値を検査できるようにする必要があります。このとき、LDAP ディレクトリにすでに存在する属性を使用する方法と、allowsgdlogin のような新しい属性を作成する方法があります。この属性は、LDAP ディレクトリ内のすべてのユーザーに設定されている必要があります。
LDAP ユーザーオブジェクトの属性を設定したら、ログインフィルタを設定します。このログインフィルタでは、LDAP 属性を検査して、条件を満たすユーザーだけがログインできるようにします。LDAP ログインフィルタを設定する方法を参照してください。
SecurID 認証では、RSA SecurID トークンを持つユーザーが SGD にログインできるようにします。SGD は、ユーザーを RSA Authentication Manager (以前の ACE/Server) と照合して認証します。
RSA SecurID は RSA Security, Inc. の製品で、ユーザーが知っていること (PIN) およびユーザーが所持しているもの (PIN パッド、標準カード、ソフトウェアトークンなどの別のトークンから提供されるトークンコード) という 2 つのファクタから成る認証を実行します。PIN およびトークンコードを組み合わせると、パスコードになります。このパスコードが、SGD にログインするときのパスワードとして使用されます。
SGD のログイン画面で、ユーザーは SecurID ユーザー名 (たとえば、indigo) およびパスコードを入力します。
この認証機構は、ローカルリポジトリ内で、ユーザーの入力したユーザー名に合致する「名前」属性を持つユーザープロファイルを検索します。一致する人物オブジェクトがない場合、「ログイン名」属性を対象に、最後に「電子メールアドレス」属性を対象に検索を繰り返します。
ユーザープロファイルが見つかった場合は、そのオブジェクトの「ログイン名」属性が SecurID ユーザー名として使用されます。ユーザープロファイルが見つからない場合は、ユーザーが入力した名前が SecurID ユーザー名として使用されます。
次に、SGD は、ユーザーの入力した SecurID ユーザー名およびパスコードを RSA Authentication Manager と照合します。認証が失敗した場合は、使用できる認証機構がほかに存在しないため、ユーザーはログインできません。
認証が成功しても、ユーザープロファイルの「ログイン」属性が有効になっていない場合、ユーザーはログインできません。認証が成功して、ユーザープロファイルの「ログイン」属性が有効になっている場合に、ユーザーはログインできます。
ユーザープロファイルがローカルリポジトリ内に見つかった場合、そのプロファイルがユーザーの識別情報とユーザープロファイルに使用されます。Administration Console では、ユーザー識別情報は user-profile (Local) のように表示されます。コマンド行では、ユーザー識別情報は .../_ens/user-profile のように表示されます。
ローカルリポジトリ内にユーザープロファイルが見つからない場合は、ユーザーの識別情報が SecurID ユーザー名になります。Administration Console では、ユーザー識別情報は SecurID-username (SecurID) のように表示されます。コマンド行では、ユーザー識別情報は .../_service/sco/tta/securid/SecurID-username のように表示されます。プロファイルオブジェクト System Objects/SecurID User Profile がユーザープロファイルとして使用されます。
SecurID 認証を設定するには、次の設定手順を実行する必要があります。
使用している RSA SecurID がサポート対象のバージョンであることを確認します。サポートされている SecurID バージョンを参照してください。
RSA Authentication Manager が最新版であり、RSA によってリリースされた最新のパッチが適用されていることを確認します。
アレイ内の各 SGD サーバーを Agent Host として設定します。
アレイ内の各 SGD サーバーは、Agent Host のように動作するので、ユーザーを RSA Authentication Manager と照合して認証できます。
SGD サーバーを Agent Host として設定を参照してください。
SecurID 認証を設定して、SecurID ユーザーが SGD にログインできるようにします。
SecurID 認証を有効にする方法を参照してください。
SecurID 認証を使用するには、アレイ内の各 SGD サーバーを Agent Host として設定する必要があります。SecurID 実装にはさまざまな種類があるため、次に示す手順は参考例にすぎません。Agent Host の設定方法の詳細は、使用している SecurID のマニュアルを参照してください。
SGD サーバーがネットワーク上の RSA Authentication Manager と通信できることを確認します。
SGD サーバーが RSA Authentication Manager と通信できるようにするために、ファイアウォールでポートを開くことが必要になる場合があります。
SGD が構成ファイルを読み書きできるようにファイルアクセス権を設定します。
# chmod 444 /etc/sdace.txt # chown -R ttasys:ttaserv /opt/ace # chmod -R 775 /opt/ace |
SGD サーバーを Agent Host として、RSA Authentication Manager データベースに登録します。
RSA Authentication Manager データベース管理アプリケーション、または sdadmin アプリケーションを使用します。
SGD サーバーを、完全修飾名 server.domain.com を使用して、UNIX Agent Host としてデータベースに追加します。
Agent Host ごとに、Group Activation または User Activation を設定します。また、「Open to All Locally Known User」オプションを設定してもかまいません。
サードパーティー認証では、外部機構で認証されたユーザーが SGD にログインできるようにします。
SGD Webtop を使用している場合、使用できるサードパーティー認証の形式は Web サーバー認証だけです。SGD Web サービスを使用してユーザー独自の Webtop アプリケーションを開発する場合は、任意のサードパーティー認証機構を使用できます。
ユーザーは、通常は Web ブラウザの認証ダイアログを使って、ユーザー名とパスワードを外部機構に直接入力します。
サードパーティー認証は、信頼に基づきます。SGD は、サードパーティー機構がユーザーを正しく認証したと信じているため、ユーザーは SGD に対しても認証されます。
次に、SGD は検索を行って、ユーザー識別情報とユーザープロファイルを確立します。SGD は、ユーザー識別情報とユーザープロファイルを確立するための次の検索方法をサポートしています。
複数の検索方法が有効になっている場合は、各検索方法が上記の順序で試行されます。最初に一致したユーザー識別情報が使用されます。検索方法については、後続のセクションを参照してください。
検索を実行しても一致するものが存在しない場合、SGD はユーザー識別情報を確立できないため、ユーザーはログインできません。SGD Webtop を使用している場合は、標準ログインページが表示されるため、ユーザーはシステム認証を使ってログインできます。
「ローカルリポジトリの検索」方法では、ローカルリポジトリを検索して、ユーザーのサードパーティーユーザー名に一致する「名前」属性を含むユーザープロファイルを探します。一致する人物オブジェクトがない場合、「ログイン名」属性を対象に、最後に「電子メールアドレス」属性を対象に検索を繰り返します。一致するユーザープロファイルがない場合は、次の検索方法が試されます。
「LDAP リポジトリを検索」方法では、LDAP ディレクトリを検索して、cn (共通名) 属性が、ユーザーによって入力されたユーザー名と一致する人物オブジェクトを探します。一致する人物オブジェクトがない場合、uid (ユーザー名) 属性を対象に、最後に mail (電子メールアドレス) 属性を対象に検索を繰り返します。一致する人物オブジェクトがない場合は、次の検索方法が試されます。
人物オブジェクトが見つかった場合は、そのオブジェクトがユーザーの識別情報として使用されます。Administration Console では、ユーザー識別情報は LDAP-ID (LDAP) のように表示されます。コマンド行では、ユーザー識別情報は .../_service/sco/tta/ldapcache/LDAP-ID のように表示されます。
次に、SGD はユーザープロファイルを検索します。ユーザープロファイルを検索するときは、「デフォルトの LDAP プロファイルを使用」または「もっとも近い LDAP プロファイルを使用」を指定できます。「デフォルトの LDAP プロファイルを使用」がデフォルトです。
「デフォルトの LDAP プロファイルを使用」が選択されている場合は、プロファイルオブジェクト System Objects/LDAP Profile がユーザープロファイルとして使用されます。
「もっとも近い LDAP プロファイルを使用」が選択されている場合、SGD は、LDAP と SGD の命名体系の差に対応できるように、ローカルリポジトリを検索することでユーザープロファイルを確立します。SGD は、一致するものが見つかるまで次の検索を行います。
LDAP 人物オブジェクトと同じ名前を持つユーザープロファイル。
たとえば、LDAP 人物オブジェクトが cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com である場合、SGD はローカルリポジトリで、dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald を検索します。
LDAP 人物オブジェクトと同じ組織単位に含まれるが、cn=LDAP Profile という名前を持つユーザープロファイル。
たとえば、dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile です。
一致するものが見つからない場合は、プロファイルオブジェクト System Objects/LDAP Profile がユーザープロファイルとして使用されます。
SGD Administration Console で、Secure Global Desktop 認証の Configuration Wizard を表示します。
「グローバル設定」 → 「Secure Global Desktop 認証」タブに移動し、「Secure Global Desktop 認証を変更」ボタンをクリックします。
「サードパーティーの認証 - ユーザー識別情報とユーザープロファイル」の手順で、ユーザーの識別情報の検索方法として、1 つ以上のチェックボックスを選択します。
検索方法の詳細については、サードパーティー認証の仕組みを参照してください。
「LDAP リポジトリを検索」チェックボックスが選択されている場合は、LDAP ユーザープロファイルを検索するオプションを選択します。
(省略可能) 「LDAP リポジトリの詳細」手順で、LDAP ディレクトリの詳細を設定します。
「LDAP リポジトリの詳細」手順が表示されるのは、手順 3 で LDAP 検索方法を選択した場合だけです。
「リポジトリタイプ」で、「LDAP」オプションを選択します。
Microsoft Active Directory サーバーを使用している場合でも、このオプションを選択してください。
「URL」フィールドに、1 つ以上の LDAP ディレクトリサーバーの URL を入力します。
たとえば、ldap://melbourne.indigo-insurance.com のように入力します。
複数の URL が存在する場合、SGD は記載されている順に URL を使用します。リスト内の最初の LDAP ディレクトリサーバーを使用できない場合に、次の LDAP ディレクトリサーバーの使用が試みられます。
LDAP ディレクトリサーバーへのセキュリティー保護された接続を使用するには、ldaps:// URL を入力します。
セキュリティー保護された接続を使用するには、LDAP ディレクトリサーバーから提示される証明書を SGD が検証できるようにする必要があります。場合によっては、SGD で使用している LDAP ディレクトリサーバーの CA 証明書を CA 証明書のトラストストアにインポートする必要があります。サポートされる CA の確認方法および CA 証明書のインポート方法の詳細は、CA 証明書トラストストアを参照してください。
LDAP ディレクトリサーバーへの接続に使用される標準ポートは、ポート 389 です。LDAP ディレクトリサーバーが別のポートを使用する場合は、そのポート番号を URL に含める必要があります。たとえば、ldap://melbourne.indigo-insurance.com:5678 のように指定します。
サーチルートを URL の最後に追加すると (例: ldap://melbourne.indigo-insurance.com/dc=indigo-insurance,dc=com)、ユーザー識別情報の検索に使用する LDAP ディレクトリの部分を制限できます。
「User Name」および「Password」フィールドに LDAP ユーザーの詳細情報を入力します。
ユーザー名は、ユーザーの識別名にする必要があります。たとえば、cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com のように指定します。
一部の LDAP ディレクトリサーバーでは匿名ログインがサポートされるため、ユーザー名やパスワードを入力する必要はありません。その他 (Microsoft Active Directory など) の場合は、LDAP ディレクトリの検索権限を有するユーザーのユーザー名とパスワードを入力する必要があります。
入力できるユーザー名とパスワードは 1 組だけであるため、このユーザーが「URL」フィールドに記載されたすべての LDAP ディレクトリサーバーを検索できる必要があります。
Web サーバー認証、つまり HTTP (Hypertext Transfer Protocol) 認証は、サードパーティー認証のもっとも一般的な使用方法です。Web サーバー認証では、Web サーバーが認証を実行し、SGD がユーザー識別情報とユーザープロファイルを判定します。
Web サーバー認証の利点は、REMOTE_USER 環境変数が設定されさえすれば、任意の Web サーバー認証プラグインを使用できることです。使用する認証プラグインが別の変数を設定する場合、それをサポートするように SGD を設定できます。Web サーバー認証での認証プラグインの使用を参照してください。
Web サーバー認証とシステム認証は一緒に使用できます。少なくとも 1 つのシステム認証機構を、フォールバック用に使用可能にしておくのが最善です。SGD がユーザーのユーザープロファイルを検出できない場合、システム認証機構を使ってユーザーが認証を実行できるように、SGD の標準ログインページが表示されます。
Web サイトのセクションは、Web サーバー管理者が保護しています。SGD の場合、これは通常、http://server.example.com/sgd URL です。ここで、server.example.com は SGD サーバーの名前です。
その保護されたセクションの URL に Web ブラウザから最初にアクセスしようとすると、Web サーバーが認証の要求で応答します。
Web サーバーがユーザーの資格情報を認証し、要求された URL へのアクセスを許可します。SGD ユーザーは、自分の Webtop に直接移動します。
保護された URL に対する要求があるたびにユーザーの資格情報を送信する必要があるため、Web ブラウザは資格情報をキャッシュします。証明書は、ブラウザから自動的に送信されます。証明書のキャッシュ方法には、次の種類があります。
Web サーバーは、ユーザーの認証を実行したあとで、REMOTE_USER 環境変数を設定します。この変数には、認証されたユーザーのユーザー名が含まれています。SGD は REMOTE_USER 変数の値を取得し、それを使ってユーザー識別情報とユーザープロファイルを検索します。SGD は、ユーザー識別情報とユーザープロファイルを確立するための 4 つの検索方法をサポートしています。サードパーティー認証の仕組みを参照してください。
SGD で Web サーバー認証を実行する場合のセキュリティー上の主な考慮事項を次に示します。
Web ブラウザのキャッシュ。Web サーバー認証では、Web ブラウザがユーザーの資格情報をキャッシュします。これは、事実上、Web ブラウザが SGD に対する認証をキャッシュすることと同義です。キャッシュされた資格情報を他人に使用される危険性を最小限に抑えるため、ユーザーは次の操作を実行する必要があります。
セキュリティーが確保されている Web サーバー。セキュリティーが確保されている (HTTPS) Web サーバーを使って、ユーザーの資格情報がプレーンテキストで送信されるのを防ぎます。
信頼できるユーザー。SGD Webtop および SGD サーバーが、信頼できるユーザーのユーザー名とパスワードという共有シークレットを持つため、SGD は Web サーバーの認証を信頼できます。この信頼できるユーザーの資格情報は、SGD のインストール時にデフォルトで作成されます。これらの資格情報を変更することをお勧めします。変更方法の詳細は、信頼されているユーザーとサードパーティー認証を参照してください。
Web サーバー認証を有効にするには、Web サーバーと SGD の両方を設定する必要があります。
Web サーバー認証を使用できるように Web サーバーを設定するには、各 SGD ホストで /sgd URL を保護します。/sgd URL を保護する方法は、Web サーバーによって異なります。詳細は、Web サーバーのマニュアルを参照してください。SGD Web サーバーの場合は、Apache または Tomcat コンポーネントで /sgd URL を保護することができます。この方法の例については、SGD Web サーバーで Web サーバー認証を有効にする方法を参照してください。
Web サーバー認証をサポートするように SGD を設定するには、サードパーティー認証を有効にする必要があります。サードパーティー認証を有効にする方法を参照してください。
/opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25/bin/htpasswd プログラムを使用して Web サーバーのパスワードファイルを作成し、エントリを追加します。
Apache 構成ファイルを編集して、/sgd URL を保護します。
Apache 構成ファイルは /opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25/conf/httpd.conf です。
SetEnvIf Request_URI "\.(class|cab|jar|gif|der)$" sgd_noauth_ok <LocationMatch /sgd> Order Allow,Deny Allow from env=sgd_noauth_ok AuthUserFile file-path AuthName auth-domain Authtype Basic Require valid-user Satisfy any </LocationMatch>
file-path は Web サーバーのパスワードファイルへのフルパス、auth-domain は Web ブラウザの認証ダイアログに表示される認証レルムの名前です。
SetEnvIf 指令は、SGD Web サーバーの開始画面の操作に影響を与えることなく /sgd URL を保護します。
注 - SGD Web サーバーは /sgd URL の管理を Tomcat に委譲するため、Directory 指令ではなく LocationMatch 指令を使用する必要があります。これは、Apache 構成ファイル内で設定されるため、.htaccess ファイルを使って /sgd URL を保護することはできません。 |
Web サーバーの認証を信頼するように SGD Web サーバーの Tomcat コンポーネントを設定する必要があります。
Tomcat 構成ファイルは、/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml です。
Coyote/JK2 AJP 1.3 Connector の設定を修正します。
次のように、tomcatAuthentication="false" 属性を <Connector> 要素に追加します。
<!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 --> <Connector port="8009" minProcessors="5" maxProcessors="75" enableLookups="true" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="0" useURIValidationHack="false" tomcatAuthentication="false" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
SGD Web サーバー認証では、Web サーバーの REMOTE_USER 環境変数の設定に基づいてユーザーが識別されます。Web サーバー認証に認証プラグインを使用する場合は、プラグインが別の環境変数を使ってユーザーを識別する可能性があります。
SGD には、REMOTE_USER 環境変数のほかに、SSL_CLIENT_S_DN_CN 変数のサポートも含まれています。この環境変数は、Web サーバー認証でクライアント証明書を使用するときに設定されます。この変数のサポートを有効にする方法の詳細は、Web サーバー認証でのクライアント証明書の使用を参照してください。
使用しているプラグインが別の環境変数を使用する場合は、その環境変数をサポートするように Webtop Web アプリケーションを設定する必要があります。Web サーバー認証でその他の環境変数のサポートを有効にする方法を参照してください。
使用する変数を Tomcat コンポーネントに転送するように、SGD Web サーバーの Apache コンポーネントを設定します。
ファイルは /opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25/conf/httpd.conf です。
次のように、既存の JKEnvVar 指令を検索して、ユーザー独自の変数用の指令を追加します。
#JkEnvVar SSL_CLIENT_S_DN_CN " " #JkEnvVar HTTP_SAFEWORD_USER " " JKEnvVar Your-Variable " "
次のように、Location 指令からコメント記号 (#) を削除します。
<Location "/sgd"> SSLOptions +StdEnvVars +ExportCertData </Location>
Web サーバー認証のセキュリティーを強化するために、有効な公開鍵インフラストラクチャー (PKI) 証明書がクライアントデバイスにインストールされているユーザーだけを認証するようにできます。
PKI 証明書を使用するには、クライアント証明書が必要となる /sgd URL にアクセスするように Web サーバーを設定します。SGD Web サーバーには、PKI クライアント証明書の設定に使用できる Apache の mod_ssl モジュールが含まれています。
SGD Web サーバー認証では、Web サーバーの REMOTE_USER 変数の設定に基づいてユーザーが識別されます。ただし、クライアント証明書を使ってユーザーが認証される場合は、通常、別の環境変数がユーザーの識別に使用されます。Apache Web サーバー (SGD Web サーバーを含む) では、SSL_CLIENT_S_DN_CN 変数が使用されます。この変数のサポートを追加する方法の詳細は、SSL_CLIENT_S_DN_CN 変数のサポートを有効にする方法を参照してください。使用している Web サーバーが別の変数を設定する場合は、Web サーバー認証でその他の環境変数のサポートを有効にする方法を参照してください。
SSL_CLIENT_S_DN_CN 変数を Tomcat コンポーネントに転送するように、SGD Web サーバーの Apache コンポーネントを設定します。
ファイルは /opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25/conf/httpd.conf です。
JkEnvVar 指令を有効にして、SSL_CLIENT_S_DN_CN 変数を転送します。
次のように、既存の JKEnvVar 指令を検索して、SSL_CLIENT_S_DN_CN 変数のコメント記号 (#) を削除します。
JkEnvVar SSL_CLIENT_S_DN_CN " " #JkEnvVar HTTP_SAFEWORD_USER " "
/SGD の位置で、SSL_CLIENT_S_DN_CN 変数を使用可能にします。
次のように、Location 指令からコメント記号 (#) を削除します。
<Location "/sgd"> SSLOptions +StdEnvVars +ExportCertData </Location>
デフォルトでは、サードパーティー認証は SGD 管理者が SGD にログインすることを許可しません。これはセキュリティー対策です。この動作を変更するには、次のコマンドを使用します。
$ tarantella config edit \ --tarantella-config-login-thirdparty-allowadmins 1 |
サードパーティー認証を使用すると、ユーザーは SGD サーバーに対して認証を行わなくても SGD にアクセスできます。SGD は、サードパーティー認証機構を信頼することができます。これは、Webtop などのクライアントアプリケーションと SGD サーバーが、信頼できるユーザーのユーザー名とパスワードという共有シークレットを持つためです。
標準インストールでは、信頼されているユーザーは 1 人しかいません。ただし、次の場合には、信頼できるユーザーを追加することをお勧めします。
Webtop を別のホストの別の JavaServer Pages (JSP) コンテナに再配置する場合。詳細については、Webtop を再配置するを参照してください。
SGD com.tarantella.tta.webservices.client.views パッケージを使用して、SGD と同じホスト上または別のホスト上で、ユーザー独自のクライアントアプリケーションを開発する場合。
アレイ内の各 SGD サーバーで、信頼できるユーザーの「データベース」を作成および維持します。データベースは、SGD サーバー間で共有されません。信頼できるユーザーを追加する方法の詳細は、信頼できるユーザーを新規作成する方法を参照してください。次の点に注意してください。
信頼できるユーザーを SGD サーバーに格納するには、tarantella webserver add_trusted_user コマンドを実行する必要があります。
既存の信頼できるユーザーのパスワードを変更するには、最初に tarantella webserver delete_trusted_user コマンドでユーザーを削除してから、ユーザーを作成し直します。
SGD Web サービスを使用してユーザー独自のアプリケーションを開発する場合は、ITarantellaExternalAuth Web サービスがサードパーティー認証で使用されます。この Web サービスは、「基本」Web サーバー認証によって保護されます。したがって、信頼できるユーザーの資格情報を使用しないと、このサービスにアクセスできません。設定方法は次のとおりです。
http://SGD-server/axis/services/document/externalauth URL は、Axis Web アプリケーション /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/axis/WEB-INF/web.xml の構成ファイルで保護されます。
SGD Web サーバーの Tomcat コンポーネントは、Tomcat の MemoryRealm と SHA (Secure Hash Algorithm) ダイジェストパスワードを使用して、「基本」Web サーバー認証をサポートするように設定されます。この設定は、Tomcat 構成ファイル /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml で行われます。
信頼できるユーザーのリストは、Tomcat のユーザー構成ファイル /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/tomcat-users.xml に格納されます。
com.tarantella.tta.webservices.client.views パッケージを使用してユーザー独自のクライアントアプリケーションを開発した場合は、Webtop と同じ方法で、開発したアプリケーションの信頼できるユーザーの資格情報を格納できます。信頼できるユーザーを新規作成する方法を参照してください。それ以外の場合は、資格情報を保存する方法を新しく開発する必要があります。
新規の信頼できるユーザーを、Webtop アプリケーションの Web サービスリソースファイルに追加します。
Webtop を別のホストに再配置してある場合は、この手順を遠隔ホストで実行する必要があります。
信頼されているユーザーのユーザー名とパスワードをエンコードします。
# /opt/tarantella/bin/jre/bin/java -classpath \ /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/shared/lib/sgd-webservices.jar \ com.tarantella.tta.webservices.client.views.SgdPasswd \ --encode username:password |
# cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2 # cd shared/classes/com/tarantella/tta/webservices/client/views |
UNIX システム認証では、SGD ホストに UNIX または Linux システムアカウントを持つユーザーが SGD にログインできるようにします。
UNIX システム認証は、デフォルトで有効に設定されています。
ユーザーを UNIX または Linux システムのユーザーデータベースと照合して認証し、ユーザー識別情報およびプロファイルを決定するために、UNIX システム認証がサポートする検索方法は次のとおりです。
SGD のログイン画面で、ユーザーはユーザー名とパスワードを入力します。ユーザー名には、次のいずれかを指定できます。
SGD は、ユーザーの入力した内容と一致する「名前」属性を持つユーザープロファイルを、ローカルリポジトリ内で検索します。一致する人物オブジェクトがない場合、「ログイン名」属性を対象に、最後に「電子メールアドレス」属性を対象に検索を繰り返します。ユーザープロファイルが見つからない場合、次のログイン認証機構が試されます。
ユーザープロファイルが見つかると、そのオブジェクトの「ログイン名」属性が UNIX または Linux システムユーザー名として使用されます。このユーザー名およびユーザーの入力したパスワードが、UNIX または Linux システムユーザーデータベースと照合されます。認証が失敗した場合は、次の認証機構が試されます。
認証が成功しても、ユーザープロファイルの「ログイン」属性が有効になっていない場合、ユーザーはログインできず、ほかの認証機構が試されることはありません。認証が成功して、ユーザープロファイルの「ログイン」属性が有効になっている場合に、ユーザーはログインできます。
SGD は、ユーザーがログイン画面で入力したユーザー名およびパスワードを、UNIX または Linux システムユーザーデータベースと照合します。
認証が成功した場合、SGD はユーザープロファイルを検索します。詳細については、ユーザーの識別情報とユーザープロファイルを参照してください。ユーザープロファイルオブジェクトの「ログイン」属性が有効になっていない場合、ユーザーはログインすることができず、ほかの認証機構が試されることはありません。ユーザープロファイルの「ログイン」属性が有効な場合、ユーザーはログインできます。
ユーザーの識別情報は、UNIX または Linux システムのユーザー名です。Administration Console では、ユーザー識別情報は UNIX-username (UNIX) のように表示されます。コマンド行では、ユーザー識別情報は .../_user/UNIX-username のように表示されます。
SGD は、ローカルリポジトリ内でユーザープロファイル cn=gid を検索します。ここで、gid は、認証されたユーザーの UNIX グループ ID です。見つかった場合、そのオブジェクトをユーザープロファイルとして使用します。ユーザーが複数のグループに所属している場合は、そのユーザーのプライマリグループまたは実効グループが使用されます。ユーザープロファイルがローカルリポジトリ内に見つからない場合、プロファイルオブジェクト System Objects/UNIX User Profile がユーザープロファイルとして使用されます。
SGD は、PAM (Pluggable Authentication Modules) をサポートします。UNIX システム認証では、ユーザー認証、アカウント操作、およびパスワード操作に PAM が使用されます。
UNIX ユーザーが有効期限の切れたパスワードを使ってログインしようとした場合に、新規パスワードの入力を要求するよう SGD を設定するには、SGD サーバーに PAM インタフェースがインストールされている必要があります。PAM インタフェースがインストールされていない場合、SGD は有効期限の切れたパスワードをサポートできません。この場合、サーバーの起動時にエラーメッセージが /opt/tarantella/var/log/pemanagerpid_error.log に記録されます。
SGD を Linux プラットフォームにインストールすると、SGD Setup プログラムにより、passwd プログラムの現在の設定がコピーされ、/etc/pam.d/tarantella ファイルが作成されて、SGD 用の PAM 設定エントリが自動的に作成されます。Solaris OS プラットフォームでは、/etc/pam.conf ファイル内に tarantella の新規エントリを追加する必要があります。
SGD Administration Console で、Secure Global Desktop 認証の Configuration Wizard を表示します。
「グローバル設定」 → 「Secure Global Desktop 認証」タブに移動し、「Secure Global Desktop 認証を変更」ボタンをクリックします。
「Unix 認証 - ユーザープロファイル」の手順で、ユーザープロファイルの検索方法として、1 つ以上のチェックボックスを選択します。
検索方法の詳細は、UNIX システム認証の動作を参照してください。
Windows ドメイン認証では、指定された Windows 2000 または Windows 2003 Server ドメインに属しているユーザーが SGD にログインできるようにします。
Windows ドメイン認証は、デフォルトでは無効になっています。
SGD のログイン画面で、ユーザーはユーザー名とパスワードを入力します。ユーザー名には、次のいずれかを指定できます。
SGD は、ローカルリポジトリを検索して、「名前」属性が、ユーザーによって入力されたユーザー名に一致するユーザープロファイルを探します。一致する人物オブジェクトがない場合、「ログイン名」属性を対象に、最後に「電子メールアドレス」属性を対象に検索を繰り返します。
ユーザープロファイルが見つかった場合は、そのユーザープロファイルの「ログイン名」属性が Windows ドメインのユーザー名として処理されます。ユーザープロファイルが見つからない場合は、ユーザーが入力した名前が Windows ドメインユーザー名として使用されます。SGD は次に、ユーザーが入力した Windows ドメインユーザー名とパスワードをドメインコントローラと照合します。
認証が成功しても、ユーザープロファイルの「ログイン」属性が有効になっていない場合、ユーザーはログインできず、ほかの認証機構が試されることはありません。
認証が成功して、ユーザープロファイルの「ログイン」属性が有効になっているか、または一致するユーザープロファイルが見つからない場合、ユーザーはログインします。
ローカルリポジトリ内にユーザープロファイルが見つかった場合は、そのオブジェクトがユーザーの識別情報およびユーザープロファイルとして使用されます。Administration Console では、ユーザー識別情報は user-profile (Local) のように表示されます。コマンド行では、ユーザー識別情報は .../_ens/user-profile のように表示されます。
ローカルリポジトリ内に一致するユーザープロファイルがなかった場合、ユーザーの識別情報は Windows ドメインのユーザー名になります。プロファイルオブジェクト System Objects/NT User Profile がユーザープロファイルとして使用されます。Administration Console では、ユーザー識別情報は NT-username (NT) のように表示されます。コマンド行では、ユーザー識別情報は .../_service/sco/tta/ntauth/NT-username のように表示されます。
Windows ドメイン認証では、大文字と小文字が区別される 8 ビットのパスワードをサポートしています。ユーザー名にはどんな文字も含めることができます。
複数のドメインのユーザーを認証する必要がある場合は、他のすべてのドメインから信頼されているドメインが 1 つ必要です。Windows ドメイン認証を設定する場合は、この信頼できるドメインを Windows ドメインコントローラとして使用する必要があります。
別のドメインのユーザーが SGD にログインするときには、ユーザー名として domain\username という形式を使用する必要があります。この形式を使用しない場合は、SGD は認証ドメインを使ってユーザーを認証しようとし、認証に失敗します。
注 - ユーザープロファイルの Windows NT ドメイン (--ntdomain) 属性は、SGD のログインでは使用されません。 |
SGD サーバーがドメインコントローラとは異なるサブネットにある場合は、ドメインコントローラの情報をハードコーディングする必要があります。別のサブネット上のドメインコントローラを指定する方法を参照してください。
# tarantella config edit \ --com.sco.tta.server.login.ntauth.NTAuthService.properties-authConfig \ authnbt=NTNAME # tarantella config edit \ --com.sco.tta.server.login.ntauth.NTAuthService.properties-authConfig-append \ authserver=my.domain.name |
ここで、NTNAME はドメインコントローラの NetBIOS 名、my.domain.name はドメインコントローラの DNS 名またはインターネットプロトコル (IP) アドレスです。
SGD へのユーザーのログイン時に発生する問題を解決する場合は、この節の情報を参照してください。この節の内容は、次のとおりです。
Secure Global Desktop 認証に関する問題を診断する場合は、次の表に示すログフィルタの 1 つまたは複数を使って詳細な情報を取得します。
ログフィルタ | 目的 |
---|---|
server/ad/* | Active Directory 認証に関する情報です。 |
server/login/* | ユーザーがログインを試みたときの処理に関する情報です。 |
server/ldap/* | LDAP ディレクトリへの接続に関する情報です。 |
server/kerberos/* | Kerberos 認証に関する情報です。 |
server/securid/* | RSA Authentication Manager への接続に関する情報です。 |
ログフィルタの設定については、ログフィルタを使用した SGD サーバーのトラブルシューティングを参照してください。
この節では、LDAP パフォーマンスを次の SGD 認証機構に合わせて調整する方法について説明します。
SGD では、LDAP ディレクトリを検索してユーザー識別情報を確立するときは、必ず LDAP 人物オブジェクトに対して次の属性を確認します。
SGD ではこれらの属性をすべて確認するので、ディレクトリが大きい場合はログイン時間が長くなることがあります。ログイン時間を改善するには、検索属性の数を減らします。たとえば、cn と mail だけにします。
LDAP ディレクトリがユーザーの識別にほかの属性を使用している場合は、ユーザーが SGD にログインできないことがあります。これを解決するには、追加の属性を検索するように SGD を設定します。
検索属性の変更方法の詳細は、LDAP ユーザー名の検索属性を設定する方法を参照してください。
LDAP ディレクトリサーバーまたは Active Directory サーバーの LDAP 検索に失敗した場合のために、LDAP タイムアウトを設定できます。LDAP タイムアウトは、データ要求などの LDAP 操作に対するディレクトリサーバーからの応答を SGD が待機する時間を制御します。デフォルト値は 20 秒です。
SGD は LDAP ディレクトリサーバーとの接続を 2 回試みます。応答がない場合、SGD はリスト内の別の LDAP ディレクトリサーバーを試みます。Active Directory 認証の場合、ドメインの Active Directory サーバーのリストは、グローバルカタログから取得します。LDAP およびサードパーティー認証の場合、LDAP ディレクトリサーバーのリストは、認証機構用に設定された URL から取得します。
すべての LDAP ディレクトリサーバーがタイムアウトすると、SGD はユーザーを認証したり、Directory Services Integration を使用したりできなくなる可能性があります。
このタイムアウト値を変更するには、次のコマンドを使用します。
$ tarantella config edit --tarantella-config-ldap-timeout secs |
LDAP 検出タイムアウトは、Active Directory 認証でのみ使用されます。
LDAP 検出タイムアウトは、初期接続要求に対する Active Directory サーバーからの応答を SGD が待機する時間を制御します。デフォルト値は 20 秒です。
SGD は Active Directory サーバーとの接続を 2 回試みます。応答がない場合、SGD は別の Active Directory サーバーを試みます。ドメインの Active Directory サーバーのリストは、グローバルカタログから取得します。すべての Active Directory サーバーがタイムアウトすると、SGD で Directory Services Integration を使用できなくなる可能性があります。
このタイムアウト値を変更するには、次のコマンドを使用します。
$ tarantella config edit \ --tarantella-config-ldap-discovery-timeout secs |
LDAP 検出タイムアウトは、KDC タイムアウトよりも長くする必要があります。KDC タイムアウトを参照してください。たとえば、KDC タイムアウトが 10 秒で、再試行回数が 3 回の場合、LDAP 検出タイムアウトを 35 秒 (3 x 10 秒 + 追加の 5 秒) に設定します。KDC タイムアウトと LDAP 検出タイムアウトの関係は保持してください。KDC タイムアウトを増やした場合、LDAP 検出タイムアウトも増やしてください。
SGD は、LDAP ディレクトリから収集したデータをキャッシュします。SGD が変更を検出していない場合は、次のコマンドを使用して、キャッシュされたデータを手動でフラッシュできます。
$ tarantella cache \ --flush ldapgroups | ldapconn | ldapconn-lookups | all |
オプション | 説明 |
---|---|
ldapgroups | すべての LDAP グループデータのキャッシュをフラッシュします。Directory Services Integration で使用します。 |
ldapconn | すべての IP アドレス、ドメイン、および属性データのキャッシュをフラッシュします。 |
ldapconn-lookups | すべての LDAP 検索データのキャッシュをフラッシュします。Directory Services Integration で使用します。 |
all | すべての LDAP データをフラッシュします。 |
注 - このコマンドによって、コマンドを実行した SGD サーバーのキャッシュだけがフラッシュされます。Administration Console には何の影響もありません。 |
LDAP ユーザーが SGD にログインできないことに気付いた場合は、次のチェックリストを使って問題を解決してください。
LDAP ディレクトリサーバーの URL は正しいですか。
LDAP 認証を使用するには、各 SGD サーバーが、指定の URL で LDAP ディレクトリサーバーに接続できる必要があります。
LDAP ディレクトリサーバーが標準以外のポートで待機している場合、LDAP ディレクトリサーバーが待機しているポート番号が URL に含まれているかどうか。
アレイ内のすべての SGD サーバーが、指定した URL の LDAP ディレクトリサーバーに接続できるかどうか。たとえば、telnet プログラムを使って SGD サーバーから LDAP ディレクトリサーバーに接続できるかどうか。
サーチルートを使用して LDAP ディレクトリの検索開始位置を制限した場合は、サーチルートが正しいかどうかを確認してください。
ログファイルが、LDAP ディレクトリサーバーへの接続がタイムアウトしていることを示す場合は、LDAP タイムアウトの値を大きくしてみてください。LDAP タイムアウトを参照してください。
LDAP ディレクトリサーバーのユーザー名とパスワードは正しいですか。
一部の LDAP ディレクトリサーバーでは匿名ログインがサポートされるため、ユーザー名やパスワードを入力する必要はありません。その他 (Microsoft Active Directory など) の場合は、LDAP ディレクトリの検索権限を有するユーザーのユーザー名とパスワードを入力する必要があります。
LDAP ディレクトリサーバーにセキュア接続を使用している場合は、セキュア接続が正しく設定されていますか。
次の点を確認してください。
各 SGD サーバーの CA 証明書のトラストストアに、各 LDAP ディレクトリサーバーの証明書の署名に使用された CA 証明書または証明書チェーンが含まれているかどうか。
サポートされる CA の確認方法および CA 証明書のインポート方法の詳細は、CA 証明書トラストストアを参照してください。
最近の LDAP 設定の変更が反映されていますか。
LDAP データベースの設定を変更した場合、変更が反映されるまで待つことをお勧めします。
SGD は、LDAP ディレクトリから収集したデータをキャッシュします。SGD が変更を検出していない場合は、tarantella cache コマンドを使用して、キャッシュされたデータを手動でフラッシュできます。LDAP キャッシュを参照してください。
ユーザーを検出するための正しい情報が SGD により提供されていますか。
SGD では、LDAP ディレクトリからユーザーを検索するときに、次の属性が使用されます。
これらの属性でユーザーを特定できない場合は、属性を追加することができます。LDAP ユーザー名の検索属性を参照してください。
Web サーバー認証を使用して SGD にログインするときに、次のような問題が発生することがあります。
Web サーバーへの認証に失敗すると、「401 認証が必要です」などのメッセージが表示される場合があります。このメッセージは、ユーザー名とパスワードに問題があるか、Web サーバーの設定に問題があることを示しています。
Web サーバー認証が正しく設定されていない場合、またはなんらかの理由で Web サーバー認証に失敗した場合は、SGD の標準ログインページが表示されます。次のチェックリストを使って問題を解決してください。
Web サーバー認証を信頼するように Tomcat が設定されていますか。
SGD Web サーバーの Tomcat コンポーネントは、Apache Web サーバー認証を信頼するように設定する必要があります。
アレイの各メンバーで、/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml ファイルを編集してください。Coyote/JK2 AJP 1.3 Connector の <Connector>要素に、tomcatAuthentication="false" 属性を追加します。
ローカルリポジトリ内でユーザーにユーザープロファイルが関連付けられていますか。
ローカルリポジトリ内でユーザーにユーザープロファイルオブジェクトが関連付けられていることを前提として SGD が設定されているときに、フォールバックプロファイルオブジェクトのいずれかを有効にしていない場合は、ユーザーがログインできないことがあります。この問題が発生したときにログを有効にしていた場合は、ログファイルで、認証済みのユーザーに一致するエントリが見つからなかったことを示すメッセージを検索します。
そのユーザー用のユーザープロファイルを作成するか、フォールバックプロファイルオブジェクトのいずれかを有効にします。詳細については、サードパーティー認証の仕組みを参照してください。
ユーザーは SGD 管理者ですか。
デフォルトでは、SGD 管理者が Web サーバーにより認証されている場合、SGD にアクセスできません。この動作を変更する方法の詳細は、SGD 管理者とサードパーティー認証を参照してください。
信頼されているユーザーに変更を加えましたか。
信頼されているユーザーのユーザー名とパスワードを変更したときに、その新しいユーザーが機能するかどうかを確認しましたか。詳細については、信頼されているユーザーとサードパーティー認証を参照してください。
SGD 管理者は、ログイン失敗ハンドラを有効にして、ログインに 3 回失敗したユーザーの SGD へのアクセスが拒否されるようにできます。ログイン失敗ハンドラを有効にする方法を参照してください。この追加のセキュリティー対策は、ユーザー独自のユーザープロファイルオブジェクトがローカルリポジトリに格納されている場合にだけ有効です。System Objects 組織のデフォルトのプロファイルオブジェクトには効果がありません。詳細は、を参照してください。
ログイン試行回数は設定可能です。ログインの試行回数を変更する方法を参照してください。デフォルトでは、ユーザーは 3 回試行できます。ログイン試行回数は、各 SGD サーバー固有な値であり、アレイ全体にはコピーされません。特定のサーバーでログイン制限に到達したときにだけ、アレイ全体でアクセスを拒否されます。たとえば、各 SGD サーバーでログインの試行は 2 回まで許可されます。特定のサーバーへのログイン失敗数が 3 回目になったときに、はじめてアレイの他のメンバーへのアクセスが拒否されます。
アクセスを拒否される場合は、SGD へのアクセスだけが拒否されます。SGD がインストールされているホストへのアクセスは拒否されません。
SGD へのアクセスを拒否されたユーザーについては、Administration Console のそのユーザープロファイルオブジェクトの「一般」タブで、「ログイン」チェックボックスが選択解除されます (--enabled false)。このユーザーにもう一度アクセス権を付与するには、このチェックボックスを再び選択します (--enabled true)。
セキュリティー上の理由から、ユーザーのアカウントが無効になっていることを示すメッセージは表示されません。代わりに、不正なパスワードを入力した場合と同じメッセージが表示されます。
すべてのユーザー (UNIX システムの root ユーザーを含む) がどの SGD サーバーにもログインできない場合は、次のどちらかが原因である可能性があります。
すべての認証機構が無効になっているかどうかを確認するには、次のコマンドを使用します。
$ tarantella config list | grep login |
すべての認証機構が無効になっている場合は、次のように、コマンド行から UNIX システム認証機構を有効にします。
$ tarantella config edit --login-ens 1 |
UNIX システム認証機構を有効にすると、ユーザー名「Administrator」と UNIX システムの root ユーザーのパスワードを使って Administration Console にログインできます。その後、認証を再設定できます。
ユーザーログインが SGD サーバーに対して無効になっているかどうかを確認するには、次のコマンドを使用します。
$ tarantella config list --server serv... --server-login |
すべての SGD サーバーへのユーザーログインが無効になっている場合は、次のコマンドを使用してユーザーログインを有効にします。
$ tarantella config edit --array --server-login 1 |
SGD では、ゲストユーザー用のアカウントを共有する場合のように、複数のユーザーが同一のユーザー名とパスワードを使用してログインできます。
注 - 匿名ユーザーは常に共有アカウントを使用しているものとして処理されます。匿名ユーザーの認証を参照してください。 |
ゲストユーザーには、アプリケーションサーバーのパスワードは一切求められません。これは、ゲストユーザーがパスワードキャッシュエントリを追加したり、変更したりできないことを意味します。ゲストユーザー用のアプリケーションサーバーパスワードを管理するには、tarantella passcache コマンドを使用します。
SGD セキュリティーサービスが有効な状態で、Solaris OS クライアントデバイスのユーザーが SGD サーバーにログインできない場合は、/dev/random デバイスがクライアントデバイス上に存在することを確認してください。
SGD セキュリティーサービスには /dev/random デバイスが必要です。このデバイスが存在しない場合は、このデバイスを含む Solaris OS パッチをインストールしてください。
ユーザー名にあいまい性があることを示すダイアログが表示されるのは、人物オブジェクトの属性を共有していて、同じパスワードを使用しているユーザーに限られます。
たとえば、John Smith という名前を持つユーザー (cn=John Smith) が 2 人いて、同じパスワードを選択しているとします。これらのユーザーの電子メールアドレスとユーザー名は異なっています。これらのユーザーが John Smith の名前を使用してログインすると、ユーザー名にあいまい性があることを示すダイアログが表示され、電子メールアドレスまたはユーザー名のどちらかを入力するよう要求されます。このダイアログが表示されるのは、提供された資格情報が複数のユーザーに一致するためです。電子メールアドレスまたはユーザー名を使用してログインした場合は、ログインが許可されます。
ユーザー名にあいまい性があることを示すダイアログが表示されるのは、ローカルリポジトリ内のユーザー ID を検索する LDAP 認証または UNIX システム認証を使用している場合だけです。
この問題を解決するには、ユーザーのパスワードが一意になるようにしてください。あるいは、一意の属性を持つようにユーザープロファイルを設定してください。SGD は、名前 (--name)、ログイン名 (--user)、および電子メールアドレス (--email) を使用してユーザーを識別し、ユーザーのあいまい性を排除しています。
ユーザーがログインしてアプリケーションを起動するときに発生する問題を解決する場合は、この節の情報を参照してください。この節の内容は、次のとおりです。
デフォルトでは、Shift キーを押しながら Webtop 上でアプリケーションのリンクをクリックして、SGD に「アプリケーション認証」ダイアログを強制的に表示させることができます。これにより、ユーザーは異なるユーザー名とパスワードでアプリケーションを起動できます。
Shift キーを押しながらのクリック動作を無効にすることができます。Administration Console で、「グローバル設定」 → 「アプリケーション認証」タブに移動し、「Shift キーを押しながらクリックしたとき」チェックボックスを選択解除します。または、次のコマンドを実行します。
$ tarantella config edit --launch-showauthdialog system |
Shift キーを押しながらのクリック動作を無効にすることは、パスワードに問題があるか、パスワードが存在しない場合にだけ「アプリケーション認証」ダイアログが表示されることを意味します。
Windows ターミナルサービスを使用している場合、ユーザーは SGD またはターミナルサーバーによって、ユーザー名とパスワードの入力を要求されることがあります。
SGD によってユーザーが常にユーザー名とパスワードの入力を要求される場合、この問題は通常、ドメイン名が見つからないことが原因です。パスワードキャッシュ内にドメイン名を含むユーザーのエントリがない場合は、「アプリケーション認証」ダイアログが表示されます。
この問題を解決するには、パスワードキャッシュに詳細情報を保存するときに、ドメイン名を指定する必要があります。ドメイン名の指定は、アプリケーションサーバーがドメインに属していない場合にも行います。
ドメイン名を設定するもっとも簡単な方法は、アプリケーションサーバーオブジェクトまたはアプリケーションオブジェクトで「ドメイン名」属性を使用することです。「アプリケーション認証」ダイアログでは、ユーザー独自のドメイン名を指定することもできます。Windows ドメインとパスワードキャッシュを参照してください。
SGD は、ユーザー名とパスワードの情報を Windows ターミナルサービスに送信して、ユーザーを認証します。認証が失敗した場合、Windows がユーザーに再度入力を要求します。認証が成功したか失敗したかを示す情報は、SGD に返されません。またパスワードが正しいか間違っているかにかかわらず、SGD パスワードキャッシュに情報の詳細が保持されます。
ユーザーが間違ったユーザー名、パスワード、またはドメイン名をパスワードキャッシュに保存した可能性があります。
この問題を解決するには、アプリケーションを起動する際に、Shift キーを押しながらリンクをクリックする必要があります。これにより、「アプリケーション認証」ダイアログが表示され、ユーザーは自身のユーザー名、パスワード、およびドメイン名を訂正できます。あるいは、パスワードキャッシュからユーザーのエントリを削除して、アプリケーションの次回起動時に SGD がユーザーに入力を要求するようにします。
ユーザーのログイン時に必ずパスワードの入力を要求するようにターミナルサーバーを設定することもできます。この動作は、Microsoft Windows 2000 Server ではデフォルトで行われますが、Microsoft Windows Server 2003 では行われません。この動作の変更方法の詳細は、認証の設定を参照してください。
Copyright © 2008, Sun Microsystems, Inc. All rights reserved