デスクトップシングルサインオンのトラブルシューティング

Agentless DSSOエンドポイントにルーティングされませんでした。IPアドレスが正しいゾーンに追加され、そのゾーンがAgentless DSSOで使用されていることを確認してください。


Agentless DSSOが機能するためには、ブラウザーがドメインのKey Distribution Center（KDC）に接続できる必要があります。これはKerberosの検証にとって非常に重要です。KDCに到達できないと、Kerberosチケットを取得できず、認証もできません。可能な場合は、仮想プライベートネットワーク（VPN）を使用してネットワークに接続してください。KDCがVPN経由で利用できる場合、Agentless DSSOが機能します。


AD内、およびOkta構成に保存されている両方のSPNアカウントのユーザー名とパスワードが正しいことを確認します。アカウントの有効期限が切れているか変更された場合、フローが中断されます。


これは、Kerberosに関連する障害の可能性があります。Wiresharkなどのツールを使用して、Agentless DSSO試行中のネットワークトラフィックをキャプチャします。キャプチャしたら、Kerberosトラフィックをフィルタリングします。このトラフィックをKDCのEvent Viewerログと比較します。これら2つのツール（または同様のツール）を使用すれば、Kerberosの障害を発見できるはずです。

注：デバッグレベルのKerberosイベントを表示するために、Kerberosイベントのログ記録を有効にする必要が生じる場合があります。詳細については、https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-loggingを参照してください。


企業ネットワークとOktaエージェントレスSSO間のクロックの誤差が大きくなりすぎると、Kerberosの検証とサインインに失敗します。ドメインコントローラーのクロックが外部のタイムサーバーに同期されている場合、この問題は発生しません。


Agentless DSSOのサインイン中に、OktaでSIDのルックアップを実行します。EAの期間中は、AD Agentへの呼び出しで行われます。サインインの動作が遅い、または失敗する場合は、AD Agentのポーリングスレッド数を増やすか、ドメインに新しいAD Agentを追加することを検討してください。この方法の詳細については、「OktaのActive Directoryエージェントを複数インストールする」および「OktaのActive Directoryエージェントのスレッド数を変更する」を参照してください。

次のような状況が発生すると、AD Agentのログに多数のLDAP読み取りコールが表示され、Next action = NONE行が表示されなくなります。例：

2018/06/11 23:14:34.441 Debug -- N079-H076(57) -- Sending result for READ_LDAP action (id=ADS2n15k1yGW23cn10g7) finished, (executionTime=00:00:00.2196026)


<MadCap:dropDownHotspot style="color: #3868dd;">/IWA</MadCap:dropDownHotspot><MadCap:dropDownHotspot style="color: #3868dd;">が動作しない</MadCap:dropDownHotspot>
  • サーバーのホスト名がクライアントネットワーク内から解決可能であることを確認します。
  • IIS認証構成とクライアントの両方でIWAをオンにする必要があります。

注：Office 2016およびWindows 10の最新ビルドには、サインインワークフロー用のWebアカウントマネージャー（WAM）が組み込まれています（このMicrosoftの記事を参照してください）。WAMにはhttpsが必要です — 認証ワークフロー中にhttps以外のトラフィックをブロックします。

このユースケース用にIWAを構成する方法の詳細については、「Okta IWA WebエージェントのSSLを構成する」を参照してください。

ヒント：Okta IWA SSOエージェントをインストールし、Okta AD Agentのインストールに使用したものと同じOktaサービスアカウントを使用している場合、ADでOktaサービスアカウントのパスワードを変更した場合、IISの［Server Manager dashboard（サーバーマネージャーダッシュボード）］>［Tools（ツール）］>［Internet Information Services (IIS) Manager（インターネットインフォメーションサービス（IIS）マネージャー）］でOktaサービスアカウントのパスワードも変更する必要があります。

Okta IWAサービスは、［Application Pools（アプリケーションプール）］メニューの下にインストールされます。［Advanced Settings（詳細設定）］で、Oktaサービスのパスワードを新しいパスワードに合わせて変更できます。キャッシュが原因で、IWAサービスがすぐに停止しない場合があります。キャッシュがリセットされたときに、ツールとエージェントをインストールしたサーバー上で、［Active Directory Users and Computers（Active Directoryユーザーとコンピューター）］ツールおよび［Services（サービス）］コンソールでリセットしたパスワードと一致するようにOktaサービスのパスワードがここで更新されていなければ、IWAは動作を停止します。


（Okta IWAサービス・アカウントには、［Logon as a Batch Job（バッチ・ジョブとしてログオン）］および［Log on as a Service（サービスとしてログオン）］権限が必要です。サービス・アカウントにこれらの権限があることを確認してください。



Okta IWA Webエージェントが次の状況の場合は、エージェントがオフラインになり、［The request was aborted: Could not create SSL/TLS secure channel（リクエストが中断されました：SSL/TLSのセキュアなチャネルを作成できません）］というエラーが表示されることがあります。

  • Windows Server 2008 R2 SP1を実行しているサーバーにインストールされており、かつ
  • HTTPSを使用するように構成されており、かつ
  • 自動フェイルオーバー用に構成されている。

Windows Server 2008 R2 SP1を実行しているサーバーにOkta IWA Webエージェントがインストールされていて、セキュリティーで保護された接続（HTTPS）でSSOを使用する場合は、受信（例：IIS）接続に対して最初に［TLS 1.2］プロトコルを有効にする必要があります。これが必要なのは、可能な限りTLS 1.2を使用しようとするOkta Active Directory（AD）エージェントが、TLS 1.2の受信接続に対して有効になっていないWindows Server 2008 R2 SP1サーバーにインストールされたOkta IWA Webエージェントとの接続を失う可能性があるためです。Windows Server 2008 R2 SP1は、TLS 1.2プロトコルの送信接続をデフォルトでサポートしています。ただし、受信接続のサポートはデフォルトで無効になっています。Oktaでは、この設定を有効にすることを強くお勧めします。

  1. IWA Webエージェントをホストしているのと同じWindows 2008 R2サーバーで、次の値をレジストリに追加します。

    2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\DisabledByDefault : 0 (DWORD)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\Enabled : 1 (DWORD)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\DisabledByDefault : 0 (DWORD)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\Enabled : 1 (DWORD)

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


エージェントのインストール中にエラーメッセージが表示された場合は、SSLピンニングがデフォルトで有効になっているバージョンのOkta IWA Webエージェントをインストールしようとしていて、SSL証明書ピンニングに対するエージェントのサポートがOktaサーバーとの通信を妨げる環境であることが考えられます。これは、多くの場合、SSLプロキシーに依存する環境で発生します。この場合にインストールを完了できるようにするために、Oktaでは、ドメインokta.comを許可リストに追加して、SSLプロキシー処理をバイパスすることを推奨しています。

SSL証明書ピンニングが有効になっている場合は、次の手順を使用して無効にします。

  1. 「Okta IWA Webエージェントをインストールする」の手順1と2を実行します。
  2. コマンド・プロンプトを開き、次のコマンドを入力します。
OktaSsoIwa.exe OktaDisableSslPinning=1
  1. Enterキーを押します。
  2. インストールを完了します。「Okta IWA Webエージェントのインストール」を参照してください。