Authentification Kerberos natif

Kerberos natif réalise une authentification transparente pour l’utilisateur, pour tout utilisateur ou service utilisant une machine membre d'un royaume Kerberos. L'utilisateur est authentifié à chaque requête.

Tout utilisateur connu du royaume Kerberos sera authentifié, cependant, pour que les politiques (ainsi que les quotas, l'outrepassement, etc) puissent être appliquées, il faut que les utilisateurs soient synchronisés dans l'Olfeo. Les utilisateurs non synchronisés seront authentifiés et pourront accéder à internet, mais ils seront considérés comme des utilisateurs inconnus et le moteur leur appliquera la politique par défaut.

Kerberos natif ne nécessite pas d'annuaire, seulement une infrastructure Kerberos indépendante. Vous pouvez par exemple l'utiliser pour offrir un service de proxy identifiant, pour des utilisateurs appartenant à un royaume qui ne fait pas partie de leur réseau, par exemple, une plateforme hébergée.

Modes d'intégration compatibles

L'authentification Kerberos peut uniquement être utilisée en mode proxy explicite. En effet, dans les autres modes d'intégration, le navigateur ne communique pas directement avec le proxy.

Contraintes et limitations

L'authentification Kerberos est un mécanisme fort, qui présente de fortes contraintes :

L'authentification Kerberos présente un coût cryptographique important (ressources CPU). Un épuisement des ressources CPU se traduit par un grand nombre d'échecs d'authentification, ainsi que de gros ralentissements de surf pour les utilisateurs authentifiés.
Un royaume Kerberos est nécessaire (implémentation MIT ou Heimdal).
L'authentification Kerberos n'est compatible avec Internet Explorer qu'à partir de la version 7.
Au niveau des postes client, c'est le FQDN du proxy qui doit être renseigné, et non son adresse IP.
Pour que l'authentification Kerberos fonctionne, l'Olfeo doit être synchronisé avec le même serveur NTP que l'ensemble du royaume Kerberos (utilisateurs, éléments d'infrastructure Kerberos : KDC, AS...). Voir Connecter votre Olfeo à un serveur NTP.
Pour faire de la répartition de charge entre des machines Olfeo demandant une authentification Kerberos, utilisez un proxy.pac.

Mettre en place une authentification Kerberos natif

À la page Proxy avancé > HTTP > Authentification, dans la liste Méthode d'authentification, sélectionnez Kerberos (natif). La page affiche les options correspondantes.
Renseignez le fichier keytab, le nom du royaume Kerberos, et le serveur associé (hostname ou adresse IP du KDC de votre royaume Kerberos). Pour plus d'informations, référez-vous à la documentation de votre implémentation de Kerberos.
Si besoin, modifiez le nombre de processus d'authentification instanciés dans le champ Nombre d'instances. Le nombre d'instances correspond au nombre de demandes d'authentification qui peuvent être traitées en parallèle à un instant donné.
Dans la section Règles, définissez les cas dans lesquels une authentification sera demandée ou non.
- Ajoutez une règle grâce au bouton .
- Définissez des critères :
  - Sources : définissez les plages d'adresses IP concernées par la règle.
  - User-Agent : utilisez ce paramètre pour désactiver l'authentification auprès du proxy HTTP pour certains types d'applications clientes incapables de s'authentifier (lecteur audio/vidéo...). Définissez une expression rationnelle sur l'en-tête User-agent de la requête. Attention, toutes les requêtes n'incluent pas cet en-tête (le navigateur peut avoir été paramétré pour l'omettre). Pour ajouter un user-agent, utilisez la dernière ligne du tableau.
  - Ports du proxy : la règle ne s'appliquera qu'aux flux reçus sur le port spécifié. La liste propose tous les ports qui ne sont pas en interception (en effet, l'interception ne tolère pas l'authentification).
  - Destination : la règle s'appliquera uniquement aux requêtes à destination de ces domaines. Vous pouvez indiquer des URLs spécifiques grâce à une expression rationnelle, ou bien utiliser des listes d'URL ou des listes de domaines existantes.
  - Authentification : définissez si dans le cas décrit par la règle, le proxy doit demander une authentification ou non.
- Si besoin, modifiez l'ordre des règles grâce aux flèches et . Le proxy évaluera les règles une par une de haut en bas : assurez-vous qu'aucune règle n'en bloque une autre. Par exemple, positionnez une règle désactivant l'authentification pour la mise à jour d'un serveur applicatif avant une règle demandant l'authentification des utilisateurs du serveur, sinon les mises à jour seront bloquées.
Sous la liste de règles, dans la liste Par défaut, définissez le comportement à adopter pour les requêtes ne correspondant à aucune des règles. (Pas d'authentification, ou Authentification).
Cliquez sur le bouton Valider pour enregistrer les changements.