Configurer l’authentification Windows dans ASP.NET Core

Par Rick Anderson et Kirk Larkin

L’authentification Windows (également appelée authentification Negotiate, Kerberos ou NTLM) peut être configurée pour les applications ASP.NET Core hébergées avec IIS, Kestrel, ou HTTP.sys.

L’authentification Windows s’appuie sur le système d’exploitation pour authentifier les utilisateurs des 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 d’identités de domaine Active Directory ou de comptes Windows pour identifier les utilisateurs. L’authentification Windows est mieux adaptée aux environnements intranet où les utilisateurs, les applications clientes et les serveurs web appartiennent au même domaine Windows.

Notes

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

Scénarios avec un proxy et un équilibreur de charge

L’authentification Windows 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é, l’authentification Windows fonctionne uniquement si le proxy ou l’équilibreur de charge :

• Gère l’authentification.
• Transmet les informations d’authentification 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 proxys et les équilibreurs de charge sont utilisés est Active Directory Federated Services (ADFS) avec OpenID Connect (OIDC).

IIS/IIS Express

Ajoutez le package NuGet Microsoft.AspNetCore.Authentication.Negotiate et les services d’authentification en appelant AddAuthentication 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 modèle ASP.NET Core Razor Pages avec l’authentification Windows 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 l’interface CLI .NET peuvent être configurés pour prendre en charge l’authentification Windows, qui met à jour le fichier Properties/launchSettings.json automatiquement.

Visual Studio

Nouveau projet

Créez une application Razor Pages ou 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 apparaît 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 Profils de lancement :

1. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet et sélectionnez Propriétés.
2. Sélectionnez l’onglet Débogage > Général et sélectionnez Ouvrir l’IU Profils de lancement de débogage.
3. Décochez la case Activer l’authentification anonyme.
4. Cochez la case Activer l’authentification Windows.

Vous pouvez également configurer les propriétés dans le nœud iisSettings du fichier launchSettings.json :

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

CLI .NET

Nouveau projet

Exécutez la commande dotnet new avec l’argument webapp (ASP.NET Core Web App) et la balise --auth Windows :

dotnet new webapp --auth Windows

Projet existant

Mettez à jour le nœud iisSettings du fichier launchSettings.json :

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

IIS

IIS utilise également 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 web.config local qui active l’authentification Windows sur le serveur lorsque l’application est déployée.
• Utilisez le Gestionnaire des services IIS pour configurer le fichier web.config d’une application ASP.NET Core qui a déjà été déployée sur le serveur.

Si ce n’est 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 Étape 2).

L’intergiciel d’intégration IIS est configuré pour authentifier automatiquement les requêtes par défaut. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS : options IIS (AutomaticAuthentication).

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 Informations de référence sur la configuration du module ASP.NET Core : 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 propriété <IsTransformWebConfigDisabled> définie sur true dans le fichier projet), le fichier web.config publié inclut la section <location><system.webServer><security><authentication>. Pour plus d’informations sur la propriété <IsTransformWebConfigDisabled>, consultez Héberger ASP.NET Core sur Windows avec IIS.

• Après avoir publié et déployé le projet, effectuez une configuration côté serveur avec le Gestionnaire des services IIS :

  1. Dans le Gestionnaire des services IIS, 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 IIS modifie le fichier web.config de l’application. Un nœud <system.webServer><security><authentication> 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 section <system.webServer> ajoutée au fichier web.config par le Gestionnaire des services IIS est en dehors de la section <location> de l’application 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 nœud <location>, les paramètres sont hérités par les sous-applications de l’application actuelle. Pour empêcher l’héritage, déplacez la section <security> ajoutée à l’intérieur de la section <location><system.webServer> fournie par le kit SDK .NET Core.

  Lorsque le Gestionnaire des services IIS est utilisé pour ajouter la configuration IIS, il affecte uniquement 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 de web.config du serveur 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 IIS pour réinitialiser les paramètres du fichier web.config après le remplacement du fichier lors du déploiement.
  • Ajoutez un fichier web.config à l’application localement avec les paramètres.

Kestrel

Le package NuGet Microsoft.AspNetCore.Authentication.Negotiate peut être utilisé avec Kestrel 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 conservées entre les requêtes sur une connexion. L’authentification Negotiate ne doit pas être utilisée avec des proxys, sauf si le proxy conserve une affinité de connexion 1:1 (connexion persistante) avec Kestrel.

Notes

Le gestionnaire Negotiate détecte si le serveur sous-jacent prend en charge l’authentification Windows en mode natif et si elle est activée. Si le serveur prend en charge l’authentification Windows, mais qu’elle est désactivée, une erreur est générée vous demandant d’activer l’implémentation du serveur. Lorsque l’authentification Windows est activée sur le serveur, le gestionnaire Negotiate lui transfère de manière transparente les demandes d’authentification.

L’authentification est activée par le code suivant mis en surbrillance pour 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 modèle ASP.NET Core Razor Pages avec l’authentification Windows spécifiée. Les API suivantes sont utilisées dans le code précédent :

• AddAuthentication
• AddNegotiate
• UseAuthentication

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 mises en évidence 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 recherche lente ou une grande quantité de mémoire utilisée pour chaque utilisateur. La résolution de domaines imbriqués peut être désactivée à l’aide de l’option IgnoreNestedGroups.

Les requêtes anonymes sont autorisées. Utilisez l’autorisation ASP.NET Core pour valider les demandes anonymes d’authentification.

Configuration de l’environnement 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 exécutant 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.

Kerberos et NTLM

Le package Negotiate sur Kestrel for ASP.NET Core tente d’utiliser Kerberos, qui est un schéma d’authentification plus sécurisé et plus performant que 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 spécifie Kerberos, car il s’agit de la valeur par défaut.

IIS, IISExpress et Kestrel prennent en charge Kerberos et NTLM.

L’examen de l’en-tête WWW-Authenticate: à l’aide d’IIS ou d’IISExpress avec un outil comme Fiddler affiche Negotiate ou NTLM.

Kestrel affiche uniquement WWW-Authenticate: Negotiate

L’en-tête WWW-Authenticate: Negotiate signifie que le serveur peut utiliser NTLM ou Kerberos. Kestrel nécessite le préfixe d’en-tête Negotiate. Il ne prend pas en charge la spécification NTLM directe dans les en-têtes d’authentification de demande ou de réponse. NTLM est pris en charge dans Kestrel, mais il doit être envoyé en tant que Negotiate.

Sur Kestrel, pour voir si NTLM ou Kerberos est utilisé, Base64 décode l’en-tête et affiche NTLM ou HTTP. HTTP indique que Kerberos a été utilisé.

Configuration de l’environnement Linux et macOS

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

Notes

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

Une fois que la machine Linux ou macOS est jointe au domaine, des étapes supplémentaires sont nécessaires pour fournir un fichier keytab avec les SPN :

• Sur le contrôleur de domaine, ajoutez de nouveaux SPN de 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 via une variable d’environnement : export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Appelez klist pour afficher les SPN actuellement disponibles.

Notes

Un fichier keytab contient des 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 à l’aide de l’authentification Negotiate, NTLM ou de base.

Le code suivant ajoute l’authentification et configure l’hôte web de l’application pour utiliser 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) (voir https://hub.docker.com/_/microsoft-windows-servercore). Pour plus d’informations sur Server Core, consultez 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 les attributs [Authorize] et [AllowAnonymous] sont utilisés dans l’application. Les deux sections suivantes expliquent comment gérer les états de configuration non autorisé et autorisé 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 attributs [Authorize] et [AllowAnonymous] n’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’attribut [AllowAnonymous] n’est pas applicable.

Autoriser l'accès anonyme

Lorsque l’authentification Windows et l’accès anonyme sont activés, utilisez les attributs [Authorize] et [AllowAnonymous]. L’attribut [Authorize] vous permet de sécuriser les points de terminaison de l’application qui nécessitent une authentification. L’attribut [AllowAnonymous] remplace l’attribut [Authorize] 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 reçoivent une réponse HTTP 403 vide. L’intergiciel StatusCodePages peut être configuré pour offrir aux utilisateurs une meilleure expérience « Accès refusé ».

Emprunt d'identité

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identity de l’application pour toutes les demandes, à l’aide d’un pool d’applications ou d’une identity de processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un middleware terminal en ligne dans Program.cs. Exécutez une seule action 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());
    }
});

Bien que le package Microsoft.AspNetCore.Authentication.Negotiate active l’authentification sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur Windows.

Transformations de revendication

Dans le cas d’un 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 un exemple de code qui active les transformations de revendications, consultez Différences entre l’hébergement in-process et out-of-process.

Ressources supplémentaires

• dotnet publish
• Héberger ASP.NET Core sur Windows avec IIS
• Module ASP.NET Core (ANCM) pour IIS
• Profils de publication Visual Studio (.pubxml) pour le déploiement d’applications ASP.NET Core