Partager via

Au cœur de SharePoint

  • Article

À l'aide de Kerberos pour l'authentification SharePoint

Pav Cherny

Bien que SharePoint offre plusieurs options d'authentification et les zones de l'authentification, les deux options principales pour les implémentations de l'entreprise dans les scénarios intranet sont NTLM et Kerberos. Ces deux protocoles sont utilisés avec l'authentification Windows intégrée dans un schéma de stimulation/réponse classique. NTLM s'appuie sur IIS génère un jeton avec un défi, envoi au client, le client répond avec un jeton et un contrôleur de domaine validant cette réponse. NTLM exige des noms d'utilisateur et mots de passe est crypté avant qu'ils sont transmis et également requiert une réauthentification (un nouveau jeton) lors de l'accès à une ressource réseau. Kerberos, d'autre part, repose sur un système de gestion des tickets où un client et un serveur d'accès, une autorité approuvée, appelée un centre de distribution (clés), qui répond aux demandes des clients et accorde des tickets le client peut utiliser pour accéder aux ressources réseau. Kerberos ne nécessite pas la réauthentification pour accéder à plusieurs ressources.

Grande partie de la documentation des préconise l'utilisation de NTLM, sauf s'il existe un besoin intéressant, telles que pour contrat de niveau de service de sites avec une sécurité élevée. Même dans ce cas, si vous creuser un peu plus, la réponse plus évidente est présentée pour l'utilisation de NTLM : Il est plus facile à mettre en œuvre, ne requiert aucune des étapes supplémentaires nécessaires et probablement réduit les problèmes de prise en charge. Par exemple : KB 832769 indique, “ … ou si vous ne pouvez pas configurer le nom principal de service (SPN), choisissez l'authentification NTLM. Si vous choisissez l'authentification Kerberos et que vous ne pouvez pas configurer le SPN, seuls les administrateurs du serveur va pouvoir s'authentifier sur le site SharePoint. ” Les directives sont techniquement précis, mais il semble suggérer que la configuration des noms principaux de service est trop complexe ou que vous devez rester de Kerberos, sauf si une personne vous apporte l'implémenter. Mais la réalité est que si vous comprenez les principes, mise en œuvre de Kerberos n'est pas autrement difficile.

Il existe de nombreuses bonnes raisons de raison pour laquelle vous devez passer à Kerberos ou utiliser Kerberos à partir du début dans une nouvelle implémentation, mais dans la plupart des cas, qu'il se résume à performances ou de sécurité. Mesure que les complexités de charge ou la topologie utilisateur, NTLM peut introduire des problèmes de performances, car l'authentification NTLM, par nature, nécessite plusieurs allers-retours entre IIS et un contrôleur de domaine pour de nombreux scénarios de l'utilisation de SharePoint, tel qu'une application Web accès à un composant WebPart SharePoint ou un service Web personnalisé. Le risque de problèmes de performances est particulièrement vrai si le contrôleur de domaine est accessible via une liaison lente ou à latence élevée. En termes de sécurité, un système basé sur le ticket (Kerberos) avec la délégation explicite des ressources du réseau est plus sûr par conception qu'uniquement le cryptage des informations d'identification de l'utilisateur. Il est également plus rapide car il utilise un ticket unique pour accéder aux ressources réseau multiples.

Beaucoup d'installations démarrer avec NTLM au lieu de Kerberos, car l'intention de topologies, dimensionnement des serveurs, les fournisseurs de prise en charge de la sécurité (SSP) et d'autres informations déjà semblent décourageante et compliquer encore plus semble il sera trop à gérer. Cette réservation a sa justification. Après tout, les implémentations Kerberos ne sont pas exempts de problèmes. Il vous suffit de rechercher dans les articles de la base de connaissances Microsoft 871179, 962943, et 832769 pour certains problèmes possibles, qui peut être aussi graves qu'une erreur stop sur fond bleu. Même existant comme documentation, le guide détaillé de la mise en œuvre de Kerberos à partir de Microsoft, ne comprend pas plus d'informations sur IIS version 7, laquelle implémentent une fonctionnalité d'authentification en mode noyau et de modifier le traitement des noms principaux de service. Mais ne vous inquiétez pas, si vous comprenez les concepts fondamentaux de la façon dont SharePoint utilise Kerberos, il est relativement simple à implémenter et à configurer. Cet article couvre les composants d'architecture essentielle et inclut des détails de configuration pour vous aider à démarrer. Microsoft a déjà publié documentation avec des détails pas à pas et des articles de la base de connaissances 832769 and 953130 que vous pouvez utiliser pour référence supplémentaire.

L'authentification des composants et dépendances

Démarrez Let’s en examinant les dépendances dans l'architecture de SharePoint qui traitent de l'authentification Windows intégrée. Au niveau de la plus simple, avec NTLM ou Kerberos, il est un client effectuant des demandes en un .aspx SharePoint page Web qui utilise .NET et IIS en arrière-plan. La page repose à son tour sur les données de la configuration de SQL Server et des bases de données de contenu. Les manière IIS traite les requêtes dans le contexte de SharePoint 2007 ont trait à l'authentification est illustrée à la 1 figure . Lorsqu'un navigateur client effectue une demande Web, il initie un thread dans IIS et objets relatif à la demande, telles que le jeton de l'objet IIdentity, qui est contenu dans l'objet IPrincipal, sont attachés au thread. Par programme, les objets IIdentity et IPrincipal sont accessibles via la propriété HttpContext.User et les objets et la propriété sont définies par les modules d'authentification qui font partie du pipeline .NET, comme dans 1 figure .

 

Figure 1 composants communs d'authentification et de flux de données dans SharePoint

Le processus suivant décrit en détail le flux de données :

  1. Un navigateur client établit une connexion à un serveur frontal SharePoint (géré par IIS avec .NET) par l'intermédiaire d'une demande HTTP GET comme anonyme.
  2. Si la zone est configurée pour l'accès anonyme (par exemple, pour les scénarios Internet), IIS continue à traiter la demande. Dans le cas contraire, IIS renvoie une erreur 401.2 et demande l'authentification à partir du navigateur client.
  3. Le navigateur client reçoit la demande et, en fonction de la zone et les options associées, authentifie le client. Une méthode courante consiste en appelant AcquireCredentialsHandle et inviter à entrer un nom d'utilisateur/mot de passe et en passant ensuite un jeton d'authentification vers SharePoint via IIS.
  4. IIS attend une réponse dans la conversation HTTP puis accepte le jeton d'authentification et autorise ou refuse l'accès. À ce stade, IIS transmet la demande à SharePoint par l'intermédiaire de .NET.
  5. Si la page demandée a un composant qui doit accéder aux bases de données SQL back-end, SharePoint s'authentifie auprès du serveur SQL Server et accède aux bases de données. La nature de l'authentification SQL varie selon les options de configuration. Par exemple, vous pouvez configurer l'authentification SQL Server ou l'authentification Windows intégrée à l'aide de NTLM ou Kerberos. Je traite les spécificités de Kerberos et NTLM plus loin dans cet article.

La clé retenir des mécanismes d'authentification dans SharePoint est que les trois couches jouent un rôle : le navigateur client, IIS avec .NET et SQL Server. Pour retourner une page .aspx compilées, l'authentification et autorisation avoir lieu entre le client ainsi qu'entre IIS et SQL Server. Parfois le processus est simplifié, par exemple, lorsque l'utilisation de NTLM dans un scénario où SQL Server réside sur le même serveur physique que IIS. Dans ce cas, il est uniquement un saut unique à partir du client aux services Internet (IIS). Pour plus d'informations sur l'authentification dans .NET, consultez Expliquées : Authentification Windows dans ASP.NET 2.0.

NTLM et Kerberos

Maintenant que nous avons have abordé le mécanisme sous-jacent utilisé par Windows Server, IIS et .NET dans authentification et autorisation des utilisateurs, let’s examiner comment qui intègre le contexte de l'authentification Windows intégrée avec NTLM et Kerberos. Comme nous l'avons déjà mentionné, la différence essentielle entre NTLM et Kerberos est qu'alors que NTLM utilise un mécanisme de stimulation/réponse nécessitant l'authentification et autorisation pour accéder à chaque ressource réseau, Kerberos utilise un système de ticket qui authentifie une fois et puis autorise via la délégation. Ne vous inquiétez pas si cette différence semble floue, que j'aborderai ensuite les détails. Figure 2 indique la manière dont SharePoint gère les requêtes lorsque vous utilisez NTLM.

 

Figure 2 authentification NTLM dans SharePoint

Comme l'indique figure 2 , à l'aide de NTLM requiert un contrôleur de domaine qui est capable d'authentifier les utilisateurs. Si le domaine fonctionne en mode natif, par défaut, un catalogue global est nécessaire sur le contrôleur de domaine ou sur un autre serveur. Cela est encore un autre problème de performances potentiel, en plus de la préoccupation double saut, parce qu'après contacter un contrôleur de domaine, il l'authentification proxy demande à un serveur de catalogue global si le catalogue global n'est pas disponible localement. Des liaisons lentes, cela permet d'utiliser une grande quantité de ressources et la largeur de bande. Vous pouvez essayer d'insérer d'améliorer les performances avec l'authentification NTLM, comme en modifiant la valeur de l'entrée de Registre MaxConcurrentApi, mais il ne résout pas le besoin fondamental dans NTLM s'appuient sur un jeu de stimulation/réponse et performances associés émet charge élevée.

Les détails de l'authentification NTLM pour les comptes dans le même domaine sont les suivantes :

  1. Le processus démarre comme mentionné précédemment, lorsqu'un navigateur client établit une connexion à un serveur SharePoint IIS .NET à l'aide d'une demande HTTP GET et tente d'authentifier comme anonyme.
  2. IIS refuse la demande anonyme avec une erreur 401.2 et les envoie une demande d'authentification avec NTLM (authentification WWW : NTLM).
  3. Le navigateur client reçoit la requête et appelle InitializeSecurityContext pour créer le jeton d'authentification qui inclut le domaine et nom de l'ordinateur, puis envoie le jeton d'authentification pour IIS.
  4. IIS accepte les détails et envoie une stimulation NTLM au client.
  5. Le client répond avec la réponse au défi (auth jeton à nouveau), crypté avec le mot de passe de l'utilisateur.
  6. À ce stade, IIS doit communiquer avec le contrôleur de domaine. Il envoie nom d'utilisateur du client, le défi et stimulation réponse.
  7. Le contrôleur de domaine récupère le hachage du mot de passe pour l'utilisateur et compare t pour la réponse défi, qui a été chiffrée à l'aide des informations d'identification de l'utilisateur. S'il existe une correspondance, le contrôleur de domaine retourne une authentification réussie à IIS, et IIS peut communiquer avec le navigateur client.
  8. À partir de là, l'application Web authentifie avec SQL Server et peut accéder à la base de données de contenu qui contient les données pour la page .aspx.

Si vous avez déjà essayé de configurer Kerberos dans la page Web Administration centrale pour une installation de base, vous savez qu'après avoir choisi Kerberos au lieu de NTLM, le message résultant indique pour configurer un compte de pool d'application pour autoriser explicitement le Kerberos que si le pool d'applications est en cours d'exécution dans le contexte de service réseau. Ceci est dû à la façon dont l'authentification Kerberos fonctionne dans nécessitant le SPN. Dans WSS et MOSS, une application Web est vraiment un site IIS Web affecté à un pool d'applications qui s'exécute dans le contexte d'un compte intégré ou utilisateur. Il est possible, mais pas recommandé pour affecter plusieurs sites Web à la même pool d'applications. À moins que vous effectuiez une modification, IIS utilise le compte service réseau pour les pools d'applications et non un compte de domaine unique. Toutefois, pour que Kerberos fonctionne dans SharePoint, vous devez définir un SPN unique contre le compte de pool d'application.

En pratique, communication basée sur Kerberos s'appuie sur ayant un client et un serveur capable de prendre en charge de Kerberos, KDC en tant que l'autorisateur intermédiaires et SPN. Les détails techniques sont légèrement plus complexes. Par exemple, Kerberos nécessite également qu'un DNS intégré à Active Directory ou de BIND avec les enregistrements SRV, TCP/IP et un service de temps. Il est probable qu'est, si l'utilisation de Windows Server 2003 ou 2008 avec DNS intégré, déjà les composants nécessaires sont et suffit de les configurer. Figure 3 affiche les différents composants impliqués et le flux de données dans l'authentification basée sur Kerberos dans SharePoint.

 


Figure 3 authentification Kerberos

  1. Comme avec NTLM, un navigateur client effectue une demande HTTP GET qu'anonyme à l'aide d'un nom ordinateur hôte (nom de domaine complet ou alias).
  2. Un serveur frontal envoie une erreur 401.2 et la WWW-Authenticate : Négocier en-tête et/ou la WWW-Authenticate : En-tête de Kerberos, qui indique qu'il prend en charge l'authentification Kerberos. Vous devez configurer ceci explicitement sur les serveurs frontaux dans Administration centrale, comme je traite ultérieurement.
  3. Le client contacte le KDC sur le contrôleur de domaine et demande un ticket pour le SPN selon ce que le navigateur client envoyé en tant que le nom d'hôte.
  4. Si le KDC localise un SPN correspondant, il crypte le ticket et le renvoie.
  5. Le navigateur client crée l'authentificateur et l'envoie avec le ticket de service au serveur IIS qui décrypte le ticket à son tour, détermine l'identité et contrôles des autorisations (liste de contrôle d'accès) pour la ressource demandée pour voir si l'accès est autorisé.
  6. Si l'accès est autorisé, IIS, via le service Web Application, contacts du serveur SQL Server et le service demande un ticket pour SQL Server à partir du KDC.
  7. Si un nom principal de service est trouvé, le KDC renvoie le ticket, l'application Web utilise à interroger la base de données de contenu et via la délégation emprunte l'identité de l'utilisateur.
  8. Le serveur SQL Server vérifie le ticket à partir de l'application Web et le valide. Lors de la réussite, SQL Server envoie les données sur le serveur, et .NET pouvez compiler la page aspx et l'envoyer au navigateur.

Compréhension SPN

SPN garantissent l'un des aspects plus difficiles de la configuration de Kerberos, car ils sont enregistrés avec le centre de distribution de clés comme identificateurs uniques pour les ressources client autorisés à accéder aux ressources de serveur spécifique. Clients et serveurs de l'authentification Windows intégrée par nature confiance le KDC car dans la plupart des cas, il est également d'un contrôleur de domaine et le KDC a besoin d'une méthode pour déterminer s'il faut accorder un ticket pour une demande ou non — et c'est le nom principal de service. Comme nous l'avons déjà mentionné, lorsque vous définissez un compte d'utilisateur de domaine pour un pool d'applications, vous devez également définir un SPN sur lui pour que tous les utilisateurs d'accéder à l'application Web associée au pool d'application.

Un SPN est une chaîne d'identificateur unique pour un service qui s'exécute sur un serveur. Il est stocké dans Active Directory dans l'attribut à valeurs multiples d'un compte d'utilisateur appelé Service Principal Name . Plusieurs services sur un ordinateur hôte ou de plusieurs hôtes sont distinguent par leurs noms principaux de service unique. Peut-être je suis overemphasizing l'importance des noms principaux de service, mais il est pour une bonne raison. Configuré de manière incorrecte SPN saut l'authentification Kerberos. Si vous définissez deux SPN identiques ou que vous oubliez de définir un nom SPN ou misconfigure une partie d'un nom principal de service, l'authentification ne fonctionne pas.

Let’s examiner un exemple d'un SPN pour voir comment Kerberos les utilise. Un SPN est composé de trois parties : la classe de service qui identifie le type de service, nom de l'ordinateur d'ordinateur hôte sur lequel le service s'exécute et le port. Assembler les composants, la syntaxe est la classe de service de / ordinateur hôte : port. Pour SharePoint, les noms pertinents deux sont HTTP et MSSqlSvc. Les noms de service ne sont pas arbitraires et définis comme alias spécifiques pour un service. La partie de nom ordinateur hôte est le nom FQDN ou NetBIOS, vous pouvez également y compris le port. Lors de l'enregistrement de noms principaux de service, il est conseillé d'inscrire un nom principal de service pour les noms d'ordinateur hôte à la fois NetBIOS et FQDN afin qu'indépendamment de l'utilisation de clients de méthode, ils peuvent accéder aux ressources sur l'ordinateur hôte cible.

Précédemment, je mentionné qui sauf si vous exécutez un pool d'applications sous le compte service réseau, vous besoin d'inscrire explicitement des noms principaux de service. Cela est dû au fait que lorsqu'un ordinateur rejoint un domaine active directory, les SPN sont automatiquement créées pour le compte d'ordinateur dans le format HOST / < NetBIOSname > et HOST / < FQDN > . Étant donné que le compte service réseau agit comme un ordinateur sur le réseau, les noms principaux de service sont valides pour elle. Toutefois, il n'est pas une meilleure solution consiste à utiliser le compte service réseau local pour des raisons de sécurité et parce qu'elle peut interrompre certains scénarios. Par exemple, si vous restaurez ou attacher une base de données contenu a été configuré avec le compte service réseau, vous devez ajoutez le compte au groupe Administrateurs sur le serveur SQL Server et puis la supprimez à nouveau après avoir attaché la base de données. La plupart de la documentation existante recommande l'utilisation de comptes de domaine.

Configuration de back-end

Vous devez d'abord configurer l'authentification Kerberos sur SQL Server que vous passer d'une batterie existante ou installer un nouveau. Le serveur SQL Server doit satisfaire aux exigences déjà mentionnés, tels que qui est joint au domaine, avoir accès à un contrôleur de domaine qui est également un KDC et ainsi de suite. Dans la plupart des environnements, ces conditions sont remplies par défaut lorsque vous utilisez Active Directory avec DNS intégré. Il est inutile de configurer explicitement Kerberos si votre environnement utilise uniquement les serveurs frontaux SharePoint et aucun serveurs d'applications, tels que ceux exécutant les services de Excel ou SQL Reporting Services. La valeur par défaut que SPN créé lorsque le serveur SQL Server est joint au domaine est suffisant pour la base connectivité front-end/back-end.

Configuration de Kerberos est relativement simple sur SQL Server. Tout d'abord, vous définissez les noms principaux de service approprié, puis vérifiez que Kerberos est utilisé et pas la valeur par défaut NTLM. Il est conseillé de définir le nom NetBIOS et le nom de domaine complet dans le format MSSQLSvc/<NetBIOS_Name>:1433 et MSSQLSvc//<FQDN hostname.domain.local>:1433, en supposant que votre instance utilise le port 1433 par défaut. Bien que vous pouvez utiliser l'outil setspn ou ADSIEdit pour définir les noms principaux de service, setspn est souvent un meilleur choix car il valide la syntaxe de votre entrée pour vous assurer qu'il est correct. Avec ADSIEdit, en revanche, vous écrivez les noms principaux de service dans l'attribut de servicePrincipalName directement. Pour créer les deux noms principaux de service, exécutez setspn-A MSSQLSvc/<NetBIOS_Name>:1433 <domain>\<username> et setspn-A MSSQLSvc/<FQDNe>:1433 <domain>\<username>, où le nom d'utilisateur est le compte de service SQL Server.

Pour confirmer que le trafic de SQL Server est à l'aide de Kerberos, vous pouvez suivre le trafic avec un analyseur de paquets tels que Wireshark, utilisez un outil tel que Kerbtray.exe ou consultez les journaux d'événements. Si vous vous connectez à l'instance SQL à l'aide de SQL Server Management Studio, le journal des événements de sécurité doit s'afficher événement ID 540, dans lequel le package de processus et l'authentification d'ouverture de session utiliser Kerberos. Pour plus d'informations, consultez Configurer l'authentification Kerberos pour les communications SQL.

Configuration du serveur frontal et application

Après avoir vérifié le fonctionnement de Kerberos dans SQL Server, vous pouvez passer à configurer SharePoint en définissant des SPN pour les pools d'applications, de l'activation de Kerberos pour les fournisseurs de services et Web Applications et de certaines étapes de configuration finale. La configuration du SPN est similaire à ce que vous faire pour le compte de service SQL Server, mais il n'y a beaucoup plus SPN pour configurer. Rappelez-vous que SPN sont construits selon un utilisateur entre dans la barre d'adresses du navigateur client, vous devez définir SPN pour chaque entrée de l'utilisateur peut effectuer dans la barre d'adresses pour accéder à un site. Cela inclut les noms de domaine complets, noms NetBIOS et les alias sous la forme d'en-têtes ordinateur hôte. Figure 4 répertorie un exemple de types de ressources et les noms principaux de service doivent être enregistrés pour chacun d'eux.

 

Figure 4 noms principaux de service pour une batterie de base de MOSS

 

Il y a quelques choses que vous devez tenir compte de la configuration du SPN. Tout d'abord, les SPN sont inscrits pour un site Web SharePoint comme ils seraient pour n'importe quel site IIS Web. Il est important de spécifier le nom d'ordinateur hôte correcte et le compte sous lequel le pool d'applications s'exécute pour chaque site. Si vous utilisez plusieurs en-têtes ordinateur hôte, assurez-vous que SPN sont définies pour tous les. Deuxièmement, il n'est pas nécessaire de spécifier des ports pour HTTP et HTTPS, mais vous devez spécifier tout port personnalisé. Et Troisièmement, il n'y a certaines dépendances supplémentaires, que vous devrez peut-être configurer, tels qu'une modification du Registre pour les services IIS prendre en charge formant des SPN avec des ports personnalisés et une mise à jour pour prendre en charge les fournisseurs de services partagés. Vous trouverez plus de détails dans Configurer l'authentification Kerberos (Office SharePoint Server).

Il y a deux étapes principales plus que vous devez effectuer pour que Kerberos fonctionne dans l'environnement. Vous devez configurer les comptes d'ordinateurs et certains comptes de service pour la délégation et vous devez configurer votre batterie de serveurs pour Kerberos dans l'administration centrale. L'idée de délégation de Kerberos est que si un utilisateur lance une demande à une ressource finale et certains comptes intermédiaires doivent traiter la demande, puis les comptes intermédiaires peuvent être approuvés pour déléguer le nom de l'utilisateur. Vous pouvez configurer un compte pour la délégation à l'aide d'utilisateurs et ordinateurs en tant qu'administrateur de domaine. Sélectionnez approbation cet utilisateur/ordinateur pour la délégation à tous les services (Kerberos) sous l'onglet Délégation du compte utilisateur ou ordinateur. Vous devez activer la délégation pour le serveur frontal, application et des comptes d'ordinateurs SQL Server, pour les pools d'applications (SSPAdmin, MonSite, différentes applications Web) et pour le compte de service de batterie de serveurs.

En outre, vous devez définir des autorisations dans les services de composants. Dans les propriétés par défaut, affectez le niveau d'emprunt d'identité = délégué. Sous service d'administration IIS WAMREG, accédez à l'onglet sécurité et accorder des autorisations Local Activation aux comptes de pool d'application. Pour plus d'informations, consultez Ko 917409, et 920783.

Une fois que vous activez la délégation, il est temps pour encapsuler les détails de configuration en activant Kerberos comme protocole par défaut de fournisseurs de services partagés et des applications Web. Pour une nouvelle installation, cela est possible pour le site Administration centrale dans l'Assistant de configuration de technologies et produits SharePoint. Sinon, accédez à des fournisseurs d'authentification sous gestion des applications dans l'administration centrale, cliquez sur par défaut et définir la méthode pour négocier (Kerberos). Don ’t oublier d'exécuter iisreset /noforce pour appliquer les modifications aux pools d'applications et pour activer l'authentification Kerberos pour SSP .

Modifications apportées à IIS 7 et Windows Server 2008

Jusqu'ici, j'have mis la discussion principalement limitée à SharePoint 2007 sur Windows Server 2003 et IIS 6. Si vous déplacez vers Windows Server 2008 et IIS 7, il n'y a certaines modifications de l'architecture qui peut nécessiter certaines étapes de configuration supplémentaires. Par exemple le changement plus notable est que IIS 7 prend en charge l'authentification de Kerberos en mode noyau. Dans l'authentification en mode noyau, le compte service réseau (vraiment, cela revient au compte d'ordinateur déjà mentionné) décrypte les tickets, sauf indication contraire. Authentification en mode noyau est activée par défaut lorsque vous installez une nouvelle batterie ou migrez vers IIS 7. N'oubliez pas que le compte service réseau est un compte local. Si vous exécutez un serveur unique, le déchiffrement fonctionne. Dans une batterie de serveurs, toutefois, il échoue parce que vous avez besoin d'utiliser des comptes de domaine qui peuvent être vérifiées contre le KDC. Cette modification signifie également que vous pouvez faire transition de protocole (activation des clients utiliser l'authentification non Kerberos dans IIS et IIS utilise Kerberos pour la communication de back-end) en utilisant le compte service réseau, car il possède déjà des privilèges LocalSystem.

Pour configurer Kerberos dans votre batterie de serveurs SharePoint qui exécute IIS 7, vous devez modifier manuellement le fichier %WinDir%\System32\inetsrv\config\ApplicationHost.config — il n'existe actuellement aucune option d'interface utilisateur. L'entrée appropriée est comme indiqué ici.

< System.webServer >   < security >      < authentication >         < windowsAuthentication activée = "true" useKernelMode = "true" useAppPoolCredentials = "true" / >     < / authentification >   < / sécurité >< /system.webServer >

N'oubliez pas d'exécuter de iisreset /noforce de pour appliquer les modifications et rechercher les dernières mises à jour pour les problèmes, telles que mise à jour l'écran bleu détaillé dans Ko 962943.

Il existe une configuration détaillée vous devez être conscient de si votre configuration utilise l'emprunt d'identité identité (< identity impersonate = "true" / > dans web.config) et le pipeline de mode intégré. Dans ce cas, vous devez validateIntegratedModeConfiguration sur false ou d'exécuter des pages .aspx dans pipeline mode classique.

Conclusion

Même si l'authentification Kerberos comporte certaines des étapes de configuration supplémentaires et des connaissances au-delà de ce qui exige NTLM, la tendance consiste à déplacer vers Kerberos. Microsoft est extrait par défaut dans II7 compris et il est excellente prise en charge en général, car il s'agit d'une norme ouverte. À l'aide de Kerberos vaut bien de l'effort. Qu'il reste suffisamment de documentation existante pour déploiement, la vérification et le dépannage, lequel renforcer le cas pour Kerberos. Et vous n'ayez pas à apporter des modifications importantes à profiter des avantages d'atténuation des coups de performances en raison d'un nombre de sauts d'authentification excessif et à profiter de la sécurité de Kerberos.

 

Pav Cherny is un expert en informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans les services de documentation et de localisation gérés.

 

Contenu associé