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

作成者: Rick Anderson および Kirk Larkin

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

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

注意

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

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

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

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

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

IIS/IIS Express

Program.csAddAuthentication を呼び出して、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 Core CLI を介して使用できる Web アプリケーション テンプレートは Windows 認証をサポートするように構成できます。これにより、Properties/launchSettings.json ファイルが自動的に更新されます。

新しいプロジェクト

新しい 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
    }
}

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 認証を使用することはできません。

注意

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 が使用されています。

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 を実行します。

Linux および macOS 環境の構成

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

注意

Windows 認証を使用した Azure Data Studio の SQL Server への接続 - Kerberos に関する記事のガイダンスに従う場合は、必要に応じて python-software-propertiespython3-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 を表示します。

注意

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;
        });
}

注意

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

注意

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

ユーザーの承認

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

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

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

匿名アクセスを許可する

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

注意

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

権限借用

ASP.NET Core では、権限の借用は実装されません。 アプリは、アプリ プールまたはプロセス ID を使用して、すべての要求に対してアプリの ID を指定して実行されます。 アプリがユーザーに代わってアクションを実行する必要がある場合は、Startup.Configureターミナル インライン ミドルウェア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 実装は既定で有効になっていません。 要求変換の詳細について、および要求変換をアクティブにするコード例については、「インプロセスおよびアウトプロセス ホスティングの相違点」を参照してください。

その他の技術情報

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

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

注意

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

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

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

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

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

IIS/IIS Express

Startup.ConfigureServicesAddAuthentication (Microsoft.AspNetCore.Server.IISIntegration 名前空間) を呼び出して認証サービスを追加します。

services.AddAuthentication(IISDefaults.AuthenticationScheme);

起動設定 (デバッガー)

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

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

新しいプロジェクト

  1. 新しいプロジェクトを作成します。
  2. [ASP.NET Core Web アプリケーション] を選択します。 [次へ] を選択します。
  3. [プロジェクト名] フィールドに名前を指定します。 [場所] エントリが正しいことを確認します。または、プロジェクトの場所を指定します。 [作成] を選択します。
  4. [認証][変更] を選択します。
  5. [認証の変更] ウィンドウで、[Windows 認証] を選択します。 [OK] を選択します。
  6. [Web アプリケーション] を選択します。
  7. [作成] を選択します

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

既存のプロジェクト

プロジェクトのプロパティを使用して、Windows 認証を有効にし、匿名認証を無効にします。

  1. ソリューション エクスプローラーでプロジェクトを右クリックして、 [プロパティ] を選択します。
  2. [デバッグ] タブを選択します。
  3. [匿名認証を有効にする] チェックボックスをオフにします。
  4. [Windows 認証を有効にする] チェックボックスをオンにします。
  5. プロパティ ページを保存して閉じます。

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

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

既存のプロジェクトを変更する場合は、プロジェクト ファイルに Microsoft.AspNetCore.App メタパッケージまたはMicrosoft.AspNetCore.Authentication NuGet パッケージのパッケージ参照が含まれていることを確認します。

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 認証を使用することはできません。

注意

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

Startup.ConfigureServicesAddAuthenticationAddNegotiate を呼び出して認証サービスを追加します。

// using Microsoft.AspNetCore.Authentication.Negotiate;
// using Microsoft.Extensions.DependencyInjection;

services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

Startup.ConfigureUseAuthentication を呼び出して認証ミドルウェアを追加します。

app.UseAuthentication();

ミドルウェアの詳細については、「ASP.NET Core のミドルウェア」を参照してください。

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

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

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

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

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDatabaseDeveloperPageExceptionFilter();
    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();

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

    services.AddRazorPages();
}

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

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

AuthenticationScheme には、NuGet パッケージ Microsoft.AspNetCore.Authentication.Negotiate が必要です。

Windows 環境構成

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

Linux および macOS 環境の構成

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

注意

Windows 認証を使用した Azure Data Studio の SQL Server への接続 - Kerberos に関する記事のガイダンスに従う場合は、必要に応じて python-software-propertiespython3-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 を表示します。

注意

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

HTTP.sys

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

Startup.ConfigureServicesAddAuthentication (Microsoft.AspNetCore.Server.HttpSys 名前空間) を呼び出して認証サービスを追加します。

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Windows 認証 (Program.cs) で HTTP.sys を使用するようにアプリの Web ホストを構成します。 UseHttpSys は、Microsoft.AspNetCore.Server.HttpSys 名前空間にあります。

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>()
                    .UseHttpSys(options =>
                    {
                        options.Authentication.Schemes = 
                            AuthenticationSchemes.NTLM | 
                            AuthenticationSchemes.Negotiate;
                        options.Authentication.AllowAnonymous = false;
                    });
            });
}

注意

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

注意

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

ユーザーの承認

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

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

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

匿名アクセスを許可する

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

注意

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

権限借用

ASP.NET Core では、権限の借用は実装されません。 アプリは、アプリ プールまたはプロセス ID を使用して、すべての要求に対してアプリの ID を指定して実行されます。 アプリがユーザーに代わってアクションを実行する必要がある場合は、Startup.Configureターミナル インライン ミドルウェア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");

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

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

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

要求の変換

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

その他の技術情報