Comment Citrix ADC implémente Kerberos pour l’authentification des clients
Important
L’authentification Kerberos/NTLM n’est prise en charge que dans la version NetScaler 9.3 nCore ou ultérieure, et elle ne peut être utilisée que 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 KDC font partie de Windows Server. Si le Windows Server est opérationnel, cela indique que le contrôleur de domaine et le 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 Windows Kerberos.
Service d’authentification et négociation de protocoles
Une appliance Citrix ADC prend en charge l’authentification Kerberos sur les serveurs virtuels d’authentification, d’autorisation et d’authentification de gestion du trafic d’audit. Si l’authentification Kerberos échoue, le 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, le Citrix ADC tente d’utiliser le protocole Kerberos pour l’authentification, l’autorisation et l’audit et si le navigateur du client ne reçoit pas de ticket Kerberos, le Citrix ADC utilise l’authentification NTLM. Ce processus est appelé négociation.
Le client peut ne pas recevoir de ticket Kerberos dans les 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 du 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.
Authorization
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 à l’aide de la journalisation d’audit suivante :
- Piste d’audit complète de l’activité des utilisateurs finaux en matière de gestion du trafic
- SYSLOG et journalisation TCP à hautes performances
- Piste d’audit complète des administrateurs système
- Tous les événements du système
- Format de journal scriptable
Environnement pris en charge
L’authentification Kerberos ne nécessite aucun environnement spécifique sur le Citrix ADC. Le client (navigateur) doit prendre en charge l’authentification Kerberos.
Haute disponibilité
Dans une configuration haute disponibilité, seul le Citrix ADC actif rejoint le domaine. En cas de basculement, le démon Citrix ADC lwagent associe 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 déroule selon 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) de l’appliance Citrix ADC lance un défi au client.
- Pour répondre à ce défi, le client reçoit 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 sur la figure, Processus d’authentification Kerberos.)
- Le client envoie le TGT au serveur d’attribution de tickets du KDC et reçoit un ticket Kerberos. (Voir 5, 6 sur la figure, Processus d’authentification Kerberos.)
Remarque
Le processus d’authentification ci-dessus n’est pas nécessaire si le client possède déjà un ticket Kerberos dont la durée de vie n’a pas expiré. En outre, les clients tels que Web Services, .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 contient les données GSSAPI nécessaires.
- L’appliance Citrix ADC établit un contexte de sécurité entre le client et Citrix ADC. Si le Citrix ADC ne peut pas accepter les données fournies dans le ticket Kerberos, le client est invité à obtenir un autre ticket. 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 le 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, puis les transmet au démon d’authentification.
- Une authentification réussie termine l’authentification Kerberos.