| Oracle Access Managerインストレーション・ガイド 10g（10.1.4.3） B55482-01 |
|
 戻る |
 次へ |
この付録では、一般的な問題のトラブルシューティングと解決のためのヒントを示します。ここでは、次の項目について説明します。
次の問題はブラウザ固有です。
ApacheベースのWebサーバー（Apache、Oracle HTTP Server、IBM HTTP Server（IHS）など）を使用するときに、Oracle Access Manager HTMLページが文字化けすることがあります。
Oracle Access ManagerのHTMLページではUTF-8エンコーディングが使用されます。ApacheベースのWebサーバーでは、管理者がAddDefaultCharsetディレクティブを使用して、HTMLページのデフォルト・キャラクタ・セットを指定できます。AddDefaultCharsetディレクティブでUTF-8以外のキャラクタ・セットを有効にすると、Oracle Access ManagerのHTMLページが文字化けします。
Oracle Access ManagerのHTMLページを正しく表示するには、AddDefaultCharsetディレクティブをWebサーバー構成ファイル（httpd.conf）で次のように無効化することをお薦めします。
AddDefaultCharset Off
この構成では、コンテナ制限ポリシーを作成し、ユーザーが包含制限イベントの通知を受けるように指定して、人セレクタで「完了」をクリックしたときに、「保存」、「取消」および「リセット」のボタンが表示されず、ポリシーを保存できません。
この問題に対処する手順
oblixbaseparams.xmlファイルを開きます。
IdentityServer_install_dir\identity\oblix\apps\common\bin\oblixbaseparams.xml
セクションapplet_customizationsで、問題が発生したアプレットのサブセクションを探します。たとえば、containmentlimit_appletサブセクションです。
このアプレットの幅と高さのパラメータを適切に調整して、問題を解決します。たとえば、applet_dimension_heightパラメータの値を530に変更します。
アイデンティティ・サーバーを再起動します。
新しいブラウザ・ウィンドウを開いて同じアプレットを表示します。
Oracle Access Managerの以前のリリースではLatin-1エンコーディングしかサポートされていませんでした。ただし、Oracle Access Manager 10.1.4ではUTF-8エンコーディングがサポートされています。このためこの問題は発生しません。
症状: Internet Explorerで「リソースを認証できない」エラーが発生します。
原因: Internet Explorerによって、URLのUTF文字を常に変換する拡張オプションが提供されています。Oracle Access Managerもこの処理を自動的に行います。両方を有効にしていると認証のエラーが引き起こされます。
解決方法: IEでの「リソースを認証できない」エラーを解消するには、次の手順を実行します。
この問題を解消する手順
テキスト・エディタでglobalparams.xmlファイルを開きます。このファイルは次の2箇所に格納されています。両方を編集してください。
\IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xml
\AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
doUtfConversionパラメータをNOに設定し、変更内容を保存します。
|
注意: UTF-8データをインポートした後でこのように設定した場合は、Webサーバーを再起動し、すべてのブラウザを閉じてから新しいブラウザ・ウィンドウを開きます。 |
Microsoft Internet Explorerで、「ツール」メニュー→「インターネット オプション」を選択します。
「インターネット オプション」ダイアログ・ボックスで「詳細設定」タブを選択します。
「ブラウズ」の下の「常にUTF-8としてURLを送信する」チェック・ボックスの選択を解除します。
ここでは、いくつかのディレクトリ・サーバーの問題について説明します。
「Oracle Virtual Directoryの実装の問題」も参照してください。
Active Directory 2000では、様々なOracle Access Managerスレッドからの同時バインド・リクエストの同一LDAP接続での受信はサポートしていません。Oracle Access Managerサーバーはマルチスレッドであり、ディレクトリ・サーバーに対する複数のLDAP接続のプールを管理しています。複数のOracle Access Managerスレッドが、リクエストを効率よく処理するためにLDAP接続を共有できます。ただし、Active Directory 2000では、様々なOracle Access Managerスレッドからの同時バインド・リクエストの同一LDAP接続での受信はサポートしていません。このため、認証障害が発生したような状態になることがあります。
この状況を回避する手順
アクセス・サーバーで、globalparams.lstファイルを探してエディタで開きます。
exclusiveAuthnConnectionという新しいフラグを追加し、trueに設定します。
これにより、Oracle Access Managerスレッドが、ディレクトリ・サーバーに送信するバインド・リクエストで別のLDAP接続を使用するように強制されます。
詳細は、次の項目を参照してください。
症状: 400のポリシー・ドメインがOracle Access Managerに作成されました。それぞれに10のリソースと10のポリシーが含まれています。ポリシー・マネージャのglobalparams.xmlファイルでlimitAMPolicyDomainResourceDisplayがtrueに設定されています。「検索」アイコンを選択すると、「製品により次のメッセージが生成されました。問題を解決するにはWebマスターに連絡してください。」というエラー・ページが表示されます。
原因: ポリシー・ドメインの数が現在の制限を超えています。
解決方法: Active Directoryではポリシー・ドメインが350を超えないようにします。
Oracle Access Managerでは、アイデンティティ・システム・コンソールを使用して、ユーザー・データのDBプロファイルをADSIとLDAPの間で変更できます。ただし、Oracle Access Managerでは、「システム・コンソール」を使用して構成またはポリシーのDBプロファイルをADSIとLDAPの間で変更することはできません。
症状: ユーザー・データはLDAPを使用するActive Directory Forestに格納され、構成データとポリシー・データはADSIを使用する別のActive Directory Forestに格納されているとします。アイデンティティ・システム・コンソールを使用して構成データDBプロファイルのADSIフラグをLDAPに変更すると、Oracle Access Managerのサーバーとサービスを再起動しても、依然としてADSIフラグが有効になっており、次のメッセージが表示されます。
「別のフォレスト内のユーザーまたは構成DBプロファイルに対してADSIを有効化することができます。このDBプロファイルにはADSIが有効化できません。」
さらに、ユーザー・データのDBプロファイルをADSIに変更しようとするとエラーが発生します。これは、Oracle Access Managerが、構成データとポリシー・データのDBプロファイルをADSI対応として認識するためです。
解決方法: 設定プログラムを再実行して、構成データとポリシー・データのDBプロファイルを変更します。
Active DirectoryをWindows Server 2003にインストールした場合、動的リンク補助クラスで問題が発生したときは、次のすべての項目を完了していることを確認してください。
Active Directoryで動的リンク補助クラスを有効化する手順
Oracle Access Managerをインストールする前に、Active Directoryのドメインとフォレストの機能がWindows 2003 Serverレベルで作動していることを確認する必要があります。
Microsoftドキュメントの説明に従って、ドメインとフォレストの両方をWindows 2003 Serverレベルに上げる必要があります。
Identity Systemのインストールと設定で、求められたときに動的リンク補助クラスを指定します。
ポリシー・マネージャのインストールと設定で、求められたときに動的リンク補助クラスを指定します。
アクセス・サーバーのインストールで、求められたときに動的リンク補助クラスを指定します。
設定の後、次のファイルでdynamicAuxiliaryフラグがtrueに設定されていることを確認してください。
\IdentityServer_install_dir\identity\oblix\data.ldap\common\ldapconfigdbparams.xml
\PolicyManager_install_dir\access\oblix\data.ldap\common\ldapconfigdbparams.lxml
\AccessServer_install_dir\access\oblix\data.ldap\common\ldapconfigdbparams.xml
NameValPair ParamName= "dynamicAuxiliary" Value= "true"
また、Oracle Access Managerによって次のファイルのdynamicAuxiliaryタグがtrueに設定されます。
\IdentityServer_install_dir\identity\oblix\config\setup.xml
|
注意: このディレクトリは静的な関連付けを探すのに最適です。 |
『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、動的補助クラスをサポートするようにOracle Access Managerを構成します。
詳細は、付録B「ADAMに対するOracle Access Managerのインストール」を参照してください。
存在するか確認してください。
このエラー・メッセージは、構成DNとポリシーDNでousを使用していないことを示す場合があります。
ADAMスキーマは、オープン・ポートを介して更新する必要があります。詳細は、「ADAMのスキーマ更新」を参照してください。
パスワード変更は、SSL対応ポートを介してのみ実行できます。詳細は、「ADAMのパスワード変更」を参照してください。
ADAMでは、ユーザー・オブジェクト・クラスの指定はActive Directoryと異なります。Active Directoryで必須のsamaccountnameはADAMには存在しません。grouptypeはADAMでも必須です。設定時に属性を自動的に構成すると、Oracle Access Managerによってgrouptype属性が構成されます。
動的補助クラスを使用する予定がない場合は、手動スキーマ更新に関して次の点に注意してください。
「ADAMに対するアイデンティティ・システムのインストールと設定」の説明に従って、IdentityServer_install_dir\identity\oblix\data.ldap\common\ADAM_oblix_schema_add.ldifを使用してスキーマを手動で更新します。
ldifdeコマンドを使用して、Oracle Access Managerスキーマ・ファイルADAMAuxSchema.ldifをIdentityServer_install_dir\identity\oblix\data.ldap\commonディレクトリからインポートします。
オブジェクト・クラスoblixorgpersonとoblixgroupが、Personオブジェクト・クラスとGroupオブジェクト・クラスそれぞれに補助クラスとして明示的に追加されていることを確認します。
パスワード変更にはSSLが必要です。パスワードの変更で問題が発生した場合、ディレクトリ・サーバーの固有のパスワード・ポリシーが無視されていることがあります。
ユーザーを作成するときに、ユーザーがパスワードを持つようにしてください。ユーザーをアクティブ化して操作が失敗した場合、ユーザーにパスワードがないことがあります。
ユーザーはADAM内で有効化する必要があります。Oracle Access ManagerのUser Managerでユーザーを検索し、検索結果にそのユーザーが含まれない場合は、オブジェクト・クラスのmsDS-UserAccountDisabled= user属性が無効か有効かを調べます。
Oracle Access Managerをインストールするときに、ADAMスキーマを手動で更新する必要があります。
ユーザー・データ・ディレクトリのインスタンスが、構成およびポリシーのデータ・ディレクトリ・インスタンスと異なる場合は、ADAM_user_schema_add.ldifファイルを手動でアップロードする必要があります。
構成データ・ディレクトリ・インスタンスでは、ADAM_oblix_schema_add.ldifファイルを手動でアップロードする必要があります。静的補助クラスを使用するときは、ADAMAuxSchema.ldifファイルを手動でアップロードする必要があります。
ポリシー・データ・ディレクトリのインスタンスが、構成データ・ディレクトリのインスタンスと異なる場合は、ADAM_oblix_schema_add.ldifファイルを手動でアップロードする必要があります。静的補助クラスを使用するときは、ADAMAuxSchema.ldifファイルを手動でアップロードする必要があります。
現在、ldifde（ADAMスキーマの拡張に使用）では、SSLポートへのバインドはサポートされていません。スキーマの更新で問題が発生する場合は、アイデンティティ・サーバーのインストール時にオープンADAMポートを指定したことを確認してください。サポートされない状況でも、アイデンティティ・サーバーのインストール時に証明書をインストールしてSSLを指定することは可能です。
問題
デフォルトで、Novell eDirectoryのOracleスキーマでは、ブラウザベースのアイデンティティ・システムの設定時にドメイン・ノード（dc=us,dc=oracle,dc=comなど）の下にoblixノード（o=oblix,<config-dn>）を作成することはサポートされていません。つまり、ブラウザベースでアイデンティティ・システムを設定しているときは、ドメイン・ノードを構成のベースとして使用できません。
Novell eDirectoryに対するブラウザベースのアイデンティティ・システムの設定時に検索ベースをdc=ncに設定する場合、o=Oblix（oblixconfig）オブジェクト・クラスが存在できるCONTAINMENTオブジェクトを定義する必要があります。eDirectoryのスキーマにおいて、oblixconfigオブジェクト・クラスは、CONTAINMENTオブジェクトとしてdomainを含むことができます。
解決方法
アイデンティティ・サーバーのインストール中に、Directory Serverスキーマを拡張するかどうかの指定を求められます。この時点で、アイデンティティ・サーバーのインストール・ディレクトリを参照し、NDS_oblix_schema_add.ldifファイルを探すことができます。次の手順を使用し、ファイル・エディタでこのオブジェクト・クラスのCONTAINMENTを編集して、domainを含めることができます。
アイデンティティ・サーバーのインストール中に、ディレクトリ・スキーマを拡張するかどうかの指定を求められたら、次のNDS_oblix_schema_add.ldifファイルを探します。
IdentityServer_install_dir\identity\oblix\data.ldap\common\'NDS_oblix_schema_
add.ldif
エディタでNDS_oblix_schema_add.ldifを開き、oblixconfigオブジェクト・クラスを探します。このオブジェクト・クラスでは、そのCONTAINMENTも定義されています。次に例を示します。
dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.3831.0.1.2 NAME 'oblixconfig' SUP top STRUCTURAL MUST ( obpersonoc $ obsearchbase $ organizationName ) MAY ( obsearchbasestr $ obgroupoc $ ………………………………..$ obver $ obduplicateAction ) X-NDS_NAMING ( 'O' ) X-NDS_CONTAINMENT ( 'organization' 'organizationalUnit' 'country' 'locality' ) )
このエントリを変更し、oblixconfigオブジェクト・クラスのCONTAINMENTクラスの1つとしてdomainを指定します。次に例を示します。
dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.3831.0.1.2 NAME 'oblixconfig' SUP top STRUCTURAL MUST ( obpersonoc $ obsearchbase $ organizationName ) MAY ( obsearchbasestr $ obgroupoc $ ………………………………..$ obver $ obduplicateAction ) X-NDS_NAMING ( 'O' ) X-NDS_CONTAINMENT ( 'domain' 'organization' 'organizationalUnit' 'country' 'locality' ) )
変更したスキーマ・ファイルを保存し、インストールとブラウザベースの設定を続行します。
orclroleオブジェクト・クラスのOracle Internet DirectoryスキーマはRFC 2256に準拠していません。結果として、Oracle Access ManagerにOracle Internet Directoryを構成すると、Oracle Internet Directoryでこのスキーマの矛盾が生じるため、Oracle Access Managerのオブジェクト・クラス構成で問題が発生します。
たとえば、アイデンティティ・システム・コンソールの「オブジェクト・クラスの追加」ページの「オブジェクト・クラス」リストには、構成で使用できるすべてのオブジェクト・クラスが示されます。ただし、Oracle Internet Directoryを構成すると、オブジェクト・クラス名のかわりにorclroleオブジェクト・クラス定義が表示されます。オブジェクト・クラスがOracle Access Managerでの使用に関して構成されている場合を除き、このことが原因でOracle Access Managerに問題が発生することはありません。ただし、「オブジェクト・クラス」リストに誤りが発生します。
このオブジェクトをOracle Access Managerでの使用に関して構成する、または誤りを修正するには、次のようにorclroleの定義を変更する必要があります。
|
注意: LDAPツールは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されたときに、-w passwordオプションと-P passwordオプションを無効化するように変更されています。-qまたは-Qを使用すると、コマンドによりそれぞれユーザー・パスワードまたはウォレット・パスワードの入力を求められます。この環境変数は、可能なかぎり設定してください。 |
誤りを修正する、またはOracle Access Managerでの使用に関してorclroleを構成する手順
次のエントリを含むLDIFファイル（ModifiedSchema_orclrole.ldif）を準備します。
|
注意: これらはサンプルのLDIFエントリです。これらのエントリを更新するには、Oracle Internet Directoryのorclroleに関する実際のスキーマ定義を使用する必要があります。 |
dn: cn=subSchemaSubentry changetype: modify delete: objectclasses objectclasses: ( 2.16.840.1.113894.1.2.43 NAME orclrole SUP top STRUCTURAL MUST ( cn ) MAY ( uniquemember $ orclassignedpermissions $ orclassignedroles $ owner $ description $ displayname ) ) dn: cn=subSchemaSubentry changetype: modify add: objectclasses objectclasses: ( 2.16.840.1.113894.1.2.43 NAME 'orclrole' SUP top STRUCTURAL MUST ( cn ) MAY ( uniquemember $ orclassignedpermissions $ orclassignedroles $ owner $ description $ displayname ) )
環境変数LDAP_PASSWORD_PROMPTONLYをTRUEまたは1に設定します。これにより、次の手順でパスワードの入力を求める-qまたは-Qを使用できるようになります。
次のようにldap_addを使用して、このLDIFをOracle Internet Directoryにアップロードします。
>ldapadd.exe -h hostname -p port -D "cn=orcladmin" -f ModifiedSchema_orclrole.ldif -q
「Oracle Internet Directoryのチューニング」で説明されているldapmodifyコマンドを使用して10.1.2以前のOracle Internet Directoryをチューニングすると、次のエラー・メッセージが表示されます。
"Attribute orclinmemfiltprocess is not supported in schema."
orclinmemfiltprocess属性は、Oracle Internet Directory 10.1.4からスキーマでサポートされるようになりました。そのため、10.1.4以前のOracle Internet Directoryがインストールされている場合は、「Oracle Internet Directoryのチューニング」を実行できません。
問題
この問題はどのプラットフォームでも発生する可能性があります。Sun Java Directory Server 6.0に対してアイデンティティ・サーバー（またはポリシー・マネージャ）をインストールする場合、ディレクトリ詳細を定義しているときに障害が発生します。「Sun Directory Server 5.x」を指定し、Sun Directory Server 6のホスト名、ポート番号および資格証明を入力し、LDAPサーバーのスキーマ構成を自動的に更新するかどうかの指定で「はい」を選択すると、次のエラーが発生します。
Error 32: LDAP Invalid credentials. Or invalid directory type supplied. Or no such object.
原因
Oracle Access Managerに対するSun Java Directory Server 6.0の動作保証は、10g（10.1.4.0.1）のリリース後に行われました。そのため、アイデンティティ・サーバーのインストール中に、Sun Java Directory Server 6.0を選択するオプションはありません。Sun Directory Server 5.xを選択すると、自動スキーマ更新の実行時に構成が失敗します。
Sun Java Directory Server 6.0に対するインストールでは、自動スキーマ更新オプションは使用できません。スキーマは手動で更新する必要があります。
解決方法
アイデンティティ・サーバー（またはポリシー・マネージャ）をインストールするときは、「Sun Directory Server 5.x」オプションを選択します。
Sun Directory Server 6のホスト名、ポート番号および資格証明を指定します。
Sun Java System Directory Server 6.0 Management Consoleまたはldapmodifyコマンドラインを使用し、次のldifファイルを使用して、Oracle Access Managerのスキーマおよびインデックス・ファイルをSun Java System Directory Server 6.0にロードします。
ユーザー・データのみをホストするLDAPサーバー・インスタンス:
IdentityServer/identity/oblix/data.ldap/common/iPlanet_user_schema_add.ldif IdentityServer_installdir/identity/oblix/data.ldap/common/iPlanet5_user_index_add.ldif
ユーザー・データと構成データ（または構成データとポリシー・データ、あるいはポリシー・データのみ）をホストするLDAPサーバー・インスタンス:
installdir/identity|access/oblix/data.ldap/common/iPlanet_oblix_schema_add.ldif installdir/identity|access/oblix/data.ldap/common/iPlanet5_oblix_index_add.ldif
前述のパス名で、identity|accessの間の縦棒は、「または」を示します。アイデンティティ・サーバーをインストールする場合のパスはIdentityServer_installdir/identityで、ポリシー・マネージャをインストールする場合のパスはPolicyManager_installdir/accessです。
|
注意: ldapmodifyコマンドの例は、http://docs.sun.com/app/docs/doc/819-0995/6n3cq3avf?a=viewにあるSunのマニュアルを参照してください。 |
通常どおりに、アイデンティティ・サーバーまたはポリシー・マネージャの設定を続行します。
問題
禁止リストに指定された属性を一致属性または参照属性として含む導出属性を作成した後、ユーザー・プロファイルにアクセスすると、製品の動作が停止します。Sun One Directory Server v5がクラッシュし、それが原因でアイデンティティ・サーバーがクラッシュする場合があります。次のエラーが表示されます。
sldap.exe application error
解決方法
Sun One Directory Server 5.2にパッチ6（パッチID 117667-06）を適用します。
問題
Oracle Access Managerサーバーは、Sun One Directory Server v5.1およびv5.2でSSLが有効のときに、リクエストを実行できない場合があります。
原因
60を超えるオープンSSL接続が存在すると、Sun One Directory Server v5.1およびv5.2はハングします。
解決方法
次のように、Sun One Directory Serverにパッチを適用します。
Sun One Directory Server 5.2: パッチ6（パッチID 117667-06）を適用します。
Sun One Directory Server 5.1: Service Pack 4を適用します。
問題
Sun One Directory Serverバージョン6.3にiPlanet5_oblix_index_add.ldifのロードを試みます。
IdentityServer_install_dir /oblix/data/common/iPlanet5_oblix_index_add.ldif
次のエラーが発生します。
No such object
原因
v6.3より前のバージョンのSun One Directory Serverで、Oracle Access Managerによりユーザー・インデックスが追加されるノードは次のとおりです。
cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
iPlanet5_oblix_index_add.ldifは引き続き、このディレクトリ・サーバーに対して以前のノード構造を使用します。ただし、Sun One Directory Server v6.3では、ノードの構造は、次のノードの下にノードを作成するように変更されています。
cn=ldbm database,cn=plugins,cn=config
このノードの名前は、この設定で使用されているディレクトリ・インスタンスのサフィックス・ノードから導出されます。たとえば、Oracle Access Managerで使用されるインスタンスのサフィックス・ノードを次のように想定します。
o=company,c=us
この場合、Sun One Directory Serverでは、次のノードが作成されます。
cn=company,cn=ldbm database,cn=plugins,cn=config
ユーザー・インデックスがロードされるノードを確認するには、その属性の値を確認します。
nsslapd-suffix
結果は、使用されているディレクトリ・インスタンスのサフィックス・ノードと同じになり、cn=indexノードが含まれます。
cn=index,cn=company,cn=ldbm database,cn=plugins,cn=config
これは、インデックスがロードされるノードです。
解決方法
Sun One v6.3ディレクトリ・サーバーに対してアイデンティティ・サーバーをインストールするときに、自動スキーマ更新を拒否します。
アイデンティティ・サーバーのインストール後、iPlanet5_oblix_index_add.ldifファイルを次のように変更します。
次の場所でiPlanet5_oblix_index_add.ldifを探します。
IdentityServer_install_dir\identity\oblix\data.ldap\common\iPlanet5_oblix_
index_add.ldif
iPlanet5_oblix_index_add.ldifで以前のノードを特定します。
cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
これを6.3ディレクトリ・インスタンスのインデックス・ノードに置き換えます。次に例を示します（前述の例を使用）。
cn=index,cn=company,cn=ldbm database,cn=plugins,cn=config
Sun One Directory Server管理コンソール（または任意のLDAPクライアント）を使用して、次のスキーマのldifを手動でアップロードします。
IdentityServer_install_dir\identity\oblix\data.ldap\common\iPlanet_oblix_
schema_add.ldif
変更したiPlanet5_oblix_index_add.ldifをアップロードします。
IdentityServer_install_dir\identity\oblix\data.ldap\common\Planet5_oblix_
index_add.ldif
『Oracle Access Managerインストレーション・ガイド』で説明されているように、すべてのコマンドライン・ユーティリティおよびツールは、製品をインストールしたユーザーとして実行する必要があります。インストール後は、ファイルの所有権や権限を変更しないことをお薦めします。
ここでは、発生する可能性がある次のアイデンティティ・サーバーの問題について説明します。
状況によっては、既存のアイデンティティ・サーバー名を再利用する場合があります。たとえば、アイデンティティ・サーバー・インスタンスを1台のコンピュータから削除して別のコンピュータに再インストールする必要がある場合は、既存のアイデンティティ・サーバー名を使用することがあります。
システム・コンソールで元のアイデンティティ・サーバー名を削除しないと、新しいインスタンスの設定の後でログインしたときに、「アプリケーションが設定されていません」というメッセージが表示されることがあります。アイデンティティ・サーバー名をリサイクルするときは、アプリケーションを設定してログインするために特別な手順を実行する必要があります。
詳細は、「アイデンティティ・サーバー・インスタンス名のリサイクル」を参照してください。
アイデンティティ・サーバーとWebPassが、下位CAから発行された証明書を使用して証明書モードでインストールされているとき、「アイデンティティ・システム・コンソール」リンクをクリックしてアイデンティティ・システムの設定を開始すると、空白のページが表示されることがあります。イベント・ビューアに、原因を特定せずにOracle Access Managerのエラーが表示される場合があります。
下位CAで生成された証明書を使用するときは、ルートCAの証明書が下位CAの証明書と一緒にxxx_chain.pemに存在する必要があります。検証を適切に行い、アイデンティティ・システムを正常に設定するためには、両方の証明書が存在する必要があります。
|
関連項目: 『Oracle Access Manager IDおよび共通管理ガイド』のトランスポート・セキュリティ・モードに関する情報 |
アクセス・サーバーが実行しているかどうかを確認するには、サーバーがリスニングしているポートを使用してサーバーにTelnetでアクセスします。ポート6021でmyserver.mycompany.comというサーバーで実行しているアクセス・サーバーへのTelnetセッションを次に示します。
myserver% telnet myserver.mycompany.com 6021 Trying 192.168.5.18. . . Connected to myserver.mycompany.com. Escape character is '^]'. ^] telnet> q Connection closed. myserver%
この例に対するシステムのレスポンスは次のようになります。
Connected to myserver.mycompany.com. Escape character is '^]'.
これは、アクセス・サーバーがTelnetリクエストを受け入れて、作動していることを示します。サーバーのインストール時にリスニングするように指定されているポートで、そのサーバーに接続できない場合は、アクセス・サーバーに問題があります。次のような問題が含まれます。
接続がファイアウォールで妨げられています。
サーバーが実行していません。
接続が開いているかどうかを確認するためにファイアウォールを調べます。アクセス・サーバー・プロセスが実行しているかどうかを調べます。アクセス・システム・サーバーでnetstatコマンドを使用すると、アクセス・サーバーのインストール時に指定したポートを使用してサーバーが通信しているかどうかを確認できます。
症状: 「DBマネージャの初期化中にIdentity2で使用されるDBプロファイルを取得できませんでした。Identity2に有効なDBプロファイルが存在することを確認してください。」というメッセージを受け取ります。
原因: 次の場合に発生することがあります。
2番目（またはそれ以降）のアイデンティティ・サーバーをインストールした場合
インストール時に、「これは、このLDAPディレクトリ・サーバーのネットワーク内で最初のアイデンティティ・サーバーのインストールですか。」という質問に「はい」と答えた場合。
アイデンティティ・サーバーおよびWebサーバーを再起動した場合。
解決方法: アイデンティティ・サーバーをアンインストールしてから再インストールするときに、「これは、このLDAPディレクトリ・サーバーのネットワーク内で最初のアイデンティティ・サーバーのインストールですか。」という質問に「いいえ」と答えます。
症状: アイデンティティ・システムの設定時に、アイデンティティ・サーバーとWebサーバーを再起動するように求められます。長い間待機した後に、ブラウザから「ページを表示できません。」というメッセージが返されます。
原因: Webブラウザが、アイデンティティ・サーバーのレスポンスを待機中にタイムアウトになることがあります。これは、ディレクトリ・サーバーの詳細を指定し、ユーザー・オブジェクト・クラスとGroupオブジェクト・クラスを自動的に構成した後で発生します。スキーマ更新がブラウザのタイムアウトよりも長くかかるためです。
解決方法: しばらく待機してからブラウザをリフレッシュして続行します。
アイデンティティ・サーバーが起動しない場合は、問題の原因について次の3つの項目を調べてください。
LDAPディレクトリに不要なデータがないことを確認します。次に例を示します。
構成ブランチが空か
構成ブランチに正しいデータがあるか
構成ブランチに、別のアイデンティティ・サーバー・エントリを含む、以前のインストールのデータがあるか
次のファイルが適切なことと正しいフォルダにあることを確認します。
\IdentityServer_install_dir\identity\oblix\config\configinfo.xml
\IdentityServer_install_dir\identity\oblix\config\ois_server_config.xml
\IdentityServer_install_dir\identity\oblix\config\setup.xml
アイデンティティ・サーバーのために選択したポートが別のアプリケーションで使用中でないことを確認します。
IdentityXMLコールで認証資格証明が必要となることがあります。WebPassを保護するWebGateがない場合は、基本の資格証明メカニズムが使用されます。このメカニズムは、ユーザー名とパスワードがSOAPリクエスト自体に埋め込まれた形式です。ただし、後からWebGateをインストールしたときは、SSOトークンによる認証を使用するように、IdentityXMLコールを変更する必要があります。
最初にOBSSOCookieを取得して、そのトークンを以降のすべてのコールに渡すように、IdentityXMLコールを変更する必要があります。これを行う方法の例は、『Oracle Access Manager開発者ガイド』を参照してください。デプロイされたIdentityXML関数のコード例とObSSOCookieの例で詳細を確認します。
インストール時に入力するアイデンティティ・サーバー識別子は、一意であることが必要です。また、WebPassのインストール時に入力するWebPass識別子とも異なる必要があります。
インストール時に入力するWebPass識別子がアイデンティティ・サーバーのインストール時に入力した識別子と一致する場合、WebPass識別子は作成されません。したがって、設定後もアイデンティティ・システム・コンソールで使用することができません。
次の手順を実行してWebPassを再構成します。
setup_webpassユーティリティを探します。次に例を示します。
WebPass_install_dir\identity\oblix\tools\setup\setup_webpass.exe
WebPass_install_dirはWebPassをインストールしたディレクトリです（たとえば、c:\OracleAccessManager\identity）。
次のオプションを使用してsetup_webpassユーティリティを実行します。
setup_webpass -i <WebPass_install_dir> [-q] [-n <WebPass ID>][-h <OIS hostname>] [-p <OIS port #>] [-s <open|simple|cert>][-P <simple|cert mode password>] [-c (request|install)][-W iis]
シンプル・モードまたは証明書モードのWebPassパスワードを変更する手順
次の手順を実行して、シンプル・モードまたは証明書モードのWebPassパスワードを変更します。
setup_webpassユーティリティを探します。次に例を示します。
WebPass_install_dir\identity\oblix\tools\setup\setup_webpass.exe
次のオプションを使用してsetup_webpassユーティリティを実行します。
setup_webpass -i <WebPass_install_dir> -k
次の手順を実行してWebPassモードを再構成します。
setup_webpassユーティリティを探します。次に例を示します。
WebPass_install_dir\identity\oblix\tools\setup\setup_webpass.exe
次のオプションを使用してsetup_webpassユーティリティを実行します。
setup_webpass -i <WebPass_install_dir> -m
IIS WebサーバーでOracle Access Manager Webコンポーネントをインストールする場合の、一般的なガイドラインを次に示します。
アカウント権限: Oracle Access Managerをインストールするアカウントには、管理権限が必要です。アイデンティティ・サーバーおよびアクセス・サーバー・サービスの実行に使用されるユーザー・アカウントには、「サービスとしてログオン」権限が必要です。これは、「管理ツール」→「ローカル セキュリティ ポリシー」→「ローカル ポリシー」→「ユーザー権利の割り当て」→「サービスとしてログオン」を選択して設定できます。
IIS 6 Webサーバー: WWWサービスをIIS 5.0分離モードで実行する必要があります。これは、ISAPIポストゲート・フィルタで必要となります。通常、これはOracle Access Managerのインストール時に自動的に設定されます。インストールされない場合は、デフォルトWebサイトで手動で設定する必要があります。
WebGate: IIS WebGateのインストール時に、IIS WebGateのために/accessディレクトリの様々な権限の設定が必要となるのは、NTFSをサポートするファイル・システムにインストールする場合のみです。たとえば、FAT32ファイル・システムを実行しているWindows 2000コンピュータに、シンプル・モードまたは証明書モードでISAPI WebGateをインストールするとします。最後のインストール・パネルには、FAT32ファイル・システム上で設定できない様々な権限を手動で設定するための指示が表示されます。この場合、この指示は無視してください。
IISに対応するWebGateをインストールしてフォームベースの認証およびシングル・サインオン（SSO）を有効にする場合は、WebGateをポリシー・マネージャ・コンポーネントと同じディレクトリにインストールしてください。次に例を示します。
Oracle Virtual Directoryでの実装に影響する、次のいくつかの条件に注意する必要があります。
詳細は、第10章「Oracle Virtual Directoryを使用したOracle Access Managerの設定」を参照してください。
Active DirectoryまたはADAMの検索の問題: Oracle Virtual DirectoryをActive Directoryディレクトリ・サーバーまたはADAMディレクトリ・サーバーと一緒に使用する場合、検索で「次と類似する」演算子を使用できません。
原因: Active DirectoryまたはADAMディレクトリ・サーバーでは、「次と類似する」検索がサポートされていません。
回避方法: Active DirectoryまたはADAMディレクトリ・サーバーでは、「次と類似する」検索を使用しないでください。
問題
複数のディレクトリ・プロファイルで異なる検索ベースが使用されている場合、管理者が有効な資格証明を入力した後でポリシー・マネージャにアクセスできません。
たとえば、アイデンティティ・サーバー・コネクタがOracle Internet Directory LDAPディレクトリ・サーバーに直接接続されており、直接的な検索ベースを使用するとします。ただし、アクセス・システムはアダプタに接続されており、このアダプタは、異なる検索ベースに対して同じLDAPディレクトリ・サーバーをフロントエンド処理するロード・バランサにインタフェース接続されています。
原因
各ディレクトリ・サーバー・プロファイル内の検索ベースは同じである必要があります。
解決方法
各ディレクトリ・サーバー・プロファイル内の検索ベースが同じであることを確認します。プロファイルに入力されたすべてのディレクトリ・サーバー情報が到達可能であり、その情報によりOblixツリーを表示できることを確認します。
属性変更ワークフローを使用して複数値属性を変更できません。
原因: デフォルトのOracle Virtual Directoryスキーマには、Sun Directory Serverスキーマと同様に複数値属性が含まれます。Active Directoryでは属性の構文が一致しない場合があります。たとえば、Active Directoryではメール・アドレスは単一値ですが、Sun Directory ServerとOracle Virtual Directoryでは複数値です。
たとえば、Oracle Virtual DirectoryがActive DirectoryおよびSun Directory Serverと通信するとき、属性変更ワークフローを作成してSun Directory Serverでユーザーの複数値属性（メール・アドレスなど）を変更しようとすると、属性は変更されますが、Active Directoryではコミットが失敗して属性が変更されません。
回避方法: 複数値属性を変更しないでください。
『Oracle Access Managerインストレーション・ガイド』のOracle Virtual Directoryを使用したOracle Access Managerの設定に関する章には、Oracle Virtual Directory SSLリスナーの構成手順が含まれています。その中の手順8には、次の例に示すような正しいコマンドライン構文が含まれています。
8. 次のコマンドを使用してルートCAをアイデンティティ・サーバーにインポートします。
certutil -d IdentityServer_install_dir\identity\oblix\config -A -n ldap -a -t "C,," -i root_ca_file
|
注意: certutilコマンドでは、-t（信頼できる引数）フラグの後に、証明書に割り当てられる信頼属性を二重引用符で囲んで記述する必要があります。 |
サブツリー検索: データベース分割プロファイルがあると、セカンダリ表に存在する属性から属性を導出できません。
原因: Oracle Access Managerは、セカンダリ・データ・ストアの属性に対してサブツリー検索を実行できません。
たとえば、マッピング・テンプレートCustomOracleDBMapping_mpy.xmlを使用して、InetOrgPersonに導出属性を次のように定義したとします。
属性名: MyAttr
表示名: MyAttr
一致する属性: employeenumber
参照属性: employeenumber
オブジェクト・クラス: InetOrgPerson
ユーザー（たとえばRohit）を検索してプロファイルを表示するとき、employeenumber属性の値を確認できますが、myAttr値は空になっています。
次の例では、データベースと分割プロファイル、次のアダプタ・テンプレートがあります。
CustomOracleAdaptorSplitPrimary_adapter_template.xml
CustomOracleAdaptorSplitSecondary1-1_adapter_template.xml
CustomOracleAdaptorSplitSecondary1-M_adapter_template.xml
CustomAdapterJoinView_adapter_template.xml
回避方法: セカンダリ・データ・ストアの属性を構成しないでください。
ユーザーの作成ワークフロー: ユーザーの作成ワークフローを定義すると、Oracle Access Managerで、Oracle Virtual Directoryのセカンダリ・ビューから属性を選択できるようになります。実行時には、ユーザー・エントリがプライマリ・ビューに作成されます。ただし、ワークフローは失敗し、これらのエントリをOracle Access Managerが使用することはできません。
原因: Oracle Access Managerはすべての属性をOracle Virtual Directoryから取得するため、どの属性がセカンダリ・データ・ストアではなくプライマリ・データ・ストアから取得されたかはわかりません。
回避方法: セカンダリ・データ・ストアの属性を構成しないでください。
少なくとも1つのLDAPディレクトリと少なくとも1つのデータベース表をフェデレートするOracle Virtual Directory仮想ディレクトリに対してOracle Access Managerを設定したとき、LDAPディレクトリのグループからメンバーを削除しようとすると、グループ全体がそのディレクトリから削除されます。
原因: パフォーマンスの理由からOracle Virtual Directoryは、ユーザーが削除を指定したメンバーのみをOracle Access Managerに返します。これに対して、標準のLDAPディレクトリ・サーバーはグループのすべてのメンバーを返します。
このようなOracle Virtual Directoryの変則的な動作のために、アイデンティティ・システムを使用してグループからメンバーを削除しようとするときに影響が生じます。標準のLDAPディレクトリ・サーバーはグループのすべてのメンバーを返すため、Oracle Access Managerは、1メンバーが削除された後も残りのメンバーを認識します。ただし、Oracle Virtual Directoryはグループ内の削除指定された1メンバーのみをOracle Access Managerに返します。Oracle Access Managerは、返されたメンバーを削除するとその他のグループ・メンバーを認識できません。このため、グループが空になったとみなして、グループとすべてのメンバーを削除します。
|
重要: これは、グループのuniqueMemberだけではなくすべてのDN属性に共通します。複数値を持つことができるすべてのDN属性に回避方法を適用する必要があります。 |
回避方法: 「Oracleデータベース用のマッピング・スクリプトのカスタマイズ」にあるカスタマイズ・ファイルを参照してください。また、アイデンティティ・システムがダミー・ユーザーをバックエンド・データベースに書き込むことを防ぐために次の詳細に注意します。
Workaround to prevent COREid from writing dummy user to backend database
if haveAttributeValue('uniqueMember','cn=Dummy User'):
#removeAttributeValue('uniqueMember','cn=Dummy User')
if operation != 'modify':
removeAttributeValue('uniqueMember','cn=Dummy User')
else:
change = removeAttribute('uniqueMember')[0]
change.values.remove(DistinguishedName('cn=Dummy User'))
addEntryChange(change)
インストール中または直後に次の問題が発生します。
症状: このサーバーに対するDBプロファイルがないというメッセージが出て、アクセス・サーバーのインストールが停止します。
解決方法: 次の手順を実行します。
ブラウザでポリシー・マネージャのWebPassインスタンスのURLを指定して、アクセス・システム・コンソールにナビゲートします。次に例を示します。
http://hostname:port/access/oblix
hostnameはWebPassインスタンスのWebサーバー・ホスト、portはWebPass Webサーバー・インスタンスのHTTPポート番号を示し、/access/oblixはアクセス・システム・コンソールを指します。
「アクセス・システム・コンソール」リンクを選択して、マスター管理者権限を持つユーザーとしてログインします。
「アクセス・システム構成」タブ→「アクセス・サーバー構成」（左側の列）→「AccessServer_Link」を選択します。
詳細ページの一番下の「DBプロファイルの関連付け」ボタンをクリックします。
ページの一番下の「AccessServer_default_user_profile」リンクをクリックします。
すべてのサーバーまたは適切なサーバーが指定された状態で、「AAA Servers」がオンになっていることを確認します。
ページの一番下でプロファイルが有効になっていることを確認します。
「保存」をクリックします。
ログアウトしてアクセス・サーバーのインストールを続行します。
症状: Oracle Access Managerをインストールした後で、WebサーバーのCGIプログラムが実行しません。
解決方法: 次の手順を実行します。
../https:server name/config directory obj.confファイルで、他のOracle Access Manager Init関数の前に次の行を追加します。
Init fn="Init-cgi" timeout-300 LateInit="yes"
このとおりに正確に入力してください。
Webサーバーを再起動します。
症状: アイデンティティ・サーバーを新しいコンピュータにインストールするとき、インストーラがwinnt/system32/Msvcrt.dllファイルを更新されたファイルで置換しようとすることがあります。このファイルはWindowsでロックされているため、「ファイルがロックされているため置換できません。」というメッセージが表示されます。
原因: インストーラが、Windowsオペレーティング・システムでロックされているファイルを置換しようとすることがあります。
解決方法: 警告ボックスで「再起動」をクリックしてDLLを置換します。
問題
インストール中、アイデンティティ・サーバーの構成画面に、これがこのLDAPディレクトリ・サーバーに対する最初のアイデンティティ・サーバーであるかどうかの指定を求めるメッセージが表示されます。しかし、ページ上のテキスト全体が欠落しているように見えます。
回避方法
インストーラ・ウィンドウのサイズをわずかに変更すると、再描画が行われ、コンテンツが更新されます。
症状: 資格証明が有効でも、GUIでのアイデンティティ・サーバーのインストールが「不正な資格証明エラー（49）」で失敗します。
原因: サード・パーティInstallshieldのISMPフレームワークの既知の問題です。インストール時に記号$を含む入力が指定されると、インストーラが予測不能な解釈を行うことがあります。たとえば、最初のアイデンティティ・サーバーのスキーマ更新時に指定するバインド・パスワードがAdmin$$の場合、ISMPはこれをAdmin$と解釈してスキーマ更新ツールを起動するため、更新が「不正な資格証明エラー（49）」で失敗します。
回避方法: 特定のツールの起動時にこの問題が発生する場合は、コマンドラインからツールを実行してください。
|
注意: 同じパスワードを使用するすべてのOracle Access Managerインストーラが、同様の資格証明の問題によって失敗することがあります。 |
問題
インストーラを起動し、インストール・パスを指定して[Enter]を押すと、インストーラの設定に進む前に、Red Hat Linux AS 3.0用のアイデンティティ・サーバーおよびWebPassのインストーラがハングします。
解決方法
インストールを開始する前に、次のコードをコピーしてシェル・ウィンドウに貼り付けます。
cd /tmp mkdir bin.$$ cd bin.$$ cat > mount <<EOF #! /bin/sh exec /bin/true EOF chmod 755 mount @ export PATH=`pwd`:$PATH
インストールを実行します。
インストーラの動作が終了したら、次のコマンドを実行して、一時ディレクトリを消去できます。
rm -r /tmp/bin.$$
症状: 同じコンピュータに下位Oracle Access Managerコンポーネントをインストールする際、または同じコンピュータにコンポーネントの2つ目のインスタンスをインストールする際に、ユーザーは次の1つ以上のDLLファイルを置換するように求められます。前回のインストール時にファイルを更新している場合も、置換を求められます。
messagedll.dll
mtl70mt.dll
原因: これらのDLLはOracle Access ManagerのDLLではありません。これらのDLLにはバージョン情報が含まれないため、Oracle Access Managerは、DLLの日付スタンプを使用してファイルを置換する必要があるかどうかを検証します。その後のインストールでは、日付スタンプが古いためにユーザーがファイルの置換を求められます。
解決方法: 「OK」をクリックしてDLLを置換します。
SolarisでのOracle Access Managerコンポーネントのインストールを完了せずに終了すると、問題が発生する場合があります。Solarisでは、インストーラを途中で終了するとコア・ダンプが作成されます。その場合、次のメッセージが表示されます。
SIGABRT 6 abort (generated by abort(3) routine)
si_signo [6]: ABRT
si_errno [0]:
si_code [-1]: SI_LWP [pid: 1724, uid: 0]
stackpointer=FFBFD7D0
"process reaper" (TID:0x72d588, sys_thread_t:0x72d4c0, state:NS, thread_t:
t@54, threadID:0x0, stack_bottom:0x0, stack_size:0x0) prio=5
...
これは、インストーラのみの問題です。インストールするOracle Access Managerコンポーネントの機能には影響しません。
症状: UNIXでGUIによるインストールを開始すると、フォントとスクロール・バーに関する警告を受け取ることがあります。
解決方法: このような警告は無視できます。これらは、インストール・ウィザードのGUIの表示変更を示すものです。
症状: Windowsインストール・ウィザードを強制終了（[Ctrl]+[C]を押すか「タスク マネージャ」を使用して終了）すると、ウィザードはファイルを適切にクリーンアップできず、大容量のデータがTEMPディレクトリに残ります。
解決方法: ファイルを手動で削除します。
Install Shieldをルート以外のユーザーとしてAIXで実行するには、次のように環境変数を設定します。
AIX_ISMP_SUPPORT=NONROOT
Oracle Access Managerコンポーネントは、標準の英数字のみでパス名が構成されるディレクトリにインストールします。すべてのファイルおよびパス名は英語の文字のみで指定してください。ファイルおよびパス名に、国際文字は使用できません。
Oracle Access Managerのインストールが終了したら、インストールをテストします。
Oracle Access Managerのインストールをテストする手順
次の手順を実行して、Oracle Access Managerのインストールをテストします。
すべてのブラウザを閉じます。
アクセス・サーバーを停止します。
Oracle Access Managerで保護されているページを開こうとしてみてください。
アクセス・サーバーおよびWebサーバーを再起動します。
手順3と同様に同じページに接続してみます。指定したページが開きます。
症状: インストールと設定の際に「人オブジェクト・クラス」ページから先に進めません。
原因: おそらくディレクトリのスキーマが無効です。
解決方法: ディレクトリ・スキーマに対して行った変更を確認し、適切に変更されているかどうかを調べます。
症状: AIXで実行しているApache WebサーバーにSSLモードでWebGateをインストールします。sample.obj.confファイルからhttpd.confファイルに変更します。httpd.confファイルに変更した後で、Apache Webサーバーが起動できなくなります。次のメッセージが表示されます。
「サーバー証明書連鎖ファイルの名前がhttpd.confにca.certとしてハードコードされています。」
解決方法: ユーザーのサーバー証明書連鎖ファイルの実際の名前と一致するようにServer-Certificate-Chain-filenameを変更します。
次に、発生する可能性がある問題の解決方法を示します。
問題: いくつかの言語パックがあるときに、コンソールからインストーラを実行すると、パスワードを入力してくださいという文字列が正しく表示されません。LDAPパスワードの入力を求める表示が文字化けすることがあります。
解決方法: ほとんどの場合に有効な解決方法は、Oracle Access Managerのインストールが実行されたコンピュータに、入手可能なすべての言語サポートをインストールすることです。必ず、各言語に必要なすべてのフォントをインストールしてください。コンピュータにローカルでログインし、ログイン画面に表示する言語を選択してください。
症状: アクセス・システムのコンポーネントに追加の管理者言語パックをインストールする場合、事前にアイデンティティ・システムに同じ言語パックをインストールしていると、ポリシー・マネージャで新しい管理者言語を表示できないことがあります。
解決方法: 次の手順を実行して、新しい管理者言語を有効にします。
アイデンティティ・システムのすべてのコンポーネントに対して新しい管理者言語をインストールします。
アクセス・システムのコンポーネントに対して新しい管理者言語をインストールします。
アイデンティティ・システム・コンソールを使用して、次のように管理者言語を有効化します。
管理者言語がすでに有効化されている場合は無効化します。
管理者言語（現在、アイデンティティ・システムとアクセス・システム両方のコンポーネントにインストールされている）を有効化します。
該当するOracle Access Managerサーバー・サービス（たとえば、アイデンティティ・サーバーおよびアクセス・サーバー・サービス）とWebコンポーネント（WebPass、ポリシー・マネージャおよびWebGate）のWebサーバー（Apache、IIS、Sun ONEなど）を再起動します。
症状: ポリシー・マネージャ、言語パック、WebGateの順に同じディレクトリにインストールすると、WebGateが、インストールされた管理者言語を使用しません。
原因: ポリシー・マネージャ、言語パック、WebGateの順に同じディレクトリにインストールすると、言語がポリシー・マネージャのみに対してインストールされます。この場合、ポリシー・マネージャとWebGateの両方が同じobnls.xmlファイルを共有します。
解決方法: WebGateに対して同じ言語パックをインストールします。
症状: ポリシー・マネージャ、言語パック、WebGateの順に同じディレクトリにインストールした場合、ポリシー・マネージャが、インストールされた言語を使用しません。
原因: WebGateのインストール時に、ポリシー・マネージャのインストール・ディレクトリのobnls.xmlを上書きするかどうかを確認されることがあります。「はい」を選択すると、ポリシー・マネージャのobnls.xmlファイル（追加の言語パック・エントリが含まれる）が新しいobnls.xmlファイル（インストール済言語すべてのリストが含まれない）で置換されます。この結果、ポリシー・マネージャが、追加の管理者言語に対応できなくなります。
解決方法: WebGateのインストール時に、ポリシー・マネージャ・インストール・ディレクトリのobnls.xmlの上書きを確認されたら、必ず「いいえ」を選択します。「はい」を選択すると、ポリシー・マネージャの場合と同様にWebGateにすべての言語をインストールする必要があります。
インストール時に選択されたデフォルトの管理者言語に関連する言語パックの削除はサポートされていません。
デフォルト管理者言語を誤ってアンインストールした場合は、次の手順を実行して元に戻すことができます。
削除したデフォルト管理者言語のために、次のような内容の1つのオプション・ファイル（たとえばoptions.txt）を作成します。
-W ObPropBean.defaultLocale="ko-kr"
この例のObPropBean.defaultLocaleの値"ko-kr"（韓国語）は、このインストールで選択されたデフォルト管理者言語のロケールです。
次の例のように、各コンポーネントにデフォルト管理者言語パックを再インストールします。
アイデンティティ・システム:
Oracle_Access_Manager10_1_4_3_0_KO_Win32_LP_Identity_System.exe
-options options.txt
アクセス・システム:
Oracle_Access_Manager10_1_4_3_0_KO_Win32_LP_Access_System.exe
-options options.txt
各コンポーネントにデフォルト管理者言語パックを再インストールしたら、サーバー・サービス（アイデンティティ・サーバーとアクセス・サーバー）と、WebPass、ポリシー・マネージャおよびWebGateのWebサーバーOracle HTTP ServerまたはIISを再起動します。
ここでは、ログイン時に発生する可能性がある次の問題について説明します。
「アイデンティティ・サーバーにログインしていますが、アクセス・システムからログアウトしています。」というメッセージが、次の1つ以上のイベントによって表示されることがあります。次に例を示します。
アクセス・システムのコンポーネントを設定した後でアイデンティティ・サーバーを再起動しなかった場合。
アイデンティティ・サーバーとアクセス・サーバーが別のコンピュータで実行しており、クロックが別の時刻に設定されている場合。
この場合は、ログインのslackパラメータを変更するか、システム・クロックを同期化します。
アイデンティティ・システムをポリシー・ドメインで保護しているが、アクセス・システムは保護していない（またはその逆）の場合。
両方のシステムを保護する必要があります。
共有シークレットを再生成する必要がある場合。
ディレクトリ・サーバーから共有シークレットを削除します。
アクセス・システム・コンソールにログインします。
「アクセス・システム構成」→「共通情報の構成」→「共有シークレット」を選択します。
新しい共有シークレットを生成します。
症状: Oracle Access Managerのインストール後にユーザーがログインできません。
原因: ユーザー・データをActive Directoryにインポートすると、すべてのパスワードが消去されます。これはActive Directoryのセキュリティの機能です。
解決方法: Active Directoryの「User and Computer MMC」で「Change password on next login」チェック・ボックスの選択が解除されていることを確認します。パスワードを変更するよう、ユーザーに指示します。
ポリシー・マネージャでは、Password属性のアクセス制御を有効化します。これで、パスワードを変更するためのサービス・チケットを、ユーザーが強制的に作成するようになります。
症状: ユーザーに対してログイン・プロンプトが繰返し表示されます。
原因: これは、Oracle Access ManagerをインストールしたWebサーバーで、Webブラウザによるセキュリティ・ポリシーを施行している場合に発生することがあります。
解決方法: Oracle Access Managerのセキュリティを有効化し、ブラウザのセキュリティを無効化します。
症状: /identityまたは/accessディレクトリを表示しようとする場合、または「システム・コンソール」リンクや「ポリシー・マネージャ」リンクをクリックした場合に、予測できない動作（ファイル・ダウンロードのためのダイアログ・ボックスの表示など）が発生することがあります。
原因: これは、Oracle Access ManagerをインストールしたWebサーバーで、Webブラウザによるセキュリティ・ポリシーを施行している場合に発生することがあります。Oracle Virtual Directoryに「スクリプトのみ」権限がある場合、ユーザーはアクセス・システム・コンソールまたはポリシー・マネージャにログインできません。
解決方法: Oracle Virtual Directoryの権限を「スクリプトのみ」から「スクリプトと実行可能ファイル」に変更します。
Oracle Virtual Directoryの権限を変更する手順
Oracle Access Managerに対して構成されているコンピュータを選択します。
デフォルトWebサイトを開きます。
identityまたはaccess（アイデンティティ・システムまたはアクセス・システムのインストール時に作成した仮想ディレクトリ）を右クリックします。
「プロパティ」を選択し、「スクリプトと実行可能ファイル」を選択します。
以前のリリースのOracle Access Manager for Linuxでは、LinuxThreadsライブラリのみを使用していました。LinuxThreadsを使用するには、環境変数LD_ASSUME_KERNELを手動で設定する必要があります。この環境変数は、使用するライブラリの実装を決定するために動的リンカーによって使用されます。LD_ASSUME_KERNELを2.4.19に設定すると、/lib/i686のライブラリが動的に使用されます。
Red Hat Linux v5以降のリリースでは、ネイティブPOSIXスレッド・ライブラリ（NPTL）のみがサポートされ、LinuxThreadsはサポートされません。この変更に対応するために、Oracle Access ManagerはNPTL仕様に準拠しています。ただし、デフォルトではLinuxThreadsが使用されます。
Oracle Access Managerは、ネイティブのPOSIXスレッド・ライブラリ（NPTL）またはLinuxThreadsのどちらかを使用します。デフォルト・モードは、LinuxThreadsです。デフォルトをサポートするために、start_ois_serverとstart_access_serverはLinuxThreadsモードで起動します。この場合、変数LD_ASSUME_KERNELは2.4.19に自動的に設定されます。コンソールとサーバーのoblogファイルに、「Linuxスレッド・ライブラリを使用中。」というメッセージが表示されます。ただし、start_ois_server_nptl（またはrestart_ois_server_nptl）またはstart_access_server_nptl（またはrestart_access_server_nptl）スクリプトを使用してサーバーを起動した場合は、NPTLモードが使用されます。この場合、コンソールとサーバーのoblogファイルに、「NPTLスレッド・ライブラリを使用中。」というメッセージが表示されます。
|
注意: Linuxの場合、Oracle HTTP Server 11gのOracle Access Manager WebコンポーネントではNPTLのみが使用されます。LinuxThreadsライブラリは使用できません。この場合、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。 |
Oracle Access Managerに対してNPTLを使用する場合、Oracle Access Manager用に作成したカスタム・プラグインとAPIに影響はありません。ただし、アップグレード時は、GCC v3.3.2 C++コンパイラを使用して、Oracle Access Managerリリース6.xからカスタム・プラグインを再コンパイルする必要があります。NPTLを使用する場合、Oracle Access Managerで使用するWebコンポーネントやサード・パーティのコネクタをインストールするときは、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。
NPTL対応のスクリプトには次のものがあります。
アイデンティティ・サーバー: start_ois_server_nptlまたはrestart_ois_server_nptl
アクセス・サーバー: start_access_server_nptlまたはrestart_access_server_nptl
|
注意: 標準の停止スクリプトと標準の設定スクリプト（start_setup_ois、start_setup_webpass、start_setup_access_manager、start_configureAAAServer、stop_snmp_agent、start_configureWebGateおよびstart_configureAccessGate）は、LinuxThreadsまたはNPTLのどちらを使用する場合でも正常に動作します。 |
SNMPエージェントの設定スクリプトであるstart_snmp_agentには、LD_ASSUME_KERNELのエントリが含まれています。Oracle Access Managerに対してNPTLを使用する場合、次のファイルのLD_ASSUME_KERNEL=2.4.19環境変数を削除またはコメント化する必要があります。
SNMPエージェント: start_snmp_agent
|
注意: Oracle Access Manager WebコンポーネントがLinuxThreadsを使用している状況で、Oracle Access ManagerサーバーがNPTLを使用して動作することは可能です（その逆も可能）。NPTLで使用するOracle Access Manager Webコンポーネントまたはサード・パーティのコネクタをインストールする場合、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。 |
NPTLおよびOracle Access Manager用のスクリプトを使用または変更する場合は、次の手順をガイドとして使用します。
Oracle Access Managerに対してNPTLを使用する手順
次の場所にある、アイデンティティ・サーバーとアクセス・サーバーのNPTLバージョンの起動スクリプトを使用します。
SNMPエージェント: 次の手順を実行して、start_snmp_agentスクリプトのLD_ASSUME_KERNEL=2.4.19環境変数を削除またはコメント化します。
次のパスにあるstart_snmp_agentスクリプトを探します。
テキスト・エディタで、次の行を削除またはコメント化します。
LD_ASSUME_KERNEL =2.4.19
ファイルを保存します。
デプロイ内のSNMPエージェントごとに、この手順を繰り返します。
次の標準の設定スクリプトと停止スクリプトを使用します。
NPTLを使用するWebコンポーネントまたはサード・パーティのコネクタ: Oracle Access Managerに対してNPTLを使用する場合、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。
既知の問題: ファイルが見つからない例外
WebGate oblog.logファイルには、次の例外が表示される場合があります。WebGate機能に悪影響はありません。
Using NPTL Threading Library. 2009/02/26@05:27:44.030874 24287 24321 INIT ERROR 0x000003B6 ../oblistrwutil.cpp:192 "Could not read file" ../oblog_config.xml Using NPTL Threading Library. 2009/02/26@05:27:44.042332 24287 24321 INIT ERROR 0x000003B6 ../oblistrwutil.cpp:192 "Could not read file" ..netlibmsg.xml
次の項目では、プラットフォーム固有の問題について説明します。
Oracle Enterprise Linuxに付属しているSELinux修正版は、LinuxカーネルでLinux Security Modules（LSM）を使用することにより、広範なセキュリティ・ポリシーを提供します。
SELinuxでは、Oracle Access Manager Webコンポーネントのインストール後、関連するWebサーバーを起動する前に追加の手順を実行する必要があります。
問題
（Oracle Access Manager Webコンポーネントのインストール後に）より厳格なSELinuxポリシーを搭載したLinuxディストリビューションでWebサーバーを起動した場合、Webサーバー・ログまたはコンソールに次のエラーが報告される可能性があります。
$WPINSTALLDIR/identity/oblix/apps/webpass/bin/libwebpass.so: cannot restore segment prot after reloc: Permission denied.
原因
このエラーは、ファイルのSecure Linuxセキュリティ・コンテキスト・ポリシーが原因で報告されます。
解決方法
このエラーを回避してWebサーバーを起動するには、各Oracle Access Manager Webコンポーネントをインストールしてから、関連するWebサーバーを再起動する前に、次のchconコマンドを実行して、ファイルのセキュリティ・コンテキストを変更します。chconコマンドの詳細は、Linuxのドキュメントを参照してください。
すべてのWebコンポーネント: chcon -t texrel_shlib_t PATH_TO_LIBWEBCOMPONENT.SOを実行します。次に例を示します。
chcon -t texrel_shlib_t /WebPass_install_dir/identity/oblix/apps/webpass/ bin/*.so
すべてのWebコンポーネント: chcon -t texrel_shlib_t PATH_TO_LIBWEBPLUGINS.SOを実行します。次に例を示します。
chcon -t texrel_shlib_t /WebPass_install_dir/identity/oblix/lib/*.so
WebGate: chcon -t texrel_shlib_t PATH_TO_LIBWEBGATE.SOを実行します。次に例を示します。
chcon -t texrel_shlib_t /WebGate_install_dir/WebGate/access/oblix/apps/ webgate/*.so
症状: Red Hat Linux v4上のアイデンティティ・システムのコンポーネントで、oblog_config.xmlファイルの"MAX_ROTATION_SIZE"を10000KBに減らしたときに、新しいNPTLベースのランタイム・ライブラリに対して障害が発生することがあります。
解決方法: LD_ASSUME_KERNEL環境変数を設定してから、Webサーバー、WebLogicコンポーネントとWebSphereコンポーネント（10.1.4 Software Developer Kitに統合されている）、およびOracle Access Manager Webコンポーネント（WebPass、WebGateおよびAccess Manager）を起動します。次に例を示します。
# export LD_ASSUME_KERNEL=2.4.19
これにより、Linux動的リンカーが古いランタイム・ライブラリを使用するようになります。
|
注意: Oracle Access Managerを実行する場合、デフォルトでLinuxThreadsが使用されます。このため、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要があります。Oracle Access Managerに対してNPTLを使用している場合は、LD_ASSUME_KERNELを2.4.19に設定しないでください。詳細は、「NPTLの要件とインストール後のタスク」を参照してください。 |
症状: LinuxプラットフォームでOracle Access Managerコマンドライン・ツールがクラッシュすることがあります。
解決方法: Linux v4プラットフォームでOracle Access Managerコマンドライン・ツールを実行するには、実行時にLD_ASSUME_KERNEL環境変数の値を2.4.19に設定する必要があります。これはLinuxの以前のスレッド・モデルがサポートされているためです（ネイティブのposixスレッド・ライブラリ（NPTL）ではない）。bashシェルを実行している場合、正確な仕様は次のとおりです。
# export LD_ASSUME_KERNEL=2.4.19
正確なコマンドは、使用しているシェルによって異なる場合があります。
有効なディレクトリを指すようにTEMP環境変数を設定する必要があります。図E-1に示すように、システム全体でこのように設定することをお薦めします。ただし、IISユーザーに対してもTEMP変数を設定できます。
この変数がないと、ポリシー・マネージャは一時的な中間ファイルをルート・ディクトリに作成しようとします。そのレベルにファイルを作成する権限がIISにない場合、次のような状況でエラーが発生します。次に例を示します。
ポリシー・マネージャを設定するとき
アクセス・システム・コンソールのメイン・ページで「ポリシー・マネージャ」または「アクセス・システム・コンソール」リンクを選択するとき
この場合、設定ページに、TEMPディレクトリを見つけられないことを警告するエラー・メッセージが表示されることがあります。
症状: オプションのポリシー・マネージャをアンインストールし、PolicyManager_install_dirのsetup*ファイルとconfig*ファイルを削除した後で、「ポリシー・ベースにアクセスするディレクトリ・サーバー・プロファイルは削除できません。」というメッセージを受け取ります。ユーザー・データと構成データのポリシー・マネージャ・プロファイルは、アイデンティティ・システム・コンソールで削除できますが、ポリシー・データのプロファイルは削除できません。
解決方法: オプションのポリシー・マネージャをアンインストールした後、残りのポリシー・マネージャのポリシー・プロファイルを削除する前に、次の手順を実行する必要があります。
残りのポリシー・マネージャ・ポリシー・プロファイルを削除する手順
残りのポリシー・マネージャ・ポリシー・プロファイルを削除するには、次の手順を実行します。
ポリシー・マネージャをアンインストールします。
ディレクトリ・サーバーで、oblix関連のすべてのエントリを削除します。必ず、最上位ノードからobpolicybase属性を削除してください。次に例を示します。
o=Oblix,o=oblixdata,c=uk
アイデンティティ・サーバーを再起動します。
アイデンティティ・システム・コンソールでポリシー・マネージャ・ポリシー・プロファイルを削除します。
|
関連項目: ポリシー・マネージャに影響する問題の詳細は、次の項目を参照してください。 |
Oracle Access Managerを削除し、同じディレクトリ・インスタンスを使用するように再インストールする場合は、Oracle Access Manager構成ツリーのみを削除してください。この場合、ディレクトリ・インスタンスからOracle Access Managerスキーマを削除する必要はありません。アイデンティティ・サーバーを再インストールするときに、スキーマ（すでに存在する）を更新するかどうかを確認されたら「いいえ」を選択します。「はい」を選択すると、「スキーマがすでに存在します」というエラー・メッセージが生成されます。
ディレクトリ・ベンダーのツールと指示を使用して、Oracle Access Manager構成ツリーをディレクトリ・サーバー・インスタンスから削除します。たとえば、Oracle Internet Directoryでは、Oracle Internet Directory管理コンソールを使用できます。ただし、依存状態があることや再起的削除が不可能であることから、親オブジェクトを単に削除することはできません。
Oracle Internet Directoryからコンソールを使用してOracle Access Managerスキーマを削除しないようにお薦めします。かわりに、component_install_dir\identity\access\oblix\data.ldap\commonのLDIFファイルを使用することをお薦めします。次に例を示します。
OID_oblix_schema_index_delete.ldif: Oracle Access Manager属性インデックス・クリーンアップ・ファイル。スキーマのクリーンアップの前または後に、Oracle Access Managerインデックスを削除します。
OID_user_schema_delete.ldif: Oracle Internet Directory用のOracle Access Managerユーザー・データ・クリーンアップ・ファイル。構成データとは別のディレクトリ・インスタンスにあるユーザー・データを削除します。
OID_oblix_schema_delete.ldif: Oracle Internet Directory用のOracle Access Manager構成データ・クリーンアップ・ファイル。同じディレクトリ・インスタンスにあるユーザー・データと構成データの両方を削除します。
ユーザー・データと構成データが同じディレクトリ・インスタンスにあるときは、OID_oblix_schema_delete.ldifのみを使用する必要があります。これによってユーザー・スキーマ・オブジェクトも削除されるためです。ただし、別のディレクトリ・インスタンスにユーザー・データのみがある場合は、OID_user_schema_delete.ldifを使用する必要があります。ただし、どちらの場合も属性インデックスの削除にはOID_oblix_schema_delete.ldifを使用してください。
手順は、第22章「Oracle Access Managerの削除」を参照してください。
コンポーネント・ファイルが指定のインストール・ディレクトリに抽出された後で、コンポーネントのインストールが終了した場合（つまりユーザーが終了した場合）、同じ場所に再インストールする前に、そのコンポーネントに対してアンインストーラを実行し、インストール・ディレクトリを削除する必要があります。単にインストール・ディレクトリを削除して、同じ場所にコンポーネントを再インストールしようとすると、vpd.propertiesファイルが一貫性のない状態になり、再インストールが機能しません。
たとえば、コンポーネント・ファイルが抽出された後でWebGateのインストールを終了し、WebGateアンインストーラを使用せずにインストール・ディレクトリを手動で削除したとします。この場合、抽出されたファイルは削除されますが、vpd.propertiesファイルは削除されません。このため、vpd.propertiesファイルが一貫性のない状態になり、正常にインストールできなくなります。
削除と再インストールの問題を避けるために適した方法は、コンポーネントのアンインストーラ・プログラムを実行し、インストール・ディレクトリを削除した後で、コンポーネントを再インストールすることです。ただし、（アンインストーラを実行せずに）コンポーネントのインストール・ディレクトリを手動で削除してから、vpd.propertiesをバックアップして削除し、コンポーネントのインストールを開始した後で、vpd.propertiesファイルをリストアすることもできます。
詳細は、第22章「Oracle Access Managerの削除」を参照してください。
Oracle Access Managerでは、3つのトランスポート・セキュリティ・モード（オープン、シンプルまたは証明書）がサポートされています。オープンは、最初に実装するときは容易ですが、セキュアではありません。
オープンで開始して後から変更するかわりに、必要なトランスポート・セキュリティ・モードを設定してOracle Access Managerをインストールすることをお薦めします。トランスポート・セキュリティ・モードの変更方法はこの後で説明します。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
アイデンティティ・システムでトランスポート・セキュリティ・モードを変更する手順
各アイデンティティ・サーバーで、IdentityServer_install_dir/identity/oblix/tools/certutilにあるアイデンティティ・サーバーのcertutilプログラムを実行します。
アイデンティティ・サーバーはWebPassの前に構成しておく必要があります。アイデンティティ・システムのすべてのコンポーネントで同じパスワードとPEMキーを使用する必要はありません。
各WebPassで、WebPass_install_dir/identity/oblix/tools/gencertにあるWebPassのgencertプログラムを実行します。
アクセス・システムでトランスポート・セキュリティ・モードを変更する手順
各アクセス・サーバーで、AccessServer_install_dir/access/oblix/tools/configureAAAServerにあるconfigureAAAServerプログラムを実行します。
アクセス・サーバーはWebGateの前に構成しておく必要があります。アクセス・システムのすべてのコンポーネントでは同じパスワードとPEMキーを使用します。
各WebGateで、WebGate_install_dir/access/oblix/tools/configureWebGateにあるconfigureWebGateプログラムを実行します。
ディレクトリに関する問題を次に示します。
Sunディレクトリ・サーバーをレプリケートして、ユーザーの変更を行うと、書込みが遅れることが通知されます。ただし、新しいユーザーの作成中には通知されません。
コンシューマに対して構成された新しいユーザーがアイデンティティ・システムのページに表示されるのは、サプライヤとコンシューマの間で次に同期化が行われるときです。
同期化をすぐに実行するか、スケジュールに基づいて実行するかは、レプリケーションの指定方法によって異なります。
症状: 「システム・コンソール」またはいずれかのアプリケーションで機能を使用しているときに、Oracle Access Managerがバグ・レポートまたはエラー・メッセージの表示を始めます。これは、データ破損のために発生することがあります。データ破損の診断は困難な場合があります。ディレクトリ・インタフェース・ツールの表示ではデータが有効に見えても、実際のデータファイルが破損していることがあります。これを確認する1つの方法は、ldapsearchのような別のツールを使用して同じ検索を実行することです。予期するデータが返されない場合は、データが破損しています。
解決方法: 最適な解決方法についてディレクトリのベンダーに問い合せます。可能であれば、ディレクトリ・データをLDIFにエクスポートして、LDIFでエラーを調べます。データに明らかなエラーがある場合は、エラーを適切に修正し、修正したデータをインポートします。
Webサーバーでは次の問題が発生する可能性があります。
症状: Apache Webサーバーを実行しているときに、次のメッセージが表示されてアクセス・サーバーで障害が発生します。
libthread panic: cannot create new lwp (PID: 9035 LWP 2). stackrace: ff3424cc 0
この症状は、Apache Webサーバーが自らのインスタンスをさらに起動したために引き起こされることがあります。1つ以上のWebGateとアクセス・サーバーの間の多数の接続を処理するために、追加のインスタンスが必要であるとサーバーが判断した場合に発生します。
追加のインスタンスによってさらに接続数が増え、アクセス・サーバーの接続数を超過します。
解決方法: MinSpareServers、MaxSpareServers、StartServersおよびMaxClientsパラメータの数値を減らします。
アクセス・サーバーの構成ディレクトリで、http.d構成ファイルを開きます。
次のパラメータ設定をお薦めします。
MinSpareServers 1
MaxSpareServers 5
StartServers 3
MaxClients 5
HP-UXでApache v2を実行するときは、共有メモリーが機能しない場合があるため、UserまたはGroupについてnobodyを使用しないでください。かわりに、"Oblix"というGroupに対してUser Nameとしてログイン名を使用します（またはUser Nameとして"www"、Group Nameとして"others"を使用）。HP-UXの"www"はSolarisの"nobody"と同じです。
HPUX 11.11でApache v2を実行するときは、Apache httpd.confファイルのAcceptMutexディレクティブを"fcntl"に設定してください。このディレクティブがない場合は、httpd.confファイルに追加します（AcceptMutex fcntl）。詳細は、次を参照してください。
ベンダーでバンドルされたApacheにWebPassまたはWebGateをインストールすると、Webサーバーの起動時に次のエラーが発生することがあります。
Error: Cannot load libgcc_s.so.1 library - Permission denied.
解決方法: 「Oracle Access Manager WebコンポーネントのためのApacheまたはIHS v2のチューニング」の説明に従って、Oracle Access Manager Webコンポーネントに対するセキュリティ強化Linux（SELinux）ポリシー・ルールを変更します。
Oracle Access Manager Webコンポーネントのインストール後に、より厳格なSELinuxポリシーを搭載したLinuxディストリビューションでWebサーバーを起動した場合、Webサーバー・ログまたはコンソールにエラーが報告されることがあります。Webサーバーを再起動する前に、インストールされているWebコンポーネントに対して適切なchconコマンドを実行することで、このようなエラーを回避できます。
次の項目は、UNIX上のWebGate用のApache v2をmpm_worker_moduleとコンパイルする場合にのみ必要になります。この場合、UNIX環境用のApacheソースのthread.cファイルを変更する必要があります。この変更を行うと、WebGate用のデフォルトのpthreadスタック・サイズにより、マルチスレッド・サーバーの実装中に最適なパフォーマンスが確実に得られます。この変更を行わない場合、デフォルトのpthreadスタック・サイズはWebGateに対して十分ではないため、クラッシュが発生する可能性があります。
Apache 2.0では、ThreadStackSizeオプションはサポートされません。そのため、次のようになります。
UNIXベースのApache v2.1以降を使用する場合、ThreadStackSizeディレクティブを使用して、クライアント接続の処理とその処理に役立つモジュールの呼び出しを行うスレッドの（autodata用の）スタックのサイズを設定する必要があります。
UNIXベースのApache 2を使用する場合、コンパイル可能なソースを使用して、mpm_worker_moduleを追加し、thread.cファイルを変更してスタック・オーバーフローを回避するのが最適です。
次の手順は、マルチスレッド・サーバーの実装中に最適なパフォーマンスを得るためにWebGateで必要になるデフォルトのpthreadスタック・サイズを提供するように、Apache v2.0 thread.cファイルを変更する方法を示しています。Apache v2.1+ ThreadStackSizeディレクティブの詳細は、http://httpd.apache.org/docs/2.2/mod/mpm_common.html#threadstacksizeを参照してください。
|
注意: 次の手順は、Apache 2.0 WebGateに対してのみ実行する必要があります。それ以外の場合、デフォルトのpthreadスタック・サイズはWebGateに対して十分ではないため、クラッシュが発生する可能性があります。 |
UNIX環境のWebGateに合せてApache v2.0 thread.cファイルを変更する手順
thread.cファイルを探します。次に例を示します。
APACHE 2.0.52 source/srclib/apr/threadproc/unix/thread.c
次のコード・セグメントでapr_threadattr_create(apr_threadattr_t **new,apr_pool_t *pool)という名前の関数を探します。
**new,apr_pool_t *pool) in the following code segment:
1-----> apr_status_t stat;
2
3-----> (*new) = (apr_threadattr_t *)apr_pcalloc(pool, sizeof(apr_threadattr_t));
4-----> (*new)->attr = (pthread_attr_t *)apr_pcalloc(pool, sizeof(pthread_attr_t));
5
6-----> if ((*new) == NULL || (*new)->attr == NULL) {
7-----> return APR_ENOMEM;
8-----> }
9
10----->(*new)->pool = pool;
11----->stat = pthread_attr_init((*new)->attr);
12
13-----> if (stat == 0) {
14-----> return APR_SUCCESS;
15-----> }
16----->#ifdef PTHREAD_SETS_ERRNO
17----->stat = errno;
18----->#endif
19
20----->return stat;
21
13行目の前に次のコードを追加します。
int stacksize = 1 << 20; pthread_attr_setstacksize(&(*new)->attr, stacksize);
configure、makeおよびmake installを実行して、mpm_worker_moduleを含むApache Webサーバーを設定します。
認証イベントの失敗: Domino Webサーバーでは、Oracle Access Managerを介したURLのリダイレクトが機能しないことがあります。認証タイプがBasic Over LDAPに設定され、リダイレクトされるURLが次のいずれかで記述されている場合です。
認証イベントの失敗を解決するには、ホスト識別子グループに定義されていないコンピュータ名を含むようにリダイレクトURLを設定する必要があります。たとえば、コンピュータのIPアドレスを使用します。
この問題は、フォームベースの認証タイプでは発生しません。
ヘッダー変数: クライアント証明書認証スキームを使用するとき、Lotus Notes Domino WebサーバーにインストールしたWebGateにREMOTE_USER以外のヘッダー変数を渡すことができない場合があります。
たとえば、クライアント証明書認証が行われるリクエストにはヘッダー変数を設定できません。ただし、他のすべてのリクエストにはヘッダー変数を設定できます。
詳細は、第18章「WebGateのためのLotus Domino Webサーバーの設定」を参照してください。
症状: Oracle Access ManagerをUNIXにインストールするときに、Webサーバー・インスタンスの作成に使用したのとは違うユーザーIDを使用すると、Oracle Access Managerが不安定になることがあります。次のような動作が発生することがあります。
解決方法: chownコマンドを使用してファイルの権限を変更します。Oracle Access Managerディレクトリを、Webサーバー・インスタンスの作成に使用したのと同じユーザーIDに変更します。
WebPass、WebGateまたはポリシー・マネージャ・インスタンスをOracle HTTP Serverにインストールした後で、サーバーが起動しなくなります。これは、Oracle Access Managerによって以前のLinuxスレッド・モデルが使用されているために起こります。
|
注意: Oracle Access Managerを実行する場合、デフォルトでLinuxThreadsが使用されます。このため、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要があります。Oracle Access Managerに対してNPTLを使用している場合は、LD_ASSUME_KERNELを2.4.19に設定しないでください。詳細は、「NPTLの要件とインストール後のタスク」を参照してください。 |
解決方法: 次の手順に示すように、LinuxThreadsモードを使用しているときは、httpd.confファイルでPerlモジュールをコメント化し、LD_ASSUME_KERNEL環境変数を更新してから再起動します。
LinuxThreadsモードでのOracle HTTP Serverの起動失敗を解決する手順
次の場所にあるhttpd.confファイルのPerlモジュールをコメント化します。
Oracle HTTP Server 11g: ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
Oracle HTTP Server v2: OH$/ohs/conf/httpd.conf
Oracle HTTP Server v1.3: OH$/Apache/Apache/conf/httpd.conf
LD_ASSUME_KERNELの値を更新するには、テキスト・エディタで次のファイルを開きます。
OH$/opmn/conf/opm.xml
次の行を探します。
<process-type id="HTTP_Server" module-id="OHS">
前の手順で探した行の下に次の情報を追加します。
<environment> <variable id="LD_ASSUME_KERNEL" value="2.4.19" /> </environment>
このファイルを保存します。
次のコマンドを実行して変更内容を実装します。
opmnctl stopall opmnctl startall
この状況は、LinuxThreadsまたはNPTLのどちらに対してOracle Access Managerを使用していても生じる場合があります。
症状: Oracle HTTP Serverで2.6.9-34.ELより前のバージョンのカーネルを搭載したRed Hat Enterprise Serverバージョン4.0を実行している場合、このOracle HTTP ServerにWebGateをインストールすると、WebGateの初期化に失敗します。バージョン2.6.9-34.ELはRed Hatバージョン4、アップデート3で提供されます。
解決方法: この問題を回避するには、Red Hatバージョン4、アップデート3以降にアップグレードする必要があります。
問題
Oracle Application Server 10.1.x、OC4Jを使用する場合、httpd.confファイルは、WebGateのインストール中にhttpd.confファイルが自動的に変更されると破損する可能性があります。
解決方法
WebGateをインストールする前に、次のコマンドを実行して、httpd.confファイルが上書きされないようにします。
$ORACLE_HOME/dcm/bin/dcmctl updateConfig -ct ohs
IIS 6 Webサーバーの場合のみ、WWWサービスをIIS 5.0分離モードで実行する必要があります。このことは、ISAPIポストゲート・フィルタの要件です。このシナリオは、32ビットWindowsオペレーティング・システムで動作する32ビットOracle Access Managerバイナリを使用する場合に適用されます。ただし、IISが32ビット・モードで動作している64ビットWindowsマシンで32ビットpostgate.dllを実行すると、問題が発生します。
問題
IISをIIS5.0分離モードで実行すると、次のメッセージが表示されます。
"ISAPI Filter 'C:\webgate\access\oblix\apps\webgate\bin\webgate.dll' could not be loaded due to a configuration problem."
原因
現在の構成では、AMD 64ビット・プロセッサ・アーキテクチャ用に作成されたイメージのロードのみがサポートされます。データ・フィールドにはエラー番号が含まれます。
解決方法
このようなプロセッサ・アーキテクチャのミスマッチ・エラーをトラブルシューティングする方法など、この問題の詳細は、次のWebサイトを参照してください。
http://go.microsoft.com/fwlink/?LinkId=29349
詳細は、次のURLにあるヘルプとサポート・センターを参照してください。
http://go.microsoft.com/fwlink/events.asp
問題
64ビットのIIS5は存在しません。ただし、64ビットWindowsコンピュータ上のIIS v6のIIS5互換モードは、64ビットとしてのみ動作します。
原因
次のURLから入手可能なドキュメントで説明されているように、64ビットWindowsでIIS5分離モードの32ビットを実行することは、アーキテクチャ上不可能です。
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.pu blic.inetserver.iis&tid=5dd07102-8896-40cc-86cb-809060fa9426&cat=en_US_ 02ceb021-bb43-476d-8f8f-6c00a363ccf5&lang=en&cr=US&p=1
http://blogs.msdn.com/david.wang/archive/2005/12/14/HOWTO-Diagnose-one-cause-of-W3 SVC-failing-to-start-with-Win32-Error-193-on-64bit-Windows.aspx
症状: Sun Webサーバーを起動しようとすると、次のようなエラーを受け取ります。
Unable to start, PCLOSE
解決方法: 次のような問題がこのエラーの原因になります。
obj.confファイルの構文エラー
obj.confファイルの先頭の空白
Webサーバー・インスタンスの作成に使用したのとは違うユーザーIDでのOracle Access Managerのインストール
obj.confファイルの最後の改行
Oracle Access ManagerをMicrosoft社のIIS Webサーバーで実行している場合、Oracle Access Managerを再インストールするときに、次のISAPIフィルタを手動でアンインストールおよび再インストールする必要があります。
tranfilter.dll
oblixlock.dll（WebGateをインストールした場合）
webgate.dll（WebGateをインストールした場合）
Oracle Access Managerをアンインストールします。
前述のDLLを手動でアンインストールします。
Active Directoryに対してOracle Access Managerを再インストールします。
DLLを手動で再インストールします。
|
注意: これらのフィルタは、使用しているIISのバージョンによって異なる可能性があります。これらのフィルタが存在しない、またはその他のフィルタが存在する場合は、オラクル社に問い合せて、存在するフィルタを削除する必要があるかどうかを確認します。 |
WebGateでは次の問題が発生する可能性があります。
アクセス・サーバーとWebGateの名前には、英語キーボードにない文字を使用することはできません。
アクセス・システム・コンソールの「AccessGateの変更」ページの説明では大文字と小文字は区別されません。たとえば、説明で大文字と小文字を変更しても、その他の部分を変更しないと、保存しても変更が表示されません。この問題に対処するには、変更を認識できるようにその他の情報を追加または変更します。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「AccessGate構成」にナビゲートします。
特定のAccessGateを検索するか、「実行」ボタンを選択してすべてのAccessGateのリストを表示します。
変更するWebGateのリンクをダブルクリックします。
ページの一番下の「変更」をクリックします。
大文字と小文字を変更し、新しい情報を加えた新しい説明を入力します。次に例を示します。
変更前: webgate
変更後: WebGate with IIS 6.0
WebGateのインストールと構成の後で、ブラウザに次のWebGate診断のURLを指定します。
http(s)://host:port/access/oblix/apps/webgate/bin/webgate.cgi?progid=1
hostとportはWebGateのホスト名とWebサーバー・インスタンスのポート番号です。診断ページが開かない場合は、WebGateが正しくインストールされていません。
症状: Solarisコンピュータでデバッグを有効にしてアクセス・サーバーを実行しているときに、そのアクセス・サーバーを使用するWindowsサーバーにWebGateをインストールすると、アクセス・サーバーのデバッグ・ログに次のようなメッセージが表示されることがあります。
Got a client! SSL handshake failed: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
解決方法: このようなメッセージは問題ありません。無視できます。
アイデンティティ・システムの保護を最大にするには、WebGateとアイデンティティ・システムを同じディレクトリにインストールします。
症状: アクセス・サーバーに接続しようとすると、停止していることを示すエラーを受け取ります。
解決方法: 様々なOracle Access Managerコンポーネントの各ホスト・コンピュータのクロックは、誤差が75秒以内であることが必要です。クロックの誤差が75秒を超える場合、インストール環境に障害が発生します。
症状: アイデンティティ・システムを起動しようとすると次のエラーを受け取ります。
Access Server error WebGate cannot connect to Access Server
原因: WebGateを「システム・コンソール」で構成するときは、各WebGateを少なくとも1つのアクセス・サーバーにリンクする必要があります。
解決方法: ポリシー・マネージャでWebGateをアクセス・サーバーに関連付けます。その後、WebGateを構成します。
症状: Oracle HTTP Serverで2.6.9-34.ELより前のバージョンのカーネルを搭載したRed Hat Enterprise Serverバージョン4.0を実行している場合、このOracle HTTP ServerにWebGateをインストールすると、WebGateの初期化に失敗します。バージョン2.6.9-34.ELはRed Hatバージョン4、アップデート3で提供されます。
解決方法: この問題を回避するには、Red Hatバージョン4をアップデート3以降にアップグレードする必要があります。
|
注意: Oracle Access Managerを実行する場合、デフォルトでLinuxThreadsが使用されます。このため、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要があります。Oracle Access Managerに対してNPTLを使用している場合は、LD_ASSUME_KERNELを2.4.19に設定しないでください。詳細は、「NPTLの要件とインストール後のタスク」を参照してください。 |
問題
ログアウト・メカニズムにより、ObSSOCookieが停止または削除されます。ログアウト後、クライアント証明書認証で保護された元のリソースに同じブラウザ・セッションからアクセスしても、認証の再チャレンジは行われません。
原因
クライアント証明書認証では、ブラウザは、リクエストごとにアクセス・サーバーで認証に使用される証明書を保存しています。アクセス・サーバーはこの証明書を使用し、認証（ユーザー証明書）を求めることなく、以前にログインしたユーザーを認証します。これにより、新しいObSSOCookieが作成されます。
解決方法
ログアウト後、ブラウザ・ウィンドウを閉じます。
次にその他の問題について説明します。
症状: ポリシー・マネージャがシンプル・トランスポート・セキュリティ・モードまたは証明書トランスポート・セキュリティ・モードを使用する場合、ポリシー・マネージャからキャッシュをフラッシュするには証明書が必要です。ポリシー・マネージャが、シンプル・モードまたは証明書モードでインストールされたWebGateで保護されている場合は、証明書が存在するため問題ありません。ただし、WebGateをシンプル・モードまたは証明書モードでインストールしていない場合は、ポリシー・マネージャがアクセス・サーバーと通信できないため、アクセス・システム・キャッシュを更新できません。
解決方法: WebGateのないシステムでは、GenCertツールを使用して証明書を生成します。このツールはIdentityServer_install_dir/identity/oblix/toolsに格納されています。IdentityServer_install_dirはアイデンティティ・サーバーのインストール・ディレクトリです。
キャッシュをフラッシュするために証明書を生成する手順（コマンド入力）
genCert install_dir
IdentityServer_install_dirは、アイデンティティ・サーバーのインストール・ディレクトリです。このファイルをインストール・ディレクトリに書き込むための権限が必要です。
マスター管理者は、Oracle Access Managerのインストールおよび設定の際に指定します。最上位のマスター管理者でも、特に割り当てないかぎり、属性の表示権限はありません。
管理者には、ディレクトリ・ツリーの一番上のレベルでcn属性（通常はフルネームとして構成される）を表示する権限が必要です。これにより、管理者は、他のユーザーに対して属性のアクセス制御を構成できます。
|
関連項目: このタスクの実行の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
症状: シンプルまたは証明書トランスポート・セキュリティ・モードを使用している場合、ユーザーのブラウザは資格証明をキャッシュして、WebGateセッションがタイムアウトになると自動的にそれらを再送信します。このため、タイムアウトの設定が機能していないように見えます。実際には、ユーザー側のアクションはありませんが、新しい認証交換が行われています。
解決方法: フォームベースの認証を使用します。ブラウザはフォームベースの認証情報をキャッシュしません。
SSLをアクティブ化するとディレクトリをロードする時間が大幅に長くなることがあります。ディレクトリをロードしてから、Webサーバーとディレクトリ・サーバーのSSLをアクティブ化してください。
症状: 正しくないTCPポートに設定されたOracle Access Manager以外のプログラムがアクセス・サーバーと通信しようとすると、アクセス・サーバーのデバッグ出力にエラーが生成されます。アクセス・サーバーのデバッグ出力に次のエラーが表示されます。
Peer does not use NetPoint Access Protocol. Connection dropped.
アクセス・サーバーのデバッグ出力のメッセージが生成されることを除き、Oracle Access Managerインストールへの影響はありません。ただし、Oracle Access Manager以外のピアがアクセス・サーバーと通信しようとすると失敗します。
解決方法: TCPポート番号を調べます。接続に誤りがあります。
Oracle Access Managerは、デフォルトでは、Sunでのレプリケーションをサポートしていません。
症状: Sunのコンシューマまたはスレーブに書込みを行うと、バグ・レポート・フォームを受け取ります。
解決方法: enableLDAPReferralパラメータを次のように更新します。
テキスト・エディタでldapconfigdbparams.xmlファイルを開きます。このファイルは次の2箇所に格納されています。両方を編集してください。
IdentityServer_install_dir/identity/oblix/data/common/ldapconfigdbparams.xml
Access_Server_install_dir/access/oblix/data/common/ldapconfigdbparams.xml
enableLDAPReferralパラメータをtrueに変更します。
変更内容を保存します。
コンシューマまたはスレーブのWebサーバーを再起動します。
症状: 検索または問合せを実行すると、「不正なリクエスト」というメッセージを受け取ります。
原因: ブラウザに対して、検索または問合せの文字列が長すぎます。ブラウザでは検索や問合せの文字列をURLとして処理します。文字列がURLの最大長を超えるとエラーが生成されます。
解決方法: 検索または問合せの文字列を短くします。
症状: 「アイデンティティ・サーバーにログインしていますが、アクセス・システムからログアウトしています。」というメッセージを受け取ります。この問題が発生するのは、Accessドメイン・ポリシーが無効でIdentityドメイン・ポリシーが有効な場合に、ポリシー・マネージャに有効なユーザーとしてログインしたときです。
解決方法: セキュリティのため、ポリシー・マネージャにログインするときは、ポリシー・マネージャ（/access）のポリシーとIdentityドメイン（/identity）のポリシーを有効にして保護する必要があります。
FrontPageがOracle Access Managerで正しく動作するためには、Oracle Access Managerがすべての認証と認可を実行できるようにIISを設定する必要があります。
Oracle Access Managerですべての認証と認可を実行できるようにする手順
Webサーバーは、Webコンテンツを含むすべてのディレクトリを全面的に制御できるユーザーとして実行する必要があります。
WebサーバーのMMCを使用して、「directory security」タブをクリックします。
匿名ユーザーと認証の「Edit」ボタンをクリックします。
「allow anonymous users」チェック・ボックスのみが選択されていることを確認します。他の2つのチェック・ボックス（「basic authentication」と「nlm authentication」）は選択を解除します。
FrontPageサーバー管理ツール（FrontPageのバージョンごとに異なる）を使用して、Webサーバー・プロセス・ユーザー（IUSR_OBLIXなど）をFrontPageのadminに追加します。
