Comment Citrix ADC implémente Kerberos pour l’authentification client
Important
L’authentification Kerberos/NTLM est prise en charge uniquement dans la version NetScaler 9.3 nCore ou ultérieure, et elle peut être utilisée uniquement pour l’authentification, l’autorisation et l’audit des serveurs virtuels de gestion du trafic.
Citrix ADC gère les composants impliqués dans l’authentification Kerberos de la manière suivante :
Centre de distribution de clés (KDC)
Dans Windows 2000 Server ou versions ultérieures, le contrôleur de domaine et le contrôleur de domaine KDC font partie du serveur Windows. Si Windows Server est opérationnel et en cours d’exécution, il indique que le contrôleur de domaine et le contrôleur de domaine KDC sont configurés. Le KDC est également le serveur Active Directory.
Remarque
Toutes les interactions Kerberos sont validées avec le contrôleur de domaine Kerberos Windows.
Service d’authentification et négociation de protocole
Une appliance Citrix ADC prend en charge l’authentification Kerberos sur les serveurs virtuels d’authentification, d’autorisation et d’audit de gestion du trafic. Si l’authentification Kerberos échoue, Citrix ADC utilise l’authentification NTLM.
Par défaut, Windows 2000 Server et les versions ultérieures de Windows Server utilisent Kerberos pour l’authentification, l’autorisation et l’audit. Si vous créez une stratégie d’authentification avec NEGOTIATE comme type d’authentification, Citrix ADC tente d’utiliser le protocole Kerberos pour l’authentification, l’autorisation et l’audit et si le navigateur du client ne parvient pas à recevoir un ticket Kerberos, l’ADC Citrix utilise l’authentification NTLM. Ce processus est appelé négociation.
Le client peut ne pas recevoir de ticket Kerberos dans l’un des cas suivants :
- Kerberos n’est pas pris en charge sur le client.
- Kerberos n’est pas activé sur le client.
- Le client se trouve dans un domaine autre que celui du KDC.
- Le répertoire d’accès sur le KDC n’est pas accessible au client.
Pour l’authentification Kerberos/NTLM, Citrix ADC n’utilise pas les données présentes localement sur l’appliance Citrix ADC.
Autorisation
Le serveur virtuel de gestion du trafic peut être un serveur virtuel d’équilibrage de charge ou un serveur virtuel de commutation de contenu.
Audit
L’appliance Citrix ADC prend en charge l’audit de l’authentification Kerberos avec l’enregistrement d’audit suivant :
- Trail d’audit complet de l’activité de l’utilisateur final de gestion du trafic
- SYSLOG et enregistrement TCP hautes performances
- Trail d’audit complet des administrateurs système
- Tous les événements système
- Format de journal scriptable
Environnement pris en charge
L’authentification Kerberos n’a besoin d’aucun environnement spécifique sur Citrix ADC. Le client (navigateur) doit fournir la prise en charge de l’authentification Kerberos.
Haute disponibilité
Dans une configuration haute disponibilité, seul Citrix ADC actif rejoint le domaine. En cas de basculement sur incident, le démon Citrix ADC lwagent joint l’appliance Citrix ADC secondaire au domaine. Aucune configuration spécifique n’est requise pour cette fonctionnalité.
Processus d’authentification Kerberos
La figure suivante illustre un processus typique d’authentification Kerberos dans l’environnement Citrix ADC.
Figure 1. Processus d’authentification Kerberos sur Citrix ADC
L’authentification Kerberos se produit dans les étapes suivantes :
Le client s’authentifie auprès du KDC
- L’appliance Citrix ADC reçoit une demande d’un client.
- Le serveur virtuel de gestion du trafic (équilibrage de charge ou commutation de contenu) sur l’appliance Citrix ADC envoie un défi au client.
- Pour répondre au défi, le client obtient un ticket Kerberos.
- Le client envoie au serveur d’authentification du KDC une demande de ticket d’octroi de tickets (TGT) et reçoit le TGT. (Voir 3, 4 dans la figure, Processus d’authentification Kerberos.)
- Le client envoie le TGT au serveur d’octroi de tickets du KDC et reçoit un ticket Kerberos. (Voir 5, 6 dans la figure, Processus d’authentification Kerberos.)
Remarque
Le processus d’authentification ci-dessus n’est pas nécessaire si le client dispose déjà d’un ticket Kerberos dont la durée de vie n’a pas expiré. En outre, les clients tels que les services Web, .NET ou J2EE, qui prennent en charge SPNEGO, obtiennent un ticket Kerberos pour le serveur cible, créent un jeton SPNEGO et insèrent le jeton dans l’en-tête HTTP lorsqu’ils envoient une requête HTTP. Ils ne passent pas par le processus d’authentification du client.
Le client demande un service.
- Le client envoie le ticket Kerberos contenant le jeton SPNEGO et la requête HTTP au serveur virtuel de gestion du trafic sur le Citrix ADC. Le jeton SPNEGO a les données GSSAPI nécessaires.
- L’appliance Citrix ADC établit un contexte de sécurité entre le client et le Citrix ADC. Si Citrix ADC ne peut pas accepter les données fournies dans le ticket Kerberos, le client est invité à obtenir un ticket différent. Ce cycle se répète jusqu’à ce que les données GSSAPI soient acceptables et que le contexte de sécurité soit établi. Le serveur virtuel de gestion du trafic sur Citrix ADC agit comme un proxy HTTP entre le client et le serveur physique.
L’appliance Citrix ADC termine l’authentification.
- Une fois le contexte de sécurité terminé, le serveur virtuel de gestion du trafic valide le jeton SPNEGO.
- À partir du jeton SPNEGO valide, le serveur virtuel extrait l’ID utilisateur et les informations d’identification GSS et les transmet au démon d’authentification.
- Une authentification réussie termine l’authentification Kerberos.