Robocopy, c’est vieux comme le monde. C’est fiable, jusqu’à un certain point, à savoir les derniers systèmes d’exploitation. En ayant fait l’amère expérience sur une bascule DFS (NTFRS vers DFS-R), il convient de clarifier un peu les choses :

• KB 973776 – The security configuration information, such as the ACL, is not copied if a backup operator uses the Robocopy.exe utility together with the /B option to copy a file on a computer that is running Windows Vista or Windows Server 2008 
• KB979808 – "Robocopy /B" does not copy the security information such as ACL in Windows 7 and in Windows Server 2008 R2

Avec cela, c’est fou ce que c’est plus facile de recopier les permissions NTFS. Au passage :

Robocopy.exe <source> <destination> /CopyAll /b /e /r:6

J’ai pas trouvé mieux pour la bascule DFS.

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

Lors de la conception d’une infrastructure Active Directory, une erreur à éviter, c’est de créer une forêt dite “single label”, ce qui signifie sans Top Level Domain. Cette approche était plus ou moins autorisée, avec des conséquences plus ou moins identifiées selon les produits. La KB2269838 résume parfaitement les problèmes de compatibilité pour les différents cas face aux produits Microsoft :

• Single labels domaine
• Disjointed Namespaces
• Discontiguous Namespaces

L’approche “Simple by Design” est donc plus que recommandée. Cela évitera les déconvenues. Donc “.Local” ou “.Lan” comme TLD, cela évitera bon nombre de problèmes.

Au passage, c’est mon 200ème billet sur ce blog, donc champagne et retour aux zerg! [|-)]

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

Coté montée en charge avec DirectAccess, jusqu’à maintenant, la seule possibilité consistait se reposer sur la fonctionnalité d’équilibrage de charge d’UAG.  De cette manière, on est capable de répartir la charge réseau entre les différents nœuds de la ferme UAG.

Cependant, cette approche présente une limite, à savoir la capacité de traitement CPU. Les tunnels IPSEC, c’est de la cryptographie, donc du temps processeur. Pour contourner cette limite, il est possible d’utiliser des carte réseaux permettant le déport des traitements IPSEC, mais on ne déporte pas tout.

Pour passer à la vitesse supérieure, il faut pouvoir déporter certaines fonctionnalité de DirectAccess sur un autre serveur. Par défaut, lors de la mise en œuvre de DirectAccess, notre serveur devient :

• Serveur et relai Teredo
• relai 6to4
• Serveur IP-HTTPS
• Routeur ISATAP
• Routeur IPV6 natif
• Passerelle IPSEC

Donc si on déporte, c’est du temps CPU économisé sur notre serveur DirectAccess. Pour l’instant, c’est disponible dans la documentation DirectAccess de Windows 2008 R2. Pour résumer ce qui va se passer, c’est que la stratégie de groupe qui configure le client DirectAccess va référencer un nouveau point de terminaison pour les tunnels IPSEC. Notre serveur DirectAccess ne fera office que de routeur.

Dès que j’ai un peu de temps, on reviendra dessus.

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

Avec l’assistant de mise en œuvre de DirectAccess de la console d’administration, on pourrait penser que dès lors qu’on passe la validation de tous les pré-requis et le l’activation se déroule sans problème on en a fini. Et bien non, il y a des cas où l’assistant ne voit pas tout car il ne teste pas tout.

Récemment, j’ai passé un temps fou à dépanner un labo DirectAccess qui refusait de fonctionner en IP-HTTPS. Pourtant toute l’installation s’est bien passée. Cela fonctionne en 6to4, en Teredo mais pas en IP-HTTPS. Après avoir exploré toutes les pistes, j’ai finalement décidé de prendre du recul avec le Best Practices Analyzer pour UAG disponible depuis début juin 2010. Et là, quel ne fut pas ma surprise :

C’est bien un problème de IP-HTTPS, plus précisément de certificat. Creusons un peu de ce coté en regardant quelques propriétés dont la localisation de la CRL :

Maquette de merde! Si la CRL n’est pas accessible, alors oui, le certificat sera reconnu comme invalide, donc IP-HTTPS est inutilisable. On peut le valider en tentant d’accéder à la CRL depuis mon serveur UAG en utilisant non pas le FQDN mais l’adresse IP :

Si on tente de résoudre le nom “pourri”, effectivement cela ne fonctionne pas.

Dès lors qu’on corrige le problème (référencement de l’hôte dans le fichier host, c’est moche mais je suis pressé!). Et oui, cela fonctionne.

Si on relance le BPA, son rapport nous indique que selon lui tout est maintenant opérationnel.

Conclusion

Monter des environnements de maquette est une chose, un environnement de production en est un autre. Dès lors que la maquette n’est pas suffisamment représentative, le moindre grain de sable peut tout bloquer. Au passage, une configuration normale pour ma PKI de maquette aurait été celle documenté dans mon billet “Publier une PKI sur Internet”.

Au passage, cela m’apprendra à ne pas relire les billets que je publie sur mon blog, à ne pas me fier qu’à mon seul neurone. Bon, je retourne à ma maquette en attendant l’ouverture des services de Starcraft 2.

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

C’est le dernier de la soirée, c’est l’été, donc on continue dans le digeste. C’est encore de la promo pour le blog de l’équipe UAG. La problématique pourrait sembler simple, mais pas tant que cela, la console Hyper-V a toujours été capricieuse au niveau réseau. Je vous laisse apprécier l’explication.

Note : On recommence le lourd bientôt, pensez à acheter de la RAM, elle va servir!

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

Encore une petite communication de l’équipe UAG, sur un sujet jusque là bien obscur, à savoir la montée en charge. Pour faire court, la performance du processeur et primordiale. Les facteurs limitant sont le carte à puce, NAP, le nombre de serveurs autorisés dans le tunnel d’infrastructure. Bref, il faut du costaud, coté :

• CPU
• Mémoire
• Interface réseau

Selon les chiffres, un “simple” bi-processeur à base d’Intel Xeon L5520 suffit pour tenir 2300 utilisateurs simultanés en accès distant.

Je veux le même à la maison!

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

Pour ceux qui comme moi vident un tube d’aspirine à chaque troubleshooting de DirectAccess avec UAG, une petite astuce. Si vous tentez de faire vos demande de certificats à votre autorité de certification interne après avoir installé UAG, on arrive sur ce problème :

Solutions :

• Option n°1, dite à la barbare : Arrêter le service “Microsoft ForeFront UAG Log Server” pour arrêter UAG et TMG pour pouvoir faire la demande de certificat. C’est ultra moche et ne résoud pas le problème à long terme.
• Option n°2 : Désactiver le Strict RPC Compliance dans TMG. C’est mieux

• Option 3 : Lire le billet Deep dive into UAG DirectAccess (Certificate Enrollment) de l’équipe produit.

Je vous laisse choisir, …

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

Dans la série quand c’est bien fait, c’est plus à faire. non seulement, le guide s’attaque à Exchange 2010 mais surtout aux deux moyens de le publier :

• Microsoft Forefront Threat Management Gateway
• Microsoft Forefront Unified Access Gateway 2010

Le document commence par opposer les deux produits. Mine de rien, il y a un monde entre les deux. Après, on rentre dans le brutal des eux produits (Surtout UAG), le tout lié à Exchange 2010. Bref, un must à lire posément.

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

Le ping est un outils de dépannage des plus basique dès lors qu’on parle de réseau. Cependant, dès qu’on est confronté au dépannage d’une infrastructure DirectAccess, cela se complique pas mal, et ce pour plusieurs raisons :

• La première raison, c’est que le trafic réseau ICMP (Ping) n’est pas inclus dans le tunnel. Ceci tiens au mode de fonctionnement de Teredo qui en a besoin pour son bon fonctionnement (si on désactive l’exception ICMP, on perd Teredo, …).
• La seconde raison, c’est que parce que le trafic ICMP n’est pas inclus dans le tunnel que cela peut induire en erreur. On peur très bien arriver à joindre un hôte sur le réseau interne sans pour autant être capable de monter le tunnel IPSEC  qui nous offre un accès complet (certificats invalides ou expirés; …).

Pour plus d’information, je vous invite à parcourir le dernier billet de Tom Shinder sur le sujet. Au passage, vous pourrez découvrir comment est construit une adresses IPV6 par NAT64/DNS64. Cela permet de valider qu’on a bien accès à une ressource IPV4 mises à disposition par les mécanismes NAT64/DNS64.

Bonne lecture,

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

Comme si ce n’était pas assez complet, Arnaud Jumelet vient de publier le détail du processus de localisation des contrôleurs de domaine. La on rentre dans le détail de la détermination du site Active Directory et ses subtilités (forcer un site Active Directory par exemple).

Bref, à conserver dans un coin.

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