Limiter DirectAccess à une population d’utilisateurs

Facile, on fait de la carte à puce comme illustré dans le billet “DirectAccess et la magie de la smartcard”. C’est vrai, mais cela pose un problème majeur, il faut distribuer des cartes à puces. Techniquement, c’est pas très compliqué (voir ma série de billets sur le sujet). Par contre coté organisation, c’est tout autre chose.

Quand on creuse un peu DirectAccess, on comprend que c’est le poste de travail qui est autorisé à faire du DirectAccess (le poste de travail est membre du groupe de filtrage). Tel que présenté jusqu’à maintenant tout utilisateur d’un poste dument autorisé peut faire du DirectAccess. Question : Comment limiter à une population d’utilisateurs?

Un début de solution

Pour ceux qui ont déjà parcouru mon blog ou assisté à notre session aux Techdays, la solution se trouve au niveau de AuthentIP, nouveauté de Windows 7 autorisant l’utilisation de l’identité de l’utilisateur ou l’état de santé de l’ordinateur pour authentifier le tunnel IPSEC. Problème, il n’est pas possible d’éditer les stratégies de groupe générées pour DirectAccess sans les corrompre. Pour rappel, depuis Windows Vista / Windows Server 2008, IPSEC est intégré au pare-feu, donc allons faire un tour dans la console de pare-feu de notre serveur UAG:

Local0

Un message nous indique que la configuration de mon UAG intègre déjà DirectAccess puis qu’une stratégie de groupe s’applique à lui. Allons voir ce qui se passe coté IPSEC. La section “IPSEC Tunnel Authorization”, nous intéresse tout particulièrement. On va donc cocher la case d’option “Advanced” et cliquer sur le bouton “Customize”.

Local2

Nous y sommes. On a donc trouvé l’interface pour désigner les ordinateurs ainsi que les utilisateurs autorisés ou refusés. Donc si on positionne un groupe préalablement créé, on a donc mis en place notre filtrage. C’est en partie vrai. Allons voir ce que cela donne sous la moquette avec NETSH :

Local3

La console de pare-feu avancée a donc bien positionné le groupe de filtrage, ici référencé sous sa notation SDDL. Pour les fans de développement Dot.Net, c’est ici que cela se passe. Maintenant qu’on a la traduction du groupe au format SDDL, on va le conserver dans un coin et retirer le paramétrage.

La problématique

C’est bien de pouvoir mettre en place ce filtrage dans la stratégie locale de notre serveur UAG, mais comment intégrer ce paramètre dans la stratégie de groupe qui s’applique à lui? La réponse est que c’est pas possible par l’interface graphique (tout du moins pour l’instant) sans corrompre la stratégie de groupe. Il faudra donc modifier la stratégie de groupe qui s’applique au serveur UAG en ligne de commande, comme le fait le script PowerShell.

Ma base de travail

Maquette

J’ai donc déjà une infrastructure DirectAccess en en place (UAG est installé avec l’update 1, c’est important). Celle-ci intègre déjà NAP. Reste plus qu’à faire un peu de magie.

La magie du NETSH

NETSH peut être utilisé à toutes les sauces, bref, on va encore faire du NETSH pour deux choses :

  • Intégrer le SDDL du groupe dans la stratégie de groupe DirectAccess applicable au serveur UAG
  • Intégrer l’activation de la prise en compte de l’authentification dans le tunnel utilisateur (Si vous n’a pas activé NAP sur votre plateforme,  si celle-ci n’intègre pas l’update 1 alors que vous tentez de faire du NAP sans carte à puce, …)

On va travailler coté UAG, plus précisément sur la GPO qui s’applique à notre serveur UAG :

USERDA0

Initialement, la commande NETSH a été utilisée pour afficher le paramétrage IPSEC global mis en œuvre sur le pare-feu. On va commencer par se positionner sur la stratégie de groupe que l’on désire mettre à jour. On constate que le paramètre AuthzUserGrp n’est pas encore configuré :

USERDA1

Reste plus qu’à configurer ce paramètre avec le groupe de sécurité “EXATECH\VIP Users”, exprimé sous sa forme SDDL :

USERDA2

La subtilité ApplyAuthorization

Pour que le filtrage soit actif, il faut que le paramètre “ApplyAuthorization” soit configuré à “Yes” sur la règle de tunnel IPSEC “UAG DirectAccess Gateway – Clients Corp Tunnel”. Par défaut, le paramètre est configuré avec la valeur “No”, sauf si :

  • On configure DirectAccess pour du Smartcard
  • On configure DirectAccess pour du Smartcard et du NAP
  • On configure DirectAccess pour faire seulement du NAP mais sur un UAG en Update 1

Dans tous les autres cas, le valeur du paramètre est à “No”, spécialement si on tente de faire du DirectAccess avec du NAP, sans carte à puce et sans l’Update 1 d’UAG!

Donc si nécessaire, il faut activer le paramètre ApplyAuthorization sur le tunnel “UAG DirectAccess Gateway – Clients Corp Tunnel”. Mais pourquoi celui-la et pas l’autre? Tout simplement parce que l’autre c’est le tunnel d’infrastructure.

USERDA3

Une petite ligne de commande NETSH magique et c’est opérationnel.

USERDA5

Il ne reste plus qu’à s’assurer que notre serveur UAG applique la stratégie de groupe pour tester.

USERDA4

Le résultat

Si je créé un nouvel utilisateur tout à fait standard (uniquement membre du groupe Utilisateurs du domaine), on obtient le résultat suivant lorsqu’on tente d’accéder aux ressources en DirectAccess :

Contrôleur de domaine

Fonctionne, c’est normal, c’est à cause du tunnel d’infrastructure.

Serveur APP USERDA6
Serveur APP2 USERDA7
Serveur APP3 USERDA8

Donc, cela bloque bien l’utilisateur. Maintenant, si on positionne notre utilisateur comme membre de notre groupe de filtrage “EXATECH\VIP Users” et que notre utilisateur ferme bien sa session, il retrouve accès à tous les serveurs.

Prochaine étape

La prochaine étape, ce sera d’appliquer ce mode de fonctionnement au mode “Selected Server”. La méthode ne sera pas tout à fait la même car la stratégie de groupe mise en place sur les serveurs sélectionnés ne met pas en place un tunnel mais uniquement un transport, ce qui empêche l’utilisation du paramètre “ApplyAuthorization”.

Conclusion

C’est donc possible de mettre en place un filtrage selon une population d’utilisateurs, voire même d’ordinateurs. Le problème, c’est que l’assistant de mise en œuvre de DirectAccess ne permet pas de configurer ces options. Espérons que cette fonctionnalité soit prise en charge dans une mise à jour de Windows Server 2008 R2 ou dans une prochaine Update de ForeFront UAG 2010.

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

Benoit

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

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.