ASP.NET Core で Windows 認証を構成する

作成者: Rick Anderson および Kirk Larkin

Windows 認証 (Negotiate、Kerberos、または NTLM 認証とも呼ばれます) は、IIS、Kestrel、または HTTP.sys でホストされている ASP.NET Core アプリに対して構成できます。

Windows 認証は、オペレーティング システムに依存して ASP.NET Core アプリのユーザーを認証します。 Windows 認証は、Active Directory ドメイン ID または Windows アカウントを使用して企業ネットワーク上で実行されるサーバーに使用され、ユーザーを識別します。 Windows 認証は、ユーザー、クライアント アプリ、および Web サーバーが同じ Windows ドメインに属しているイントラネット環境に最適です。

Note

Windows 認証は、HTTP/2 ではサポートされていません。 認証チャレンジは HTTP/2 応答で送信できますが、認証する前にクライアントを HTTP/1.1 にダウングレードする必要があります。

プロキシとロード バランサーのシナリオ

Windows 認証はステートフルなシナリオであり、プロキシまたはロード バランサーによってクライアントとサーバー間のトラフィックが処理されないイントラネットで主に使用されます。 プロキシまたはロード バランサーが使用されている場合は、プロキシまたはロード バランサーが以下である場合にのみ、Windows 認証が機能します。

• 認証を処理します。
• 認証情報を処理するアプリにユーザー認証情報を渡します (要求ヘッダーなど)。

プロキシやロード バランサーが使用されている環境で Windows 認証の代わりになるのは、OpenID Connect (OIDC) を使用する Active Directory フェデレーション サービス (ADFS) です。

IIS/IIS Express

Program.cs で AddAuthentication を呼び出して、NuGet パッケージ Microsoft.AspNetCore.Authentication.Negotiate と認証サービスを追加します。

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapRazorPages();

app.Run();

上記のコードは、Windows 認証を使用して ASP.NET Core Razor Pages テンプレートによって生成されました。

起動設定 (デバッガー)

起動設定の構成は、IIS Express のProperties/launchSettings.json ファイルにのみ影響し、Windows 認証用に IIS が構成されません。 サーバーの構成については、「IIS」セクションで説明します。

Visual Studio または .NET CLI を介して使用できる Web アプリケーション テンプレートは Windows 認証をサポートするように構成できます。これにより、Properties/launchSettings.json ファイルが自動的に更新されます。

Visual Studio

新しいプロジェクト

新しい Razor Pages または MVC アプリを作成します。 [追加情報] ダイアログで、[認証の種類] を [Windows] に設定します。

アプリを実行します。 ユーザー名は、表示されるアプリのユーザー インターフェイスに表示されます。

既存のプロジェクト

プロジェクトのプロパティを使用して、Windows 認証を有効にし、匿名認証を無効にします。 起動プロファイル ダイアログを開きます。

1. ソリューション エクスプローラーで、プロジェクトを右クリックして [プロパティ] を選択します。
2. [デバッグ] > [全般] タブの順に選択し、[Open debug launch profiles UI](デバッグ起動プロファイル UI を開く) を選択します。
3. [匿名認証を有効にする] チェックボックスをオフにします。
4. [Windows 認証を有効にする] チェックボックスをオンにします。

または、launchSettings.json ファイルの iisSettings ノードでプロパティを構成することもできます。

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

.NET CLI

新しいプロジェクト

webapp 引数 (ASP.NET Core Web App) と --auth Windows スイッチを指定して、dotnet new コマンドを実行します。

dotnet new webapp --auth Windows

既存のプロジェクト

launchSettings.json ファイルの iisSettings ノードを更新します。

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

IIS

IIS では、ASP.NET Core モジュールを使用して ASP.NET Core アプリをホストします。 Windows 認証は、web.config ファイルを使用して IIS に対して構成されます。 以下のセクションでは、その方法について説明します。

• アプリの展開時にサーバーで Windows 認証をアクティブ化するローカル web.config ファイルを指定します。
• サーバーに既に展開されている ASP.NET Core アプリの web.config ファイルを構成するには、IIS マネージャーを使用します。

まだ行っていない場合は、IIS で ASP.NET Core アプリをホストできるようにします。 詳細については、「IIS を使用した Windows での ASP.NET Core のホスト」を参照してください。

Windows 認証に対して IIS の役割サービスを有効にします。 詳細については、IIS の役割サービスでの Windows 認証の有効化 (手順 2 を参照) に関するセクションを参照してください。

IIS 統合ミドルウェアは、既定で自動的に要求を認証するように構成されています。 詳細については、IIS を使用した Windows での ASP.NET Core のホスト: IIS オプション (AutomaticAuthentication) に関するページを参照してください。

ASP.NET Core モジュールは、既定で Windows 認証トークンをアプリに転送するように構成されています。 詳細については、ASP.NET Core モジュール構成リファレンス: aspNetCore 要素の属性に関するページを参照してください。

次のいずれかの方法を使用します。

• プロジェクトを発行して展開する前に、次の web.config ファイルをプロジェクトのルートに追加します。

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <security>
          <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true" />
          </authentication>
        </security>
      </system.webServer>
    </location>
  </configuration>
  

  プロジェクトが .NET Core SDK によって発行された場合 (プロジェクト ファイルの <IsTransformWebConfigDisabled> プロパティが true に設定されていない場合)、発行された web.config ファイルには <location><system.webServer><security><authentication> セクションが含まれます。 <IsTransformWebConfigDisabled> プロパティの詳細については、「IIS を使用した Windows での ASP.NET Core のホスト」を参照してください。

• プロジェクトを発行および展開した後、IIS マネージャーを使用してサーバー側の構成を実行します。

  1. IIS マネージャーで、[接続] サイドバーの [サイト] ノードの下の IIS サイトを選択します。
  2. [IIS] 領域で [認証] をダブルクリックします。
  3. [匿名認証] を選択します。 [アクション] サイドバーで [無効] を選択します。
  4. [Windows 認証] をクリックします。 [アクション] サイドバーで [有効] を選択します。

  これらの操作を実行すると、IIS マネージャーによって、アプリの web.config ファイルが変更されます。 <system.webServer><security><authentication> ノードは、anonymousAuthentication および windowsAuthentication の更新された設定を使用して追加されます。

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
  

  IIS マネージャーによって web.config ファイルに追加された <system.webServer> セクションは、アプリの発行時に .NET Core SDK によって追加されたアプリの <location> セクションの外側にあります。 セクションは <location> ノードの外側に追加されるため、設定は サブアプリによって現在のアプリに継承されます。 継承されないようにするには、.NET Core SDK が提供された <location><system.webServer> セクション内に、追加される <security> セクションを移動します。

  IIS マネージャーを使用して IIS 構成を追加すると、サーバー上のアプリの web.config ファイルにのみ影響します。 サーバーの web.config のコピーがプロジェクトの web.config ファイルで置き換えられた場合、その後のアプリの展開でサーバーの設定が上書きされる可能性があります。 設定を管理するには、次のいずれかの方法を使用します。

  • 展開時にファイルが上書きされた後、IIS マネージャーを使用して、web.config ファイルの設定をリセットします。
  • 設定を使用して、アプリに web.config ファイル をローカルに追加します。

Kestrel

Microsoft.AspNetCore.Authentication.Negotiate NuGet パッケージは、Kestrel と共に使用して、Windows、Linux、macOS で Negotiate と Kerberos を使用した Windows 認証をサポートできます。

警告

資格情報は、接続時に要求間で永続化できます。 プロキシで Kestrel と 1:1 のアフィニティ (永続的な接続) が維持されている場合を除いて、プロキシで Negotiate 認証を使用することはできません。

Note

Negotiate ハンドラーでは、基になるサーバーが Windows 認証をネイティブでサポートしているかどうか、また有効になっているかどうかを検出します。 サーバーが Windows 認証をサポートしていても、無効になっている場合は、サーバーの実装を有効にするように求めるエラーがスローされます。 サーバーで Windows 認証が有効になっている場合、Negotiate ハンドラーは認証要求を透過的に転送します。

Program.cs に対して次の強調表示されたコードによって認証が有効になっています。

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapRazorPages();

app.Run();

上記のコードは、Windows 認証を使用して ASP.NET Core Razor Pages テンプレートによって生成されました。 上記のコードでは、次の API が使用されています。

• AddAuthentication
• AddNegotiate
• UseAuthentication

Kerberos 認証とロールベースのアクセス制御 (RBAC)

Linux または macOS での Kerberos 認証では、認証されたユーザーのロール情報は提供されません。 Kerberos ユーザーにロールとグループの情報を追加するには、LDAP ドメインからロールを取得するように認証ハンドラーを構成する必要があります。 最も基本的な構成では、クエリを実行する LDAP ドメインを指定し、認証されたユーザーのコンテキストを使用して LDAP ドメインのクエリを実行します。

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            options.EnableLdap("contoso.com");
        }
    });

一部の構成では、LDAP ドメインをクエリするために特定の資格情報が必要になる場合があります。 資格情報は、次の強調表示されたオプションで指定できます。

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate(options =>
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                options.EnableLdap(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword =
                                      builder.Configuration["Password"];
                });
            }
        });

builder.Services.AddRazorPages();

既定では、ネゴシエート認証ハンドラーは、入れ子になったドメインを解決します。 大規模または複雑な LDAP 環境では、入れ子になったドメインを解決すると、検索速度が低下したり、ユーザーごとに大量のメモリが使用されたりする可能性があります。 入れ子になったドメインの解決は、IgnoreNestedGroups オプションを使用して無効にすることができます。

匿名の要求が許可されます。 ASP.NET Core 承認を使用して、認証のための匿名要求のチャレンジを実行します。

Windows 環境構成

Microsoft.AspNetCore.Authentication.Negotiate コンポーネントは、ユーザー モード認証を実行します。 サービス プリンシパル名 (SPN) は、コンピューター アカウントではなく、サービスを実行しているユーザー アカウントに追加する必要があります。 管理コマンド シェルで setspn -S HTTP/myservername.mydomain.com myuser を実行します。

Kerberos と NTLM

ASP.NET Core の Kestrel 上のネゴシエート パッケージが Kerberos の使用を試みます。これは、NTLM よりも安全でパフォーマンスの高い認証スキームです:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();

NegotiateDefaults.AuthenticationScheme では、Kerberos が既定値であるため、それを指定します。

IIS、IISExpress、Kestrel は、Kerberos と NTLM の両方をサポートします。

FIddler のようなツールで IIS または IISExpress を使用して WWW-Authenticate: ヘッダーを調べると、Negotiate または NTLM が表示されます。

Kestrel のみが WWW-Authenticate: Negotiate を示します

WWW-Authenticate: Negotiate ヘッダーは、サーバーが NTLM または Kerberos を使用できることを意味します。 Kestrel には、Negotiate ヘッダー プレフィックスが必要です。要求または応答の認証ヘッダーでの NTLM の直接指定はサポートされていません。 NTLM は Kestrel でサポートされていますが、Negotiate として送信する必要があります。

Kestrel で、NTLM または Kerberos が使用されているかどうかを確認するために、Base64 はヘッダーをデコードし、NTLM または HTTP のいずれかを示します。 HTTP は、Kerberos が使用されたことを示します。

Linux および macOS 環境の構成

Linux または macOS マシンを Windows ドメインに参加させる手順については、Windows 認証を使用した Azure Data Studio の SQL Server への接続 - Kerberos に関する記事を参照してください。 手順では、ドメイン上の Linux マシンのマシン アカウントを作成します。 SPN は、そのマシン アカウントに追加する必要があります。

Note

Windows 認証を使用した Azure Data Studio の SQL Server への接続 - Kerberos に関する記事のガイダンスに従う場合は、必要に応じて python-software-properties を python3-software-properties に置き換える必要があります。

Linux または macOS マシンがドメインに参加したら、keytab ファイルに SPN を指定するための追加の手順が必要です。

• ドメイン コントローラーで、マシン アカウントに新しい Web サービス SPN を追加します。
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• ktpass を使用して keytab ファイルを生成します。
  • ktpass -princ HTTP/mywebservice.mydomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1
  • 一部のフィールドは、指示のとおり大文字で指定する必要があります。
• keytab ファイルを Linux または macOS マシンにコピーします。
• 環境変数を使用して keytab ファイルを選択します: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• klist を呼び出して、現在使用できる SPN を表示します。

Note

keytab ファイルにはドメイン アクセス資格情報が含まれているので、必要に応じて保護する必要があります。

HTTP.sys

HTTP.sys では、Negotiate、NTLM、基本認証を使用した カーネル モード Windows 認証がサポートされています。

次のコードでは、認証を追加し、Windows 認証で HTTP.sys を使用するようにアプリの Web ホストを構成します。

using Microsoft.AspNetCore.Server.HttpSys;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    builder.WebHost.UseHttpSys(options =>
        {
            options.Authentication.Schemes =
                AuthenticationSchemes.NTLM |
                AuthenticationSchemes.Negotiate;
            options.Authentication.AllowAnonymous = false;
        });
}

Note

HTTP.sys では、Kerberos 認証プロトコルを使用したカーネル モード認証に処理が委任されます。 Kerberos および HTTP.sys ではユーザー モード認証がサポートされていません。 Active Directory から取得され、クライアントによって、ユーザーを認証するサーバーに転送される Kerberos トークン/チケットを暗号化解除するには、コンピューター アカウントを使用する必要があります。 アプリのユーザーではなく、ホストのサービス プリンシパル名 (SPN) を登録します。

Note

HTTP.sys は、Nano Server バージョン 1709 以降ではサポートされていません。 Nano Server で Windows 認証と HTTP.sys を使用するには、Server Core (microsoft/windowsservercore) コンテナー (https://hub.docker.com/_/microsoft-windows-servercore を参照) を使用します。 Server Core の詳細については、「Windows Server の Server Core インストール オプションとは」を参照してください。

ユーザーを承認

匿名アクセスの構成状態によって、アプリで [Authorize] および [AllowAnonymous] 属性を使用する方法が決まります。 次の 2 つのセクションでは、匿名アクセスの許可および許可されていない構成状態を処理する方法について説明します。

匿名アクセスを許可しない

Windows 認証が有効で、匿名アクセスが無効になっている場合、[Authorize] および [AllowAnonymous] 属性は無効になります。 IIS サイトが匿名アクセスを許可しないように構成されている場合、要求はアプリに到達しません。 このため、[AllowAnonymous] 属性は適用できません。

匿名アクセスを許可する

Windows 認証と匿名アクセスの両方が有効になっている場合は、[Authorize] および [AllowAnonymous] 属性を使用します。 [Authorize] 属性を使用すると、認証を必要とするアプリのエンドポイントをセキュリティで保護できます。 [AllowAnonymous] 属性は、匿名アクセスを許可するアプリの [Authorize] 属性をオーバーライドします。 属性の使用法の詳細については、「ASP.NET Core での単純な承認」を参照してください。

Note

既定では、ページへのアクセスの承認がないユーザーには、空の HTTP 403 応答が表示されます。 StatusCodePages ミドルウェアは、ユーザーにより優れた "アクセス拒否" エクスペリエンスを提供するように構成できます。

偽装

ASP.NET Core では、権限の借用は実装されません。 アプリは、アプリ プールまたはプロセス identity を使用して、すべてのリクエストに対してアプリの identity で実行されます。 アプリがユーザーに代わってアクションを実行する必要がある場合は、Program.cs の ターミナル インライン ミドルウェア で WindowsIdentity.RunImpersonated または RunImpersonatedAsync を使用します。 このコンテキストで 1 つのアクションを実行し、コンテキストを閉じます。

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity!;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        await WindowsIdentity.RunImpersonatedAsync(user.AccessToken, async () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            await context.Response.Body.WriteAsync(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Microsoft.AspNetCore.Authentication.Negotiate パッケージでは Windows、Linux、macOS での認証が有効ですが、権限の借用は Windows でのみサポートされます。

要求の変換

IIS でホストする場合、ユーザーを初期化するために内部で AuthenticateAsync が呼び出されることはありません。 そのため、認証のたびに要求を変換するための IClaimsTransformation 実装は既定で有効になっていません。 要求変換の詳細について、および要求変換をアクティブにするコード例については、「インプロセスおよびアウトプロセス ホスティングの相違点」を参照してください。

その他のリソース

• dotnet publish
• IIS を使用した Windows での ASP.NET Core のホスト
• IIS の ASP.NET Core モジュール (ANCM)
• ASP.NET Core アプリを配置するための Visual Studio 発行プロファイル (.pubxml)