4. Mise en place de l'authentification dans le cadre d'une publication
4.1 Introduction au mécanisme d'authentification
La mise en place d'un système d'authentification permet
d'augmenter fortement le niveau de sécurité global d'une entreprise et ce à tout
niveau (authentification pour l'accès au partages de fichiers, pour l'accès
Internet, pour l'accès au réseau sans fil, pour l'accès VPN...). Malheureusement cet aspect est
trop souvent négligé (notamment sur les réseaux sans fil où les méthodes
d'authentification i802.11x sont rarement implémentées). Conscient de ce
problème, Microsoft tente de sensibiliser les administrateurs à ce sujet et
essaye de faciliter la mise en place de l'authentification au sein de ses
produits. ISA Server 2006 intègre d'ailleurs de nombreuses nouveautés en
terme d'authentification comme...
-
Le support de l'authentification basée sur les
formulaire
-
Le support de l'authentification Active Directory - LDAP
-
L'ouverture de session unique (SSO)
-
Etc.
4.2 Intégration de l'authentification basées sur les formulaires
ISA Server 2004 implémente une méthode d'authentification
nommée OWA Forms-based permettant d'authentifier les clients Outlook
Web Access directement au niveau du serveur ISA plutôt qu'au niveau du
serveur Exchange. Ce concept d'authentification par formulaire Web a été
largement amélioré au sein d'ISA Server 2006. En effet, il est dorénavant
possible d'utiliser ce système sur n'importe quel site Web (HTTP / HTTPs)
sans aucune contrainte. Le gros avantage est bien sur de pouvoir authentifier
les utilisateurs directement au niveau du serveur ISA ce qui améliore les
performances et évite de gaspiller de la bande passante. La capture d'écran
ci-dessous présente l'interface Web d'authentification utilisée par défaut avec
ISA Server 2006 :
A l'instar d'Outlook Web Access, deux modes de connexions
sont proposées selon le type de machine utilisée : ordinateur privé ou ordinateur
public/partagé. Lorsque le paramètre "ordinateur public ou partagé"
est utilisée, aucune information confidentielle (sous la forme de cookie par
exemple) n'est conservée sur le poste client ce qui permet d'augmenter la
sécurité.
Lorsque l'administrateur souhaite utiliser l'authentification
par formulaire Web sur un ou plusieurs règles de publication, il doit aussi
sélectionner la base de compte ainsi que la méthode d'accès à cette base de
compte. Voici la listes des options actuellement disponibles :
Il est bien sur possible de modifier le formulaire par défaut de
manière à personnaliser la fenêtre d'authentification aux couleurs de
l'entreprise (comme c'est d'ailleurs le cas avec le système d'authentification
par formulaire intégré à Exchange). On peut aussi paramétrer un certain nombre d'options comme
la gestion des
cookies ou bien encore la durée de vie d'une session inactive (cette TTL peut être différente
selon que l'accès est réalisé à partir d'un ordinateur "public" ou "privé").
4.3 Implémentation de l'ouverture de session unique (SSO) sur un port d'écoute Web
Il arrive fréquemment qu'une entreprise utilise un seul
nom de domaine pour publier plusieurs sites Web internes (cela permet de
réduire les coûts car il suffit d'acheter un unique domaine DNS). Cette
fonctionnalité est fournie par l'intégration d'un système de traduction de
liens au niveau des règles de publication Web (exactement le même que celui
d'ISA 2004). La traduction de lien permet par exemple :
ISA Server 2006 va encore plus loin car il permet de
mettre en place une ouverture de session unique ou SSO (Single Sign On)
sur tous les sites Web publiés au niveau du serveur ISA ! Ainsi lorsqu'un
utilisateur a entré une fois ses informations d'indentifications, elles ne
lui sont plus demandées pour toute la durée de sa session et ce, même si il
passe d'un site Web à l'autre. Par exemple lorsqu'un utilisateur s'authentifie
sur http://site1.laboms.com, il n'a pas
besoin de se ré-authentifier pour accéder au site
http://site2.laboms.com !
|
Ce système d'ouverture de session unique n'est supporté que lorsque
l'authentification par formulaire a été choisie ! Pour l'activer, il suffit
de côcher la case Enable Single Sign On dans l'onglet SSO
du port d'écoute Web considéré.
L'administrateur doit aussi lister tous les domaines
au niveau desquels l'ouverture de session unique doit être activée !
Dans l'exemple ci-contre, le SSO est activé pour le domaine Active
Directory *.laboms.com. Cela permet aux utilisateurs du site OWA
(http://mail.laboms.com) de ne pas
avoir à se ré-authentifier lorsqu'ils accèdent au site Web
http://www.laboms.com ! |
 |
4.4 Rappels sur les différentes méthodes d'authentification intégrée à ISA 2006
Voici un récapitulatif de toutes les méthodes d'accès utilisables sur une
règle de publication avec ISA Server 2006 :
| Méthode |
Explication |
| De base |
Cette méthode envoie l’identifiant
et le mot de passe de l’utilisateur en clair sur le réseau. Il ne faut
donc jamais l’utiliser sauf si on l’utilise de concert avec le protocole
SSL (Secure Socket Layer) pour chiffrer les données ! |
| Digest |
Cette méthode est plus sécurisée que l’authentification de base car le mot de
passe est envoyé de façon hachée (cryptage non réversible). Pour fonctionner, le
protocole Digest à besoin de deux pré-requis :
- Les contrôleurs de domaine doivent exécuter Windows 2000 Server ou Windows
Server 2003
- Les contrôleurs de domaine doivent stocker les mots de passe des utilisateurs
avec un cryptage réversible (cette option est configurable dans la partie «
Configuration Ordinateur / Paramètres Windows / Paramètres de sécurité /
Stratégie de compte / Stratégie de mot de passe » d’un objet stratégie de
groupe)
L’utilisation de Digest est donc à proscrire car elle fait énormément baisser le
niveau de sécurité du domaine Active Directory (en effet les mots de passe ne
doivent pas être stockés de manière réversible).
ISA Server 2004 supporte aussi la méthode WDigest qui est une évolution de
Digest. Pour activer cette méthode, il suffit de côcher la case « Digest » et
d’utiliser uniquement des contrôleurs de domaines et des serveurs ISA sous
Windows Server 2003. L’avantage de WDigest est qu’il ne nécessite pas que les
mots de passe soient stockés de manière réversible dans Active Directory. |
| Intégrée à Windows |
Cette méthode utilise le protocole d’authentification Kerberos V5 (ou bien le
protocole NTLM). Son niveau de sécurité est élevé (il utilise le hachage des
données et propose une authentification mutuelle). Cependant il nécessite que
tous les clients utilisent Internet Explorer. Les clients pare-feu utilisent toujours l’authentification intégrée à Windows et
il n’est pas possible de modifier ce paramètre. |
| certificat numérique |
Cette méthode utilise des certificats numériques pour identifier les
utilisateurs. Pour mettre en place cette méthode, il faut donc disposer d’une
infrastructure à clés publiques ou infrastructure PKI et posséder une ou
plusieurs autorités de certification internes (des autorités de certification
commerciales peuvent éventuellement être utilisées). Un certificat de type « Utilisateur » doit être attribué à chaque utilisateur.
Ce sont les informations contenues dans ce certificat qui permettront
d’identifier l’utilisateur. Cette méthode d’authentification n’est pas
supportées par les clients du proxy Web (ni par les clients pare-feu qui
n’utilisent que l’authentification intégrée à Windows) mais elle est souvent
utilisée dans le cadre d’une publication de serveur Web (cf. section 5 sur la
publication). |
| RADIUS |
RADIUS est un protocole
d’authentification standardisé qui peut être utilisé dans de nombreux
scénarios. Ainsi il permet d’authentifier, les clients du proxy Web mais
aussi les utilisateurs VPN, les utilisateurs du réseau sans fil et les
utilisateurs externes dans le cadre d’une publication de serveur Web.
Pour que le serveur ISA utilise l’authentification RADIUS, il faut le
configurer pour pointer vers un serveur RADIUS situé dans le réseau
interne. En effet, avec cette méthode, ce n’est pas le serveur ISA qui
authentifie les clients mais le serveur RADIUS (le serveur ISA se
contente de rediriger les demandes d’authentification vers le serveur
RADIUS).
Pour augmenter la sécurité du trafic d’authentification, il est
recommandé d’utiliser IPSec pour chiffrer les données entre le serveur
ISA et le serveur RADIUS.
Lorsque l’authentification RADIUS est utilisée avec les clients du
proxy Web ou bien dans le cadre d’une règle de publication, les requêtes
sont encapsulées dans le protocole HTTP. Cela est permis par le filtre
d’authentification RADIUS (radiusauth.dll). |
| RSA SecureID |
RSA SecureID est la méthode d’authentification à deux facteurs la plus
utilisée au monde. Pour s’authentifier l’utilisateur doit utiliser un objet
qu’il possède (l’authentificateur) ainsi qu’une information qu’il connaît (un
code pin). L’authentificateur est un périphérique permettant de générer un code
utilisable une fois (on parle de clé physique) et le code pin est généralement
un numéro à 4 ou 6 chiffres connu uniquement de l’utilisateur. Cette méthode d’authentification est uniquement disponible pour les règles de
publication Web et ne s’applique pas aux règles d’accès. Contrairement aux 5
méthodes précédemment étudiées, l’authentification RSA SecureID s’active au
niveau d’un port d’écoute Web (cf. section 5). Le support de cette méthode
d’authentification spécifique est fourni par le filtre SecureID (sdisa.dll). |
| RADIUS OTP |
RADIUS OTP (pour One Time Password) est une
méthode d'authentification multifactorielle permettant d'utiliser une
carte à puce ainsi que son pin pour valider les informations
d'identification de l'utilisateur. Pour plus de renseignements, vous
pouvez consulter la RFC 1938. |
| LDAP (Active Directory) |
Cette méthode est très proche de l'authentification
intégrée à Windows. La principale différence est qu'elle peut être
utilisée pour valider les informations d'identification des comptes
stocké dans l'annuaire Active Directory même si le serveur ISA
appartient à un groupe de travail ! En effet avec l'authentification
intégrée à Windows, le serveur ISA doit impérativement être membre du
domaine. |
 Sommaire
1. Présentation du produit
1.1 Présentation d'ISA Server et bref historique
1.2 Les nouveautés offertes par ISA Server 2006
1.3 Les différentes éditions d'ISA Server 2006
1.4 L'intégration aux Appliances : un enjeu important pour l'avenir
1.5 Vers un produit plus fiable et plus complet ?
1.6 Essayez ISA Server 2006 gratuitement !
2. Déploiement d'ISA Server 2006
2.1 Configuration minimale
2.2 Installation d'ISA Server 2006 édition standard
2.3 Installation d'ISA Server 2006 édition entreprise
2.4 Les différents scénarii de mise à jour vers ISA 2006
2.5 Mise à jour vers ISA Server 2006 SE à partir d'ISA Server 2004 SE SP2
2.6 Mise à jour vers ISA Server 2006 EE à partir d'ISA Server 2004 EE SP2
3. Gestion de la publication sous ISA Server 2006
3.1 Présentation des nouveaux assistants de publication
3.2 Gestion des certificats sur les ports d'écoute Web
3.3 Gestion de la traduction de liens dans ISA 2006
3.4 Publication d'une ferme de serveurs Web
4. Mise en place de l'authentification dans le cadre d'une publication
4.1 Introduction au mécanisme d'authentification
4.2 Intégration de l'authentification basées sur les formulaires
4.3 Implémentation de l'ouverture de session unique (SSO) sur un port
d'écoute Web
4.4 Rappels sur les différentes méthodes d'authentification intégrée à ISA
2006
5. Déploiement d'ISA Server 2006 dans un site distant
5.1 Problématique du déploiement d'ISA Server 2004 EE dans un site distant
5.2 Déploiement automatisé d'ISA Server 2006 SE/EE dans un site distant
5.3 Procédure de déploiement pas-à-pas d'un serveur ISA 2006 dans un site
distant
5.4 Intégration des nouveautés du Service Pack 2 d'ISA Server 2004
6. Protection de l'accès Web et fonctionnalités de monitoring associées
6.1 La problématique
6.2 La réduction du flood
6.3 Test des fonctionnalités de monitoring
6.4 Un produit encore en version beta...
7. Conclusion
7.1 Nos impressions sur la Beta1 d'ISA Server 2006
7.2 Que pouvons-nous attendre pour l'avenir ?
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Tout savoir sur ISA Server 2006 (Beta1 - Codename Wolverine)
