ASA Identity Firewall 8.4(2)
La version 8.4(2) de l’ASA disponible depuis juin 2011 apporte le support du filtrage statefull basé sur l’identité ou le groupe d’appartenance des utilisateurs.
La solution fonctionne en conjonction avec l’active directory de Microsoft via un agent dédié qui assure le transfert d’informations vers l’ASA.
Cette fonctionnalité est compatible avec l’ensemble de la gamme ASA du 5505 au 5585, l’agent peut être installé sur un serveur du domaine ou directement co-localisé sur le contrôleur de domaine.
La solution fonctionne dans les environnements multi-domaines, chaque ASA peut adresser 30 serveurs et jusqu’à 64 000 utilisateurs peuvent être gérés simultanément dans le cache d’un ASA.
Les ASA dialoguent directement en LDAP vers l’AD pour afficher les groupes et noms d’utilisateurs et ainsi configurer la table de filtrage (voir exemple ci-dessous)
table de filtrage de l’ASA avec champ user
Fenêtre de sélection des groupes et utilisateurs
les architectures proposées sont complètement redondante, deux agents peuvent être configurés par domaines et chacun peuvent adresser plusieurs contrôleurs de domaine :
L’identity Firewall est entièrement configurable via ASDM, un monitoring temps réel de l’activité des utilisateurs a été intégré dans l’interface graphique :
Monitoring des utilisateurs coté ASA
La solution est totalement transparente pour les utilisateurs, le simple fait de s’authentifier sur leur poste dans le domaine assure une identification coté ASA. il ne leur sera ainsi pas demandé de s’authentifier sur le Firewall.
Dans le cas d’utilisateurs extérieurs au domaine la solution propose également une possibilité d’authentification locale sur le Firewall afin d’utiliser cette nouvelle fonction d’identity Firewall.
La version 8.4.2 est disponible sur l’ensemble de la gamme ASA à l’exception de l’ASA service module
Plus d’informations sur la 8.4.2 -> http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html#wp535067
5 commentaires
J’ai envie de dire, Enfin ! 🙂
Par contre j’aimerais savoir comment fait l’ASA pour connaître quel utilisateur ouvre la connexion ? Autant pour du HTTP je comprendrais que ca utilise une authentification NTLM sur un Proxy HTTP sur l’ASA, mais là ?
Il se base sur l’IP source et vérifie si l’utilisateur s’est récemment connecté via le contrôleur de domaine sur l’ip source ? Si c’est le cas, que se passe t-il si l’utilisateur se déconnecte et qu’un autre se connecte (sans passer par le domaine donc sans notifier le DC de sa connexion) ?
Bonjour,
On utilise les évènement d’ouverture et fermeture de connexion de l’AD (via WMI), le mapping dans l’ASA se présente sous la forme d’une table User/group/IP.
Si un utilisateur tente de se connecter sans être dans le domaine, il n’y a plus de SSO et il devra s’authentifier sur le portail web de l’ASA.
La phase suivante c’est l’intégration des group tag de TrustSec, ce qui veut dire que n’importe quel utilisateur authentifié en 802.1x filaire ou Wifi se verra attribué un TAG et que ce TAG sera filtré dans l’ASA. (Béta en MARS)
cordialement
Christophe
En lisant la documentation j’ai compris que ça lisait en effet les logs de l’AD pour associer un utilisateur à un hôte/IP, mais du coup je ne vois pas le rapport avec la SSO, ça n’a pas l’air d’en être car il n’y a aucune authentification qui est faite après s’être connecté au domaine, c’est juste une sorte de table utilisateur = IP construite a partir des logs AD si j’ai bien compris ?
Dans ce cas comment l’ASA va réagir si il y a plusieurs utilisateurs connectés sur le même hôte (via RDP par exemple) ? Ou si le poste change d’IP entre temps ? (passage d’ethernet au réseau wifi pour un laptop par exemple)
A propos du portail web, celui ci est il personnalisable (fichiers HTML modifiables ? pour pouvoir éventuellement y faire une sorte de portail captif, ou bien est ce juste une authentification HTTP ?
Merci
En voilà une fonctionnalité très intéressante.
Est-ce qu’elle pourra fonctionner avec des utilisateurs connectés en VPN AnyConnect… ?
Les clients VPN sont déjà authentifiés pour l’ouverture de la connexion, et des règles spécifiques peuvent donc déjà s’appliquer. Ceci étant, si le flux VPN repasse au travers du moteur firewall, il n’y a pas de raison de ne pas pouvoir combiner les deux !