本記事ではIWAの機能と、IWAの導入後にぶつかることの多い問題をトラブルシューティングするための手法を説明します。記事を読み進める前に、「デスクトップSSOの設定方法」を参照し、ブラウザーが適切に設定されていることをご確認ください。 

IWAおよびOktaデスクトップSSOの概要

IWA（Integrated Windows Authentication）とは、接続状況に応じて多様な認証方法を利用し、サードパーティー製アプリケーションにドメイン認証（またはドメインの信頼関係）を拡張するMicrosoft社の技術です。OktaのIWAサービスはそのプラットフォームとは切り離して構築され、フローにKerberosとNTLM認証方式を採用しています。OktaのIWAではネットワークを介してドメインにアクセスできる必要があります。クライアントからネットワーク（IWAサーバー、DNS、AD Agentサーバーなど）に到達できない場合は、認証に失敗します。ドメインのネットワークに直接アクセスできない機器にIWAアクセスを拡張することも技術的には可能ですが、この記事では扱いません。その開発作業には、Private Communications Transport（PCT）プロトコルに即してTLS/Schannel SSPを実装するための多大な労力が伴います。このタイプの認証を実装する必要に迫られる場合は、プロフェッショナルサービスに頼るのが無難です。

標準的なドメインベースの認証には2つの方式があり、IISマネージャーの［認証］>［Windows Authentication（Windows認証）］>［Providers（プロバイダー）］から設定できます。

1. ［Negotiate（ネゴシエート）］ - 通常はKerberos認証を指します。Oktaユーザーが期待する、SSOのシームレスな使用感を得るにはこの方式が必要です。

2. [NTLM] - この認証では、プロンプトを介してユーザー名とパスワードを求めるチャレンジ/レスポンス方式が使用されます。

プロバイダーの設定は優先順位に従います。つまり、一覧の先頭にある認証方式が最初に使用されます。IISの新規インストールを伴う大抵の構成では、先頭がネゴシエート、2番目がNTLMの順で設定されます。

注：

• ネゴシエートとNTLMについて：
  • ネゴシエート方式を使用するように設定されているIISが認証に失敗した場合、NTLMによる認証がフェイルオーバーとして実行されます。
  • 下記の図1では、ネゴシエート（Kerberos）方式による認証が成功したため、NTLM方式は使用されません。図2ではKerberos認証が失敗したため、NTLMで認証が試みられています。

図1	図2

匿名認証を利用すると、ユーザーはユーザー名とパスワードを入力しなくてもWebサイトのパブリック領域にアクセスできます。認証スキームで示したとおり、クライアントは認証情報を求められないため、技術的には実際のクライアント認証を行いません。代わりにIISからWindowsに対して、IISに保存されている認証情報が渡されます。この時、特殊なユーザーアカウントであるIUSR_machinenameが使用されます。匿名ユーザーの権限は、IISがパスワードを管理しているか否かで変わります。IISがパスワードを管理している場合は、標準のネットワークログインウィンドウ（ネットワーク経由で共有フォルダーにアクセスする際に同じプロンプトが使用されています）を介して、サブ認証DLL（iissuba.dll）によってユーザーが認証されます。

KerberosとNTLMはWindows認証で単独で使用されています。匿名認証がWebサイトのデフォルトレベルで有効化されている場合、Windows認証ではなくネットワークログインをIISから求められる可能性があります。Okta IWAのフローの中でもっとも多い失敗は［401 Access is Denied（401アクセスが拒否されました）］というエラーで、フェイルオーバーによる匿名認証からWindows認証への切り替えが正常に行われなかった場合に発生します。Kerberosが正しく機能している場合は、管理者が匿名認証を無効にすることで、SSOで確実にWindows認証が実行されるようになります。

IISの検証設定

• ［IIS Manager（IISマネージャー）］> ［IWA Site（IWAサイト）］>［認証］>［Providers...（プロバイダー...）］

  • ［Enabled Providers（有効なプロバイダー）］は［Negotiate（ネゴシエート）］（上）、［NTLM］（下）の順にします。

• ［IIS Manager（IISマネージャー）］> ［IWA Site（IWAサイト）］>［認証］>［詳細設定］>［Extended Protection（拡張保護）］>［オフ］

  • この設定を有効にすると、Mozilla Firefoxではこの保護機能がサポートされていないために悪影響が出ることがわかっています。

• 既定のWebサイトおよびIWAサイトの認証プロバイダーのリスト 

  • ［Default Web Site（既定のWebサイト）］ - Windows認証のみ有効にします。

  • ［IWA Site（IWAサイト）］ - Windows認証と匿名認証の両方を有効にします。

Kerberosベースの認証が失敗した場合のトラブルシューティング

注：

• Kerberosに関連するエラーが起きた場合、SSOは必ず失敗します。失敗の種類はKerberosのエラーに応じてさまざまですが、Kerberosでエラーが起きると、必ず一定の型があるエラーメッセージが生成されるため、問題の診断と解決に役立ちます。

Kerberosのトラブルシューティングツールとしてもっとも汎用性があり、信頼性が高いのはWiresharkです。適切なフィルター設定を行えば、認証パケットの中身か、特定のKerberosエラー応答のどちらかでKerberosのエラーを確認できます。

• 使用するフィルターはWiresharkのバージョンによって異なります。KerberosV5など、フィルターロジックが上手くいかない場合に使用できる内蔵フィルターがあります。
• Wiresharkを使用してトレースを確認する場合、フィルターは次のようにシンプルなものになります："dns || Kerberos || ip.addr==<対象マシンのIPアドレス>"。このフィルターには、「対象マシンを発着点とするパケット、DNSの名前照会と応答、Kerberos認証をすべて表示する」という意味があります。

実行すると次の画像のような結果が得られます。

ネットワークキャプチャーが完了すると、試行されたKerberos認証の情報（中身にKerberosのチケットが含まれるパケットも）だけでなく、リモートシステム宛てのあらゆる情報を確認できます。

1. 対象システムのホスト名からIPアドレスを割り出します。
   1. HOSTSファイルの内容を確認する。
   2. DNSにクエリーを発行する。
   3. LMHOSTSファイルの内容を確認する。
   4. WINS/NBNSにクエリーを発行する。
2. リモートシステムにpingを実行します。
3. Wiresharkを実行した状態でブラウザーからIWAフローを試行し、認証プロトコルをネゴシエート（Kerberosのチケットをリクエスト）します。無関係なパケットのデータが検索結果に入り込まないようにするため、処理が完了次第キャプチャーを停止させます。

上記の操作を行った状態で、Wiresharkによってキャプチャーされるパケットの例を次に示します。

1. 名前の解決

2. リモートシステムへのping：

3. IWAフローでのネゴシエートによる認証：

認証プロトコルにネゴシエートした結果、リモートシステムが応答したことが上記の手順からわかります。この応答こそが、パケットのもっとも重要な部分です。応答部分の項目をクリックすると、より詳しい情報が表示されます。

4. Kerberosチケットのリクエスト：

こちらの有益なTechNetブログでは、Kerberosチケットをリクエストする際に経験することの多いエラーについて説明されています。

SPNの意味とその設定方法

サービスプリンシパル名（SPN）はサーバー上で稼働しているサービスを一意に識別するもので、Kerberosを使用するサービスではこの名前が必須になります。コンピューターのアカウントがSPNを失うと、認証や認証情報、権限、アクセスの各処理でエラーメッセージが表示されるようになります。SPNは次の情報を組み合わせて表現されます。

SPNを設定するコマンドでは、上記の条件を次の形式で使用します（ホスト名とFQDNの両方に設定）。

• setSPN -s HTTP/<ホスト名> <ドメイン><サービスアカウント>

• setSPN -s HTTP/<ホスト名>.<FQDN> <ドメイン><サービスアカウント>

上記の情報を使用した例：

setspn -s http/OKTAICE-IWA oktaice\oktaservice

および

setspn -s http/OKTAICE-IWA.oktaice.info oktaice\oktaservice

SPNを確認する方法は2つあります。

1. Setspnコマンド（用法は以下のとおり）

   • 例：setspn -L oktaice\oktaservice

2. ADSI Editを使用する

   1. ADSI Editを起動する。

   2. 該当のOUでサービスアカウントを探す。

   3. OUを右クリックし、［プロパティー］をクリックする。

   4. 画面をスクロールさせてservicePrincipalName属性を見つける。

   5. 上記のコマンドで追加された値を確認する。 

SPNを手作業で設定し終わったら、IWA Webアプリ用のカーネルモードの認証を、Windows認証の設定で無効にします。