| Oracle® Fusion Middleware Oracle Mobile Security Suiteの管理 11gリリース2 (11.1.2.3) for All Platforms E61946-02 |
|
 前 |
| Oracle® Fusion Middleware Oracle Mobile Security Suiteの管理 11gリリース2 (11.1.2.3) for All Platforms E61946-02 |
|
前 |
この章では、Oracle Mobile Security Suiteのトラブルシューティングのヒントを提供します。
次の項が含まれます:
クライアント・ログは、必要なすべてのクライアント・ログをパッケージ化するログ送信機能を使用してメール送信できます。
トラブルシューティング用の詳細ログを収集するには、次のようにします。
モバイル・セキュリティ・ワークスペースのアプリケーション設定に移動します。
「ログ・モード」を有効にします。
「ログ・レベル」を「verbose」に設定します。
モバイル・セキュリティ・アクセス・サーバー(MSAS)のコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを作成します。システム・アクティビティの監視および問題の診断に役立つログ・ファイルを表示したり管理する方法の詳細は、『Oracle Fusion Middleware Oracle Mobile Security Access Serverの管理』のログ・ファイルの管理に関する項を参照してください。
ロギングは、コンポーネントがファイルにメッセージを書き込むためのメカニズムです。管理者は、ロギング機能を使用して、様々な粒度レベルの情報を含むコンポーネント・イベントを取得できます。Oracleモバイル・セキュリティ・マネージャは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとガイドラインを使用しています。これはjava.util.loggingパッケージを使用して行いますが、このパッケージは標準的なもので、すべてのJava環境で使用できます。ロギング・システムはフラット・ファイルにのみ出力を書き出します。
ロギングの構成とログ・ファイルの検索がこの項の焦点です。ログ・ファイルの情報を使用した問題診断については、このマニュアルでは取り上げません。この項の内容は次のとおりです。
Oracle Diagnostic Logging (ODL)は、Oracleモバイル・セキュリティ・マネージャが使用する主要なロギング・サービスです。ODLロギングを動作させるには、ロガーとログ・ハンドラの両方を構成する必要があります。ロガーはハンドラにメッセージを送信し、ハンドラはメッセージを受け入れてログ・ファイルに出力します。
Oracleモバイル・セキュリティ・マネージャは、次の表のファイルを使用します
表13-1 Oracleモバイル・セキュリティ・マネージャで使用されるロギング・ファイル
| ファイル・タイプ | 説明 |
|---|---|
|
ロギング構成ファイル |
ロギング・レベルとロギングに関するその他の構成情報を提供します。このファイルは次のパスに格納されています。 $DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml |
|
ログ・ファイル |
記録された情報は次の場所に格納されます。 $DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log |
ロギング構成は、第13.3.5項「logging.xmlファイルを使用したロガーおよびログ・ハンドラの構成」で説明されているlogging.xmlファイルによって制御されます。このファイルは、直接編集するか(第13.3.5項「logging.xmlファイルを使用したロガーおよびログ・ハンドラの構成」)、またはOracle Fusion Middleware Controlを使用して編集できます(第13.3.4項「Fusion Middleware Controlを使用したロガーおよびログ・ハンドラの構成」)。
|
関連項目: Oracleモバイル・セキュリティ・マネージャのコンポーネント・ロガーの詳細は、第13.3.2項「Oracleモバイル・セキュリティ・マネージャのコンポーネント・ロガーについて」を参照してください。ロギング・メッセージのタイプとレベルの詳細は、第13.3.3項「ロギング・メッセージのタイプとレベルについて」を参照してください。 |
Oracleモバイル・セキュリティ・マネージャには、他のOracle Identity Managementコンポーネントのロガーとは異なる独自のロガーがあり、それぞれ異なる情報量を1つ以上のログ・ハンドラに送信するように個別に構成できます。
表13-2に、Oracleモバイル・セキュリティ・マネージャのコンポーネント・ロガーを示します。
表13-2 Oracleモバイル・セキュリティ・マネージャのコンポーネント・ロガー
| ロガー名 | 説明 |
|---|---|
|
oracle.idm.msm.common |
他の機能によって内部で使用される設定、構成およびセキュリティに関連するイベントをログに記録します。 |
|
oracle.idm.msm.identity |
アイデンティティ管理に関連するイベントをログに記録します。 |
|
oracle.idm.msm.notification |
ユーザーおよびデバイス通知に関連するイベントをログに記録します。 |
|
oracle.idm.msm.platform |
プラットフォームで提供されるサービス(主に他の機能で使用される)に関連するイベントをログに記録します。永続性管理、Bean管理などのサービスが含まれます。 |
|
oracle.idm.msm.policy |
ポリシー管理に関連するイベントをログに記録します。 |
|
oracle.idm.msm.repository |
アプリケーション・カタログ管理、デバイス操作キューおよびデバイス構成に関連するイベントをログに記録します。 |
|
oracle.idm.msm.runtime |
登録サービス、プロファイル・サービス、デバイス管理、SCEPサービスなどのランタイム・サービスに関連するイベントをログに記録します。 |
|
oracle.idm.msm.service |
外部クライアントに公開されるすべてのサービスに関連するイベントをログに記録します。これには、ReSTサービス実装も含まれます。 |
ロガーにより出力されるデータの量はロガーのレベルによって制御され、レベルが高くなるほどより多くの情報が記録されます。ODLのロギング・メッセージのタイプとレベルを指定できます。ODLでは、INCIDENT_ERROR、ERROR、WARNING、NOTIFICATION、TRACEの5つのメッセージ・タイプを認識します。各メッセージ・タイプで1 (最高重大度) - 32 (最低重大度)の数値を使用して、メッセージ出力をさらに制限することもできます。メッセージ・タイプを指定すると、ODLではそのタイプのすべてのメッセージと、指定したタイプ以上の重大度のメッセージが返されます。たとえば、メッセージ・タイプをWARNINGに設定した場合、ODLではINCIDENT_ERRORとERRORのタイプのメッセージも返されます。
メッセージのタイプとレベルの詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルに書き込まれる情報レベルの設定に関する項を参照してください。
表13-3 ODLのメッセージのタイプとレベル
| メッセージ・タイプおよび数値 | 説明 |
|---|---|
|
INCIDENT_ERROR:1 |
製品のbugが原因の可能性があり、Oracleサポートに報告する必要がある重大な問題。 この例として、回復不能なエラーがあります。 |
|
ERROR:1 |
管理者がただちに対処する必要があり、製品のbug以外が原因の重大な問題。 この例として、Oracle Fusion Middlewareがログ・ファイルを処理できないものの、ドキュメントに対する権限の調整によって問題の修正が可能な場合などがあります。 |
|
WARNING:1 |
管理者による確認を要する、潜在的な問題。 この例としては、パラメータ値が無効な場合や指定したファイルが存在しない場合などがあります。 |
|
NOTIFICATION:1 |
プライマリ・サブコンポーネントや機能のアクティブ化や非アクティブ化などの主要なライフサイクル・イベント。 これは |
|
NOTIFICATION:16 |
通常のイベントをレポートする粒度の詳細なレベル。 |
|
TRACE:1 |
パブリックAPIエントリや終了ポイントなど、管理者に重要なイベントに関するトレースまたはデバッグ情報。 |
|
TRACE:16 |
詳細なトレースまたはデバッグ情報で、Oracleサポートによる特定のサブシステムの問題診断に有益なもの。 |
|
TRACE:32 |
非常に詳細なトレースまたはデバッグ情報で、Oracleサポートによる特定のサブシステムの問題診断に有益なもの。 |
Oracle Fusion Middlewareのコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを作成します。管理者は、この項の説明に従い、Fusion Middleware Controlを使用してOracleモバイル・セキュリティ・マネージャのログ・レベルを設定したり、新しいログ・ハンドラを作成できます。
Fusion Middleware Controlを使用するかわりにlogging.xmlファイルを編集してロガーおよびログ・ハンドラを構成する場合は、第13.3.5項「logging.xmlファイルを使用したロガーおよびログ・ハンドラの構成」を参照してください。
ロギング構成へのアクセス
Oracle Fusion Middleware Controlを使用してロギング構成にアクセスするには、次のようにします。
Oracle Fusion Middleware Controlにログインします。
Oracle Fusion Middleware Controlへのログインの詳細は、『Oracle Fusion Middleware管理者ガイド』のFusion Middleware Controlの表示に関する項を参照してください。
ナビゲーション・ペインで、ファーム、「WebLogicドメイン」、ドメインの順に展開します。
ドメインを右クリックし、「ログ」、「ログ構成」の順に選択します。
「ログ構成」ページが表示されます。図13-1に示すように、ログ構成画面に、ロギングに使用できるすべてのパッケージが表示されます。
図13-1 Oracle Fusion Middleware ControlでのOracleモバイル・セキュリティ・マネージャのログ構成
Oracleモバイル・セキュリティ・マネージャ固有のパッケージには、oracle.idm.msmからアクセスできます。
ロギング・レベルの構成
Oracle Diagnostic Loggingレベル列で、各ログ・レベルを選択できます。
Oracle Diagnostic Loggingレベルを構成するには、次のようにします。
「ログ・レベル」タブをクリックします。
Oracle Diagnostic Loggingレベル列で、対応するロガーのロギング・レベルを選択します。
「適用」をクリックして、ログ・レベル構成の変更を送信し、適用すると、変更内容はただちに有効になります。
新しいログ・ハンドラの作成
さらに、「ログ・ファイル」タブを使用して、新しいログ・ハンドラを作成および構成できます。
「ログ・ファイル」タブをクリックします。
「作成」ボタンをクリックして、新しい「ログ・ファイルの作成」フォームを表示します。
このログ・ファイルの名前とファイル・システム・パスを入力します。
希望のログ・ファイル形式をクリックします。たとえば、... 「テキスト」をクリックします。
ロギング属性を設定します。
ロガーを関連付けます。
ローテーション・ポリシーを指定します。
「OK」をクリックして構成を送信します。
既存のログ・ハンドラに類似したログ・ハンドラを作成する場合は、「類似作成」ボタンをクリックします。
Fusion Middleware Controlではロガーを構成し、ログ・ハンドラを作成できます。ただし、ここで説明するように、logging.xmlファイルを編集してロガーおよびログ・ハンドラを構成することもできます。
logging.xmlファイルは、次のディレクトリにあります。
DOMAIN_NAME/config/fmwconfig/servers/SERVER_NAME/logging.xml
DOMAIN_NAMEとSERVER_NAMEは、それぞれOracleモバイル・セキュリティ・マネージャのインストール時に指定されたドメイン名とサーバー名です。
logging.xmlファイルには<log_handlers>構成セクションがあり、その下に<loggers>構成セクションが続きます。各ログ・ハンドラを、<log_handlers>セクションで定義し、各ロガーを<loggers>セクションで定義します。
ファイルの基本構造は次のとおりです。
<logging configuration>
<log_handlers>
<log_handler name='console-handler' level="NOTIFICATION:16"></log_handler>
<log_handler name='odl-handler'></log_handler>
<!--Additional log_handler elements defined here....-->
</log_handlers>
<loggers>
<logger name='' level='WARNING:1'>
<handler name='odl-handler'/>
<handler name='wls-domain'/>
<handler name='console-handler'/>
</logger>
<logger name="example.logger.one" level="NOTIFICATION:16">
<handler name="console-handler"/>
</logger>
<logger name="example.logger.two" />
<logger name="example.logger.three" />
<!--Additional logger elements defined here....-->
</loggers>
</logging_configuration>
メッセージをコンソールかファイルのどちらかに書き込むようにロガーを構成する場合は、ロガーとハンドラの両方の構成変更を行います。ロガーでのレベル属性の設定は、ロガーがハンドラに送信する詳細の量(つまりメッセージ量)を構成します。同様に、ハンドラでのレベル属性の設定は、ハンドラがロガーから受け入れる詳細の量を構成します。
個々のログ・ハンドラは、logging.xmlファイルの<log_handlers>セクションで構成します。ハンドラのレベル属性を構成して、ハンドラがロガーから受け入れる詳細の量を設定します。
ログ・ハンドラのレベル属性を構成するには、次のようにします
DOMAIN_NAME/config/fmwconfig/servers/SERVER_NAME/logging.xmlファイルを開きます。
レベル属性を次の例に示すように変更します。
このXMLコード例では、omsm-handlerのレベル属性がWARNING:32に設定されます。
<log_handler name='omsm-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory' filter='oracle.dfw.incident.IncidentDetectionLogFilter' level='WARNING:32' >
omsm-handlerがコンソールにTRACEレベルのメッセージを書き込めるようにするには、レベル属性を次のように変更します。
<log_handler name='omsm-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory' filter='oracle.dfw.incident.IncidentDetectionLogFilter' level='TRACE:1' >
変更を保存して、アプリケーション・サーバーを再起動します。
ファイルに書き込まれるログ・ハンドラの追加プロパティを構成できます。たとえば、次に示すlogging.xmlからの抜粋では、omsm-handlerが構成されています。
<log_handler name='omsm-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory' filter='oracle.dfw.incident.IncidentDetectionLogFilter'>
<property name='path' value='${domain.home}/servers/${weblogic.Name}/logs/${weblogic.Name}-diagnostic.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='encoding' value='UTF-8'/>
<property name='useThreadName' value='true'/>
<property name='supplementalAttributes' value='J2EE_APP.name,J2EE_MODULE.name, WEBSERVICE.name,WEBSERVICE_PORT.name,composite_instance_id,component_instance_id, composite_name,component_name'/>
</log_handler>
Fusion Middleware ControlツールおよびWLSTコマンドライン・ツールの詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルの設定の構成に関する項を参照してください
WLSTコマンドライン・ツールの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のカスタムWLSTコマンドのロギングに関する項を参照してください
個々のロガーは、logging.xmlファイルの<loggers>セクションで構成します。Oracleモバイル・セキュリティ・マネージャには、ログ・ハンドラにメッセージを送信するように構成できる、8つのロガーがあります。ロガーのレベル属性の設定で、ロガーがハンドラに送信する詳細の量(つまりメッセージ量)が構成されます。1つ以上の<handler>要素を<logger>要素内にネストすると、ロガーにハンドラが割り当てられます。次の抜粋に、oracle.idm.msm.serviceというロガーを示します。レベル属性はTRACE:32に設定され、ロガーによって2つのハンドラにメッセージが送信されます。
<logger name='oracle.idm.msm.service' level='TRACE:32' useParentHandlers='false'> <handler name='odl-handler'/> <handler name='omsm-handler'/> </logger>
ロガーは、親のレベル設定やその他の属性、親のロガーのハンドラなど、親のロガーの設定を継承します。継承を無効にするには、前述の抜粋に示すように、useParentHandlers属性をfalseに設定します。
ロガーの継承ツリーの最上部にあるのがルート・ロガーです。ルート・ロガーは、次の例に示すように、名前属性が空のロガーです。
<loggers>
<logger name="" level="WARNING:1">
<handler name="odl-handler"/>
<handler name="wls-domain"/>
<handler name="console-handler"/>
</logger>
<!-- Additional loggers listed here -->
</loggers>
次の例に示すように、ロガーを名前属性のみで構成すると、ロガーは残りの属性をルート・ロガーから継承します。
<loggers>
<logger name="oracle.idm.msm.service"/>
<!-- Additional loggers listed here -->
</loggers>
ロガーを構成するには、次のようにします。
DOMAIN_NAME/config/fmwconfig/servers/SERVER_NAME/logging.xmlファイルを開きます。
構成するロガーに移動します。Oracleモバイル・セキュリティ・マネージャのロガーのリストは次の場所にあります。
<logger>要素のレベル属性を定義します。この項の先頭の例を参照してください。
1つ以上の<handler>要素を<logger>要素に追加します。
logging.xmlの<loggers>と<log_handlers>の両方のセクションの編集が終了したら、ファイルを保存します。
アプリケーション・サーバーを再起動して変更を有効にします。
次のODLログの抜粋は、Oracleモバイル・セキュリティ・マネージャで想定される出力例を示しています。
[2015-03-10T14:29:38.713-07:00] [omsm_server1] [ERROR] [MSM-00906] [oracle.idm.msm.identity] Identity Service exception. [2015-03-12T01:57:03.391-07:00] [omsm_server1] [TRACE] [] [oracle.idm.msm.policy] [SRC_CLASS: oracle.idm.msm.policy.impl.PolicyManagerImpl] [SRC_METHOD: getMobilePolicy] Error while Getting Policy:Default Policy_DeviceProvisioningPolicy [2015-03-12T01:57:03.315-07:00] [omsm_server1] [TRACE:16] [] [oracle.idm.msm.policy] [SRC_CLASS: oracle.idm.msm.policy.impl.spi.oes.PolicyManagerSpiImpl] [SRC_METHOD: getPolicyNames] ENTRY ( ( "MOBILE_POLICY_NAME" eq "policy" ) or ( "POLICY_DESCRIPTION" eq "policy" ) or ( "POLICY_GROUP" eq "policy" ) )
この項では、Oracle Mobile Security Suiteをデプロイするときに発生する可能性がある一般的な問題を示します。パラメータは次のとおりです。
ポートが開かない(モバイル・セキュリティ・アクセス・サーバーへの着信およびモバイル・セキュリティ・アクセス・サーバーからの送信)。
ポートが外部ファイアウォール、アプリケーション・ファイアウォールまたはiptables構成のいずれかによってブロックされる
ホスト名が解決されないか、DNSの問題がある
ユーザーがサーバー証明書の取得方法を認識していない
モバイル・セキュリティ・アクセス・サーバーの証明書がモバイル・デバイスで信頼されていない
モバイル・セキュリティ・アクセス・サーバーとWindowsドメイン・コントローラのクロックが同期されていない
ユーザーが完全なUPNのかわりに使用されるUIDを入力した
Kerberosサービス・プリンシパル名(SPN)がバックエンド・アプリケーション用に正しく定義されていない
ワークスペースとコンテナ化済アプリケーションが異なる証明書で署名されている
iOS用のワークスペース静的ライブラリ・プロジェクトをビルドするときに、一般的なiOSデバイスではなく、シミュレータまたは接続デバイスがビルド・ターゲットとして選択された
モバイル・セキュリティ・アクセス・サーバーとモバイル・デバイスのクロックが同期されていない
Win2k8 R2よりも前のバージョンのWindowsでPKINITが試行される
使用されたユーザーの証明書テンプレートが不正である
不正なWeb設定により、すべてが直接転送またはブロックされた
マルチドメイン環境に信頼関係がない
KINITで代替UPN接尾辞が使用されている(構成の変更が必要)
一部のバックエンド・サーバーが古いSSLスタックを実行し、モバイル・セキュリティ・アクセス・サーバーによって報告済の新しい暗号を処理できない(構成の変更が必要)
Androidデバイスが古いまたはローエンド
ユーザーの電子メール・アドレスがLDAPディレクトリにない場合、「招待」ボタンが無効になる。
Oracle Access Management Access Managerコンソールにユーザーがアクセスすると、ユーザーに適用可能なロールのリストにDomain Users LDAPグループが表示されません。Domain Usersロールはロール・リストに表示されませんが、多くのユーザーはこのロールに関連付けられていません。
Domain Users LDAPグループが表示されないのは、Domain Usersがユーザーのセキュリティ属性に含まれる特別なグループであり、グループ・メンバーシップに関する情報を提供するADのmemberOf属性には含まれないためです。primaryGroupID属性は、オブジェクトのプライマリ・グループであるグループのprimaryGroupTokenが格納される単一値の属性です。オブジェクトのプライマリ・グループはmemberOf属性には含まれません。たとえば、デフォルトでは、ユーザー・オブジェクトのプライマリ・グループはDomain UsersグループのprimaryGroupTokenですが、Domain Usersはオブジェクトのユーザー・オブジェクトのmemberOf属性には含まれません。
memberOfおよびprimaryGroupIdの詳細は、https://msdn.microsoft.com/en-us/library/ms677943.aspxを参照してください。
この問題を回避するには、別のLDAPグループを作成して、ユーザーをそのグループのメンバーにします。
この項では、Oracleモバイル・セキュリティ・アクセス・サーバーのトラブルシューティングのヒントについて説明します。内容は次のとおりです。
モバイル・セキュリティ・アクセス・サーバーのSecure Sockets Layer (SSL)に関連する問題が発生した場合は、次のヒントが問題の解決に役立つことがあります。
モバイル・セキュリティ・アクセス・サーバーの証明書および証明書チェーンが失効していないことを確認します。
モバイル・セキュリティ・アクセス・サーバーの証明書にサブジェクト代替名が含まれている場合、サーバーの証明書サブジェクト名も証明書のサブジェクト代替名(SAN)属性に存在することを確認します。
すべてのサブジェクト名またはサブジェクト代替名がDNSで解決されることを確認します。
証明書チェーン・ファイルが発行元CA、次にゼロ以上の中間CA、ルートCAで構築されていることを確認します。
モバイル・セキュリティ・アクセス・サーバーのインターネット接続に関連する問題が発生した場合は、次のヒントが問題の解決に役立つことがあります。
モバイル・デバイスがオンラインまたはインターネットに接続されていることを確認します。
モバイル・セキュリティ・アクセス・サーバーが実行中であることを確認します。
すべての必要なモバイル・セキュリティ・アクセス・サーバーのポートが、モバイル・デバイスからモバイル・セキュリティ・アクセス・サーバーまでのルートでホストのファイアウォールまたは他のファイアウォールに対してオープンになっていることを確認します。
その他のサービスが構成済モバイル・セキュリティ・アクセス・サーバーのポートを使用していないことを確認します。
モバイル・セキュリティ・アクセス・サーバーの背後にあるアプリケーションにモバイル・セキュリティ・アクセス・サーバーからアクセスできることを確認します。
モバイル・セキュリティ・アクセス・サーバーがモバイル・セキュリティ・アクセス・サーバーの背後にあるアプリケーションのホスト名をDNSで解決できることを確認します。
モバイル・セキュリティ・アクセス・サーバーの背後にあるアプリケーションの1つでのみ接続エラーが発生する場合、そのアプリケーションが実行中であることを確認します。
ネットワークをブロックするプロキシ・トラフィックにシステムがないことを確認します(ファイアウォールまたはリバース・プロキシが構成されている場合)。
この項では、Kerberos対応アプリケーションのトラブルシューティングのヒントについて説明します。トラブルシューティングのヒントは次のとおりです。
|
注意: 通常のリクエストはscheme://hostname:port/pathの形式で、その結果のサービス・プリンシパル名(SPN)はHTTP/hostnameの形式です。
MSMリクエストは リクエストの形式が |
モバイル・セキュリティ・アクセス・サーバーからアクセスするWebアプリケーションをKerberos用に構成し、ホスト名ではなく別名でアクセスする各アプリケーション・サーバーのサービス・プリンシパル名(SPN)を指定する必要があります。
たとえば、ホスト名がsp1.oracle.internalであっても、HTTP/sharepoint.oracle.internalとしてアクセスされる場合、SPNはhttp://sharepointとして設定する必要があります。追加の証明書要件がモバイル・セキュリティ・アクセス・サーバーの証明書に適用されます。
アプリケーション・サーバーのドメイン内のマシンで(同じドメインに結合されている場合はモバイル・セキュリティ・アクセス・サーバーを使用できます)、次の手順に従います。
コマンド・ウィンドウを開きます。
コマンド・プロンプトで次を入力します。
setspn -l customer_application_hostname
デバイスがアクセスしようとしているURLのSPNが存在することを確認します。
SPNがない場合、次を入力します。
setspn -a customer_application_hostname
次を入力して、SPNを確認します。
setspn -l customer_application_hostname
Microsoft SharePointなどのInternet Information Services (IIS)アプリケーションをネゴシエート認証用に構成します。必要に応じてNTLM認証用の構成を続けることができます。
Internet Information Services (IIS)アプリケーションでは、アプリケーション・プール・アイデンティティを持つアプリケーション・プールが使用されます。このプールはWebサーバー上でローカル・アカウントにできません。通常、これは、認証用にActive Directoryにアクセスする権限を持つ、NETWORKという組込みアカウントに設定できます。
サービス・アカウントをプール・アイデンティティに使用する場合、そのアカウントがActive Directoryに対してアクセスおよび認証する権限を持っていることを確認します。
認証プロバイダがネゴシエートに設定されていることを確認します。
Windows認証が設定されていることを確認します。
匿名ユーザーが設定されていないことを確認します。
|
注意: 次のコマンドが、Wiresharkでのネットワークの問題のデバッグに役立ちます。
|
この項では、モバイル・デバイスのアクセスの問題をトラブルシューティングする方法について説明します。内容は次のとおりです。
次に、モバイル・デバイスのアクセスの問題をトラブルシューティングするための一般的なヒントの一部を示します。
モバイル・セキュリティ・アクセス・サーバーのホスト名がモバイル・デバイスで解決できることを確認します。
プロキシ自動構成(PAC)ファイルがモバイル構成で指定されたURLの場所からアクセスできることを確認します。
PACファイルで指定したモバイル・セキュリティ・アクセス・サーバーのホスト名がDNSで解決できることを確認します。
モバイル・セキュリティ・アクセス・サーバー名がOracleモバイル・セキュリティ・アクセス・サーバー上のPACファイル内のPROXY文に一致することを確認します。
モバイル・デバイスにWi-Fiが構成されている場合、bmax.pacファイルのURLを設定したプロキシが指定されていることを確認します。
モバイル・デバイスにVPNが構成されている場合、bmax.pacファイルのURLを設定したプロキシがVPNで指定されていて、Wi-Fi構成でこれが不要であることを確認します。
bmconfig_*.jsonというモバイル・セキュリティ・アクセス・サーバーの構成ファイルがモバイル・セキュリティ・ワークスペースのアプリケーション設定で正しく構成されていることを確認します。
モバイル・セキュリティ・アクセス・サーバーがPKINITまたはKINIT認証に対して構成されている場合、使用しているユーザー・アカウントがActive Directoryでロックされていないことを確認します。
モバイル・セキュリティ・アクセス・サーバーがOracle Access Manager認証に対して構成されている場合、ユーザー・アカウントがロックされていないことを確認します。
モバイル・セキュリティ・アクセス・サーバーがPKINIT認証に対して構成されている場合、クライアントの証明書が相互認証およびスマートカード・ログインに対して正しい属性が設定されていることを確認します。
モバイル・セキュリティ・アクセス・サーバーがPKINIT認証に対して構成されている場合、モバイル・セキュリティ・アクセス・サーバーの証明書のCA証明書チェーンがモバイル・デバイスのキー・チェーン(ネットワーク・プロファイル)にインストールされていることを確認します。
第13.6.1項「モバイル・セキュリティ・アクセス・サーバーのSSL関連の問題のトラブルシューティング」を参照してください。
モバイル・セキュリティ・ワークスペースのアプリケーション設定に移動します。「ログ・モード」を有効にし、「ログ・レベル」を「verbose」または「デバッグ」に設定します。
モバイル・セキュリティ・ワークスペースの通常の登録プロセス中、次のリクエスト・シーケンスが送信されます。
予想レスポンスがHTTP 407の認証URLに対するリクエストのシーケンス。使用している認証方式によって、リクエスト数は異なることがあります。認証するユーザーのUPNまたはユーザーIDが認証リクエストに関連付けられた行の初めに表示される必要があります。これらのリクエストは認証ごとに発生します。
予想レスポンスがHTTP 200またはHTTP 302の認証URLに対する最後のリクエスト。HTTP 200のレスポンスは、認証がモバイル・セキュリティ・ワークスペース内で直接開始されたということを意味しますが、HTTP 302のレスポンスは、Safari Webブラウザまたはコンテナ化済アプリケーションなどの外部アプリケーションからのリダイレクトによって認証が開始されたことを意味します。HTTP 403が認証リクエストのレスポンスで返された場合、認証が失敗したという意味です。このリクエストは認証ごとに発生します。
/actionに対するリクエスト。このリクエストにより、オフライン認証およびPIN/パスワードのリセット用のワークスペースが設定されます。このリクエストは、登録およびPIN/パスワードのリセット時にのみ発生します。
/ecp/ecpservice/registercontainerに対するリクエスト。このリクエストにより、ワークスペースがモバイル・セキュリティ・マネージャ・サーバーに登録されます。予想レスポンスはHTTP 200です。このリクエストは、登録時にのみ発生します。
/ecp/ecpservice/policy/getに対するリクエスト。これは、ワークスペースに関連付けられたポリシーを取得するためのリクエストです。予想レスポンスはHTTP 200です。このリクエストは認証ごとに発生します。
/ecp/ecpservice/settings/getに対するリクエスト。これは、会社の設定を取得するためのリクエストです。予想レスポンスはHTTP 200です。このリクエストは認証ごとに発生します。
/ecp/ecpservice/getcommandsへのリクエスト。これは、ワークスペースに対して保留中のコマンドを取得するためのリクエストです。予想レスポンスはHTTP 200です。このリクエストは登録後に定期的に発生します。
デプロイメント構成によっては、bmax.pacファイルおよびstunnel.pacに対しても多数のリクエストが発生します。stunnel.pacまたはbmax.pacに対してリクエストが発生しない場合、これは、モバイル・セキュリティ・アクセス・サーバーがモバイル・デバイスからアクセスできない可能性があるという意味です。
この項では、Microsoft Exchange通知と統合する場合のトラブルシューティングのヒントについて説明します。
通知がクライアントに送信されていない場合、次のことを確認します。
Exchangeの構成がExchangeのバージョンと一致していること。
ユーザーのかわりに動作するプロキシ・アカウントの権限がExchangeで構成されていること。この権限は、Microsoft Exchange Server 2007とExchange Server 2010で異なっています。
2つのバージョンの詳細は、次の項で説明しています。
Microsoft Exchange Server 2007でExchange偽装が機能するためには、次の2つの権限が必要です。
*ms-Exch-EPI-Impersonation: この権限はクライアント・アクセス・サーバーに適用され、そのCAS上でExchange偽装として機能するためのサービス・アカウント権限を付与します。
oms-Exch-EPI-May-Impersonate: この権限は偽装を有効化する必要があるユーザーごとに適用されるか、またはメールボックス・データベースに適用されます。
たとえば、Joe Clientはデバイスを持つユーザーで、EWS Proxyは通知用にユーザーを偽装するために使用するアカウントです。
これらの権限を追加するには、次のようにします。
Add-ADPermission
-Identity (Get-ExchangeServer
-IdentityYOUR_ CAS).DistinguishedName
-User (Get-User -Identity "EWS Proxy").Identity
-extendedRight ms-Exch-EPI-Impersonation
Add-ADPermission
-Identity (Get-User -Identity "Joe Client").DistinguishedName
-User (Get-User -Identity "EWS Proxy").Identity
-extendedRight ms-Exch-EPI-May-Impersonate
Exchange 2010では、Exchange偽装が機能するために権限が必要です。
特定のユーザー・グループにExchange偽装を構成するには、次のようにします。
ADユーザーがグループ(Notification Usersなど)にまとめられ、サービス・アカウントにExchangeが認識されるADグループの管理スコープがあることを確認します。次に例を示します。
New-ManagementScope -Name:"ExchImpersonationScope" -RecipientRestrictionFilter {memberofgroup -eq "CN=BNS Users,OU=QA,DC=bitzermobile,DC=com"}
次のように、ロールの割当てを定義します。
New-ManagementRoleAssignment -Name:"ExchImpersonationRole" -Role:ApplicationImpersonation -User:"ewsproxy@example.com" -CustomRecipientWriteScope:"ExchImpersonationScope
次のメッセージが表示された場合は、Exchange通知の統合用に間違ったExchangeバージョンを構成している可能性があります。
microsoft.exchange.webservices.data.ServiceVersionException: Method SubscribeToPushNotificationsOnAllFolders is only valid for Exchange Server version Exchange2010 or later
エラーがない場合、Apple Push Notificationサーバーが配信を保証していないため、このサーバーが原因の可能性があります。指定されたApple資格証明が有効であることを確認します。
次のいずれかのWindowsバージョンのWindowsファイル共有が、システム固有のホスト名ではなくDNS別名で参照されている場合は、モバイル・ファイル・マネージャは接続に失敗します。
Windows Server 2012
Windows Server 2008
Windows 8
Windows 7
Windows Vista
問題を修正するには、固有のホスト名を使用してファイル共有にアクセスするか、次の手順を完了してファイル共有サーバーのレジストリを変更します。
サーバーのレジストリで次のキーを見つけてクリックします。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
「編集」メニューで、「値の追加」をクリックして次のレジストリ値を追加します。
値の名前: DisableStrictNameChecking
データ型: REG_DWORD
Radix: Decimal
値: 1
ファイル共有サーバーでWindows Serverサービスを再起動します。
