1. Comparaison entre Kerberos et NTLM :
Le protocole Kerberos V5 est plus sécurisé, plus flexible et plus efficace que le protocole NTLM. Les avantages offerts par l’authentification Kerberos sont les suivants :
Authentification déléguée:
Les services Windows empruntent l’identité d’un client lorsqu’ils accèdent à des ressources pour le compte de ce client. Dans de nombreux cas, un service peut effectuer son travail pour le client en accédant aux ressources de l’ordinateur local. Les protocoles NTLM et Kerberos V5 fournissent les informations dont un service a besoin pour emprunter l’identité de son client localement. Toutefois, certaines applications distribuées sont conçues de telle sorte qu’un service frontal est obligé d’emprunter l’identité des clients lorsqu’il accède à des services principaux sur d’autres ordinateurs. Le protocole Kerberos V5 comprend un mécanisme de proxy qui permet à un service d’emprunter l’identité de son client lorsqu’il se connecte à d’autres services. Il n’existe aucun équivalent avec le protocole NTLM.
Interopérabilité:
L’implémentation par Microsoft du protocole Kerberos V5 est basée sur des spécifications normatives faisant l’objet de recommandations auprès du groupe de travail IETF. Par conséquent, l’implémentation Windows du protocole Kerberos V5 pose les bases d’une interopérabilité avec les autres réseaux où le protocole Kerberos V5 est utilisé à des fins d’authentification.
Authentification plus efficace auprès des serveurs:
Avec l’authentification NTLM, un serveur d’applications doit se connecter à un contrôleur de domaine afin d’authentifier chaque client. En revanche, avec le protocole d’authentification Kerberos V5, le serveur n’est pas obligé d’accéder à un contrôleur de domaine. À la place, le serveur peut authentifier le client en examinant les informations
19
d’identification présentées par le client. Les clients peuvent obtenir des informations d’identification pour un serveur particulier, puis réutiliser ces informations d’identification tout au long d’une session ouverte sur le réseau. Les tickets de session renouvelables remplacent l’authentification directe.
Authentification mutuelle:
À l’aide du protocole Kerberos, chacune des parties situées à chaque extrémité d’une connexion réseau peut vérifier que la partie distante est bien l’entité qu’elle prétend être.
Bien que le protocole NTLM permette aux serveurs de vérifier les identités de leurs clients, NTLM ne permet pas aux clients de vérifier l’identité d’un serveur. Par ailleurs, NTLM ne permet pas non plus à un serveur de vérifier l’identité d’un autre serveur. L’authentification NTLM a été conçue pour un environnement réseau dans lequel les serveurs sont considérés comme authentiques. Le protocole Kerberos V5 n’utilise pas ce genre d’hypothèse.
2. Correctifs et Personnalisations introduits par Microsoft :
Augmentation de la taille de mémoire tampon du jeton de contexte SSPI Kerberos Lorsque les applications cherchent à déterminer la taille maximale de mémoire tampon du jeton de contexte d’authentification afin de pouvoir préallouer de la mémoire, leur authentification peut échouer lorsque le message Kerberos ou le message de négociation retourné est plus grand que prévu.
Quels avantages cette modification procure-t-elle ?
L’augmentation de la taille par défaut de cette mémoire tampon évite un plus grand nombre d’échecs de demande d’authentification des applications en raison d’une limitation de l’espace.
En quoi le fonctionnement est-il différent ?
Dans Windows Server 2012 et Windows 8, il a été conseillé d’augmenter la taille de mémoire tampon du jeton de contexte SSPI Kerberos par défaut pour définir cette valeur au-delà de 48 000 octets.
Centre de distribution de clés avec événements d’avertissement pour les tickets Kerberos de grande taille
Le nouveau paramètre de stratégie de modèle d’administration du centre de distribution de clés Événements d’avertissement pour les tickets Kerberos de grande taille vous permet de contrôler les événements d’avertissement système consignés par un centre de distribution de clés lorsque des tickets délivrés durant l’authentification Kerberos sont proches ou supérieurs à une taille de valeur de seuil configurée. Les avertissements relatifs à la taille des tickets correspondent à l’ID d’événement 31 dans le journal système.
En quoi le fonctionnement est-il différent ?
Toutefois, vous devez prendre en compte certaines considérations pour fixer ce seuil d’avertissement. S’il est trop élevé, les avertissements ne sont pas émis avant les échecs d’authentification en raison de la taille de mémoire tampon du jeton de contexte d’authentification qui est plus importante que prévu. S’il est trop faible, l’augmentation des
20
entrées de journal rend l’analyse plus difficile. La taille doit être définie selon : Votre valeur de Registre MaxTokenSize personnalisée :
La taille déployée par le paramètre de stratégie de groupe Définir la taille maximale de la mémoire tampon des jetons de contexte SSPI Kerberos.
Si le paramètre Événements d’avertissement pour les tickets Kerberos de grande taille n’est pas activé, la valeur de seuil est par défaut de 12 000 octets, ce qui représente le paramètre par défaut pour MaxTokenSize pour les tickets Kerberos dans Windows 7, Windows Server 2008 R2 et les versions antérieures.
Nouvelles fonctionnalités et fonctionnalités modifiées pour les professionnels de l’informatique
Prise en charge par la filiale de l’authentification des ressources externes à la filiale : Dans Windows 7, lorsque l’utilisateur se connectait à l’aide d’une carte à puce avec un groupe mappé, le groupe était perdu lorsque l’utilisateur se connectait à des ressources en dehors de la filiale. Un périphérique exécutant Windows 8 dans une filiale utilise un contrôleur de domaine du concentrateur exécutant Windows Server 2012 pour obtenir un ticket TGT (Ticket-Granting Ticket). Il utilise le ticket TGT pour demander des tickets de service pour des ressources en dehors de la filiale. Aucune configuration n’est requise pour utiliser cette fonctionnalité.
Prise en charge des revendications, de l’authentification composée et du blindage Kerberos :
Si vous souhaitez créer un contrôle d’accès basé sur les revendications et l’authentification composée, vous devez déployer le contrôle d’accès dynamique. Cela nécessite une mise à niveau vers les clients Kerberos et l’utilisation du centre de distribution de clés, qui prennent en charge ces nouveaux types d’autorisation. Avec Windows Server 2012, il n’est pas nécessaire d’attendre que tous les contrôleurs de domaine et le niveau fonctionnel de domaine soient mis à niveau pour tirer parti des nouvelles options de contrôle d’accès.
Pour plus d’informations sur le contrôle d’accès dynamique dans Windows Server 2012, voir Contrôle d’accès dynamique : vue d’ensemble des scénarios et les rubriques connexes.
Quels avantages cette modification procure-t-elle ?
Vous pouvez créer un contrôle d’accès basé sur les revendications et l’authentification composée.
En quoi le fonctionnement est-il différent ?
Le nouveau paramètre de stratégie de modèle d’administration du centre de distribution de clés Prise en charge du centre de distribution de clés pour les revendications, l’authentification composée et le blindage Kerberos vous permet de configurer un contrôleur de domaine de façon à prendre en charge les revendications et l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos à l’aide de l’authentification Kerberos. Ce paramètre de stratégie est configuré sur l’unité d’organisation du contrôleur de domaine.
Lorsque le paramètre Pris en charge (ou supérieur) est configuré, les contrôleurs de domaine
21
exécutant Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008 signalent la prise en charge par le domaine des revendications et de l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos. Aucun contrôleur de domaine exécutant Windows Server 2003 ne peut se trouver dans un domaine qui prend en charge les revendications et l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos.
En outre, le paramètre de stratégie de modèle d’administration Prise en charge par le client Kerberos des revendications, de l’authentification composée et du blindage Kerberos vous permet de configurer des périphériques exécutant Windows 8 pour prendre en charge les revendications et l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos à l’aide de l’authentification Kerberos. L’authentification des périphériques exécutant Windows 8 échoue si aucun contrôleur de domaine exécutant Windows Server 2012 n’est trouvé. Il est important de s’assurer qu’il existe suffisamment de contrôleurs de domaine exécutant Windows Server 2012 pour tous les comptes, références et domaines de ressources qui sont pris en charge.