Simple and secure by Design but Business compliant [Benoît SAUTIERE / MVP]

Simple, yes, Secure Maybe, by design for sure, Business compliant always

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

DirectAccess en mode Selected Servers

DirectAccess, c’est pas la première fois que j’en parle sur ce blog, j’en ai déjà beaucoup parlé. Pour preuve, il suffit de consulter le nuage de Tags DirectAccess. Pourtant, il reste encore des choses à voir. Par exemple : le mode Selected Server.

 

Pour illustrer mon propos, voila l’interface de configuration DirectAccess UAG sur le sujet. Jusqu’à maintenant, on a tous coché la case d’option “Require end-to-Edge authentication and encryption”, ce qui signifie que tous les tunnels se terminaient au niveau du serveur Microsoft Forefront Unified Access Gateway 2010.

9

Pourtant le mode “Require-end-to-end authentication and encryption to specified applications servers” mérite qu’on s’attarde un peu sur lui. Prenons un cas concret avec ma maquette pour les Exatechdays à Lyon:

Maquette

Cela ressemble à du DirectAccess classique implémenté avec UAG et NAP. Cependant, j’ai ajouté deux serveurs applicatifs (Web-Server et File-Server) pour démontrer l’intérêt du mode “Selected Servers”. Concrètement, mon serveur “APP2.Exatechdays.Local” est bien accessible de l’extérieur mais avec la mise en place d’un tunnel IPSEC additionnel. Cette fois, le tunnel se termine donc sur le serveur visé et non sur le serveur UAG comme ce sera le cas pour le serveur “APP3.Exatechdays.Local”

 

La mise en œuvre

Pour illustrer mon propos, voila la configuration UAG qui va avec. En plus cela me permettra de présenter certaines spécificités liées à la mise en œuvre de DirectAccess avec UAG.

0

Premier étage : Rien de bien compliqué : Un groupe de filtrage qui sera utilisé pour filtrer l’application de la stratégie de groupe destinée à configurer les clients DirectAccess. Je reste simple.

1

Deuxième étage, cela se corse un peu : On retrouve la même interface que pour le DirectAccess Windows, dans le cas qui nous occupe, je n’ai rien changé. Si on passe ce cap, c’est que déjà les principaux pré-requis sont respectés.

2

Troisième étage, la spécificité UAG. DNS64 et NAT64 sont des protocoles de translation permettant d’accéder à nos ressources IPV4, ce que ne permet pas l’implémentation Windows de DirectAccess. Pour ceux qui veulent en savoir plus, je recommande la lecture des deux billets de Stanislas QUASTANA sur son blog : Partie n°1, Partie n°2. A mon sens, cela justifie pleinement l’utilisation d’UAG pour faire du DirectAccess.

3

Quatrième étape, l’authentification : Ici rien de bien nouveau, on doit décider quelle autorité de certification on va utiliser pour valider les tunnels IPSEC et désigner le certificat qui sera mis en œuvre pout le protocole IP-HTTPS.

4 

Note : A ce niveau, je signale qu’au moment de la rédaction de ce billet, il subsiste un bogue dans UAG lorsqu’on décide de faire du NAP sans Smartcard. J’espère que cette problématique sera résolue dans l’Update 2 d’UAG.

 

Cinquième étage, le Network Location Server : Ici encore rien n’a changé.

5

Sixième étage, la Name Resolution Policy Table : On pourrait croire que rien n’a changé, pourtant si on regarde de plus près l’adresse IP du DNS associée au domaine Active Directory, on observe la mention DNS64. Cela signifie que nos clients à l’extérieurs ne vont pas s’adresser directement aux serveurs DNS tel que c’était le cas dans une implémentation DirectAccess Windows.

6

Septième étage, les serveurs d’infrastructure : Ici l’interface est plus claire. On peut enfin classer ses serveurs selon des catégories. A noter que tous ceux qui seront référencés ici seront autorisés à utiliser le tunnel IPSEC infrastructure.

7

Note : A ce niveau, assurez vous que vos serveurs DNS répondent bien en IPV6, plus particulièrement qu’ils écoutent bien sur l’interface ISATAP. Si le serveur est un Windows 2008 sans Service Pack 2, attention à la KB958194, je me suis encore fait avoir récemment.

 

Dans la catégorie NAP, j’ai ajouté mon HRA. Oui, mon HRA est interne et alors?

8

Huitième étage, le Selected server mode : On va commencer par s’assurer de cocher la bonne case.

9

Puis de cliquer sur le lien “Edit IPSEC Cryptographic settings…” pour constater les spécifications du tunnel IPSEC qui sera mis en œuvre.

10

Il ne reste plus qu’à spécifier un groupe de serveurs pour lesquels le tunnel sera mis en place. D’un point de vue technique, le groupe est utilisé pour filtrer l’application de la troisième stratégie de groupe (celle qu’on n’utilisait jamais jusque là).

11

Le résumé de la configuration nous rappelle bien notre configuration :

  • On a accès à tout le réseau interne
  • L’accès à certains serveurs nécessitera la mise en place d’un tunnel IPSEC additionnel

14

Neuvième étage, l’activation de la configuration d’UAG. A ce niveau, je tiens à remercier Alexandre GIRAUD pour son workaround sur le bug “The adapter configured as external-facing is connected to a domain”.

16

Le résultat coté client

Maintenant que tout est en place, voyons ce qui a changé coté client. Dans la console “Firewall with Advanced Security”, on constate la présence d’une nouvelle association de sécurité avec l’adresse ISATAP de notre serveur App2.exatechdays.local.

CLIENT0

Dès lors que je vais accéder à mon serveur “App2.exatechdays.local”, il va automatiquement mettre en place le tunnel IPSEC additionnel vers le serveur.

CLIENT1

Le résultat coté serveur

Coté serveur, on constate la présence de deux associations de sécurité dans la console “Firewall and Advanced Security” sur le serveur “App2.exatechdays.local”. C’est le résultat de la stratégie de groupe appliquée au membres du groupe de serveurs.

APP2_0

Dans le détail, on constate la mise en place de l’association de sécurité avec le client, plus particulièrement l’utilisateur.

APP2_1

 

Pour aller plus loin

Par extension, ce mode de fonctionnement peut être utilisé pour les scénarios suivants :

  • On peut facilement limiter l’accès au système d’information de l’entreprise au travers de DirectAccess.
  • En personnalisant les règles de pare-feu et plus particulièrement les associations de sécurité on peut autoriser l’accès à certaines ressources interne selon l’utilisateur et ou l’ordinateur (scénarios VIP par exemple)

 

Les limites

On en dénombre deux, concernant uniquement les serveurs internes :

  • Les serveurs référencés dans le groupe de filtrage fonctionnent au moins sous Windows 2008, (sinon ils ne seront pas capable d’interpréter les règles de pare-feu).
  • Les serveurs référencés dans le groupe de filtrage pour un tunnel IPSEC sans protection de la charge (ESP Null) doivent nécessairement fonctionner sous Windows 2008 R2 ou supérieur.

 

Conclusion

Voila un scénario DirectAccess bien intéressant. Dans mon prochain billet, je vais élever encore le niveau avec un scénario pour utilisateurs VIP en DirectAccess :

Credentials 

Benoîts – Simple and Secure by Design (j’insiste sur le Secure)

Comments

Stanislas Quastana's blog on TechNet said:

Le mois de mai aura été un bon mois concernant DirectAccess avec pas mal d'articles assez intéressants

# juin 3, 2010 9:55

Simple (and secure) by Design [Benoît SAUTIERE / Exakis / MVP] said:

Facile, on fait de la carte à puce comme illustré dans le billet “ DirectAccess et la magie de la smartcard

# juillet 4, 2010 11:34