Partager via

Configurer l’authentification de MQTT broker

  • Article

Important

Opérations Azure IoT Préversion avec Azure Arc est actuellement en préversion. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Lorsqu’une version en disponibilité générale sera publiée, vous devrez déployer une nouvelle installation d’Opérations Azure IoT. Vous ne pourrez pas mettre à niveau une installation en préversion.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

MQTT broker prend en charge plusieurs méthodes d’authentification pour les clients, et vous pouvez configurer chaque écouteur pour qu’il ait son propre système d’authentification avec des ressources BrokerAuthentication. Pour obtenir la liste des paramètres disponibles, consultez la référence de l’API d’authentification Broker.

Les règles suivantes s’appliquent à la relation entre BrokerListener et BrokerAuthentication :

  • Chaque BrokerListener peut avoir plusieurs ports. Chaque port peut être lié à une ressource BrokerAuthentication.
  • Chaque BrokerAuthentication peut prendre en charge plusieurs méthodes d’authentification à la fois.

Pour lier un BrokerListener à une ressource BrokerAuthentication, spécifiez le champ authenticationRef dans le paramètre ports de la ressource BrokerListener. Pour en savoir plus, consultez Ressource BrokerListener.

Ressource BrokerAuthentication par défaut

Opérations Azure IoT (préversion) déploie une ressource BrokerAuthentication par défaut nommée default liée à l’écouteur par défaut dans l’espace de noms azure-iot-operations. Elle est configurée pour utiliser uniquement des jetons de compte de service (SAT) Kubernetes pour l’authentification.

Important

La méthode d’authentification du jeton de compte de service (SAT) dans la ressource BrokerAuthentication par défaut est requise pour que les composants des opérations Azure IoT fonctionnent correctement. Évitez de mettre à jour ou de supprimer la ressource BrokerAuthentication par défaut.

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Dans la liste des stratégies d’authentification, sélectionnez le nom de la stratégie par défaut.

    Capture d’écran montrant l’affichage de la stratégie d’authentification de l’Agent MQTT par défaut dans le portail Azure.

Pour ajouter de nouvelles méthodes d’authentification, sélectionnez Ajouter une méthode.

Flux d’authentification

L’ordre des méthodes d’authentification dans le tableau détermine comment MQTT broker authentifie les clients. MQTT broker tente d’authentifier les informations d’identification du client à l’aide de la première méthode spécifiée, et parcourt le tableau jusqu’à ce qu’il trouve une correspondance ou atteigne la fin.

Pour chaque méthode, MQTT broker vérifie d’abord si les informations d’identification du client sont pertinentes pour cette méthode. Par exemple, l’authentification SAT nécessite un nom d’utilisateur commençant par K8S-SAT, et l’authentification X.509 nécessite un certificat client. Si les informations d’identification du client sont pertinentes, MQTT broker vérifie ensuite si elles sont valides. Pour plus d’informations, consultez la section Configurer la méthode d’authentification.

Pour l’authentification personnalisée, MQTT broker traite l’échec de la communication avec le serveur d’authentification personnalisé comme des informations d’identification non pertinentes. Ce comportement permet à MQTT broker de revenir à d’autres méthodes si le serveur personnalisé est inaccessible.

Le flux d’authentification se termine lorsque :

  • L’une de ces conditions est vraie :
    • Les informations d’identification du client sont pertinentes et valides pour l’une des méthodes.
    • Les informations d’identification du client ne sont pertinentes pour aucune des méthodes.
    • Les informations d’identification du client sont pertinentes mais non valides pour l’une des méthodes.
  • MQTT broker accorde ou refuse l’accès au client en fonction du résultat du flux d’authentification.

Avec plusieurs méthodes d’authentification, MQTT broker a un mécanisme de secours. Par exemple :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...
    - method: X509
      x509Settings:
        # ...

L’exemple précédent spécifie Custom et SAT. Lorsqu’un client se connecte, MQTT broker tente d’authentifier le client à l’aide des méthodes spécifiées dans l’ordre suivant : Custom, puis SAT.

  1. MQTT broker vérifie si les informations d’identification du client sont valides pour l’authentification personnalisée. Étant donné que l’authentification personnalisée s’appuie sur un serveur externe pour déterminer la validité des informations d’identification, le répartiteur considère toutes les informations d’identification pertinentes pour l’authentification personnalisée et les transfère au serveur d’authentification personnalisé.
  2. Si le serveur d’authentification personnalisé répond avec le résultat Pass ou Fail, le flux d’authentification se termine. Toutefois, si le serveur d’authentification personnalisé n’est pas disponible, MQTT broker revient aux méthodes spécifiées restantes, la méthode SAT étant la suivante.
  3. MQTT broker tente d’authentifier les informations d’identification en tant qu’informations d’identification SAT. Si le nom d’utilisateur MQTT commence par K8S-SAT, MQTT broker évalue le mot de passe MQTT en tant que SAT.

Si le serveur d’authentification personnalisé n’est pas disponible et que toutes les méthodes suivantes ont déterminé que les informations d’identification fournies ne sont pas pertinentes, le répartiteur refuse la connexion cliente.

Configurer la méthode d'authentification

Vous pouvez ajouter des méthodes d’authentification telles que X.509, SAT ou personnalisées aux stratégies d’authentification.

Pour ajouter une méthode d’authentification à une stratégie :

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Choisissez une stratégie d’authentification existante ou créez-en une.

  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.

  6. Choisissez le type de méthode dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.

    Capture d’écran montrant l’ajout d’une stratégie d’authentification de l’Agent MQTT dans le portail Azure.

Pour en savoir plus sur chacune des options d’authentification, consultez les sections suivantes pour chaque méthode.

Pour plus d’informations sur l’activation des paramètres sécurisés en configurant un coffre Azure Key Vault et en activant les identités de charge de travail, consultez Activer les paramètres sécurisés dans un déploiement Opérations Azure IoT (préversion).

X.509

Un certificat d’autorité de certification racine approuvé est requis pour valider le certificat client. Les certificats clients doivent enracinés dans cette autorité de certification pour que MQTT broker puisse les authentifier. Les clés EC et RSA sont prises en charge, mais tous les certificats de la chaîne doivent utiliser le même algorithme de clé. Si vous importez vos propres certificats d’autorité de certification, vérifiez que le certificat client utilise le même algorithme de clé que les autorités de certification. Pour importer un certificat racine qui peut être utilisé pour valider les certificats clients, importez le certificat PEM en tant que ConfigMap sous la clé client_ca.pem. Par exemple :

kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations

Pour vérifier que le certificat d’autorité de certification racine est correctement importé, exécutez kubectl describe configmap. Le résultat montre le même encodage base64 du fichier de certificat PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
<Certificate>
-----END CERTIFICATE-----


BinaryData
====

Enfin, une fois que le certificat d’autorité de certification racine du client approuvé et le mappage de certificat à attribut sont importés, activez l’authentification du client X.509 en l’ajoutant en tant qu’une des méthodes d’authentification dans le cadre d’une ressource BrokerAuthentication liée à un écouteur compatible TLS.

Attributs de certificat pour l’autorisation

Les attributs X.509 peuvent être spécifiés dans la ressource BrokerAuthentication et ils sont utilisés pour autoriser les clients en fonction de leurs propriétés de certificat. Les attributs sont définis dans le champ authorizationAttributes.

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Choisissez une stratégie d’authentification existante ou créez-en une.

  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.

  6. Choisissez le type de méthode X.509 dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.

    Capture d’écran montrant la définition de la méthode d’authentification X.509 pour l’Agent MQTT dans le portail Azure.

Dans cet exemple, chaque client disposant d’un certificat émis par l’autorité de certification racine CN = Contoso Root CA Cert, OU = Engineering, C = US ou une autorité de certification intermédiaire CN = Contoso Intermediate CA reçoit les attributs répertoriés. En outre, le ventilateur intelligent reçoit des attributs spécifiques à celui-ci.

La correspondance pour les attributs commence toujours à partir du certificat client de nœud terminal, puis est acheminée le long de la chaîne. L’affectation d’attributs s’arrête après la première correspondance. Dans l’exemple précédent, même si smart-fan a le certificat intermédiaire CN = Contoso Intermediate CA, il n’obtient pas les attributs associés.

Des règles d’autorisation peuvent être appliquées aux clients utilisant des certificats X.509 avec ces attributs. Pour plus d’informations, consultez Autoriser les clients qui utilisent l’authentification X.509.

Connecter le client mosquitto à MQTT broker avec un certificat client X.509

Un client tel que mosquitto a besoin de trois fichiers pour pouvoir se connecter à MQTT broker avec l’authentification du client TLS et X.509. Par exemple :

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem

Dans l’exemple :

  • Le paramètre --cert spécifie le fichier PEM du certificat client.
  • Le paramètre --key spécifie le fichier PEM de clé privée du client.
  • Le troisième paramètre --cafile est le plus complexe : la base de données de certificats approuvée, utilisée à deux fins :
    • Lorsque le client mosquitto se connecte à MQTT broker via TLS, il valide le certificat de serveur. Il recherche les certificats racines dans la base de données pour créer une chaîne approuvée vers le certificat de serveur. Pour cette raison, le certificat racine du serveur doit être copié dans ce fichier.
    • Quand MQTT broker demande un certificat client au client mosquitto, il nécessite également une chaîne de certificats valide à envoyer au serveur. Le paramètre --cert indique à mosquitto quel certificat envoyer, mais ce n’est pas suffisant. MQTT broker ne peut pas vérifier ce certificat seul, car il a également besoin du certificat intermédiaire. Mosquitto utilise le fichier de base de données pour générer la chaîne de certificats nécessaire. Pour prendre en charge ce problème, le cafile doit contenir à la fois les certificats intermédiaires et racines.

Comprendre le flux d’authentification du client X.509 MQTT broker

Diagramme du flux d’authentification du client X.509.

Voici les étapes du flux d’authentification du client :

  1. Lorsque l’authentification du client X.509 est activée, le client se connectant doit présenter son certificat client et tous les certificats intermédiaires pour permettre à MQTT broker de générer une chaîne de certificats enracinée dans l’un de ses certificats approuvés configurés.
  2. L’équilibreur de charge dirige la communication vers l’un des répartiteurs front-end.
  3. Une fois que le répartiteur front-end a reçu le certificat client, il tente de générer une chaîne de certificats qui est enracinée dans l’un des certificats configurés. Le certificat est requis pour l’établissement d’une liaison TLS. Si le répartiteur front-end a correctement créé une chaîne et que la chaîne présentée est vérifiée, il termine l’établissement d’une liaison TLS. Le client qui se connecte est en mesure d’envoyer des paquets MQTT au front-end via le canal TLS généré.
  4. Le canal TLS est ouvert, mais l’authentification ou l’autorisation du client n’est pas encore terminée.
  5. Le client envoie ensuite un paquet CONNECT à MQTT broker.
  6. Le paquet CONNECT est routé à nouveau vers le serveur front-end.
  7. Le serveur front-end collecte toutes les informations d’identification présentées par le client jusqu’à présent, telles que les champs nom d’utilisateur et mot de passe, les données d’authentification à partir du paquet CONNECT et la chaîne de certificats client présentée lors de l’établissement d’une liaison TLS.
  8. Le serveur front-end envoie ces informations d’identification au service d’authentification. Le service d’authentification vérifie à nouveau la chaîne de certificats et collecte les noms d’objet de tous les certificats de la chaîne.
  9. Le service d’authentification utilise ses règles d’autorisation configurées pour déterminer les attributs dont disposent les clients qui se connectent. Ces attributs déterminent les opérations que le client peut exécuter, y compris le paquet CONNECT lui-même.
  10. Le service d’authentification retourne la décision au répartiteur front-end.
  11. Le répartiteur front-end connaît les attributs du client et s’il est autorisé à se connecter. Si c’est le cas, la connexion MQTT est terminée et le client peut continuer à envoyer et recevoir des paquets MQTT déterminés par ses règles d’autorisation.

Jetons de compte de service Kubernetes

Les jetons de compte de service (SAT) Kubernetes sont des JSON Web Tokens associés à des comptes de service Kubernetes. Les clients présentent des SAT à MQTT broker pour s’authentifier eux-mêmes.

MQTT broker utilise des jetons de compte de service liés qui sont détaillés dans le billet Ce que les utilisateurs de GKE doivent savoir sur les nouveaux jetons de compte de service Kubernetes. Voici les principales fonctionnalités de la publication :

Lancés dans Kubernetes 1.13 et devenus le format par défaut dans la version 1.21, les jetons liés répondent à toutes les fonctionnalités limitées des jetons traditionnels, et plus encore :

  • Les jetons eux-mêmes sont plus difficiles à voler et à utiliser à mauvais escient. Ils sont limités dans le temps, limités à l’audience et limités à l’objet.
  • Ils adoptent un format standardisé : OpenID Connect (OIDC), avec détection OIDC complète, ce qui permet aux fournisseurs de services de les accepter plus facilement.
  • Ils sont distribués aux pods de manière plus sécurisée, à l’aide d’un nouveau type de volume projeté Kubelet.

Le répartiteur vérifie les jetons à l’aide de l’API de révision des jetons Kubernetes. Activez la fonctionnalité TokenRequestProjection Kubernetes pour spécifier audiences (par défaut depuis la version 1.21). Si cette fonctionnalité n’est pas activée, les SAT ne peuvent pas être utilisés.

Création d’un compte de service

Pour créer des SAT, commencez par créer un compte de service. La commande suivante crée un compte de service appelé mqtt-client.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Ajouter des attributs pour l’autorisation

Les clients qui s’authentifient via SAT peuvent éventuellement faire annoter leurs SAT avec des attributs à utiliser avec des stratégies d’autorisation personnalisées. Pour plus d’informations, consultez Autoriser les clients qui utilisent des jetons de compte de service Kubernetes.

Activer l’authentification par jeton de compte de service (SAT)

Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier ServiceAccountToken comme méthode d’authentification valide. Le audiences spécifie la liste des audiences valides pour les jetons. Choisissez des valeurs uniques qui identifient le service MQTT broker. Vous devez spécifier au moins une audience, et tous les SAT doivent correspondre à l’une des audiences spécifiées.

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.
  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.
  3. Sélectionnez l’onglet Authentification.
  4. Choisissez une stratégie d’authentification existante ou créez-en une.
  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.
  6. Choisissez le type de méthode SAT Kubernetes dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.

Capture d’écran montrant la définition de la méthode d’authentification SAT pour l’Agent MQTT dans le portail Azure.

Tester l’authentification SAT

L’authentification SAT doit être utilisée à partir d’un client dans le même cluster que MQTT broker. Seuls les champs d’authentification améliorée sont autorisés. Définissez la méthode d’authentification sur K8S-SAT et les données d’authentification sur le jeton.

La commande suivante spécifie un pod qui a le client mosquitto et monte le SAT créé dans les étapes précédentes dans le pod.

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
spec:
  serviceAccountName: mqtt-client
  containers:
  - image: efrecon/mqtt-client
    name: mqtt-client
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: mqtt-client-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: mqtt-client-token
    projected:
      sources:
      - serviceAccountToken:
          path: mqtt-client-token
          audience: my-audience
          expirationSeconds: 86400

Ici, le champ serviceAccountName de la configuration du pod doit correspondre au compte de service associé au jeton utilisé. En outre, le champ serviceAccountToken.audience de la configuration du pod doit être l’un des audiences configurés dans la ressource BrokerAuthentication.

Une fois le pod créé, démarrez un interpréteur de commandes dans le pod :

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

Dans l’interpréteur de commandes du pod, exécutez la commande suivante pour publier un message sur le répartiteur :

mosquitto_pub --host aio-broker --port 18883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)

Le résultat doit être semblable à ce qui suit :

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

Le client mosquitto utilise le jeton de compte de service monté sur /var/run/secrets/tokens/broker-sat pour s’authentifier auprès du répartiteur. Le jeton est valide pendant 24 heures. Le client utilise également le certificat d’autorité de certification racine par défaut monté sur /var/run/certs/ca.crt pour vérifier la chaîne de certificats TLS du répartiteur.

Actualiser les jetons de compte de service

Les jetons de compte de service sont valides pendant une durée limitée et configurés avec expirationSeconds. Toutefois, Kubernetes actualise automatiquement le jeton avant son expiration. Le jeton est actualisé en arrière-plan et le client a seulement besoin de le récupérer à nouveau.

Par exemple, si le client est un pod qui utilise le jeton monté en tant que volume, comme dans l’exemple tester l’authentification SAT, le dernier jeton est disponible au même chemin d’accès /var/run/secrets/tokens/mqtt-client-token. Lorsque vous effectuez une nouvelle connexion, le client peut récupérer le dernier jeton et l’utiliser pour s’authentifier. Le client doit également disposer d’un mécanisme permettant de gérer les erreurs non autorisées MQTT en récupérant le dernier jeton et en réessayant la connexion.

Authentification personnalisée

Étendez l’authentification du client au-delà des méthodes d’authentification fournies avec l’authentification personnalisée. Le service est enfichable car il peut être n’importe quoi tant qu’il respecte l’API.

Lorsqu’un client se connecte à MQTT broker et que l’authentification personnalisée est activé, MQTT broker délègue la vérification des informations d’identification du client à un serveur d’authentification personnalisé avec une requête HTTP accompagnée de toutes les informations d’identification présentées par le client. Le serveur d’authentification personnalisé répond par l’approbation ou le refus du client avec les attributs pour l’autorisation du client.

Créer un service d’authentification personnalisé

Le serveur d’authentification personnalisé est implémenté et déployé séparément de MQTT broker.

Un exemple de serveur d’authentification personnalisé et des instructions sont disponibles sur GitHub. Utilisez cet exemple en tant que modèle pour implémenter votre propre logique d’authentification personnalisée.

API

L’API entre MQTT broker et le serveur d’authentification personnalisé suit la spécification de l’API pour l’authentification personnalisée. La spécification OpenAPI est disponible sur GitHub.

HTTPS avec chiffrement TLS requis

MQTT broker envoie des requêtes contenant des informations d’identification client sensibles au serveur d’authentification personnalisée. Pour protéger ces informations d’identification, la communication entre MQTT broker et le serveur d’authentification personnalisée doit être chiffrée avec TLS.

Le serveur d’authentification personnalisée doit présenter un certificat de serveur, et MQTT broker doit disposer d’un certificat d’autorité de certification racine approuvé pour valider le certificat de serveur. Si vous le souhaitez, le serveur d’authentification personnalisée peut exiger que MQTT broker présente un certificat client pour s’authentifier lui-même.

Activer l’authentification personnalisée pour un écouteur

Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier Custom comme méthode d’authentification valide. Ensuite, spécifiez les paramètres nécessaires pour communiquer avec un serveur d’authentification personnalisé.

Cet exemple montre tous les paramètres possibles. Les paramètres exacts requis dépendent des exigences de chaque serveur personnalisé.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Désactiver l’authentification

Pour les tests, vous pouvez désactiver l’authentification pour un port d’écouteur d’agent. La désactivation de l’authentification n’est pas recommandée pour les environnements de production.

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.
  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.
  3. Sélectionnez l’écouteur d’agent que vous souhaitez modifier dans la liste.
  4. Sur le port pour lequel vous souhaitez désactiver l’authentification, sélectionnez Aucune dans la liste déroulante d’authentification.

Déconnexion du client après l’expiration des informations d’identification

MQTT broker déconnecte les clients à l’expiration de leurs informations d’identification. La déconnexion après l’expiration des informations d’identification s’applique à tous les clients qui se connectent aux front-ends MQTT broker, notamment :

  • Les clients authentifiés avec des SAT se déconnectent lorsque leur SAT expire
  • Les clients authentifiés avec X.509 se déconnectent lorsque leur certificat client expire
  • Les clients authentifiés avec une authentification personnalisée se déconnectent en fonction de l’heure d’expiration retournée par le serveur d’authentification personnalisée.

Lors de la déconnexion, la connexion réseau du client est fermée. Le client ne reçoit pas de paquet MQTT DISCONNECT, mais le répartiteur enregistre un message indiquant qu’il a déconnecté le client.

Les clients MQTT v5 authentifiés avec des SAT et une authentification personnalisée peuvent se réauthentifier avec de nouvelles informations d’identification avant l’expiration de leurs informations d’identification initiales. Les clients X.509 ne peuvent pas se réauthentifier et doivent rétablir la connexion, car l’authentification est effectuée au niveau de la couche TLS.

Les clients peuvent se réauthentifier en envoyant un paquet AUTH MQTT v5.

Les clients SAT envoient un client AUTH avec les champs method: K8S-SAT, data: <token>. Les clients d’authentification personnalisée définissent la méthode et le champ de données en fonction des exigences du serveur d’authentification personnalisée.

La réauthentification réussie met à jour l’expiration des informations d’identification du client avec l’heure d’expiration de ses nouvelles informations d’identification, et le répartiteur répond avec un paquet Success AUTH. En cas d’échec d’authentification dû à des problèmes temporaires, le répartiteur répond avec un paquet ContinueAuthentication AUTH. C’est le cas par exemple en cas d’indisponibilité du serveur d’authentification personnalisée. Le client peut réessayer ultérieurement. Les autres échecs d’authentification entraînent l’envoi d’un paquet DISCONNECT par le répartiteur, et la fermeture de la connexion réseau du client.

Contenu connexe