Authentification et type d'intégration

Suivant le type d'intégration, l'Olfeo ne récupère pas les mêmes informations.

Type d'intégration	Informations récupérées
Intégration proxy	Proxy explicite : l'intégration en mode proxy explicite permet d'utiliser une méthode d'authentification forte (NTLM ou Kerberos). Si le proxy ne demande pas d'authentification, il récupère les adresses IP. Proxy en interception : l'Olfeo récupère les adresses IP. Il n'est pas possible de faire de l'authentification forte avec un proxy en interception : le navigateur n'échange pas d'informations avec le proxy, celui-ci ne peut donc pas demander d'authentification au navigateur. L'authentification est automatiquement désactivée sur un proxy en interception.
Intégration couplage/connecteur	Dans une intégration en mode couplage, si l'équipement tiers (proxy, UTM) réalise une authentification, l'identifiant de l'utilisateur sera transmis au moteur de filtrage. protocole ICAP : pour transmettre les identifiants, l'équipement tiers doit être paramétré pour fournir l'en-tête ICAP X-Client-Username ou l'en-tête HTTP X-Forwarded-User (pour les équipements transmettant les identifiants)/X-Authenticated-User (pour les équipements réalisant eux-mêmes l'authentification). Les équipements utilisant le protocole WISP (Cisco et Juniper) ne font pas d'authentification. Ils ne transmettront que l'adresse IP.
Intégration réseau	En coupure : l'Olfeo reçoit les adresses IP. Si la coupure est faite devant un proxy réalisant une authentification NTLM ou basique, l'Olfeo peut récupérer les identifiants des utilisateurs. En miroir de port : L'Olfeo peut récupérer les identifiants si on copie le trafic à destination d'un proxy explicite qui réalise de l'authentification NTLM. Si on copie le trafic à destination de la passerelle, seules les adresses IP sont récupérées.

Dans tous les cas, si un équipement situé avant l'Olfeo dans votre architecture réalise une authentification, l'Olfeo pourra recevoir l'identifiant de l'utilisateur (si l'équipement transmet cette information).

Traitement des adresses IP récupérées

Si l'Olfeo reçoit uniquement des adresses IP (et pas d'identifiants), il ne peut pas identifier les utilisateurs, l'adresse IP ne lui permettant pas de faire le lien avec la liste des utilisateurs (sauf pour les utilisateurs créés à la main pour lesquels on a renseigné une adresse IP). Pour résoudre ce problème, vous pouvez :

Utiliser un portail captif ou un mécanisme SSO Novell afin d'associer les adresses IP récupérées aux identifiants des utilisateurs. Vous pourrez ainsi appliquer une politique à n'importe quel niveau (utilisateur, groupe ou UO).
Créer les utilisateurs automatiquement à partir de leur adresse IP (autocréation par IP), et donc appliquer une politique sur le groupe ou l'UO.
Créer manuellement un utilisateur de type plage d'IPs et lui appliquer une politique.

Identifiant (et adresse IP)

Si l'Olfeo reçoit l'identifiant de l'utilisateur (si une authentification a été faite par un autre équipement avant que le flux n'arrive à l'Olfeo), il retrouve celui-ci dans la liste des utilisateurs et applique la politique correspondante.

Compatibilité entre méthodes d'authentification/identification et modes d'intégration

Comme pour les modules compatibles en fonction du mode d'intégration il faut vous référer à ce tableau en ce qui concerne l'authentification ou l'identification des utilisateurs.

	Proxy explicite	Proxy interception	Couplage	Capture du trafic		Filtrage DNS	Nomadisme
	Proxy explicite	Proxy interception	Couplage	Coupure	Copie	Filtrage DNS	Nomadisme
NTLM & Kerberos AD	OUI	NON	NON	NON	NON	NON	OUI⁽³⁾
Kerberos natif	OUI	NON	NON	NON	NON	NON	OUI⁽³⁾
LDAP basique	OUI	NON	NON	NON	NON	NON	OUI⁽²⁾
Portail captif	OUI	OUI	OUI	OUI	OUI	NON	OUI⁽²⁾
Portail captif avec NTLM	OUI	OUI	OUI	OUI	OUI	NON	OUI⁽²⁾
Portail Public (base locale)	OUI	OUI	OUI	OUI	OUI	NON	OUI⁽²⁾
SSO Novell	OUI	OUI	OUI	OUI	OUI	NON	OUI⁽²⁾
Identification (relation IP / login)	OUI	OUI	OUI	OUI	OUI	OUI⁽¹⁾	NON

Remarque :

(1) : Afin de se reposer sur une association entre l'adresse IP de l'équipement filtré et un identifiant utilisateur, l'équipement Olfeo doit etre positionné en tant que serveur DNS sur les équipements à filtrer et non en tant que relais DNS.
(2): Ce sont des mécanismes d'authentification faible. L'authentification a lieu après la première requête, puis l'Olfeo stocke la correspondance entre l'identifiant de l'utilisateur et son adresse IP. Par la suite il réalisera une identification basée sur cette adresse IP. Lorsque le nomade accède au proxy externe, c'est l'adresse IP publique de la connexion internet qui sera visible dans les logs. Ce mode de fonctionnement se limite donc à un utilisateur par adresse IP gérée.
(3): Kerberos requiert l'ouverture de certains flux réseaux entre les machines clientes et l'infrastructure d'authentification, ce qui pose des problèmes de sécurité lorsque le nomade doit s'authentifier via le proxy externe.