Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Access Manager 6 2005Q1 管理ガイド 

第 7 章
認証オプション

Sun JavaTM System Access Manager 6 2005Q1 では、認証のフレームワークを備えています。認証フレームワークは、エンタープライズのアプリケーションにアクセスするユーザーのアイデンティティを確認するプロセスです。認証とは、エンタープライズ内のアプリケーションにアクセスするユーザーのアイデンティティを確認するためのプロセスです。ユーザーは、Access Manager コンソールまたは Access Manager で保護されたリソースにアクセスする前に、認証プロセスにパスする必要があります。認証は、ユーザーのアイデンティティを検証するプラグインによって実装されます。このプラグインアーキテクチャの詳細については、『Access Manager Developer's Guide』で説明します。

デフォルト値の設定、認証モジュールの追加、認証テンプレートの作成、および関連認証モジュールの有効化を行うには、Access Manager コンソールを使用します。この章では、認証モジュールの概要と追加手順について説明します。この章は、次の節で構成されています。


コア認証

Access Manager では、コア認証モジュールばかりではなく、デフォルトで 15 種類の認証モジュールを提供しています。コア認証モジュールでは、認証モジュールの全体的な設定を行います。Active Directory 認証、匿名認証、証明書に基づく認証、HTTP 基本認証、JDBC 認証、LDAP 認証、任意の認証のモジュールを追加して有効にする前に、コア認証モジュールの追加と有効化を行う必要があります。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトの組織に対して自動的に有効になります。第 20 章「コア認証属性」に、コア属性の詳細なリストを示します。

コアサービスを追加し、有効にする

  1. コアモジュールを追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. ナビゲーション区画で「追加」をクリックします。
  4. 利用可能なモジュールのリストがデータ区画に表示されます。

  5. 「コア認証」のチェックボックスを選択し、「追加」をクリックします。
  6. コア認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  7. 「コア」認証のプロパティの矢印をクリックします。
  8. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  9. 「作成」をクリックします。
  10. コア属性がデータ区画に表示されます。必要に応じて属性を修正します。コア属性の説明については、第 20 章「コア認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。


Active Directory 認証

Active Directory 認証モジュールでは、LDAP ディレクトリ認証モジュールと同様の認証が実行されますが、LDAP 認証モジュールの場合の Directory Server ではなく、Microsoft の Active DirectoryTM サーバーが使用されます。LDAP 認証モジュールを Active Directory サーバー用に設定できますが、このモジュールでは、LDAP と Active Directory 認証の両方を同一組織下に存在させることができます。


このリリースの Active Directory 認証モジュールでは、ユーザー認証のみがサポートされます。パスワードポリシーは LDAP 認証モジュールのみでサポートされます。


Active Directory 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. メンバーシップ認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、Active Directory 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「Active Directory 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. Active Directory 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「Active Directory」認証のプロパティの矢印をクリックします。
  9. 「現在このモジュールにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. Active Directory 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。

  12. 「保存」をクリックします。
  13. Active Directory 認証モジュールが有効になりました。

Active Directory 認証を使用してログインする

Active Directory 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、Active Directory 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=AD (大文字と小文字を区別) を使用してログインするときに、Active Directory 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


匿名認証

デフォルトでは、このモジュールを有効にすると、ユーザーは anonymous ユーザーとして Access Manager にログインできるようになります。「有効な匿名ユーザーリスト」属性を設定して、このモジュールに匿名ユーザーのリストを定義することもできます。匿名アクセスを許可するということは、パスワードなしでアクセスさせるということです。匿名アクセスは、特定の種類のアクセス (読み取りのためのアクセスや検索のためのアクセスなど)、特定のサブツリー、またはディレクトリ内の個別のエントリに制限されます。

匿名認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. 匿名認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、匿名認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「匿名認証」のチェックボックスを選択し、「追加」をクリックします。
  7. 匿名認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「匿名」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. 匿名認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 18 章「匿名認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. 匿名認証モジュールが有効になります。

匿名認証を使用してログインする

匿名認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、匿名認証を有効にして選択する必要があります。これにより、ユーザーが http(s)://ホスト名:ポート/サーバー_配備_URI//UI/Login?module=Anonymous&org=org_name を使用してログインするときに、匿名認証のログインウィンドウが表示されます。匿名認証のログインウィンドウを表示せずにログインするには、次の構文を使用します。

http(s)://ホスト名:ポート/サーバー_配備_URI//UI/Login?module=Anonymous&org=org_name&Login.Token1=user_id

使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


匿名認証モジュールにおけるデフォルトの匿名ユーザー名属性値は anonymous です。ユーザーがログインするときは、この名前が使用されます。デフォルトの匿名ユーザーを組織内に作成する必要があります。そのユーザー ID は、匿名認証属性で指定されているユーザー名と同一にする必要があります。大文字と小文字を区別するようにもできます。



証明書に基づく認証

証明書に基づく認証では、個人用デジタル証明書 (PDC) を使用してユーザーを特定し、認証します。Directory Server に格納された PDC に一致すること、また証明書失効リスト (CRL) で確認されていることを求めるように、PDC を設定できます。

証明書に基づく認証モジュールを組織に追加する前に、行う必要のある作業があります。まず、Access Manager とともにインストールした Web コンテナを保護し、証明書に基づく認証で使用できるように設定する必要があります。証明書に基づくモジュールを有効にする前に、Web Server に対するこれらの初期設定手順について、『Sun ONE Web Server 6.1 管理者ガイド』の第 6 章「証明書と鍵の使用」を参照してください。このマニュアルは、次の場所にあります。

または、次の場所にある『Sun ONE Application Sever Administrator's Guide to Security』を参照してください。

証明書に基づく認証を追加し、有効にする

組織管理者として、Access Manager にログインする必要があります。

  1. 証明書に基づく認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、証明書に基づく認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「証明書」認証のチェックボックスを選択し、「追加」をクリックします。
  7. 証明書に基づく認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「証明書」に基づく認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. 証明書に基づく認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 19 章「証明書認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。

証明書に基づく認証のプラットフォームサーバーリストにサーバー URL を追加する

このモジュールを追加するためには、Access Manager に組織管理者としてログインし、Access Manager と Web コンテナに対して SSL を設定し、クライアント認証を有効化しておく必要があります。詳細は、「Access Manager を SSL モードに設定する」を参照してください。

証明書に基づく認証を使用してログインする

証明書に基づく認証をデフォルトの認証方法として設定するには、コア認証モジュール属性である「組織認証モジュール」(282 ページ参照) を修正する必要があります。これにより、ユーザーが https://ホスト名:ポート/配備_URI/UI/Login?module=Cert を使用してログインするときに、証明書に基づく認証のログインウィンドウが表示されます。使用している認証タイプ (ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


HTTP 基本認証

HTTP プロトコルのビルトイン認証サポートである基本認証を使用します。Web サーバーはユーザー名とパスワードを求めるクライアント要求を発行し、その情報を認証済み要求の一部としてサーバーに返します。Access Manager ではユーザー名とパスワードを取得し、LDAP 認証モジュールに対してユーザーを内部的に認証します。HTTP 基本認証が正常に機能するために、LDAP 認証モジュールを追加する必要があります (HTTP 基本モジュールを単独で追加しても機能しない)。詳細は、「LDAP 認証を追加し、有効にする」を参照してください。いったん認証に成功したユーザーには、以降の認証でユーザー名とパスワードの入力は要求されません。

HTTP 基本認証を追加し、有効にする

組織管理者または最上位レベル管理者として Access Manager にログインし、LDAP 認証モジュールを前もって登録しておきます。

  1. HTTP 基本認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、HTTP 基本認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「HTTP 基本認証」のチェックボックスを選択し、「追加」をクリックします。
  7. HTTP 基本認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「HTTP 基本」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. HTTP 基本認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 21 章「HTTP 基本認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. HTTP 基本認証モジュールが有効になります。

HTTP 基本認証を使用してログインする

LDAP 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、HTTP 基本認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/サーバー_配備_URI/UI/Login?module=HTTPBasic を使用してログインするときに、HTTP 基本認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。認証に失敗した場合、ユーザーは新しいインスタンスを開いてログインし直す必要があります。HTTP 基本認証を使用したあとに完全にログアウトするには、存在するすべてのブラウザインスタンスを閉じて、新しいブラウザインスタンスを開始する必要があります。


JDBC 認証

JDBC (Java Database Connectivity) 認証モジュールでは、JDBC 技術に対応したドライバを提供する SQL データベースを通して Access Manager でユーザーを認証できるようにするメカニズムが提供されます。SQL データベースへの接続は、JDBC ドライバを通して直接行うか、JNDI 接続プールで行います。


このモジュールは、MySQL4.0 と Oracle 8i でテストされています。


JDBC 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

  1. JDBC 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、JDBC 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「JDBC 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. JDBC 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「JDBC」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. JDBC 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。

  12. 「保存」をクリックします。
  13. JDBC 認証モジュールが有効になります。

JDBC 認証を使用してログインする

JDBC 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、JDBC 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=JDBC (大文字と小文字を区別) を使用してログインするときに、JDBC 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


LDAP ディレクトリ認証

LDAP 認証モジュールを使用すると、ユーザーがログインするときに、特定のユーザー DN およびパスワードを使用して、LDAP Directory Server にバインドする必要があります。すべての組織ベースの認証では、デフォルトの認証モジュールです。ユーザーが Directory Server に存在するユーザー ID およびパスワードを指定すると、ユーザーは有効な Access Manager セッションへのアクセスが許可され、セットアップされます。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトの組織に対して自動的に有効になります。このモジュールが無効である場合の手順を次に示します。

LDAP 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. LDAP 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、LDAP 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「LDAP 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. LDAP 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「LDAP」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. LDAP 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 23 章「LDAP 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. パスワードを「root ユーザーバインドパスワード」属性に入力します。デフォルトで、インストール中に入力した amldapuser パスワードが、バインドユーザーとして使用されます。匿名アクセスでのユーザーエントリ読み出しを Directory Server が許可する場合は、この手順はスキップできます。
  13. 別のバインドユーザーを使用するには、「root ユーザーバインド DN」属性でユーザーの DN を変更し、そのユーザーのパスワードを「root ユーザーバインドパスワード」属性に入力します。

  14. 「保存」をクリックします。
  15. LDAP 認証モジュールが有効になります。

LDAP 認証を使用してログインする

LDAP 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、LDAP 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/server_配備_URI/UI/Login?module=LDAP を使用してログインするときに、LDAP 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

LDAP 認証のフェイルオーバーを有効にする

LDAP 認証属性には、プライマリとセカンダリ両方の Directory Server の値フィールドがあります。Access Manager では、プライマリサーバーが利用できなくなると、認証を行うためにセカンダリサーバーを使用します。詳細は、「プライマリ LDAP サーバー」および「セカンダリ LDAP サーバー」の LDAP 属性を参照してください。

複数の LDAP 設定

フェイルオーバーの形式として、あるいは、Access Manager コンソールで値フィールドが 1 つだけ提供されている場合に、属性に複数の値を設定するために、管理者は 1 つの組織に複数の LDAP 設定を定義できます。これら追加の設定はコンソールに表示されませんが、要求を行っているユーザーの承認が初期検索で見つからない場合に、主設定とともに機能します。複数の LDAP 設定については、『Access Manager Developer's Guide』の「Multi LDAP Configuration」を参照してください。


メンバーシップ認証

メンバーシップ認証は、my.site.com または mysun.sun.com のように、パーソナライズされたサイトのように実装されます。モジュールが有効なときに、ユーザーは管理者の支援なしでアカウントを作成し、パーソナライズします。ユーザーは作成したアカウントを使用し、追加済みユーザーとしてアクセスできます。また、ユーザーはビューアのインタフェースにアクセスできます。ビューアのインタフェースは、認証データおよびユーザー設定として、ユーザープロファイルデータベースに保存されています。

メンバーシップ認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. メンバーシップ認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、メンバーシップ認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「メンバーシップ認証」のチェックボックスを選択し、「追加」をクリックします。
  7. メンバーシップ認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「メンバーシップ」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. メンバーシップ認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 24 章「メンバーシップ認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. パスワードを「root ユーザーバインドパスワード」に入力します。デフォルトで、インストール中に入力した amldapuser パスワードが、バインドユーザーとして使用されます。
  13. 別のバインドユーザーを使用するには、「root ユーザーバインド DN」属性でユーザーの DN を変更し、そのユーザーのパスワードを「root ユーザーバインドパスワード」属性に入力します。

  14. 「保存」をクリックします。
  15. メンバーシップ認証モジュールが有効になります。

メンバーシップ認証を使用してログインする

メンバーシップ認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、メンバーシップ認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=Membership を使用してログインするときに (大文字と小文字の区別に注意)、メンバーシップ認証 (自己登録) のログインウィンドウが表示されます。使用している認証タイプ (モジュール、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


MSISDN 認証

MSISDN (Mobile Station Integrated Services Digital Network) 認証モジュールでは、携帯電話などのデバイスに関連するモバイル加入者 ISDN を使用して認証できます。これは対話型モジュールではありません。このモジュールでは加入者 ISDN が取得されて Directory Server で確認され、番号が一致するユーザーが検索されます。

MSISDN 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

  1. MSISDN 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、MSISDN 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「MSISDN 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. MSISDN 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「MSISDN」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. MSISDN 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。

  12. 「保存」をクリックします。
  13. MSISDN 認証モジュールが有効になります。

MSISDN 認証を使用してログインする

MSISDN 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、MSISDN 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=MSISDN (大文字と小文字を区別) を使用してログインするときに、MSISDN 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


Microsoft Windows NT 認証

Access Manager は、すでにインストールされている Microsoft Windows NT または Microsoft Windows 2000 サーバーで使用できるように設定できます。Access Manager では、NT 認証のクライアント部分を担当します。

  1. NT サーバーを設定します。詳しい手順については、Microsoft Windows NT サーバーのマニュアルを参照してください。
  2. Microsoft Windows NT 認証モジュールを追加し、有効にする前に、Samba クライアントを入手してインストールし、Solaris システム上の Access Manager と通信できるようにする必要があります。詳細は、「Microsoft Windows NT 認証属性」を参照してください。
  3. Microsoft Windows NT 認証モジュールの追加と有効化を行います。

Samba クライアントのインストール

Microsoft Windows NT 認証モジュールをアクティブにするには、Samba Client 2.2.2 をダウンロードして次のディレクトリにインストールする必要があります。

Samba Client は、Microsoft Windows マシンと UNIX マシンを共存させるためのファイルサーバー兼プリントサーバーで、専用の Microsoft Windows NT/2000 Server を必要としません。詳細とダウンロードについては、http://wwws.sun.com/software/download/products/3e3af224.html を参照してください。

Red Hat Linux とともに出荷される Samba クライアントは、次のディレクトリに置かれています。

Linux 用 Microsoft Windows NT 認証モジュールを使って認証を行うためには、クライアントのバイナリを Access Manager の次のディレクトリにコピーします。

Microsoft Windows NT 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. Microsoft Windows NT 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、Microsoft Windows NT 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「Microsoft Windows NT 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. Microsoft Windows NT 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「Microsoft Windows NT」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. Microsoft Windows NT 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 26 章「Microsoft Windows NT 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. Microsoft Windows NT 認証モジュールが有効になります。

Microsoft Windows NT 認証を使用してログインする

Microsoft Windows NT 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、Microsoft Windows NT 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=NT を使用してログインするときに、Microsoft Windows NT 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


RADIUS サーバー認証

Access Manager は、すでにインストールされている RADIUS サーバーで使用できるように設定できます。エンタープライズで認証のためにレガシーの RADIUS サーバーを使用している場合に便利です。RADIUS 認証モジュールを有効にするには、次の 2 つの手順を行います。

  1. RADIUS サーバーを設定します。
  2. 詳しい手順については、RADIUS サーバーのマニュアルを参照してください。

  3. RADIUS 認証モジュールを登録し、有効にします。

RADIUS 認証を追加し、有効にする

組織管理者として、Access Manager にログインする必要があります。

  1. RADIUS 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、RADIUS 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「RADIUS 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. RADIUS 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「RADIUS」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. RADIUS 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 27 章「RADIUS 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. RADIUS 認証モジュールが有効になります。

RADIUS 認証を使用してログインする

RADIUS 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、RADIUS 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=RADIUS を使用してログインするときに、RADIUS 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

Sun ONE Application Server で RADUIS を設定する

RADUIS クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。RADUIS 認証を正常に機能させるには、次のアクションを許可する必要があります。

ソケット接続のアクセス権を与えるには、Application Server の server.policy ファイルにエントリを追加します。SocketPermission は、ホストの指定と、そのホストへの接続方法を指定する一連のアクションとで構成されます。ホストは次のように指定されます。

host = hostname | IPaddress:portrange:portrange = portnumber | -portnumberportnumber-portnumber

ホストは、DNS 名または IP アドレスの数値で表されるか、ローカルマシンの場合は localhost と表されます。DNS 名でホストを指定する場合は、ワイルドカード "*" を 1 つだけ使用できます。ワイルドカードを使用する場合は、*.example.com のように、左端に置く必要があります。

ポート (portrange) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

listen アクションは、ローカルホストで使用される場合のみ有効です。resolve (ホスト/IP 解決のネームサービスルックアップ) アクションは、ほかのアクションで暗黙的に使用されます。

たとえば、SocketPermission を作成するときに次のアクセス権をコードに与えると、そのコードは machine1.example.com のポート 1645 に接続することと、そのポート上で接続を受け入れることができます。

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

同様に、次のアクセス権を与えられたコードは、ローカルホストのポート 1024 〜 65535 に接続することと、これらのポートで接続受け入れおよび待機を行うことができます。

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";

permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";


リモートホストに対する接続受け入れや接続作成のアクセス権をコードに与えると、悪意のあるコードによって、本来アクセス権を持たない第三者に機密データが転送されたり共有されたりしやすくなるので、問題が発生することがあります。適切なアクセス権だけを与えるために、ポート番号を範囲で指定するのではなく、正確なポート番号を指定してください。



SafeWord 認証

Secure Computing の SafeWordTM または SafeWord PremierAccessTM 認証サーバーに対して送られる SafeWord 認証要求を処理するように、Access Manager を設定できます。Access Manager は、SafeWord 認証のクライアント部分を担当します。SafeWord サーバーは、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。

SafeWord 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. SafeWord 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、SafeWord 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「SafeWord 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. SafeWord 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「SafeWord」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. SafeWord 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 28 章「SafeWord 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. SafeWord 認証モジュールが有効になります。

SafeWord 認証を使用してログインする

SafeWord 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、SafeWord 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=SafeWord を使用してログインするときに、SafeWord 認証のログインウィンドウが表示されます。使用している認証タイプ (ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

Sun ONE Application Server で SafeWord を設定する

SafeWord クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。SafeWord 認証を正常に機能させるには、次のアクションを許可する必要があります。

ソケット接続のアクセス権を与えるには、Application Server の server.policy ファイルにエントリを追加します。SocketPermission は、ホストの指定と、そのホストへの接続方法を指定する一連のアクションとで構成されます。ホストは次のように指定されます。

host = (hostname | IPaddress)[:portrange] portrange = portnumber | -portnumberportnumber-[portnumber]

ホストは、DNS 名または IP アドレスの数値で表されるか、ローカルマシンの場合は localhost と表されます。DNS 名でホストを指定する場合は、ワイルドカード "*" を 1 つだけ使用できます。ワイルドカードを使用する場合は、*.example.com のように、左端に置く必要があります。

ポート (portrange) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

listen アクションは、ローカルホストで使用される場合のみ有効です。resolve (ホスト/IP 解決のネームサービスルックアップ) アクションは、ほかのアクションで暗黙的に使用されます。

たとえば、SocketPermission を作成するときに次のアクセス権をコードに与えると、そのコードは machine1.example.com のポート 1645 に接続することと、そのポート上で接続を受け入れることができます。

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

同様に、次のアクセス権を与えられたコードは、ローカルホストのポート 1024 〜 65535 に接続することと、これらのポートで接続受け入れおよび待機を行うことができます。

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";

permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";


リモートホストに対する接続受け入れや接続作成のアクセス権をコードに与えると、悪意のあるコードによって、本来アクセス権を持たない第三者に機密データが転送されたり共有されたりしやすくなるので、問題が発生することがあります。適切なアクセス権だけを与えるために、ポート番号を範囲で指定するのではなく、正確なポート番号を指定してください。



SAML 認証

SAML (Security Assertion Markup Language) 認証モジュールでは、ターゲットサーバーで SAML アサーションの受信と確認が行われます。このモジュールが、Access Manager 2004Q2 から Access Manager 2005Q1 などのアップグレード後も含めて、ターゲットマシンで設定されている場合にかぎって、SAML SSO は動作します。

SAML 認証を追加し、有効にする

組織管理者または最上位レベル管理者として Access Manager にログインし、LDAP 認証モジュールを前もって登録しておきます。

  1. SAML 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、SAML 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「SAML 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. SAML 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「SAML」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. SAML 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 21 章「HTTP 基本認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. SAML 認証モジュールが有効になります。

SAML 認証を使用してログインする

SAML 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、HTTP 基本認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/サーバー_配備_URI/UI/Login?module=SAML を使用してログインするときに、認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


SecurID 認証

RSA の ACE/Server 認証サーバーに対して送られる SecureID 認証要求を処理するように、Access Manager を設定できます。Access Manager では、SecurID 認証のクライアント部分を担当します。ACE/Server は、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

SecurID 認証では、認証ヘルパー amsecuridd を使用します。認証ヘルパーは Access Manager のメインのプロセスとは独立したプロセスです。起動すると、このヘルパーは設定情報を得るためにポートで待機します。Access Manager が nobody として、または root 以外のユーザー ID で実行するようにインストールされている場合でも、AccessManager-base/SUNWam/share/bin/amsecuridd プロセスは root ユーザーとして実行する必要があります。amsecuridd ヘルパーについての詳細は、「amsecuridd ヘルパー」を参照してください。


このリリースの Access Manager の場合、Linux プラットフォームと Solaris x86 プラットフォームでは SecurID 認証モジュールを使用できません。この 2 つのプラットフォームでは、SecurID 認証モジュールの登録、設定、有効化を行わないでください。SecurID 認証モジュールは、SPARC のみで使用できます。


SecurID 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. SecurID 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、SecurID 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「SecurID 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. SecurID 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「SecurID」 認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. SecurID 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 30 章「SecurID 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。
  13. SecurID 認証モジュールが有効になります。

SecurID 認証を使用してログインする

SecurID 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、SecurID 認証を有効にして選択する必要があります。これにより、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=SecurID を使用してログインするときに、SecurID 認証のログインウィンドウが表示されます。使用している認証タイプ (ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


UNIX 認証

Access Manager がインストールされている Solaris または Linux システムで既知の UNIX ユーザー ID およびパスワードに対する認証要求を処理するように、Access Manager を設定できます。UNIX 認証では組織属性は 1 つだけしかなく、またグローバル属性は少ししかありませんが、システムの観点から検討すべき点があります。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

UNIX 認証では、認証ヘルパー amunixd を使用します。認証ヘルパーは Access Manager のメインのプロセスとは独立したプロセスです。起動すると、このヘルパーは設定情報を得るためにポートで待機します。UNIX ヘルパーは Access Manager ごとに 1 つだけあり、そのすべての組織で共用されます。

Access Manager が nobody として、または root 以外のユーザー ID で実行するようにインストールされている場合でも、AccessManager-base/SUNWam/share/bin/amunixd プロセスは root ユーザーとして実行する必要があります。UNIX 認証モジュールは、UNIX 認証要求を待機するために localhost:58946 へのソケットを開くことで、amunixd デーモンを呼び出します。デフォルトのポートで amunixd ヘルパーを実行するには、次のコマンドを入力します。

./amunixd

デフォルト以外のポートで amunixd ヘルパーを実行するには、次のコマンドを入力します。

./amunixd [-c ポート番号] [IP アドレス]

IP アドレスとポート番号は、AMConfig.properties 内の UnixHelper.ipadrs 属性 (IPV4 形式) と UnixHelper.port 属性で指定されています。amunixdamserver コマンド行ユーティリティーから実行することもできます。amserverAMConfig.properties からポート番号と IP アドレスを取り出し、このプロセスを自動的に実行します。

/etc/nsswitch.conf ファイル内の passwd エントリでは、/etc/passwd および /etc/shadow ファイル、または NIS を認証で探すかどうかを指定します。

UNIX 認証を追加し、有効にする

以下の手順では、最上位レベル管理者として、Access Manager にログインする必要があります。

  1. サービス設定モジュールを選択します。
  2. 「サービス名」リストで、「UNIX」認証のプロパティの矢印をクリックします。
  3. グローバル属性および組織属性が表示されます。1 つの UNIX ヘルパーで Access Manager サーバーの組織すべてにサービスを提供するので、UNIX 属性のほとんどはグローバルです。これらの属性の説明については、第 31 章「UNIX 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  4. 「保存」をクリックして、属性の新しい値を保存します。
  5. 組織管理者として Access Manager にログインすると、組織に対する UNIX 認証を有効にできます。

  6. UNIX 認証を追加する組織に移動します。
  7. 「表示」メニューから「サービス」を選択します。
  8. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、UNIX 認証モジュールとともに追加できます。

  9. ナビゲーション区画で「追加」をクリックします。
  10. 利用可能なモジュールのリストがデータ区画に表示されます。

  11. 「UNIX 認証」のチェックボックスを選択し、「追加」をクリックします。
  12. UNIX 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  13. 「UNIX」認証のプロパティの矢印をクリックします。
  14. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  15. 「作成」をクリックします。
  16. UNIX 認証の組織属性がデータ区画に表示されます。必要に応じて認証レベル属性を修正します。この属性の説明については、第 31 章「UNIX 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  17. 「保存」をクリックします。UNIX 認証モジュールが有効になります。

UNIX 認証を使用してログインする

UNIX 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュールを修正し、UNIX 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=Unix を使用してログインするときに、UNIX 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。


Microsoft Windows デスクトップ SSO 認証

Microsoft Windows デスクトップ SSO 認証モジュールは、Microsoft Windows 2000TM に使用する、Kerberos ベースのプラグインモジュールです。このサービスを使用すると、Kerberos Distribution Center (KDC) で認証されたユーザーは、ログインの条件を再度提示しなくても Identity Server に認証されます。

ユーザーは、SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) プロトコルで Access Manager に Kerberos トークンを送信します。この認証モジュールで Access Manager への Kerberos ベースのシングルサインオンを実行するには、ユーザーが、クライアントサイドにおいて、SPNEGO プロトコルをサポートして自分自身を認証する必要があります。一般的に、このプロトコルをサポートするすべてのユーザーは、このモジュールを使用して Access Manager に認証できます。クライアントサイドでトークンを使用できるかどうかにより、SPENGO トークンか Kerberos トークン (どちらの場合でもプロトコルは同一) がこのモジュールによって提供されます。Microsoft Windows 2000 以上で動作している Microsoft Internet Explorer 5.01 以上では、このプロトコルがサポートされています。Solaris 9 および 10 の Mozilla 1.4 では SPNEGO がサポートされますが、Solaris では SPNEGO がサポートされていないので、返されるトークンは KERBEROS トークンのみです。


Kerberos V5 認証モジュールの新機能を使用するには、JDK 1.4 以上を使用する必要があります。この SPNEGO モジュールで Kerberos ベースの SSO を実行するには、Java GSS API を使用する必要があります。


Internet Explorer の既知の制限事項

WindowsDesktopSSO 認証に Microsoft Internet Explorer 6.x を使用しており、WindowsDesktopSSO モジュールで設定されている KDC レルムと一致する、ユーザーの Kerberos/SPNEGO トークンにこのブラウザでアクセスできない場合、WindowsDesktopSSO モジュールへの認証がエラーになったあとで、このブラウザはその他のモジュールに対して不正に動作します。この問題の直接的な原因は、Internet Explorer が WindowsDesktopSSO モジュールでエラーになると、ブラウザを再起動するまで、コールバックを要求されても、別のモジュールのコールバックを Access Manager に渡すことができなくなることです。このため、WindowsDesktopSSO のあとのすべてのモジュールは、ユーザー資格が NULL であるためにエラーとなります。

関連情報については、次の資料を参照してください。

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Microsoft Windows デスクトップ SSO 認証を追加し、有効にする

Microsoft Windows デスクトップ SSO 認証サービスを有効にするには、次の 3 つの手順を実行します。

  1. Microsoft Windows 2000 のドメインコントローラにユーザーを作成します。
  2. Internet Explorer をセットアップします。
  3. Microsoft Windows デスクトップ SSO 認証モジュールを追加し、設定します。

Microsoft Windows 2000 のドメインコントローラにユーザーを作成する

  1. ドメインコントローラで、Access Manager 認証モジュール用のユーザーアカウントを作成します。
    1. 「スタート」メニューから、「プログラム」>「管理ツール」に進みます。
    2. 「Active Directory ユーザーとコンピュータ」を選択します。
    3. Access Manager ホスト名がユーザー ID (ログイン名) の新しいユーザーを作成します。Access Manager ホスト名には、ドメイン名を含めないでください。
  2. ユーザーアカウントをサービスプロバイダの名前と関連付け、Keytab ファイルを Access Manager がインストールされたシステムにエクスポートします。そのためには、次のコマンドを実行します。
  3. ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out hostname.host.keytab

    ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out hostname.host.keytab

    ktpass コマンドには、次のパラメータを使用できます。

    hostname: Access Manager が稼働する、ドメイン名なしのホスト名です。

    domainname: Access Manager のドメイン名です。

    DCDOMAIN: ドメインコントローラのドメイン名です。この名前は、Access Manager のドメイン名とは異なる場合があります。

    password: ユーザーアカウントのパスワードです。ktpass はパスワードを検証しないので、パスワードが正しいことを確認します。

    userName: ユーザーアカウント ID です。これはホスト名と同じにする必要があります。


    両方の Keytab ファイルがセキュリティ保護されているようにします。


  4. サーバーを再起動します。

Internet Explorer をセットアップする

この手順は、Microsoft Internet ExplorerTM 6 以上に当てはまります。これよりも前のバージョンを使用している場合は、Access Manager がブラウザのインターネットゾーンにあり、ネイティブ Microsoft Windows 認証が有効であることを確認します。

  1. 「ツール」メニューで、「インターネットオプション」>「詳細設定」>「セキュリティ」に進みます。
  2. 「統合 Microsoft Windows 認証を使用する」オプションを選択します。
  3. 「セキュリティ」>「イントラネット」に進みます。
    1. 「レベルのカスタマイズ」を選択します。「ユーザー認証」の「ログオン」で「イントラネットゾーンでのみ自動的にログオンする」オプションを選択します。
    2. 「サイト」に進み、すべてのオプションを選択します。
    3. 「詳細設定」をクリックして、Access Manager をローカルゾーンに追加します (まだ追加されていない場合)。

Internet Explorer の既知の制限事項

WindowsDesktopSSO 認証に Microsoft Internet Explorer 6.x を使用しており、WindowsDesktopSSO モジュールで設定されている KDC レルムと一致する、ユーザーの Kerberos/SPNEGO トークンにこのブラウザでアクセスできない場合、WindowsDesktopSSO モジュールへの認証がエラーになったあとで、このブラウザはその他のモジュールに対して不正に動作します。この問題の直接的な原因は、Internet Explorer が WindowsDesktopSSO モジュールでエラーになると、ブラウザを再起動するまで、コールバックを要求されても、別のモジュールのコールバックを Access Manager に渡すことができなくなることです。このため、WindowsDesktopSSO のあとのすべてのモジュールは、ユーザー資格が NULL であるためにエラーとなります。

関連情報については、次の資料を参照してください。

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Microsoft Windows デスクトップ SSO 認証を追加し、設定する

組織管理者または最上位レベル管理者として、Access Manager にログインする必要があります。

  1. Microsoft Windows デスクトップ SSO 認証を追加する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. コアモジュールが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、Microsoft Windows デスクトップ SSO 認証モジュールとともに追加できます。

  4. ナビゲーション区画で「追加」をクリックします。
  5. 利用可能なモジュールのリストがデータ区画に表示されます。

  6. 「Window デスクトップ SSO 認証」のチェックボックスを選択し、「追加」をクリックします。
  7. Microsoft Windows デスクトップ SSO 認証モジュールがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  8. 「Window デスクトップ SSO」認証のプロパティの矢印をクリックします。
  9. 「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

  10. 「作成」をクリックします。
  11. Microsoft Windows デスクトップ SSO 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 32 章「Microsoft Windows デスクトップ SSO 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

  12. 「保存」をクリックします。Microsoft Windows デスクトップ SSO 認証モジュールが有効になります。

Microsoft Windows デスクトップ SSO 認証を使用してログインする

Microsoft Windows デスクトップ SSO 認証を使用してログインするには、「組織認証モジュール」のコア認証モジュール属性を修正し、Microsoft Windows デスクトップ SSO 認証を有効にして選択する必要があります。これで、Microsoft Windows 2000 のドメインコントローラの一部であるホストに http://ホスト名:ポート/配備_URI/UI/Login?module=WindowsDesktopSSO を使ってすでにドメインユーザーとしてログインしているユーザーが、そのホストからログインしても正しく認証されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。



前へ      目次      索引      次へ     


Part No: 819-1938.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.