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

Agentless DSSOを有効にした状態でOktaテナントを閲覧すると、通常のサインインページが表示される

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

リモートで作業しているが、Agentless DSSOが機能しない

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

オンプレミスの適切なゾーンにいるが、Agentless DSSOに継続して失敗する

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

正しいゾーンにいること、SPNに使用するアカウントが正しいこと、オンプレミスであることを確認したにもかかわらず、Agentless DSSOに継続して失敗する

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

注

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

Kerberosバリデーターとサインインの失敗

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

サインオン動作が遅い、または失敗する

エージェントレス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)

デスクトップSSO/IWAが機能しない

  • サーバーのホスト名がクライアントネットワーク内から解決可能であることを確認します。
  • 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は動作を停止します。

サーバーの再起動後またはグループポリシーの変更後にIWAが機能しない

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

The request was aborted: Could not create SSL/TLS secure channel(リクエストが中断されました:SSL/TLSのセキュアなチャネルを作成できません)というエラーメッセージが表示されたときは、どうすればよいですか?

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) Agentが、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)

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

エージェントのインストール時にIWA構成を保存できませんでした

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

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

  1. Okta(未定義の変数:okta-feature-names.IWA)Webエージェントをインストールする」手順のステップ1、2を実行します。
  2. コマンドプロンプトを開いて次のコマンドを入力します:OktaSsoIwa.exe OktaDisableSslPinning=1
  1. Enterキーを押します。
  2. インストールを完了します。「Okta(未定義の変数:okta-feature-names.IWA)Webエージェントをインストールする」を参照してください。