Archives mensuelles : février 2011

ADCS en mode Cross-Forest

Mais à quoi çà sert?

Depuis Windows NT 4.0 et jusqu’à Windows Server 2008, une autorité de certification “Microsoft” ne pouvait prendre en charge que des clients situés dans la même forêt. Donc jusqu’à maintenant, on ne pouvait pas avoir moins d’autorité de certification que de forêts.

 

De plus en plus souvent, les architectures complexes vont vers une séparation entre les ressources et les utilisateurs. C’est le cas d’Exchange et Lync. Problème, pour ces environnement, on était obligé de déployer au moins une instance du rôle ADCS par forêt. Conclusion, on devait se prendre la tête avec de la Cross certification.

 

Le rôle ADCS de Windows 2008 R2 supportant maintenant le LDAP Referrals, il est maintenant possible de faire beaucoup plus simple, avec une seule instance du rôle ADCS couvrant plusieurs forêt.

 

Les pré-requis

Pour obtenir ce résultat, il est nécessaire que :

  • De mettre en place une forêt de ressource pour notre rôle ADCS
  • De mettre en place une forêt de compte dédiée aux clients Windows XP ou Windows 2003 minimum
  • De mettre en place le rôle ADCS dans la forêt de ressources sur un serveur Windows 2008 R2 de type Enterprise ou Datacenter

 

Les fondations sont la, maintenant place à la mise en œuvre.

 

Etablir la confiance

C’est la base de tout. Notre Autorité de certification devra être reconnue dans la forêt de compte et accepter les demandes de certificats en provenance de celles-ci. Pour cela, on a besoin de vérifier l’identité. On a donc besoin de Kerberos. Pour cette raison, on a besoin d’une relation d’approbation de type Forêt, ce qui implique un mode de forêt Windows 2003 natif au minimum dans la forêt de compte. Coté forêt de ressources, c’est aussi Windows 2003 natif mais là, c’est normal.

Trust0

 

Cette relation d’approbation doit nécessaire être bi-directionnelle. D’un coté les utilisateurs de la forêt de compte doivent pouvoir être identifiés comme autorisés à accéder à des gabarits de certificats et réaliser l’enrôlement. De l’autre coté, notre autorité de certification doit être capable de vérifier l’identité du demandeur dans la forêt de compte.

Trust1

 

Lors de l’établissement de la relation d’approbation, il est possible d’utiliser la fonctionnalité “Selective Authentication qui permet de déterminer quels sont les utilisateurs autorisés à utiliser la relation d’approbation. Pour cela, il faut s’assurer que :

  • Les demandeurs de certificats (machine ou utilisateur) de la forêt de compte puissent se présenter dans la forêt de ressource
  • L’autorité de certification présente dans la forêt de ressource doit être capable de s’authentifier auprès de tous les contrôleurs de domaine demandeurs dans la forêt de compte. C’est nécessaire pour valider l’identité des demandeurs.

 

Configuration de l’autorité de certification

Par défaut, une autorité de certification n’est pas capable de traiter les demandes en provenance d’autres forêt. C’est une des nouvelles capacités de Windows 2008 R2 qu’il faut activer. En ce qui nous concerne, le “LDAP Referrals”.

LDAPREFERRALS

 

Le redémarrage de l’autorité de certification est nécessaire pour que le paramétrage soit pris en compte. Notre autorité de certification racine devant être reconnue par les forêts de compte. Il nous faudra donc exporter le certificat de l’autorité de certification racine.

EXPORTROOTCA

 

Pour que ce certificat soit valable, encore faut-il que les informations inscrites dedans puissent être accessibles dans la forêt de compte. On parle ici d’AIA et de CDP. Il faut donc s’assurer que ces informations sont bien accessibles. Publier la CRL est un de ces éléments.

AIAAVAILABILITY0

 

Configuration de la forêt de compte

Pour que la forêt de compte reconnaisse notre autorité de certification, il est nécessaire de commencer par l’import du certificat de l’autorité de certification racine (généralement mis hors ligne). On utilisera pour cela la commande “CERTUTIL.EXE –DsPublish –F <Fichier de certificat> ROOTCA”.

DSPUBLISHGPUPDATE

 

Note : L’actualisation des GPO doit permettre de s’assurer que le contrôleur de domaine que nous allons utiliser par la suite dispose bien des bonnes informations.

 

L’autorité de certification est maintenant déclarée comme autorité racine de confiance. C’est ce qu’on peut constater dans la partition de configuration.

VIEWSTORE0

 

On peut obtenir la même information à l’aide du provider “CERT” inclus avec PowerShell.

VIEWSTORE1

 

Une autorité de certification reconnue comme de confiance c’est bien mais si en plus elle peut être utilisée pour fournir des certificats d’authentification, c’est mieux. Pour cela, il faut positionner le certificat dans le conteneur “NTAuthCA” à l’aide de la commande “certutil.exe –DsPublish –f <Fichier du certificat> NTAuthCA”.

NTAUTHCA0

 

Dans la console ADSIEdit, on doit pouvoir constater l’apparition d’un objet “CertificationAuthority” pour notre précédente commande.

NTAUTHCA1

 

Même si ce n’est pas obligatoire (cela fonctionne sans), il est recommandé de publier tous les niveaux de cette infrastructure. Pour cela, on dispose d’un conteneur “SubCA” et de la commande “CERTUTIL.EXE –DsPublish –F <Fichier de certificat"> SubCA”. Dans l’illustration ci-dessous, il est indiqué que le conteneur est déjà peuplé car mon infrastructure de clé publique n’a qu’un seul niveau. Le certificat est donc déjà dans le bon conteneur.

ISSUINGCAPUBLISH

 

Le fait de publier les certificat dans les bon conteneurs de suffit pas. Il nous faudra des permissions. Avec l’Active Directory, tout passe par le groupe “Cert Publishers”. Dès lors qu’on installe une autorité de certification dans une forêt, le compte ordinateur est automatiquement positionné dans ce groupe.

GROUPMEMBER0

 

Dans le scénario du Cross-Forest, il n’y a pas d’autorité de certification dans la forêt. Le groupe est donc vide. Il faut donc positionner le compte ordinateur de notre autorité de certification dans le groupe. Cela sert aussi à cela la relation d’approbation bi-directionnelle.

GROUPMEMBER1

 

On approche de la fin de la configuration. On rentre maintenant dans les détails avec l’activation de la fonctionnalité “Auto-Enrollment” pour tous les systèmes.

GPMC0

 

On peut être activer la fonctionnalité pour les gabarits de certificats V1 et spécifier les gabarits en question.

GPMC1

 

Qu’est ce que cela donne dans la forêt de compte?

A ce stade, on va plutôt constater ce qui manque. On constate bien la présente de l’AIA pour notre autorité de certification.

ACCOUNTCONTENT0

 

Par contre, on n’a aucun gabarit de certificat à proposer à nos utilisateurs. A ce stade, c’est normal, ils sont toujours dans la forêt de ressource. Il va falloir travailler un peu.

ACCOUNTCONTENT1

 

Coté OID, c’est aussi le désert, …

ACCOUNTCONTENT4

 

Pour ceux qui ont suivi mon billet sur ADCS Enrollment Web Services, on a découvert la notion des service d’enrôlement. Dans l’état actuel des choses, il n’y en a pas dans notre forêt de compte. Conclusion, les clients ne pourront pas savoir quels sont les gabarits de certificats mis à sa disposition.

ACCOUNTCONTENT3

 

Alors, on synchronise à la fin?

C’est bien là l’astuce. On va devoir recopier les objets manquants depuis la forêt de ressources vers la forêt de comptes. Coté Microsoft, il n’y a pas réellement d’outillage sinon un script Powershell disponible sur Technet.

 

Ce script sera exécuté dans la forêt de compte pour aller chercher les objets manquants dans la forêt de ressources. Ce sera le même script pour la synchronisation initiale et les synchronisation suivantes.

PKISYNC0

 

Note : Je recommande vivement l’utilisation du paramètre “-WhatIf” pour identifier les changements que le script va réaliser.

PKISYNC1

 

Ca marche?

A ce stade, attention il faut que la réplication inter-site fasse son œuvre. Normalement, on doit pouvoir retrouver les gabarits de certificats en provenance de notre forêt de ressources.

ACCOUNTCONTENTAFTER0

 

On trouve même un service d’enrôlement, ce qui signifie que les clients de cette forêt peuvent déterminer quels sont les gabarits de certificats mis à sa disposition.

ACCOUNTCONTENTAFTER1

 

Et pour finir, on a aussi les OID. On est donc au complet.

ACCOUNTCONTENTAFTER2

 

Pourquoi je ne voit pas mes gabarits de certificats?

Encore un code erreur 40 de Kevin le boulet? Ben oui et non. Celui-là il est volontaire pour illustrer un propos. Oui, on ne voit pas les gabarits de certificats. Par contre, la raison est-elle évidente  non?

FAILURE0

 

C’est juste une histoire de permissions, celles positionnées sur les gabarits de certificats. Par défaut, elle ne peuvent concerner que des objets de la forêt de ressources. Il nous faut donc ajouter deux types de permissions. La première est celle nécessaire aux administrateurs de la forêt de compte pour accéder et formuler des demandes de certificat pour un gabarit donné.

FAILURE1

 

La seconde est destinée aux populations pouvant faire de l’Auto-Enrollment”. Eux aussi doivent disposer des permissions “Enroll”et “AutoEnroll”.

FAILURE2

 

Voila pour la gabarit “Domain Controller Authentication”, à vous de travailler pour les éventuels autres certificats.

 

Journalisation

Dès lors qu’on va ajouter ou modifier les gabarits dans la forêt de ressources, il faudra déclencher une synchronisation des objets. La mise en place d’un compte de service disposant des privilèges appropriés est recommandé. Je recommande même d’encadrer l’exécution du script PowerShell avec le commandlet “Start-Transcript”.

TRACE0

 

Pour pouvoir journaliser tous les messages dans un fichier texte.

TRACE1

 

Cette phase d’industrialisation doit être accompagnée d’une supervision. Microsoft documente les différents évènements à suivre dans cet article Technet, Le dépannage est lui aussi disponible à cet emplacement.

 

La critique

La première critique que l’on pourrait formuler est que l’ensemble repose sur DCOM et donc sur les RPC. C’est vrai. Mais il est aussi possible d’utiliser les Web Proxy livrés avec le rôle ADCS. Par contre, la configuration sera juste un peu plus compliquée que celle présentée dans mon billet sur le sujet.

 

Benoits – Simple and Secure by Design  but Business compliant.

Windows 7 & Windows 2008 R2 service pack tip

Ca a beau être dimanche, c’est mon “Service Pack day”. Même si mes machines sont assez bien tenues à jour en terme de correctifs de sécurité, une bonne remise à niveau générale ne peut pas faire de mal.

 

Au vue des premiers retours, il ne semble pas avoir de problématiques liées à la mise en œuvre de ce Service Pack. Cependant, on est jamais assez prudent. On doit pouvoir revenir en arrière.

 

Cependant, si comme moi vos machines sont quelque peu limitées en terme d’espace disque (j’approche le Tera de machines virtuelles), il devient nécessaire de vite récupérer de l’espace disque. C’est que j’ai quelques snapshot à faire ces jours ci.

 

Pour cela, un petit coup de baguette magique avec “la commande “DSIM.EXE suivante :

SPUNSTALL

 

Note : Je vais enfin pouvoir installer le pilote vidéo sur le Windows Server 2008 R2 de mon portable .

 

Benoits – Simple and Secure by Design  but Business compliant.

Windows Command reference

Powershell est certainement l’avenir du scripting. Pourtant, celui-ci présente encore certaines lacunes. Comment manipuler des objets de sites avec le commandlet Active Directory? Il arrive encore souvent qu’ou doive encore faire référence aux bon vieux exécutables mis à disposition dans Windows pour les intégrer dans nos scripts PowerShell.

Pour cela encore faut-il qu’on connaisse l’existence de ces exécutables et savoir à quoi ils servent. Pour adresser cette problématique, Microsoft vient de mettre à disposition un fichier CHM présentant tous ces outils avec les syntaxes associées.

Benoits – Simple and Secure by Design  but Business compliant.