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

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

エージェントレスDSSOが機能するためには、あなたのブラウザがあなたのドメインの鍵配布センター(KDC)に接続できることが必要です。これは、Kerberos検証に不可欠です。KDCにアクセスできないと、Kerberosチケットを取得できず、認証できません。利用可能な場合、仮想プライベートネットワーク(VPN)経由でネットワークに接続してください。VPN経由でKDCを使用できれば、エージェントレスDSSOは機能します。

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

これは、ある種のKerberos認証失敗であることが考えられます。Wiresharなどのツールを使用して、エージェントレスDSSO試行中のネットワークトラフィックをキャプチャしてください。キャプチャしたら、Kerberosトラフィックをフィルターします。このトラフィックをKDC上のイベントビューアのログと比較します。これら2つのツール(または同等品)を使用することで、Kerberos認証失敗をさらすことができるはずです。
注:デバグレベルのKerberosイベントを見るためには、 Kerberosイベントロギングを有効にする必要があるかもしれません。詳細は、https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-loggingを参照してください。

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

エージェントレスDSSOサインイン中、OktaはSIDルックアップを行います。EAタイムフレーム中、これはADエージェントを呼び出すことで行われます。サインインに時間がかかるか失敗する場合は、ADエージェントのポーリングスレッド数を増やすか、ドメイン用の新しいADエージェントを追加することをご検討ください。この方法の詳細は、 複数のOkta Active Directoryエージェントのインストール とOkta Active Directoryエージェントスレッドの数の変更を参照してください。
これが発生した場合は、ADエージェントログに、Next action = NONE行なしで、大量のread LDAP呼び出しで埋められているはずです。例:
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)

- サーバーのホスト名がクライアントネットワーク内から解決できることを確認します。
- IWAがIIS認証構成とクライアントの両方でオンになっている必要があります。
注:Office 2016およびWindows 10の最新ビルドには、サインイン・ワークフロー用のWebアカウント・マネージャー(WAM)が組み込まれています( この Microsoftの記事を参照してください)。WAMにはhttpsが必要です — 認証ワークフロー中にhttps以外のトラフィックをブロックします。このユース・ケース用にIWAを構成する方法の詳細については、「SSLの構成」を参照してください。
ヒント: OktaService アカウントパスワードをAD内で変更した場合、Okta IWA SSOエージェントもインストールして、Okta ADエージェントのインストールに使用したのと同じOktaサービスアカウントを使用する場合、IISサーバーマネージャーダッシュボード> ツール> インターネット情報サービス(IIS) マネージャーでのOktaサービスアカウントパスワードも変更する必要があります。
Okta IWA サービスは[Application Pools(アプリケーションプール)]メニューの下にインストールされています。 [Advanced Settings(詳細設定)]の下で、新しいパスワードに一致するようにOktaサービスパスワードを変更できます。キャッシングのため、IWAサービスは即時停止しないことがあります。キャッシュがリセットするとき、OktaServiceパスワードをここで更新して、Active Directoryユーザーおよびコンピュータツールおよびエージェントがインストールされているサーバーのサービスコンソールでリセットしたパスワードに一致させないと、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 セキュアチャネルを作成できませんでした)
エラーメッセージを受け取ったらどうしますか? OktaIWA Webエージェントが以下の場合、OktaIWA Webエージェントがオフラインになり、The request was aborted: Could not create SSL/TLS secure channel(リクエストが中止されました:SSL/TLS セキュアチャネルを作成できませんでした)
エラーメッセージが表示されることがあります。
- Windows Server 2008 R2 SP1を実行しているサーバーにインストールされているおよび
- HTTPSを使用して構成されている および
- 自動フェイルオーバー用に構成されている
OktaIWA WebエージェントがWindows Server 2008 R2 SP1を実行しているサーバー上にインストールされており、 セキュア接続(HTTPS)経由でSSO IWAを使用する場合、着信接続( IISなど)用のTLS 1.2プロトコルをまず有効にしてください。これは、Okta Active Directory (AD)は可能な限り TLS 1.2 を使用することを試みるため、TLS 1.2着信接続用に有効になっていない Windows Server 2008 R2 SP1サーバー上にOktaIWA Webエージェントがインストールされていると、OktaIWA Webエージェントとの接続が失われることがあるためです。Windows Server 2008 R2 SP1 はTLS 1.2 プロトコル 発信 接続をデフォルトでサポートしています。しかしながら、着信接続のサポートはデフォルトで無効になっています。Oktaでは、この設定を有効にすることを強く推奨しています。
- IWA WebエージェントをホストするWindows 2008 R2サーバーのレジストリに次の値を追加します。
- サーバーを再起動します。

エラーのインストール時に次のエラーメッセージが表示される場合、
Failed to store IWA config
おそらく、SSL 証明書のピン留めをがデフォルトで有効になっているバージョンのOkta IWA Webエージェント をインストールしようとしており、SSL証明書のピン留めに対するエージェントのサポートがOktaサーバーとの通信を妨げている環境です。このエラーは、SSLプロキシに依存する環境で最もよく発生します。この場合、インストールが完了するようにするには、ドメインokta.comを許可リストに追加してSSLプロキシの処理をバイパスすることをお勧めします。
あるいは、SSL証明書のピン留めが有効になっていれば、無効にできます。
SSL証明書のピン留めを無効にする
- 「Okta IWA Webエージェントのインストール」手順のステップ1と2を実行します。
- ステップ3で説明されているようにファイルをダブルクリックする代わりに、コマンドライン端末を開いて、以下を入力します:
OktaSsoIwa.exe OktaDisableSslPinning=1
- Enterを押します。
- インストールを完了します。「Okta IWAウェブエージェントのインストール」を参照してください。