非ドメイン環境のIISにEdgeからWindows統合認証する際に「毎回資格情報の入力を求められる問題」を解決

2011年から開発をはじめ、現在の原型が出来上がったのが2014年。MovieJukeBoxをリリースしてから10年たちました。ここ3年近く解決できなかったWindows統合認証で「毎回資格情報を求められる」問題を解決できました。

環境

1. 非ドメイン環境で　IIS＋ASP.NET+SQL server 2016 で構成されるWebアプリケーションを自宅で展開しています。
2. WebアプリケーションはHyper-V上の仮想マシン（Windows 11 Pro）に展開しています。
3. Webアプリケーションの認証法は　Windows統合認証　です。
4. 利用者のアカウント（Microsoftアカウント）に対し、Webアプリケーションのフォルダアクセス権を付与しています。
5. Webアプリケーションに家庭内LAN内パソコンのEdgeからアクセスします。
6. Webアプリケーションを展開する仮想マシン、Webアプリケーションを利用するパソコンは同一ネットワーク上にあり、ネットワークの場所は「プライベートネットワーク」になっています。
7. Edgeのインターネットオプション　－　セキュリティ　ー　ローカルインターネット　ゾーンの設定で
• Webアプリケーションのコンピュータ名　を登録済
• イントラネットゾーンのみ自動でログオンする　を選択済
8. ドメイン環境でなくても、アカウント名とパスワードが同じであれば異なるコンピューター間で認証できることを利用しています。

問題

• 必ず資格情報を求められます。
• 資格情報を保存する　チェック欄　がありません。
• 毎回マイクロソフトアカウントとパスワードが求められ入力する必要があります。入力すれば認証されます。
• IEモードで読み込むと発生しません。

ただし、初回利用時のみ　上記のポップアップの赤丸に　「資格情報保存する」チェック　欄があって、Webサーバ側に登録されている　ローカルアカウント　か　マイクロソフトアカウント　のアカウント名とパスワードを入力し、チェックを入れていたかもしれません。

アカウントとパスワードを入力しないでOK押せば、当然認証は失敗します。

ただ、わからないのが「たまにアカウント、パスワードを求めてこないこと」もあることです。このWebアプリケーションを別タブで開くのでなく、すべてのブラウザを閉じて再立ち上げしてもアカウント、パスワードを求めてこないこともあるのです。

いつから問題が発生していたか？

2020年か2021年くらいからだったと思います。
すべてのパソコンで一気に上記問題が発生したわけではなく、徐々にという感じでした。


仕方がないので毎回アカウントとパスワードを入力する運用を3年くらいやっていました。

今思えばChromnium版Edgeに切り替わったのにその対応をしていなかったことが原因だったと思います。

解決

Windows統合認証のプロバイダーには　Negotiate　を入れてはいけないようです。ドメイン環境ではないので、IIS側ではNegotiate（Kerberos認証）できないとうことでしょうか？

Negotiateは入れてはいけないようです。

「たまにアカウント、パスワードを求めてこないこともある」というのは有効なプロバイダーに登録した順序の関係で、NTLMでの認証情報のキャッシュが残っていたとか、Negotiateではなく時としてNTLMで認証要求される（する）場合があるとか、そういったことでしょうか・・・よくわかりません。わかる方教えていただけると嬉しいです。

Edgeでアプリとしてインストールした状態

拡張機能で日本語に翻訳

後書き：認証種類の検証

1. Microsoft Edge での Kerberos ダブルホップ認証 (Chromium) - Internet Information Services | Microsoft Learn
2. Windows 統合認証のトラブルシューティングの診断ページ - Internet Information Services | Microsoft Learn
3. Windows 統合認証のトラブルシューティングの診断ページ - Internet Information Services | Microsoft Learn

1→2→3の順で3に行きつけたので、3から検証ソース「WhoAmI.aspx」と「ScrapperTest.aspx」をダウンロードし、Webアプリケーションに配置してテストしました。

「WhoAmI.aspx」の検証結果を記載しておきます。

テストでは、IISで展開するWebアプリケーションのWindows認証の設定は、いずれのパターンでも詳細設定の　拡張保護：オフ、カーネルモード認証：有効　としました。

テストパターンは有効なプロバイダーについて　Negociate　と　NTLM　について以下の4つパターンです。なお「Negociate：Kerberos」は認証通りませんでした。

1. Negociate　のみ
2. Negociate　を上、NTLM　を下　にして2つを指定
3. Negociate　を下、NTLM　を上　にして2つを指定
4. NTLM　のみ

WhoAmI.aspx　及び　Webアプリケーション　そのものにアクセスします。

Authentication Method　はWebサイトへのアクセス時に使用される認証メソッドを示しているようなので、上記テストパターンでこの値をみていきます。

IdentityとWindows identity　についてはOpenAIのChat-GPT3.5に解説してもらったのでそれを記載しておきます。

（プロンプト）

省略

提供された情報は、IIS（Internet Information Services）とASP.NETを使用して構築されたWebサイトに関連するものです。以下に、提供された情報をもとに説明します。

1. **Identity (`vMJB\Atsushi`, `Request.ServerVariables("AUTH_USER") or System.Threading.Thread.CurrentPrincipal.Identity)`**:
- `vMJB\Atsushi` は、Webサイトにアクセスしたユーザーの識別情報を表します。`vMJB`はWindowsドメイン、`Atsushi`はユーザー名です。
- `Request.ServerVariables("AUTH_USER")` は、HTTPリクエストに含まれる認証情報から取得されるユーザー名です。この情報は、Webサーバーが認証を実施した結果です。例えば、Windows認証が使用されている場合、これにはユーザー名が含まれます。
- `System.Threading.Thread.CurrentPrincipal.Identity` は、現在のスレッドに関連付けられたセキュリティプリンシパルのIdentityを表します。これにより、ASP.NETアプリケーション内でのユーザーコンテキストを取得できます。

2. **Windows Identity (`IIS APPPOOL\DefaultAppPool`, `System.Security.Principal.WindowsIdentity.GetCurrent`)**:
- `IIS APPPOOL\DefaultAppPool` は、IISが使用しているアプリケーションプールのアイデンティティを示しています。IISアプリケーションプールは、アプリケーションの実行に使用されるプロセスです。このアイデンティティは、アプリケーションプールがどのユーザーまたはサービスとして実行されているかを表します。
- `System.Security.Principal.WindowsIdentity.GetCurrent` は、現在のWindowsユーザーのセキュリティコンテキストを取得します。これは、ASP.NETアプリケーションが実行されている際に、アプリケーションプールのアイデンティティではなく、実際のユーザーの情報を取得するために使用されます。

この情報は、Webサイトへのアクセス時に使用されるユーザーやアプリケーションプールの情報を提供しています。

テスト結果

結果は、テストパターン１から３は以下のとおりです。

1. 認証要求なしに　Authentication Method:

   Negotiate (Session Based)　で認証される

2. 認証要求なしに　Authentication Method:

   Negotiate (NTLM - fallback)　で認証される

3. 認証要求される

上記1から3をランダムにかつ数十秒、数分、数十分の時間間隔で可変します。つまり不安定です。

テストパターン４のみ安定して認証要求なしに表示されます。

NTLMで認証されている

参考1：Negotiate　と　NTLM　を　Chat-GPT3.5が解説

（プロンプト）

Windows統合認証におけるnegociateとNTLMの違いは？

Windows統合認証におけるNegotiateとNTLMは、異なる認証プロトコルであり、セキュリティコンテキストの確立や認証の方法においていくつかの重要な違いがあります。

1. **Negotiate**:
- **協議 (Negotiation)**: Negotiateは、クライアントとサーバーが利用可能な認証プロトコルを協議し、最適なものを選択するメカニズムを提供します。クライアントがKerberosをサポートしている場合、NegotiateはKerberosを使用し、サポートしていない場合はNTLMをフォールバックとして使用します。
- **Kerberosを利用可能な場合**: Kerberosが環境で使用可能でかつ構成されている場合、NegotiateはKerberosを優先的に選択します。

- **クライアントとサーバーが同じドメイン**: Negotiateは、クライアントとサーバーが同じWindowsドメインに属している場合に、より効果的な認証手段を提供します。

2. **NTLM (Windows NT LAN Manager)**:
- **挑戦応答方式 (Challenge-Response)**: NTLMは挑戦応答方式を使用して認証を行います。サーバーがクライアントに挑戦（challenge）を送り、クライアントはその挑戦に対する応答（response）を生成して認証を試みます。
- **Kerberosが利用不可能な場合**: クライアントやサーバーがKerberosをサポートしていないか、Kerberosが適用できない場合、NTLMが使用されます。

- **認証情報の流れ**: NTLMではユーザーの認証情報がサーバーによりハッシュとして保存され、それが挑戦応答の一環として使用されます。

簡潔に言えば、Negotiateはクライアントとサーバーが利用可能な認証プロトコルを最適化して選択し、Kerberosを優先的に利用します。一方でNTLMは、Kerberosが使えない場合やサポートされていない場合のフォールバックとして使用されます。

参考2：SQLServerのDBアクセス権及びデータベースロールとアプリケーションプールのIdentity

SQLServerへのアクセス権不足によりデータアクセスが失敗している場合は、認証要求されるのではなく、Webアプリケーション側でエラーとなるのであまり疑いませんでしたが、解決できない期間が長かったため疑心暗鬼になりました。そのためSQLServer設定もメモしておきます。

今回評価しているアプリケーションプールのIdentity　は　デフォルトの　ApplicationPoolIdentity　を指定

SQLServerのDBアクセス用のユーザー

アプリケーションプールのIdentity　で指定した　ApplicationPoolIdentity　は　動的に生成される　IIS APPPOOL\DefaultAppPool　となるので、これをSQL Serverインスタンスのログインユーザーに追加しています。

今回評価したWebアプリケーション　MovieJukeBox　ではストアドプロシージャやスカラ関数が実行されるので、データベースのロール権限　Execute　を作成。

WebアプリケーションのDBである　MOVIE　に　　IIS APPPOOL\DefaultAppPool　を追加し、Execute権限を付与しています。

雑感

長くなるので書きませんが、この3年間で試したことがいくつかありますので箇条書きで。なおすべて空振りでした。

• ローカルグループポリシーエディタの　Edgeのテンプレート　をインストールし「http認証」や「IDとサインイン」の設定をいろいろ試した
• Edgeの設定からWebアプリケーションのURLについてIDとパスワードを手動登録した
• 自己証明書を作成し、IISでSSLを有効化しhttpsでのアクセスを試みた
• Web.configの設定値をいろいろ変えてみた　などなど