トラブルシューティングガイド

トラブルシューティングを開始する前に知っておくべきこと

Access Gatewayを正しくトラブルシュートするためには、以下の前提条件を満たしている必要があります：

• Okta orgへの管理者アクセス権。

• Access Gateway Managementコンソールへのアクセス権。

• ネットワークアプライアンス、アプリケーションサーバーなどからのログを取得し、監視する方法を知っている。

• ログステートメントに現れるHTTPステータスコードを識別する方法を知っている。

直面している問題を知るには

受け取ったエラーをこのリストと比較し、以下の適切な問題の説明をクリックします：

• ログを監視するには
• トラッキングID
• HTTPステータスコード
• リソースが見つからない
• Access Gatewayがタイムアウト
• SSHを使用したAccess Gatewayへの接続エラー

ログを監視するには

メモ：ログはダウンロード、またはGraylogなどのログサーバーへ転送できます。 詳しくはロギングの管理を参照してください。

1. Access Gateway Managementコンソールにログインします。デフォルトの資格情報は以下の通りです：
   • ユーザー名: oag-mgmt
   • パスワード：OktaMgmt@123



2. Access Gateway Managementコンソールメニューから4 - モニタリングを選択します。
3. モニタリングメニューから1- ログを監視を選択します。

HTTPステータスコード

Access Gatewayとその他のアプリケーションは任意のイベント中に以下のステータスコードをブラウザーに返します。また、これらは問題のトラブルシューティングのためにアクセスログに記録されます。

ステータスコードを見つけるには？

Access Gatewayは以下に示すようにステータスコードを表示します。

メモ

• ブラウザーに表示されるHTTPステータスコードがバックエンドアプリケーションから返されますが、分かりくいことがあります。HTTPエラーの場合、Access Gatewayから返されたすべてのHTTPステータスコードが、ユーザーフレンドリーなメッセージとして、ヘッダーおよびフッターセクションのAccess Gatewayブランディングと共にページに表示されます（上のスクリーンショットの例をご覧ください）。

• 以下のスクリーンショットの例は、Access Gatewayに生成されたメッセージではなく一般的なエラーメッセージの例です。このタイプの一般的なエラーメッセージは、アプリケーションごとに異なって見えます。ページがAccess Gatewayページでない場合、Access Gatewayによって保護されたアプリケーションがどのHTTPステータスコードを返しているかを示します（下の「エラー500」のスクリーンショットの例をご覧ください）。

一部のステータスコードはバックエンドアプリケーションエラーによって発生したもので、アプリケーション側の調査が必要です。

HTTPステータスコードを取得する手順：

メモ

一部のケース、アプリケーションまたはエラーによっては、エンドユーザーはAccess Gatewayエラー画面を見ることができず、ブラウザーからステータスコードを取得する必要があります。以下の手順に従い、ブラウザーの開発者用ツールを使用してステータスコードを取得します。

1. 新規ブラウザーウィンドウを開きます。

2. ページを右クリックし、[Inspect（検査）]をクリックして開発者用ツールを開きます。

3. [Network（ネットワーク）]タブをクリックします。

4. テストしたいURLを入力し、Enterキーを押します。

5. 必要に応じてログインプロセスを完了します。

6. 問題のページのステータスコードを取得します。詳しくは下図を参照してください。

メモ

上記の開発者用ツールを開く手順はGoogle Chrome向けです。IEでは、開発者用ツールはF12を押すと開きます。

トラッキングID

内部サーバーエラーの場合、Access GatewayはトラッキングIDを生成し、エラーメッセージに表示します。このトラッキングIDを使用して、トラブルシューティング中のログファイルからイベントとそれに対応するログメッセージを識別できます。

エラーメッセージにトラッキングIDが含まれる場合、[Tracking ID（トラッキングID）]ボタンをクリックしてログに含まれるトラッキングIDと関連するエラーメッセージをコピーできます。このメッセージには問題のトラブルシュートに役立つ重要な情報が含まれています。

ログステートメント


Gateway host:[<host URL>]referer:[<IDP SSO URL>]error:[Login Error] tracking ID:[6eff1f9ca3] details:[Requester/RequestDenied: Could not validate the following SAML AuthnRequest from partner Test App: ]


ステータスコード400

未知のホストステータス

リクエストされたホスト：<リクエストされたホスト名>はこのAccess Gatewayでサービスされていません。

考えられる原因

DNSレコードがAccess Gatewayを解決したが、対応するホスト名を持つAccess Gatewayで利用可能なサービスまたはアプリケーションがない。

ログステートメント

Mar 7 15:26:26 localhost.localdomain icsDefault443Access <host URL> <IP ADDRESS> - - [07/Mar/2018:15:26:26 -0600] "GET / HTTP/1.1" 400 1992 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36" "-" 0.035 0.035

修正／検証手順

1. 正しいURLを使用しているか確認します。

2. Access Gatewayアプリケーションの[Public Domain（パブリックドメイン）]フィールドが正しいことを確認します。

3. DNSまたはローカルホストファイルがホスト名およびIPアドレスを正しく指定していることを確認します。

4. アプリケーションが関連するホスト名で正しく構成されていることを確認します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード403

リソースへのアクセスが拒否された

アプリケーション“Requested Applications”のリソース<リクエストされたリソース>へのアクセスが拒否されました。

考えられる原因

ポリシーエンジンが保護されたリソースへのアクセスを拒否した場合、Access Gatewayはこのステータスコードを返します。リソースへの一部のアクセスが意図的に拒否される条件がある場合、このステータスコードを受信する場合があります。

ログステートメント

Mar 7 15:36:22 localhost ACCESS_GATEWAY ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_id="aa3b92617708c430ad74acbd6b1cf23f4809b48141" SUBJECT="<User login ID>" RESOURCE="/test" METHOD="GET" POLICY="test" POLICY_TYPE="PROTECTED_REGEX" DURATION="0" APP="<Application name / description>" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="DENY" REASON="Groups=(?!.*Everyone:) - SESSIONID=_aa3b92617708c430ad74acbd6b1cf23f4809b48141 RelayDomain=<Relay domain URL> static1=static1 secret=secretvalue spgw_username=<User ID> UserName=<User ID> spgw_username=<User ID> cloud:identity:domain=<IDP tenant subdomain> workEmail=<User work email attribute> cloud:identity:tenant=<IDP tenant subdomain> givenName=<User first name> familyName=<User last name> email=<User email> SourceAuthNType=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport RemoteIP=192.168.1.4 USER_AGENT=Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 creationTime=1520458088124 maxInactiveInterval=3600000 maxActiveInterval=28800000 lastAccessedTime=1520458092027 " REMOTE_IP="<IP Address>" USER_AGENT="Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36"] deny access to resource

修正／検証手順

1. これが実際のエラーであり、意図的に拒否されたリソースではないことを確認します。

2. Access Gatewayアプリケーションで定義されたポリシーを確認して修正します。

3. ポリシーによってユーザーがアクセスを許可されていることを確認します。

4. それでもアプリケーションリソースにアクセスできない場合、サポートにお問い合わせください。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード404

リソースが見つからない

アクセスしようとしているページが存在しません。

考えられる原因

リクエストされたリソースが利用可能でない場合、Access Gatewayはこのコードを返します。

ログステートメント

Apr 5 03:59:57 oag01 icsIcsgwAccess <Gateway domain> <Gateway IP address> - - [05/Apr/2018:03:59:57 -0500] "GET / HTTP/1.1" 404 1922 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "<Gateway IP address>" 0.019 0.019

修正／検証手順

1. URLが正しいか確認し、リソースが存在し、正しい場所を指しているかを確認します。
2. リソースがアクセス不可能である場合、サポートに連絡します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード405

アクセス拒否

Access Gatewayが、<リクエストされたアプリケーション>へのユーザーアクセスで異常を検出しました。

考えられる原因

セッション整合性で問題を検出した場合、セッションのハイジャックを防止するためにAccess Gatewayはこのステータスコードを返します。これは、ユーザーがアクティブなセッションが設定されているネットワークを切り替えた時も発生します。

ログステートメント

Apr 2 15:19:32 ACCESS AUTHZ SESSION WARN USER_SESSION [SESSION_id="0e53b206b5aa2d8b93cdf7f48c4c5ca51e2eeff494" SUBJECT="<User ID>" APP="IDP Sample Header App 1" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="DENY" REASON="SESSION_INTEGRITY_REMOTEIP_MISMATCH" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] SRF Request RemoteIP (http_x_real_ip): <User IP address> failed to match session RemoteIP: <Remote IP address> Apr 2 15:19:32 IDPsampleheaderapp1 <App domain URL> <User IP address> - - [02/Apr/2018:15:19:32 -0500] "GET / HTTP/1.1" 405 2050 "<IDP SSO URL>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "<User IP address>" 0.010 0.010.

修正／検証手順

1. Access Gatewayのアクティブセッション中にユーザーがネットワークを切り替えたかどうか確認します。
2. 手順1を確認したら、ユーザーはブラウザーを再起動してログインし直し、新しいセッションを作成する必要があります。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード413

エンティティにリクエストしたコードが大きすぎる

アップロードするファイルが1MBを超える場合、Access Gatewayはエラー413を表示します。

考えられる原因

デフォルトでは、Access Gatewayは1MB以下の容量のファイルのアップロードを許可するよう設定されています。

修正／検証手順

1. 開発者用ツールを使用して、Access Gatewayによって返されるHTTPステータスコードが413であることを確認します。

2. ファイルのアップロード上限を増やすには、[Applications（アプリケーション）]タブをクリックします。

3. 該当するアプリケーションの[Edit App（アプリの編集）]アイコンをクリックします。

4. アプリケーション内で[Advanced（詳細設定）]ドロップダウンメニューを開きます。

5. [Maximum File Upload Size Adjuster（最大ファイルアップロード容量の調整）]をスライドして適切な容量に合わせます。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード500

内部サーバーエラー

予期せぬサーバーエラーが発生しました。エラーはログ記録されています。このエラーメッセージが表示された場合はサポートサービスに連絡してください。

考えられる原因

Access Gatewayコンポーネントでエラーが発生した。

ログステートメント

Apr 2 22:53:10 IDPsampleheaderapp1 2018/04/02 22:53:10 [info] 26875#0: *3909 client closed connection while waiting for request, client: 192.168.10.20, server: 0.0.0.0:443Apr 2 22:53:10 IDPsampleheaderapp1 <App domain URL> <IP address> - - [02/Apr/2018:22:53:10 -0500] "GET /GOPYX48z5/module.php/icsgw/as_login.php?AuthId=k3x6WX20E&ReturnTo=https://<App domain URL> HTTP/1.1" 302 2707 "<Gateway domain URL>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "-" 0.006 0.006

修正／検証手順

問題を調査するため、サポートに連絡します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード502

アプリケーションが応答しない

バックエンドWebアプリケーション<リクエストされたアプリケーション>がAccess Gatewayからのユーザーリクエストを受信せず、使用できません。

考えられる原因

保護対象のバックエンドアプリケーションへの接続に失敗すると、Access Gatewayはこのエラーを返します。

ログステートメント

Apr 5 04:01:38 oag01 icsadmin <Gateway domain URL> <IP address> - - [05/Apr/2018:04:01:38 -0500] "GET / HTTP/1.1" 502 2130 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "-" 0.006 0.000, 0.000 : 0.005
.

修正／検証手順

1. アプリが動作しており、Access Gatewayで指定された保護対象URLが到達可能であることを確認します。

2. DNSレコードが解決可能であるか確認します。

3. 付録のトラブルシューティングツールを使用して、Access Gatewayアプライアンスをホストするサーバーからバックエンドアプリケーションに到達できるか確認します。

4. ロードバランシングソリューションを使用している場合、Access Gatewayアプライアンスの1つまたはすべてでこの問題が発生しているか個別に検証します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード503

アプリケーションがインアクティブ

アプリケーション<要求されたアプリケーション>が無効化され、使用できません。

メモ

管理者が一時的にアプリケーションへのアクセス権を削除することを選択した場合、この503ステータスコードが表示されることがあります。同様に、アプリケーションはIDPでも無効化されます。Access Gateway Admin UIコンソールで設定を編集する前に、アプリケーションの所有者または適切な管理者にアプリケーションステータスを確認してください。

考えられる原因

アプリケーションがインアクティブにマークされていると、Access Gatewayはこの警告ページを表示します。

ログステートメント


Mar 7 16:56:39 localhost ACCESS_GATEWAY ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_ID="N/A" SUBJECT="" RESOURCE="/" METHOD="GET" POLICY="INACTIVE" POLICY_TYPE="NO_AUTH" DURATION="0" APP="IDP Sample Header App" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="ALLOW" REASON=" - N/A" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36"] allow access to resource.


修正／検証手順

1. Access Gateway Admin UIコンソールを開きます。

2. [Applications（アプリケーション）]タブに進みます。

3. アプリケーションのステータスが[Inactive（インアクティブ）]に設定されているか確認します。

4. [Application（アプリケーション）]を編集します。

5. アプリケーションステータスを[Application is Active（アプリケーションがアクティブ）]に変更します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

アプリケーションがメンテナンス中

アプリケーション<要求されたアプリケーション>が一時的に使用できません。

考えられる原因

メンテナンス操作のためにアプリケーションステータスがメンテナンスモードに変更されている場合、Access Gatewayはこの警告ページを表示します。

ログステートメント


Mar 7 16:58:23 localhost ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_ID="N/A" SUBJECT="" RESOURCE="/" METHOD="GET" POLICY="ACTIVE_MAINT" POLICY_TYPE="NO_AUTH" DURATION="0" APP="IDP Sample Header App" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="ALLOW" REASON=" - N/A" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36"] allow access to resource


修正／検証手順

1. Access Gateway Admin UIコンソールを開きます。

2. [Applications（アプリケーション）]タブに進みます。

3. アプリケーションのステータスが[Maintenance（メンテナンス）]に設定されているか確認します。

4. アプリケーションのメンテナンスが完了しバックエンドアプリケーションが利用可能であるか確認します。

5. アプリケーションを編集します。

6. アプリケーションのメンテナンスが終了したら、アプリケーションステータスを[Application is Active（アプリケーションがインアクティブ）]に変更します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

アプリケーションがオフライン

アプリケーション<要求されたアプリケーション>が正しく動作せず、オフラインになる。この機能停止はログに記録されます。

考えられる原因

アプリケーション構成でエラーの可能性を検出し、オフラインにマークした場合、Access Gatewayはこの警告を表示します。

ログステートメント


Apr 2 15:02:33 ACCESS_GATEWAY ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_ID="N/A" SUBJECT="" RESOURCE="/favicon.ico" METHOD="GET" POLICY="ACTIVE_OFFLINE" POLICY_TYPE="NO_AUTH" DURATION="0" APP="IDP Sample Header App 1" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="ALLOW" REASON=" - N/A" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"] allow access to resource Apr 2 15:02:33 IDPsampleheaderapp1 <App domain URL> <IP address> - - [02/Apr/2018:15:02:33 -0500] "GET /favicon.ico HTTP/1.1" 503 2063 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0" "-" 0.011 0.011


修正／検証手順

1. Access Gateway Admin UIコンソールを開きます。

2. [Applications（アプリケーション）]タブに進みます。

3. アプリケーションのステータスが[Offline（オフライン）]に設定されているか確認します。

4. アプリケーションを編集します。

5. アプリケーション構成エラーを修正した後、アプリケーションステータスを[Application is Active（アプリケーションがアクティブ）]に変更します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ステータスコード504

Access Gatewayがタイムアウト

504ゲートウェイタイムアウトはOracle EBS Integrationのタイムアウトエラーです。

考えられる原因

EBS登録が稼働していないか、インスタンスから削除されています。デバッグを有効にした時にアプリケーションはGUIDを提供せず、Access GatewayログにUSER_ORCLGUIDヘッダーが表示されません。

ログステートメント


Apr 2 15:49:53 oracleaccessgatetest1 <App domain URL> <App IP address> - - [02/Apr/2018:15:49:53 -0500] "GET /accessgate/ssologin HTTP/1.1" 504 2050 "<IDP federation response>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "-" 1.017 1.002 : 0.008
>

修正／検証手順

1. 1. EBSが60秒以上かかることが予想される場合、[Application Settings（アプリケーション設定）]の[Advanced（詳細設定）]ドロップダウンメニューで[Backend Timeout duration（バックエンドのタイムアウト時間）]を増やします。
2. EBSアプリケーションインスタンスをトラブルシュートして修正します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

アプリケーションのタイムアウト - バックエンドアプリ

バックエンドWebアプリケーション<要求されたアプリケーション>がAccess Gatewayからのユーザーリクエストを受信せず、使用できません。

考えられる原因

保護されている内部アプリケーションへの接続でタイムアウトが発生した場合、Access Gatewayはこのエラーを返します。

ログステートメント


Mar 7 17:47:32 localhost.localdomain headerssoapp11 2018/03/07 17:47:32 [error] 6703#0: *4793 upstream timed out (110: Connection timed out) while connecting to upstream, client: <Client IP address>, server: <Server domain URL>, request: "GET / HTTP/1.1", upstream: "http://1.1.1.1:80/", host: "<Host URL>", referrer: "<Access Gateway Admin UI URL>"


修正／検証手順

1. アプリケーションが応答するか確認します。

2. アプリケーションURLがAccess Gatewayから到達可能かどうか確認します。

3. どのステージでも接続がブロックされていることを確認します。

4. Access Gatewayからバックエンドアプリケーションへの接続をテストします。

5. アプリケーションが60秒以上かかることが予想される場合、[Application Settings（アプリケーション設定）]の[Advanced（詳細設定）]ドロップダウンメニューで[Backend Timeout duration（バックエンドのタイムアウト時間）]を増やします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

アプリケーションレンダリングのエラー

バックエンドアプリケーションの応答に60秒以上かかる場合、アプリケーションが表示されません。

考えられる原因

バックエンドアプリケーションからの応答を待機して60秒経過するとタイムアウトするよう、Access Gatewayが設定されています。

ログステートメント


Mar 7 17:47:32 localhost.localdomain headerssoapp11 2018/03/07 17:47:32 [error] 6703#0: *4793 upstream timed out (110: Connection timed out) while connecting to upstream, client: <Client IP address>, server: <Server domain URL>, request: "GET / HTTP/1.1", upstream: "http://1.1.1.1:80/", host: "<Host domain URL>", referrer: "<Access Gateway Admin UI URL>"


修正／検証手順

1. アプリケーションが応答するか確認します。

2. アプリケーションURLがAccess Gatewayから到達可能かどうか確認します。

3. どのステージでも接続がブロックされていることを確認します。

4. Access Gatewayからバックエンドアプリケーションへの接続をテストします。

5. アプリケーションが60秒以上かかることが予想される場合、[Application Settings（アプリケーション設定）]の[Advanced（詳細設定）]ドロップダウンメニューで[Backend Timeout duration（バックエンドのタイムアウト時間）]を増やします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

アプリケーションのタイムアウト - 内部アプリ

バックエンドWebアプリケーション<リクエストされたアプリケーション>がAccess Gatewayからのユーザーリクエストを受信せず、使用できません。

考えられる原因

保護されている内部アプリケーションへの接続中にタイムアウトが発生した場合、Access Gatewayはこのエラーを返します。

ログステートメント


Mar 7 17:47:32 localhost.localdomain headerssoapp11 2018/03/07 17:47:32 [error] 6703#0: *4793 upstream timed out (110: Connection timed out) while connecting to upstream, client: <Client IP address>, server: <Server domain URL>, request: "GET / HTTP/1.1", upstream: "http://1.1.1.1:80/", host: "<Server domain URL>", referrer: "<Access Gateway Admin UI URL>"


修正／検証手順

1. アプリケーションが応答するか確認します。

2. アプリケーションURLがAccess Gatewayから到達可能かどうか確認します。

3. どのステージでも接続がブロックされていることを確認します。

4. Access Gatewayからバックエンドアプリケーションへの接続をテストします。

5. アプリケーションが60秒以上かかることが予想される場合、[Application Settings（アプリケーション設定）]の[Advanced（詳細設定）]ドロップダウンメニューで[Backend Timeout duration（バックエンドのタイムアウト時間）]を増やします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

 username$ ssh 100.25.225.222 username@100.25.225.222:Permission denied (publickey, gssapi-keyex,gssapi-with-mic). username $

 username$ ssh oag-mgmt@100.25.225.222 Access Gateway Administration . . . 1 - Network 2 - Services . . . 

修正／検証手順1

1. Access Gateway Admin UIコンソールにログインします。

2. [Settings（設定）]タブを選択します。

3. [Advanced（詳細設定）]を選択します。

4. 時刻が正確であるか確認します。

5. 時刻が正確でない場合、[Resync（再同期）]をクリックします。

6. 更新ボタンをクリックしてシステム時刻を更新し、現在時刻であることを確認します。

7. アプリケーションをテストして時刻が正しく同期しているか確認します。

ログステートメント2


Apr 3 14:20:09 oag01 ACCESS_GATEWAY ACCESS AUTHN SAML ERROR USER_AUTHN [TYPE="SAML_2_0" TRACKER_ID="882d8b2faf" SOURCE="<IDP SSO URL>" RESULT="FAIL" REASON="Invalid SAML Assertion" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] Received an assertion that is valid in the future. Check clock synchronization on IdP and SP.


修正／検証手順2

1. Access Gateway Managementコンソールにログインします。

2. [Service（サービス）]オプションを選択し、[NTP]オプションを選択します。

3. NTPサービスを再スタートするオプションを選択します。

4. Access Gateway Webコンソールの時間を確認します。

5. アプリケーションをテストします。

ログステートメント3


Apr 4 16:20:11 oag01 ACCESS_GATEWAY ACCESS AUTHN SAML ERROR USER_AUTHN [TYPE="SAML_2_0" TRACKER_ID="d7703c136c" SOURCE="<IDP SSO URL>" RESULT="FAIL" REASON="Invalid SAML Assertion" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] Received an assertion that has expired. Check clock


修正／検証手順3

1. Access Gateway Managementコンソールにログインします。

2. [Service（サービス）]オプションを選択し、[NTP]オプションを選択します。

3. [Set System Time（システム時刻の設定）]オプションを選択します。

4. 時刻をMON DD YYYY HH:MI:SS AM/PMの形式で入力します。

5. Access Gateway Admin UIコンソールで時刻を確認し、一致することを確認します。

6. アプリケーションをテストします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ブラウザーがドメインを信頼せず、SAMLリクエストを処理しない

メモ

このエラーは、ユーザーがSAMLアサーションの再投稿を続けているか、自己署名SSL証明書の承認プロセスでエラーが発生した場合に起こります。

ログステートメント


Apr 04 14:19:44 ACCESS ERROR [3137b1cb3f] Caused by: Exception: Unable to find the current binding.


修正／検証手順1

1. 返された証明書を開きます。

2. 証明書の有効性を確認します。

3. 証明書が有効でない場合、新しい証明書を要求し、それをAccess Gateway Managementコンソールでアップデートします。

4. アプリケーションをテストします。

修正／検証手順2

1. アプリケーションのURLがブラウザーで信頼されているか確認します。

2. ブラウザの信頼済みゾーン設定の下に、アプリケーションのURLと他のすべてのAccess Gatewayエンドポイントを追加します。

3. ブラウザーを再起動します。

4. アプリケーションをテストします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

予期せぬアプライアンスの動作

考えられる原因

ブラウザーのキャッシュが原因で、アプリケーションまたはAccess Gatewayで予期せぬ動作が発生することがあります。

修正／検証手順

1. ブラウザーのキャッシュを消去して再テストします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

複数のアプリケーション証明書エラー

1. アプリケーションにアクセスするとブラウザーに証明書の警告が表示され、ユーザーが続行リンクをクリックするとアプリケーションに移動します。

2. アプリケーションが開かず、ユーザーにはAccess Gatewayエラー画面が表示されます。

3. 以前に使用していたものと同じブラウザーセッションで開くとアプリケーションは正常に動作します。

   考えられる原因

   • これは、ブラウザーが証明書を信頼していない時に発生します。ユーザーが続行リンクをクリックすると、ブラウザーはデータをSAMLエンドポイントに投稿せず、SAMLアサーションに失敗します。

   • または、同じブラウザーセッションでアプリケーションを再度開いた場合、ブラウザーはユーザーからURLを信頼する権限があるため次回からURLを信頼し、正しいデータをSAMLエンドポイントに投稿します。

修正／検証手順

暫定的な修正 - ローカルシステム専用

Access Gatewayクライアント証明書をブラウザーの信頼済みストアに追加します。Internet Explorerの例を示します：

1. アプリケーションページから、ブラウザーで証明書を開き、ローカルマシンにエクスポートします。
2. [Internet Options（インターネットオプション）]を開きます。
3. [Content（コンテンツ）]タブに進みます。
4. [Certificates（証明書）]をクリックします。
5. ポップアップウィンドウで、[Trusted Root Certification Authorities（信頼されたルート証明機関）]に進みます。
6. [Import（インポート）]**をクリックします。
7. [Next（次へ）] → [Next（次へ）] → [Finish（終了）]*の順にクリックします。
8. セキュリティ警告ウィンドウで[Yes（はい）]をクリックし、インストールを続行します。
9. [OK]をクリックして開いているウィンドウをすべて閉じます。
10. それでも解決しない場合はマシンを再起動します。
11. ログインを再テストします。

恒久的な修正 - すべてのシステム用

1. 有効な証明書を購入します。

2. Access Gatewayアプライアンスで証明書をアップデートします。

3. 証明書を提示している場合はロードバランサーで証明書をアップデートします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

ループのリダイレクト

Internet Explorerでタブの開閉またはループのリダイレクトが発生する場合があります。

考えられる原因1

ブラウザーがアプリケーションまたはAccess Gatewayエンドポイントを信頼していない。

修正／検証手順1

1. IEの設定で、Access Gatewayホスト名のエンドポイントとアプリケーションのエンドポイントのURLを[Trusted Zone（信頼済みゾーン）]設定に追加します。

考えられる原因2

ロードバランシング ソリューションを使用している場合、ブラウザーがAccess Gatewayホスト名をあるノードに解決し、アプリケーションのパブリックドメインを別のノードに解決している。

修正／検証手順2

1. ロードバランサーがスティッキーセッションを実施しているか確認します。

2. Access Gatewayホスト名とアプリケーションパブリックドメインにpingし、異なるIPアドレスで解決されているか確認します。

3. 正しいIPアドレスに一致するよう、ローカルホストファイルまたはDNSエントリをアップデートします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

無効なIDP APIキー

考えられる原因

IDP APIトークンがIDPから削除された。

修正／検証手順

1. [Security（セキュリティ）] → [API Menu（APIメニュー）]でIDPで新しいIDP APIトークンを作成します。
2. [Setting（設定）] → [Identity Providers（IDプロバイダー）]で、Access GatewayでAPIキーをアップデートします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

アプリ名が同期しない

IDPで<アプリ名>が同期していません。このアプリケーションを<IDP Org名>として再作成しますか？

考えられる原因
このアプリケーションがIDPから削除された。

修正／検証手順

1. Access Gatewayの構成に使用されたAPIキーがアクティブのままであるか確認します。アクティブでない場合、以下の手順を続けます。

2. Access Gatewayから既存のアプリケーションを削除します。

3. アプリケーションがIDPから削除されたことを確認してからアプリを再作成します。

4. Access Gatewayでアプリケーションを再度追加します。

5. アプリケーションがIDPに作成されたことを確認します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

サイトに到達できない／表示されない

考えられる原因

ブラウザーがサイトに到達できない。根本的原因：アプリケーション／Access Gatewayサービスが実行されていないか、DNSエントリが抜けている。

修正／検証手順

1. 応答しない場合、Access Gatewayサービス／バックエンドアプリを再起動します。
2. 必要なDNSエントリをDNSまたはローカルホストファイルに追加します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

セットアップ／アプリの作成でフリーズした

Access Gatewayでアプリケーションの初期セットアップ中または作成中に進行状況インジケーターが回転し続ける。

考えられる原因

Access Gatewayが指定されたIDPに到達できない場合、この問題が発生します。

ログステートメント

Mar 7 17:19:43 localhost.localdomain WEB_CONSOLE IOException occured validating IDP host :IDP login URL

修正／検証手順

1. Access GatewayアプライアンスがIDPに接続できることを確認します。

2. 接続をブロックしているコンポーネントを探し、IDPへの接続を許可します。

3. Access GatewayからIDPへの接続を確認します。

4. クライアントIDとクライアントシークレットの値が正しいことを確認します。

5. Access GatewayでIDP構成を確認し、設定を保存します。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。

TLSページが表示されない

考えられる原因

これは、ブラウザーのTLSセキュリティ設定がAccess Gatewayとのセキュア接続を正しく認証しない場合に起こります。

ログステートメント

Apr 16 10:55:41 test-oag icsDefault443Error 2018/04/16 10:55:41 [crit] 18480#0: *3047 SSL_shutdown() failed (SSL: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init) while SSL handshaking, client: Client IP address, server:0.0.0.0:443

修正／検証手順

1. Internet Explorerで、[Settings（設定）]メニューをクリックします。

2. [Internet Options（インターネットオプション）]を選択します。

3. [Advanced（詳細設定）]タブをクリックします。

4. [Security（セキュリティ）]セクションにSSL/TLS設定が表示されるまでスクロールします。

5. IEがTLS 1.1、1.2、および1.3を使用しているか確認します。

6. [Apply（適用）]をクリックします。

7. [OK]をクリックします。

修正／検証手順で問題が解決しましたか？解決しない場合、フィールドサポートチケットを提出してアシスタンスをお求めください。