Comment NetScaler 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.
NetScaler 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 NetScaler 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, NetScaler 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 politique d’authentification avec NEGOTIATE comme type d’authentification, NetScaler 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, NetScaler 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, NetScaler n’utilise pas les données présentes localement sur l’appliance NetScaler.
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 NetScaler prend en charge l’audit de l’authentification Kerberos grâce à 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 NetScaler. Le client (navigateur) doit prendre en charge l’authentification Kerberos.
Haute disponibilité
Dans une configuration à haute disponibilité, seul le NetScaler actif rejoint le domaine. En cas de basculement, le démon NetScaler lwagent associe l’appliance NetScaler secondaire au domaine. Aucune configuration spécifique n’est requise pour cette fonctionnalité.
Processus d’authentification Kerberos
La figure suivante montre un processus typique d’authentification Kerberos dans l’environnement NetScaler.
Figure 1. Processus d’authentification Kerberos sur NetScaler
L’authentification Kerberos se déroule selon les étapes suivantes :
Le client s’authentifie auprès du KDC
- L’appliance NetScaler reçoit une demande d’un client.
- Le serveur virtuel de gestion du trafic (équilibrage de charge ou commutation de contenu) de l’appliance NetScaler envoie 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 NetScaler. Le jeton SPNEGO contient les données GSSAPI nécessaires.
- L’appliance NetScaler établit un contexte de sécurité entre le client et NetScaler. Si NetScaler 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 NetScaler agit comme un proxy HTTP entre le client et le serveur physique.
L’appliance NetScaler 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.