HTTPステータスコードのトラブルシューティング

Access GatewayのHTTPステータスコードはAccess Gateway管理者UIコンソールに表示され、想定とは異なる動作が示されます。

Access GatewayのHTTPステータスコードは、バックエンドアプリケーションコードとは異なります。Access Gateway管理者UIコンソール以外にHTTPステータスコードが表示されるときは、その原因となったバックエンドアプリケーションを調べてください。

その他のエラーについては、「その他の問題のトラブルシューティング」を参照してください。

はじめに

HTTPステータスコードをトラブルシューティングするには、以下の前提条件を満たす必要があります：

  • 自分が所属するOkta orgへの管理者アクセス権がある。
  • Access Gateway管理者コンソールへのアクセス権がある。
  • ネットワークアプライアンスとアプリケーションサーバーからログを取得して監視できる。
  • ログステートメントに表示されるHTTPステータスコードを識別できる。

HTTPSステータスコードと説明

Access Gatewayとその他のアプリケーションは、あらゆるイベントの発生時に次のステータスコードをブラウザーに返します。アクセスログには、問題のトラブルシューティングのためにこの情報も記録されます。

HTTPステータスコード

ステータスコード 説明

200

成功

302

リダイレクト

400

Access Gatewayが、IPアドレスまたはホスト名で呼び出されたアプリケーションに対応していません。

401

セッションが存在しません。

403

ポリシールールによってリソースへのアクセスが拒否されました。

404

不明なページ、コンテンツ、またはリソース。

405

セッション整合性エラー。

413

リクエストエンティティが大きすぎます。

500

サーバー側のエラー。

502

バックエンドアプリケーションを利用できません。

503

アプリケーションのモードが、メンテナンス、非アクティブ、オフラインのいずれかです。

504

バックエンドアプリケーションへのリクエストがタイムアウトしました。

HTTPステータスコードをキャプチャする

アプリケーションやエラーの種類によっては、Access Gatewayエラーページが表示されない場合があります。このようなときは、ブラウザー開発者ツールを使ってブラウザーからのHTTPステータスコードをキャプチャします。

手順については、Googleのドキュメントを参照してください。その他のブラウザーについては、各ブラウザーのドキュメントで手順を確認してください。

トラッキングIDを見つける

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

［Tracking ID（トラッキングID）］をクリックすると、そのIDと、ログ内の関連エラーメッセージがコピーされます。

次に、ログステートメントとトラッキングIDの例を示します。

Gateway host:[<host URL>]referrer:[<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 Resource（要求されたリソース）へのアクセスが拒否されました。
説明 保護されたリソースへのアクセスをポリシーエンジンが拒否した場合、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 (WindowsNT 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. リソースがアクセス不可能なときは、Oktaサポートまでお問い合わせください。

ステータスコード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. ファイルのアップロード上限を増やすには、アプリケーションタブをクリックします。
  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

検証と軽減の手順 Oktaサポートまでお問い合わせください。

ステータスコード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アプライアンスをホスティングしているサーバーからアクセス可能であることを確認します。「ネットワークインターフェイスを管理する」のcURL接続テストのセクションを参照してください。
  4. 負荷分散ソリューションを使用しているときは、この問題がいずれかのAccess Gatewayアプライアンスで生じているかどうかを個別に検証します。

ステータスコード503：アプリケーションを利用できない

メッセージ：
  • アプリケーション<要求されたアプリケーション>が無効化されており、利用できません。
  • アプリケーション<要求されたアプリケーション>は一時的に使用できません。
  • アプリケーション<要求されたアプリケーション>は正しく機能しておらず、オフラインになっています。この機能停止はログに記録されます。
説明

アプリケーションが無効化されている、アクティブ化されていない、メンテナンスモードである、またはオフライン状態にある場合、Access Gatewayはこの警告ページを表示します。

管理者がアプリケーションへのアクセスを一時的に削除した場合も、そのアプリケーションはIDプロバイダーで無効化されます。Access Gateway管理者UIコンソールで設定を変更する前に、アプリケーション所有者またはアプリケーションマネージャーの権限でアプリケーションのステータスを確認してください。
ログステートメントの例

アプリケーションが無効化されている、またはアクティブ化されていない場合：

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.

アプリケーションがメンテナンス中の場合：

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

アプリケーションがオフライン状態の場合：

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管理者UIコンソールを開きます。
  2. アプリケーションタブをクリックします。
  3. アプリケーションのステータスが、非アクティブ、メンテナンス、またはオフラインであることを確認します。
  4. アプリケーションを編集します。
  5. アプリケーションがオンライン状態に戻る、メンテナンスが完了する、またはアプリケーション構成エラーを修正したら、アプリケーションステータスを［Application is Active（アプリケーションはアクティブ）］に変更します。

ステータスコード504：タイムアウトエラー

メッセージ：
  • 504ゲートウェイタイムアウトエラーメッセージは、Oracle E-Business Suite（EBS）のタイムアウトエラーです。
  • バックエンドWebアプリケーション<要求されたアプリケーション>が、Access Gatewayからのユーザーリクエストに適時応答しない、および/または利用できません。
  • バックエンドアプリケーションの応答に60秒以上かかる場合、アプリケーションは表示されません。
  • バックエンドWebアプリケーション<要求されたアプリケーション>がAccess Gatewayからのユーザーリクエストを受信しておらず、利用できません。
説明

これらのエラーは、バックエンドアプリケーションからの応答を待機するAccess Gatewayで内部アプリケーションとの接続がタイムアウトになる、またはOracle EBS登録が機能していない、またはインスタンスから消去されている場合に表示されます。

Oracle EBS統合が機能していない場合、アプリケーションはGUIDを提供しません。デバッグを有効にしても、Access GatewayログにはUSER_ORCLGUIDヘッダーはありません。
ログステートメントの例

Oracle EBS統合タイムアウトエラーの場合：

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

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

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>"

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

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>"

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

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. アプリケーションまたはOracle EBSの応答に60秒以上かかることが想定されるときは、応答時間を変更します。
    1. 「アプリケーション設定」を参照してください。
    2. ［Advanced（詳細設定）］ドロップダウンメニューから［Backend Timeout duration（バックエンドタイムアウト時間）］を選択します。
    3. タイムアウト時間の値を長めに変更します。
  6. 問題がOracle EBS統合タイムアウトエラーであるときは、Oracle EBSアプリケーションインスタンスのトラブルシューティングを行って修正してください。