configurer l’authentification Windows dans ASP.NET Core

Par Rick Anderson et Kirk Larkin

Windows l’authentification (également appelée négociation, Kerberos ou authentification NTLM) peuvent être configurées pour les applications ASP.NET Core hébergées avec IIS, ou HTTP.sys.

l’authentification Windows s’appuie sur le système d’exploitation pour authentifier les utilisateurs d’applications ASP.NET Core. l’authentification Windows est utilisée pour les serveurs qui s’exécutent sur un réseau d’entreprise à l’aide de Active Directory identités de domaine ou des comptes de Windows pour identifier les utilisateurs. Windows l’authentification est mieux adaptée aux environnements intranet où les utilisateurs, les applications clientes et les serveurs web appartiennent au même domaine de Windows.

Notes

l’authentification Windows n’est pas prise en charge avec HTTP/2. Les défis liés à l’authentification peuvent être envoyés sur les réponses HTTP/2, mais le client doit passer à la version HTTP/1.1 avant l’authentification.

Scénarios de proxy et d’équilibrage de charge

Windows l’authentification est un scénario avec état principalement utilisé dans un intranet, où un proxy ou un équilibreur de charge ne gère généralement pas le trafic entre les clients et les serveurs. si un proxy ou un équilibreur de charge est utilisé, Windows authentification fonctionne uniquement si le proxy ou l’équilibreur de charge :

  • Gère l’authentification.
  • Transmet les informations d’authentification de l’utilisateur à l’application (par exemple, dans un en-tête de demande), qui agit sur les informations d’authentification.

une alternative à l’authentification Windows dans les environnements où les proxies et les équilibrages de charge sont utilisés est Active Directory Services fédérés (ADFS) avec OpenID Connecter (OIDC).

IIS/IIS Express

Ajoutez des services d’authentification en appelant AddAuthentication ( Microsoft.AspNetCore.Server.IISIntegration espace de noms) dans 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();

le code précédent a été généré par le Razor modèle de Pages ASP.NET Core avec l' Razor spécifiée.

Paramètres de lancement (débogueur)

la Configuration des paramètres de lancement affecte uniquement le fichier Properties/launchSettings. json pour IIS Express et ne configure pas IIS pour l’authentification Windows. La configuration du serveur est expliquée dans la section IIS .

les modèles d' Application Web disponibles via Visual Studio ou le CLI .NET Core peuvent être configurés pour prendre en charge l’authentification Windows, qui met à jour automatiquement le fichier Properties/launchSettings. json .

Nouveau projet

Créez des Razor pages ou une application MVC. Dans la boîte de dialogue informations supplémentaires , définissez le type d’authentification sur Windows.

Exécutez l’application. Le nom d’utilisateur s’affiche dans l’interface utilisateur de l’application rendue.

Projet existant

les propriétés du projet activent l’authentification Windows et désactivent l’authentification anonyme. Ouvrez la boîte de dialogue lancer les profils :

  1. Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet, puis sélectionnez Propriétés.
  2. Sélectionnez l' onglet général de débogage et sélectionnez ouvrir l’interface utilisateur des profils de lancement du débogage.
  3. Désactivez la case à cocher activer l’authentification anonyme.
  4. cochez la case activer l’authentification Windows.

Les propriétés peuvent également être configurées dans le iisSettings nœud du fichier iisSettings :

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

IIS

IIS utilise le Module ASP.NET Core pour héberger des applications ASP.NET Core. l’authentification Windows est configurée pour IIS via le fichier web.config . Les sections suivantes décrivent diverses opérations :

  • fournissez un fichier de web.config local qui active l’authentification Windows sur le serveur lors du déploiement de l’application.
  • utilisez le gestionnaire des services internet pour configurer le fichier web.config d’une application ASP.NET Core qui a déjà été déployée sur le serveur.

si vous ne l’avez pas déjà fait, activez IIS pour héberger des applications ASP.NET Core. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS.

activez le Service de rôle IIS pour l’authentification Windows. pour plus d’informations, consultez activer l’authentification Windows dans les services de rôle IIS (voir l’étape 2).

L' intergiciel (middleware) d’intégration IIS est configuré pour authentifier automatiquement les demandes par défaut. pour plus d’informations, voir Host ASP.NET Core sur Windows avec iis : iis options (AutomaticAuthentication) (en anglais).

le Module ASP.NET Core est configuré pour transférer le jeton d’authentification Windows à l’application par défaut. pour plus d’informations, consultez ASP.NET Core référence de configuration du Module : attributs de l’élément aspNetCore.

Utilisez l' une des approches suivantes :

  • Avant de publier et de déployer le projet, ajoutez le fichier web.config suivant à la racine du projet :

    <?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>
    

    Lorsque le projet est publié par le kit SDK .NET Core (sans la <IsTransformWebConfigDisabled> propriété définie à true dans le fichier projet), le fichier <IsTransformWebConfigDisabled> publié comprend la <location><system.webServer><security><authentication> section. pour plus d’informations sur la <IsTransformWebConfigDisabled> propriété, consultez <IsTransformWebConfigDisabled>.

  • Après la publication et le déploiement du projet, effectuez une configuration côté serveur à l’aide du gestionnaire des services Internet :

    1. Dans le gestionnaire des services Internet, sélectionnez le site IIS sous le nœud sites de la barre latérale connexions .
    2. Double-cliquez sur authentification dans la zone IIS .
    3. Sélectionnez authentification anonyme. Sélectionnez Désactiver dans la barre latérale actions .
    4. Sélectionnez Authentification Windows. Sélectionnez activer dans la barre latérale actions .

    Lorsque ces actions sont effectuées, le gestionnaire des services Internet modifie le fichier web.config de l’application. Un <system.webServer><security><authentication> nœud est ajouté avec les paramètres mis à jour pour anonymousAuthentication et windowsAuthentication :

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

    La <system.webServer> section ajoutée au fichier <system.webServer> par le gestionnaire des services Internet est en dehors de la section de l’application <location> ajoutée par le kit SDK .net Core lors de la publication de l’application. Étant donné que la section est ajoutée en dehors du <location> nœud, les paramètres sont hérités par toutes les <location> de l’application actuelle. Pour empêcher l’héritage, déplacez la <security> section ajoutée à l’intérieur de la <location><system.webServer> section que le kit SDK .net Core fourni.

    Quand le gestionnaire des services Internet est utilisé pour ajouter la configuration IIS, il n’affecte que le fichier web.config de l’application sur le serveur. Un déploiement ultérieur de l’application peut remplacer les paramètres sur le serveur si la copie du serveur de web.config est remplacée par le fichier web.config du projet. Utilisez l' une des approches suivantes pour gérer les paramètres :

    • Utilisez le gestionnaire des services Internet pour réinitialiser les paramètres dans le fichier web.config une fois que le fichier a été remplacé lors du déploiement.
    • Ajoutez un fichierweb.config à l’application localement avec les paramètres.

Kestrel

le package Microsoft. AspNetCore. authentication. Negotiate NuGet peut être utilisé avec pour prendre en charge l’authentification Windows à l’aide de Negotiate et Kerberos sur Windows, Linux et macOS.

Avertissement

Les informations d’identification peuvent être rendues persistantes entre les demandes sur une connexion. L’authentification par négociation ne doit pas être utilisée avec les proxies, sauf si le proxy gère une affinité de connexion 1:1 (une connexion permanente) avec .

Notes

le gestionnaire Negotiate détecte si le serveur sous-jacent prend en charge Windows l’authentification en mode natif et s’il est activé. si le serveur prend en charge l’authentification Windows, mais qu’elle est désactivée, une erreur est générée pour vous demander d’activer l’implémentation du serveur. lorsque Windows authentification est activée sur le serveur, le gestionnaire Negotiate transfère de manière transparente les demandes d’authentification à celui-ci.

L’authentification est activée par le code en surbrillance suivant dans 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();

le code précédent a été généré par le Razor modèle de Pages ASP.NET Core avec l' Razor spécifiée. Les API suivantes sont utilisées dans le code précédent :

Authentification Kerberos et contrôle d’accès en fonction du rôle (RBAC)

L’authentification Kerberos sur Linux ou macOS ne fournit aucune information de rôle pour un utilisateur authentifié. Pour ajouter des informations de rôle et de groupe à un utilisateur Kerberos, le gestionnaire d’authentification doit être configuré pour récupérer les rôles à partir d’un domaine LDAP. La configuration la plus simple spécifie uniquement un domaine LDAP sur lequel interroger et utilise le contexte de l’utilisateur authentifié pour interroger le domaine 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");
        }
    });

Certaines configurations peuvent nécessiter des informations d’identification spécifiques pour interroger le domaine LDAP. Les informations d’identification peuvent être spécifiées dans les options en surbrillance suivantes :

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

Par défaut, le gestionnaire d’authentification Negotiate résout les domaines imbriqués. Dans un environnement LDAP volumineux ou complexe, la résolution des domaines imbriqués peut entraîner une lenteur de recherche ou une grande quantité de mémoire utilisée pour chaque utilisateur. La résolution de domaine imbriquée peut être désactivée à l’aide de l' IgnoreNestedGroups option.

Les demandes anonymes sont autorisées. utilisez ASP.NET Core autorisation pour défier les demandes anonymes pour l’authentification.

configuration de l’environnement de Windows

Le composant Microsoft. AspNetCore. Authentication. Negotiate effectue l’authentification en mode utilisateur . Les noms de principal du service (SPN) doivent être ajoutés au compte d’utilisateur qui exécute le service, et non au compte d’ordinateur. Exécutez setspn -S HTTP/myservername.mydomain.com myuser dans un interpréteur de commandes d’administration.

Configuration de l’environnement Linux et macOS

les Instructions permettant de joindre un ordinateur Linux ou macOS à un domaine de Windows sont disponibles dans le Connecter Azure Data Studio à votre SQL Server à l’aide de l’article authentification Windows-Kerberos . Les instructions créent un compte d’ordinateur pour la machine Linux sur le domaine. Les noms de principal du service doivent être ajoutés à ce compte d’ordinateur.

Notes

lorsque vous suivez les instructions de la Azure Data Studio Connecter à votre SQL Server à l’aide de l’article authentification-Kerberos Windows , remplacez par python3-software-properties si nécessaire.

Une fois que l’ordinateur Linux ou macOS est joint au domaine, des étapes supplémentaires sont nécessaires pour fournir un fichier keytab avec les noms de principal du service (SPN) :

  • Sur le contrôleur de domaine, ajoutez de nouveaux noms de principal du service Web au compte d’ordinateur :
    • setspn -S HTTP/mywebservice.mydomain.com mymachine
    • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
  • Utilisez Ktpass pour générer un fichier 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
    • Certains champs doivent être spécifiés en majuscules, comme indiqué.
  • Copiez le fichier keytab sur l’ordinateur Linux ou macOS.
  • Sélectionnez le fichier keytab à l’aide d’une variable d’environnement : export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
  • Appelez klist pour afficher les noms de principal du service actuellement disponibles.

Notes

Un fichier keytab contient les informations d’identification d’accès au domaine et doit être protégé en conséquence.

HTTP.sys

HTTP.sys prend en charge l’authentification Windows en Mode noyau en utilisant Negotiate, NTLM ou l’authentification de base.

le code suivant ajoute l’authentification et configure l’hôte web de l’application afin qu’il utilise HTTP.sys avec l’authentification Windows :

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

Notes

HTTP.sys délègue à l’authentification en mode noyau avec le protocole d’authentification Kerberos. L’authentification en mode utilisateur n’est pas prise en charge avec Kerberos et HTTP.sys. Le compte d’ordinateur doit être utilisé pour déchiffrer le ticket/jeton Kerberos obtenu à partir d’Active Directory et transféré par le client au serveur afin d’authentifier l’utilisateur. Inscrivez le nom de principal du service (SPN) pour l’hôte, et non l’utilisateur de l’application.

Notes

HTTP.sys n’est pas pris en charge sur nano Server version 1709 ou ultérieure. pour utiliser l’authentification Windows et HTTP.sys avec Nano Server, utilisez un conteneur Server Core (microsoft/windowsservercore). pour plus d’informations sur server core, voir qu’est-ce que l’option d’installation server core dans Windows Server ?.

Autoriser les utilisateurs

L’état de configuration de l’accès anonyme détermine la façon dont [Authorize] les [AllowAnonymous] attributs et sont utilisés dans l’application. Les deux sections suivantes expliquent comment gérer les États de configuration non autorisés et autorisés de l’accès anonyme.

Interdire l’accès anonyme

lorsque l’authentification Windows est activée et que l’accès anonyme est désactivé, les [Authorize] attributs [] (xref : Microsoft. AspNetCore. authorization. AuthorizeAttribute) et n' [AllowAnonymous] ont aucun effet. Si un site IIS est configuré pour interdire l’accès anonyme, la demande n’atteint jamais l’application. Pour cette raison, l' [AllowAnonymous] attribut n’est pas applicable.

Autoriser l’accès anonyme

lorsque les deux Windows l’authentification et l’accès anonyme sont activés, utilisez les [Authorize] attributs [] (xref : Microsoft. AspNetCore. authorization. AuthorizeAttribute) et [AllowAnonymous] . L' [Authorize] attribut [] (XREF : Microsoft. AspNetCore. Authorization. AuthorizeAttribute) vous permet de sécuriser les points de terminaison de l’application qui requièrent une authentification. L' [AllowAnonymous] attribut remplace l' [Authorize] attribut dans les applications qui autorisent l’accès anonyme. Pour plus d’informations sur l’utilisation des attributs, consultez autorisation simple dans ASP.net Core.

Notes

Par défaut, les utilisateurs qui n’ont pas l’autorisation d’accéder à une page s’affichent avec une réponse HTTP 403 vide. L' intergiciel StatusCodePages peut être configuré pour fournir aux utilisateurs une expérience de « accès refusé » améliorée.

Emprunt d'identité

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identité de l’application pour toutes les demandes, à l’aide du pool d’applications ou de l’identité du processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un intergiciel (middleware) en WindowsIdentity.RunImpersonated dans Startup.Configure . Exécutez une action unique dans ce contexte, puis fermez le contexte.

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

tandis que le package Microsoft. AspNetCore. authentication. Negotiate permet l’authentification sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur les Windows.

Transformations de revendication

Lors de l’hébergement avec IIS, AuthenticateAsync n’est pas appelé en interne pour initialiser un utilisateur. Par conséquent, une implémentation de IClaimsTransformation utilisée pour transformer les revendications après chaque authentification n’est pas activée par défaut. pour plus d’informations et pour obtenir un exemple de code qui active les transformations de revendications, consultez ASP.NET Core Module.

Ressources supplémentaires

Windows l’authentification (également appelée négociation, Kerberos ou authentification NTLM) peuvent être configurées pour les applications ASP.NET Core hébergées avec IIS, ou HTTP.sys.

l’authentification Windows s’appuie sur le système d’exploitation pour authentifier les utilisateurs d’applications ASP.NET Core. vous pouvez utiliser l’authentification Windows lorsque votre serveur s’exécute sur un réseau d’entreprise à l’aide de Active Directory identités de domaine ou Windows comptes pour identifier les utilisateurs. Windows l’authentification est mieux adaptée aux environnements intranet où les utilisateurs, les applications clientes et les serveurs web appartiennent au même domaine de Windows.

Notes

l’authentification Windows n’est pas prise en charge avec HTTP/2. Les défis liés à l’authentification peuvent être envoyés sur les réponses HTTP/2, mais le client doit passer à la version HTTP/1.1 avant l’authentification.

Scénarios de proxy et d’équilibrage de charge

Windows l’authentification est un scénario avec état principalement utilisé dans un intranet, où un proxy ou un équilibreur de charge ne gère généralement pas le trafic entre les clients et les serveurs. si un proxy ou un équilibreur de charge est utilisé, Windows authentification fonctionne uniquement si le proxy ou l’équilibreur de charge :

  • Gère l’authentification.
  • Transmet les informations d’authentification de l’utilisateur à l’application (par exemple, dans un en-tête de demande), qui agit sur les informations d’authentification.

une alternative à l’authentification Windows dans les environnements où les proxies et les équilibrages de charge sont utilisés est Active Directory Services fédérés (ADFS) avec OpenID Connecter (OIDC).

IIS/IIS Express

Ajoutez des services d’authentification en appelant AddAuthentication ( Microsoft.AspNetCore.Server.IISIntegration espace de noms) dans Startup.ConfigureServices :

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Paramètres de lancement (débogueur)

la Configuration des paramètres de lancement affecte uniquement le fichier Properties/launchSettings. json pour IIS Express et ne configure pas IIS pour l’authentification Windows. La configuration du serveur est expliquée dans la section IIS .

le modèle d' Application Web disponible via Visual Studio ou le CLI .NET Core peut être configuré pour prendre en charge l’authentification Windows, qui met à jour automatiquement le fichier Properties/launchSettings. json .

Nouveau projet

  1. Créez un projet.
  2. Sélectionnez Application web ASP.NET Core. Sélectionnez Suivant.
  3. indiquez un nom dans le champ nom de l' Project . Confirmez que l’entrée d' emplacement est correcte ou indiquez un emplacement pour le projet. Sélectionnez Créer.
  4. Sélectionnez modifier sous authentification.
  5. dans la fenêtre modifier l’authentification , sélectionnez Windows l’authentification. Sélectionnez OK.
  6. Sélectionnez application Web.
  7. Sélectionnez Créer.

Exécutez l’application. Le nom d’utilisateur s’affiche dans l’interface utilisateur de l’application rendue.

Projet existant

les propriétés du projet activent l’authentification Windows et désactivent l’authentification anonyme :

  1. Dans Explorateur de solutions , cliquez avec le bouton droit sur le projet, puis sélectionnez Propriétés.
  2. Sélectionnez l’onglet Débogage.
  3. Désactivez la case à cocher activer l’authentification anonyme.
  4. cochez la case activer l’authentification Windows.
  5. Enregistrez et fermez la page de propriétés.

Les propriétés peuvent également être configurées dans le iisSettings nœud du fichier iisSettings :

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

lors de la modification d’un projet existant, vérifiez que le fichier projet contient une référence de package pour le Microsoft.AspNetCore.Appou le package Microsoft. AspNetCore. authentication NuGet.

IIS

IIS utilise le Module ASP.NET Core pour héberger des applications ASP.NET Core. l’authentification Windows est configurée pour IIS via le fichier web.config . Les sections suivantes décrivent diverses opérations :

  • fournissez un fichier de web.config local qui active l’authentification Windows sur le serveur lors du déploiement de l’application.
  • utilisez le gestionnaire des services internet pour configurer le fichier web.config d’une application ASP.NET Core qui a déjà été déployée sur le serveur.

si vous ne l’avez pas déjà fait, activez IIS pour héberger des applications ASP.NET Core. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS.

activez le Service de rôle IIS pour l’authentification Windows. pour plus d’informations, consultez activer l’authentification Windows dans les services de rôle IIS (voir l’étape 2).

L' intergiciel (middleware) d’intégration IIS est configuré pour authentifier automatiquement les demandes par défaut. pour plus d’informations, voir Host ASP.NET Core sur Windows avec iis : iis options (AutomaticAuthentication) (en anglais).

le Module ASP.NET Core est configuré pour transférer le jeton d’authentification Windows à l’application par défaut. pour plus d’informations, consultez ASP.NET Core référence de configuration du Module : attributs de l’élément aspNetCore.

Utilisez l' une des approches suivantes :

  • Avant de publier et de déployer le projet, ajoutez le fichier web.config suivant à la racine du projet :

    <?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>
    

    Lorsque le projet est publié par le kit SDK .NET Core (sans la <IsTransformWebConfigDisabled> propriété définie à true dans le fichier projet), le fichier <IsTransformWebConfigDisabled> publié comprend la <location><system.webServer><security><authentication> section. pour plus d’informations sur la <IsTransformWebConfigDisabled> propriété, consultez <IsTransformWebConfigDisabled>.

  • Après la publication et le déploiement du projet, effectuez une configuration côté serveur à l’aide du gestionnaire des services Internet :

    1. Dans le gestionnaire des services Internet, sélectionnez le site IIS sous le nœud sites de la barre latérale connexions .
    2. Double-cliquez sur authentification dans la zone IIS .
    3. Sélectionnez authentification anonyme. Sélectionnez Désactiver dans la barre latérale actions .
    4. Sélectionnez Authentification Windows. Sélectionnez activer dans la barre latérale actions .

    Lorsque ces actions sont effectuées, le gestionnaire des services Internet modifie le fichier web.config de l’application. Un <system.webServer><security><authentication> nœud est ajouté avec les paramètres mis à jour pour anonymousAuthentication et windowsAuthentication :

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

    La <system.webServer> section ajoutée au fichier <system.webServer> par le gestionnaire des services Internet est en dehors de la section de l’application <location> ajoutée par le kit SDK .net Core lors de la publication de l’application. Étant donné que la section est ajoutée en dehors du <location> nœud, les paramètres sont hérités par toutes les <location> de l’application actuelle. Pour empêcher l’héritage, déplacez la <security> section ajoutée à l’intérieur de la <location><system.webServer> section que le kit SDK .net Core fourni.

    Quand le gestionnaire des services Internet est utilisé pour ajouter la configuration IIS, il n’affecte que le fichier web.config de l’application sur le serveur. Un déploiement ultérieur de l’application peut remplacer les paramètres sur le serveur si la copie du serveur de web.config est remplacée par le fichier web.config du projet. Utilisez l' une des approches suivantes pour gérer les paramètres :

    • Utilisez le gestionnaire des services Internet pour réinitialiser les paramètres dans le fichier web.config une fois que le fichier a été remplacé lors du déploiement.
    • Ajoutez un fichierweb.config à l’application localement avec les paramètres.

Kestrel

le package Microsoft. AspNetCore. authentication. Negotiate NuGet peut être utilisé avec pour prendre en charge l’authentification Windows à l’aide de Negotiate et Kerberos sur Windows, Linux et macOS.

Avertissement

Les informations d’identification peuvent être rendues persistantes entre les demandes sur une connexion. L’authentification par négociation ne doit pas être utilisée avec les proxies, sauf si le proxy gère une affinité de connexion 1:1 (une connexion permanente) avec .

Notes

le gestionnaire Negotiate détecte si le serveur sous-jacent prend en charge Windows l’authentification en mode natif et s’il est activé. si le serveur prend en charge l’authentification Windows, mais qu’elle est désactivée, une erreur est générée pour vous demander d’activer l’implémentation du serveur. lorsque Windows authentification est activée sur le serveur, le gestionnaire Negotiate transfère de manière transparente les demandes d’authentification à celui-ci.

Ajoutez des services d’authentification en appelant AddAuthentication et AddNegotiate dans Startup.ConfigureServices :

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

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

Ajoutez l’intergiciel (middleware) d’authentification en appelant UseAuthentication dans Startup.Configure :

app.UseAuthentication();

pour plus d’informations sur les intergiciels (middleware), consultez ASP.NET Core intergiciel (middleware).

Authentification Kerberos et contrôle d’accès en fonction du rôle (RBAC)

L’authentification Kerberos sur Linux ou macOS ne fournit aucune information de rôle pour un utilisateur authentifié. Pour ajouter des informations de rôle et de groupe à un utilisateur Kerberos, le gestionnaire d’authentification doit être configuré pour récupérer les rôles à partir d’un domaine LDAP. La configuration la plus simple spécifie uniquement un domaine LDAP sur lequel interroger et utilise le contexte de l’utilisateur authentifié pour interroger le domaine LDAP :

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

Certaines configurations peuvent nécessiter des informations d’identification spécifiques pour interroger le domaine LDAP. Les informations d’identification peuvent être spécifiées dans les options en surbrillance suivantes :

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

Par défaut, le gestionnaire d’authentification Negotiate résout les domaines imbriqués. Dans un environnement LDAP volumineux ou complexe, la résolution des domaines imbriqués peut entraîner une lenteur de recherche ou une grande quantité de mémoire utilisée pour chaque utilisateur. La résolution de domaine imbriquée peut être désactivée à l’aide de l' IgnoreNestedGroups option.

Les demandes anonymes sont autorisées. utilisez ASP.NET Core autorisation pour défier les demandes anonymes pour l’authentification.

AuthenticationSchemerequiert le package NuGet AuthenticationScheme.

configuration de l’environnement de Windows

Le composant Microsoft. AspNetCore. Authentication. Negotiate effectue l’authentification en mode utilisateur . Les noms de principal du service (SPN) doivent être ajoutés au compte d’utilisateur qui exécute le service, et non au compte d’ordinateur. Exécutez setspn -S HTTP/myservername.mydomain.com myuser dans un interpréteur de commandes d’administration.

Configuration de l’environnement Linux et macOS

les Instructions permettant de joindre un ordinateur Linux ou macOS à un domaine de Windows sont disponibles dans le Connecter Azure Data Studio à votre SQL Server à l’aide de l’article authentification Windows-Kerberos . Les instructions créent un compte d’ordinateur pour la machine Linux sur le domaine. Les noms de principal du service doivent être ajoutés à ce compte d’ordinateur.

Notes

lorsque vous suivez les instructions de la Azure Data Studio Connecter à votre SQL Server à l’aide de l’article authentification-Kerberos Windows , remplacez par python3-software-properties si nécessaire.

Une fois que l’ordinateur Linux ou macOS est joint au domaine, des étapes supplémentaires sont nécessaires pour fournir un fichier keytab avec les noms de principal du service (SPN) :

  • Sur le contrôleur de domaine, ajoutez de nouveaux noms de principal du service Web au compte d’ordinateur :
    • setspn -S HTTP/mywebservice.mydomain.com mymachine
    • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
  • Utilisez Ktpass pour générer un fichier 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
    • Certains champs doivent être spécifiés en majuscules, comme indiqué.
  • Copiez le fichier keytab sur l’ordinateur Linux ou macOS.
  • Sélectionnez le fichier keytab à l’aide d’une variable d’environnement : export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
  • Appelez klist pour afficher les noms de principal du service actuellement disponibles.

Notes

Un fichier keytab contient les informations d’identification d’accès au domaine et doit être protégé en conséquence.

HTTP.sys

HTTP.sys prend en charge l’authentification Windows en Mode noyau en utilisant Negotiate, NTLM ou l’authentification de base.

Ajoutez des services d’authentification en appelant AddAuthentication ( Microsoft.AspNetCore.Server.HttpSys espace de noms) dans Startup.ConfigureServices :

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

configurez l’hôte web de l’application pour qu’il utilise HTTP.sys avec l’authentification Windows (Program. cs). UseHttpSys se trouve dans l' Microsoft.AspNetCore.Server.HttpSys espace de noms.

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

Notes

HTTP.sys délègue à l’authentification en mode noyau avec le protocole d’authentification Kerberos. L’authentification en mode utilisateur n’est pas prise en charge avec Kerberos et HTTP.sys. Le compte d’ordinateur doit être utilisé pour déchiffrer le ticket/jeton Kerberos obtenu à partir d’Active Directory et transféré par le client au serveur afin d’authentifier l’utilisateur. Inscrivez le nom de principal du service (SPN) pour l’hôte, et non l’utilisateur de l’application.

Notes

HTTP.sys n’est pas pris en charge sur nano Server version 1709 ou ultérieure. pour utiliser l’authentification Windows et HTTP.sys avec Nano Server, utilisez un conteneur Server Core (microsoft/windowsservercore). pour plus d’informations sur server core, voir qu’est-ce que l’option d’installation server core dans Windows Server ?.

Autoriser les utilisateurs

L’état de configuration de l’accès anonyme détermine la façon dont [Authorize] les [AllowAnonymous] attributs et sont utilisés dans l’application. Les deux sections suivantes expliquent comment gérer les États de configuration non autorisés et autorisés de l’accès anonyme.

Interdire l’accès anonyme

lorsque l’authentification Windows est activée et que l’accès anonyme est désactivé, les [Authorize] attributs et n' [AllowAnonymous] ont aucun effet. Si un site IIS est configuré pour interdire l’accès anonyme, la demande n’atteint jamais l’application. Pour cette raison, l' [AllowAnonymous] attribut n’est pas applicable.

Autoriser l’accès anonyme

lorsque les deux Windows l’authentification et l’accès anonyme sont activés, utilisez les [Authorize][AllowAnonymous] attributs et. L' [Authorize] attribut vous permet de sécuriser les points de terminaison de l’application qui requièrent une authentification. L' [AllowAnonymous] attribut remplace l' [Authorize] attribut dans les applications qui autorisent l’accès anonyme. Pour plus d’informations sur l’utilisation des attributs, consultez autorisation simple dans ASP.net Core.

Notes

Par défaut, les utilisateurs qui n’ont pas l’autorisation d’accéder à une page s’affichent avec une réponse HTTP 403 vide. L' intergiciel StatusCodePages peut être configuré pour fournir aux utilisateurs une expérience de « accès refusé » améliorée.

Emprunt d'identité

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identité de l’application pour toutes les demandes, à l’aide du pool d’applications ou de l’identité du processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un intergiciel (middleware) en WindowsIdentity.RunImpersonated dans Startup.Configure . Exécutez une action unique dans ce contexte, puis fermez le contexte.

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

tandis que le package Microsoft. AspNetCore. authentication. Negotiate permet l’authentification sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur les Windows.

Transformations de revendication

Lors de l’hébergement avec IIS, AuthenticateAsync n’est pas appelé en interne pour initialiser un utilisateur. Par conséquent, une implémentation de IClaimsTransformation utilisée pour transformer les revendications après chaque authentification n’est pas activée par défaut. pour plus d’informations et pour obtenir un exemple de code qui active les transformations de revendications, consultez ASP.NET Core Module.

Ressources supplémentaires