Archives mensuelles : janvier 2011

Attack Surface Analyzer Beta

En matière de sécurité informatique, chaque composant du système d’information peut être vulnérable. La problématique étant de connaitre les faiblesses de chaque composant du système pour pouvoir déterminer une stratégie visant à améliorer la sécurité générale du système.

 

Il est relativement facile de déterminer la surface d’attaque d’un système d’exploitation Microsoft et des applications du même éditeur. Ces point sont documentés et révisés par l’éditeur à chaque nouvelle version du système et applications.

 

Par contre pour les applications tierces, c’est nettement plus difficile. Pour adresser cette problématique, Microsoft propose Attack Surface Analyzer (encore en phase Beta). Cet outil a pour but de mettre en évidence les changements intervenus sur un système suite à l’installation d’une applications. L’outil n’est pas magicien, il va traiter les grandes familles de problématiques de sécurité et donc nous aider à mieux orienter nos investigations.

 

De mon point de vue, c’est une manière de se faire une première idée de ce à quoi on s’expose. La pression sur les couts IT force souvent à mutualiser les services et applications sur un même socle technique. Même s’il peuvent cohabiter techniquement, il faut tout de même savoir à quoi on s’expose.

 

Benoits – Simple and Secure by Design  but Business compliant.

Impossible d’activer DirectAccess à cause de 6to4

C’est à conserver dans les archives car cela arrivera certainement un jour (vécu personnel en plus). Lors de l’activation d’une configuration UAG pour DirectAccess, on peut rencontrer la problématique illustrée ci-dessous:

Activate

 

La lecture du billet de Ben Ari vous apprendra comment traiter ce type de problématique et évitera donc la réinstallation totale du serveur UAG.

 

Benoits – Simple and Secure by Design  but Business compliant.

La bible de l’UAG est disponible

Pour beaucoup de personnes UAG, reste un mystère. Cela tien en partie au produit mais aussi qu’il n’existe pas assez de documentation publique sur ce produit. J’avais déjà évoqué toutes les ressources disponibles. J’y avais déjà référencé le futur ouvrage de Ben-Ari.

 

UAG_HandBook

 

Et bien maintenant cet ouvrage est maintenant disponible, et peut déjà être qualifié d’ouvrage de référence en la matière. Bref, un must to have! Cet ouvrage devrait grandement démystifier UAG qui est un produit à part chez Microsoft.

 

Benoits – Simple and Secure by Design  but Business compliant.

ADCS Enrollment Web Services

Le rôle ADCS est présent depuis Windows NT 4.0. Avec Windows 2000, il a fait son entrée dans l’annuaire Active Directory avec son mode “Enterprise”. Problème, ce mode de fonctionnement implique que les clients soumettent leurs demande de certificats en passant par DCOM et non les RPC.

A l’heure de Windows 7/Windows 2008 R2, l’utilisation de RPC/DCOM pour soumettre ses demandes de certificats, c’est pas ce qu’il y a de mieux pour sécuriser le rôle ADCS. Pourtant, on dispose bien d’un site web d’enregistrement de demande de certificats mais c’est pour traiter des demande manuelle. Avec Windows 7 / Windows 2008 R2, on dispose de deux Web Services pour adresser cette problématique:

  • Certificate Enrollment Policy Web Service
  • Certificate Enrollment Web Service

 

Pourquoi deux Web Services? La raison est simple. Dans un premier temps, le client doit déterminer quelles autorités de certification sont disponibles ainsi que les gabarits de certificats utilisables. Ces informations sont disponibles dans l’annuaire Active Directory. Le “Certificate Enrollment Policy Web Service” joue le rôle de proxy pour les clients. Il n’ont donc plus à accéder à nos contrôleurs de domaine.

 

Le “Certificate Enrollment Web Service” a lui la charge de recevoir les demandes de certificats pour les soumettre à l’autorité de certification et de retourner les résultats.

 

Stratégie d’enrôlement par défaut

Sans autre indication, Windows 7 et Windows Server 2008 R2 utilisent l’annuaire Active Directory pour localiser le point d’Enrôlement qui n’est rien d’autre que notre autorité de certification.

ADSIEDIT_BEFORE

Pour être plus précis, nos systèmes d’exploitation effectuent les recherches suivantes :

  • La liste des Enrollment Services déclarés dans la partition de configuration (pKIEnrollmentService)
  • La liste des gabarits de certificats disponibles dans l’annuaire Active Directory (pKICertificateTemplate)

Dès lors qu’on a localisé notre service d’enrôlement, on a immédiatement accès à notre autorité de certification pour lui soumettre les demandes de certificats en DCOM, ce qui implique donc de passer par les RPC. C’est à ce stade qu’on va introduire nos deux Web Services.

 

Bases de travail

Avant de pouvoir installer les Web Services du rôle ADCS, il faut encore avoir préalablement avoir mis en œuvre une autorité de certification intégrée à l’annuaire Active Directory. Le rôle ADCS devra avoir été installé en mode “Entreprise”. Pour cela, je vous renvoie vers une mise en œuvre déjà documentée.

 

Dans ce billet, il sera considéré que les deux Web Services du rôle ADCS seront installés sur un même serveur distinct de l’autorité de certification.

 

Installation des Web Services

Nos deux Web Services seront installés sur un même serveur membre du domaine.

ROLE0

 

En premier lieu on configure le “Certificate Enrollment Web Service”. Celui-ci a besoin de savoir vers quelle autorité de certification renvoyer les demandes. A ce stade, on peut noter qu’il est possible de le configurer pour ne traiter que les demandes de renouvèlement de certificat. D’un point de vue sécurité, c’est intéressant, surtout si notre autorité de certification est accessible depuis Internet.

ROLE1

 

Dès lors qu’on doit dialoguer avec un des deux Web Services, une authentification est nécessaire. Il n’est pas possible de soumettre des demandes anonymes! Les Web Services proposent trois modes d’authentification. Dans le cas qui nous occupe, j’ai choisi l’authentification Windows intégrée, c’est le scénario  le plus simple.

ROLE2

 

Pour que le Certificate Enrollment Web Service puisse soumettre les demandes des clients, il est nécessaire que le serveur web ou le compte de service que l’on précise à ce niveau soit configuré pour la délégation Kerberos. La demande doit être formulée au nom du client et non au nom du serveur web. Dans le cas illustré dans ce billet, j’ai volontairement choisit de réutiliser le contexte par défaut utilisé par le site web de IIS. Ce n’est peut être pas le scénario le plus sécurisé mais le plus simple à illustrer .

ROLE3

 

Qui dit Web Service et autorité de certification dit impérativement SSL. On va donc avoir besoin de certificats. Dans le scénario développé dans ce billet, les deux Web Services partageront le même certificat et le même nom. Il est possible de faire mieux mais on va continuer à faire “Simple by Design” .

ROLE4

 

Le résumé de l’installation nous apprend plusieurs choses:

  • L’URI du Certificate Enrollment Policy Web Service
  • L’URI du Certificate Enrollment Web Service
  • Que nous utiliseront le contexte de sécurité du site web par défaut pour le “Certificate Enrollment Web Service”
  • Que le mode d’authentification est identique pour les deux Web Services
  • Qu’il manque un certificat

 

ROLE5

 

Dans des scénarios plus développés, on choisirait de séparer les deux Web Services avec des URI distinctes. On conserve ces informations dans un coin pour plus tard. La fin de l’installation nous indique un certain nombre d’informations complémentaires :

  • L’absence de certificat SSL pour finaliser l’installation
  • La configuration de la stratégie d’Enrôlement à prévoir
  • La délégation Kerberos à mettre en œuvre

 

ROLE6

 

Une fois les Web Services installés, on peut constater la présence de deux nouveaux pools applicatifs dans la console IIS. Chaque Web service dispose d’un contexte de sécurité qui lui est propre. On repassera plus tard.

ROLE7

 

Pour l’instant, on va se focaliser sur ce qu’il manque, à savoir notre certificat. Etant donné que nos deux Web Services sont mutualisés sur le même serveur web, on va demander un certificat au nom de notre serveur web:

ROLE8

 

Pour raison de commodité, on va ajouter un “Friendly Name” dans notre demande de certificat. Cela permettra de plus facilement identifier le certificat.

ROLE9

 

Une fois obtenu, notre certificat doit être associé au listener HTTPS.

ROLE10

 

On comprend immédiatement l’intérêt d’avoir intégré un “Friendly name”.

ROLE11

 

Pour parachever la configuration des Web Services, on va aller configurer quelques propriétés dans la console Internet Information Server. Plus précisément, on va aller faire un tout du coté du “Certificate Enrollment Policy Web Service”. A ce stade, nous devons configurer le “Friendly name” sous lequel ce Web service va s’inscrire dans l’annuaire Active Directory.

IIS0

 

Le “Certificate Enrollment Policy Web Service” est référencé sous une URI. C’est celle-ci que l’on va réutiliser dans la stratégie de groupe.

IIS1

 

A t’on besoin de délégation Kerberos?

Le sujet est complexe et simple à la fois, tout dépend si on sépare ou mutualise les Web Services entre eux et si on désire les cumuler ou non avec l’autorité de certification.

La règle est pourtant simple. Si toutes les conditions suivantes sont remplies alors il sera nécessaire de configure une délégation Kerberos pour le Certificate Enrollment Web Service:

  • Le rôle ADCS et le Certificate Enrollment Web Service sont installés sur des serveurs distincts
  • L’authentification retenue pour le Web Service est de type “Windows intégrée” ou “Client Certificate authentication”
  • Le Certificate Enrollment Web Service sera configuré en mode “Renouvèlement uniquement”.

 

Pour plus d’informations sur le sujet, je vous renvoie sur le site Technet :

Configuring Delegation Settings for the Certificate Enrollment Web Service Account

 

Dans le cas de cet article, l’ai volontairement :

  • Choisit de mutualiser les deux Web Services sur la même machine
  • Les Web Services ne sont pas mutualisés avec l’autorité de certification (mesure d’isolation)
  • Le compte de service utilisé pour le Certificate Enrollment Web service a volontairement et conservé

 

Ayant volontairement réutilisé ne contexte par défaut de IIS, il y aura bien une délégation à mettre en place mais pas pour le compte de service mais le compte ordinateur hébergeant mes deux Web Services. On va mettre en place une délégation Kerberos pour seulement deux services tel qu’illustré ci-dessous:

KERBEROS

 

Configuration d’une nouvelle politique d’enrollment

Par défaut, lorsqu’on demande un certificat à notre autorité de certification, cela ressemble à l’illustration ci-dessous :

ENROLL0

 

Si on creuse un peu dans la partition de configuration, on constate qu’il existe déjà une politique d’enrôlement de certificat pour notre autorité de certification. La référence indiquée dans l’annuaire Active Directory indique même les gabarits de certificats disponibles. Il nous faut donc remplacer cette politique d’enrôlement par une nouvelle référençant non pas l’usage directe de notre autorité de certification mais notre “Certificate Enrollment Policy Web Service”. C’est techniquement possible mais uniquement pour les systèmes de la génération Windows 7 et Windows 2008 R2 au travers des stratégies de groupe.

Le paramétrage peut s’effectuer au niveau de l’ordinateur ou de l’utilisateur. On peut choisir d’avoir une seule stratégie d’enrôlement ou la différencier.  La stratégie d’enrôlement se configure au travers du paramètre “Certificate Services Client – Certificate Enrollment Policy”.

GPO0

La stratégie d’enrôlement initiale prévoit d’utiliser l’annuaire Active Directory, c’est ce qui est inscrit dans la partition de configuration de notre forêt. On va donc commencer par supprimer cette référence. A ce niveau, on peut aussi forcer l’utilisation de la même politique pour l’utilisateur du poste:

GPO1

Dans une configuration par défaut, la stratégie d’enrôlement indique LDAP comme URL de localisation de la ressource (URI). Etant donné que nous référençons le Web service de notre “Certificate Enrollment Policy Web Service”. C’est l’URI que nous avons préalablement identifié. Le copier/Coller sera ici très utile:

GPO2

Le processus validation va vérifier que le “Certificate Enrollment Policy Web Service” est référencé dans l’annuaire Active Directory sous forme d’une Enrollment Policy qui elle même référence le  “Certificate Enrollment Web Service”. Bref, on valide la chaine.

GPO3

Etant donné que tout fonctionne, on indique maintenant que cet “Enrollment Policy” est celle qu’il faudra utiliser.

GPO4

Changements coté Active Directory

Le premier changement, c’est que la politique d’enrôlement par défaut a été remplacée par une nouvelle référençant notre “Certificate Enrollment Policy Web Service”.

ADSIEDIT_AFTER0

Si on interroge la politique d’enrôlement de notre autorité de certification (CERTUTIL.EXE –ADA), on peut constater un certain nombre de choses :

  • La liste de la ou les autorités de certifications disponibles
  • La liste des gabarits de certificats mis à disposition
  • Le mode d’authentification des clients auprès du Web Service
  • L’URI du Web Service “Certificate Enrollment Policy Web Service”

CERTUTILADA

La commande “CERTUTIL.EXE –POLICY” permet de déterminer quelle est la stratégie d’enrôlement configurée, son URI ainsi que la fréquence de mise à jour. Ce qu’il faut comprendre à ce niveau, c’est que notre “Certificate Enrollment Policy Web Service” agit comme un proxy auprès des contrôleurs de domaine. Le client n’accède plus à nos contrôleurs de domaine.

CERTUTILPOLICY

Changements coté client

Avant, lorsqu’on effectuait une demande de certificat auprès de notre autorité de certification, on obtenait la stratégie par défaut nous envoyant directement vers l’autorité de certification.

ENROLL0

Dès lors que la nouvelle stratégie d’enrôlement de certificats a été déployée, on peut constater les premiers changements:

ENROLL1

Plus précisément que le client va s’adresser au Certificate Enrollment Policy Web Service pour obtenir son certificat:

ENROLL2

Coté demande de certificat, rien ne change à première vue.

ENROLL3

Pourtant, lorsqu’on regarde d’un peu plus près la requête qui va être traitée, on constate que celle-ci sera soumise à au “Certificate Enrollment Web Service”:

ENROLL4

Pour preuve cela fonctionne.

ENROLL5

Conclusion

Il a fallu attendre Windows 7 et Windows 2008 R2 pour sécuriser l’enrôlement de certificats. C’est un peu dommage. C’est très utile pour UAG car par défaut, les RPC sont bloqués (UAG et le RPC Server is unavailable).

 

Benoits – Simple and Secure by Design  but Business compliant.

DirectAccess, en attendant le Géocluster

Les vacances ont été longues, presque tout le mois de décembre. Je commence donc cette année comme j’avais fini la précédente avec DirectAccess avec un retour sur un billet de Tom Shinder : Supporting Business Continuity, Disaster Recovery and Multi-Site Scenarios with UAG 2010 RTM and UAG 2010 Service Pack 1.

 

La haute disponibilité simplement

Au cours de mes pérégrinations dans ce domaine, les sujets de la haute disponibilité, de la continuité d’activité sont souvent des points de blocage. Si on réfléchit rapidement, qui dit haute disponibilité avec UAG dit invariablement ferme de serveur UAG avec équilibrage de charge réseau Microsoft ou matériel. Pour le premier, je renvoie vers ma série de billets DirectAccess high availability with UAG 2010. Pourtant ce scénario peut être complexe à mettre en œuvre entre deux sites. Il faut travailler autrement:

  • Une ferme UAG en DirectAccess sur le site de production
  • Un simple serveur UAG en VPN/SSL sur le site de secours

 

La bascule ne s’effectuera pas automatiquement mais manuellement en utilisant le Direct Access Connectivity Assistant qui redirigera le portail UAG. On dispose ainsi d’un moyen simple pour la continuité d’activité.

 

Miroir mon beau miroir!

C’est l’option proposée par Tom Shinder dans son billet. Ici la virtualisation nous facilitera grandement le travail. Il sera en effet très facile de basculer une machine virtuelle UAG du site de production vers le site de secours. Cette approche implique notre fournisseur d’accès puisse basculer nos adresses IP vers le site de secours.

 

Geo-cluster

Voila l’option luxe dont tout le monde rêve. On doit distinguer deux cas:

  • Réseau LAN IPv4
  • Réseau LAN IPv6

Dans le premier cas, c’est du Canada Dry! En effet, ça a le gout du Geo-Cluster mais il manque juste la bascule entre les nœuds. Le scénario présenté par Tom repose sur une affectation statique des clients DirectAccess à un serveur UAG ou une ferme UAG.

 

Par contre, en IPv6 (ISATAP plus précisément), c’est tout  autre chose:

ILLUSTRATION

 

Alors oui, on devra faire de l’IPv6 mais je rappelle toujours que ce sera de l’ISATAP, donc de l’IPv6 encapsulé dans IPv4. Tom Shinder promet la mise à disposition d’un Test Lab Guide autour de ces scénarios de Géo Cluster prochainement en ce début de nouvelle année.

What else?

Il ne manque plus grand chose sinon la formalisation des scénarios en Géo-Cluster. Selon les informations livrées lors du TechEd 2010 Europe de Berlin, on devrait avoir une mise à jour d’UAG 2010 SP1 pour intégrer ces scénarios avec le support en plus.

image

 

Conclusion

Finalement, il y a quand même pas mal de possibilité pour avoir de la haute disponibilité avec DirectAccess sans pour autant rentrer dans des scénarios ultra complexes à mettre en œuvre. Je reviendrai sur le futur Test la Guide de Tom Shinder sur le déploiement en Geo-Cluster. Celui-ci permettra de rentrer dans le cœur d’IPv6.

 

Meilleurs vœux pour cette année, je vous souhaite tout plein de bonnes choses et vous invite à me retrouver en compagnie d’Arnaud LHEUREUX pour une session retour d’expérience sur nos déploiements de DirectAccess.

 

Benoits – Simple and Secure by Design  but Business compliant.