Archives de catégorie : Windows Server 2012R2

Dépannage des publications Web Application Proxy avec Kerberos Constrained Delegation

Vous avez vraiment cru que je ferai un truc simple comme annoncé dans mon billet Kerberos Constrained Delegation avec Web Application Proxy expliquée? Je déconnais. L’application simple, c’est SharePoint 2013. J’avais déjà abordé Web Application Proxy dans le billet « Quand Windows Azure Pack rencontre Web Application Proxy (WAP versus WAP) » pour publier le portail est les API des tenant à l’extérieur. Ça c’était simple. Maintenant on passe la vitesse supérieure.

Pour ce billet, je pars du principe que les éléments suivants sont en place :

  • Vos contrôleurs de domaine reposent sur Windows Server 2012 minimum
  • Votre infrastructure ADFS est en place et opérationnelle (ADFS 3.0, donc Windows Server 2012 R2)
  • Votre serveur Web Application Proxy est déjà en place et membre du domaine
  • Votre infrastructure SharePoint 2013 est en place
  • Votre application dans SharePoint 2013 a été correctement configurée pour utiliser Windows Integrated Authentication (WIA) et plus précisément Kerberos

Coté SharePoint, je n’ai donc qu’un seul prérequis, mais un prérequis de taille, celui que notre front-end accepte d’utiliser des tickets Kerberos pour l’authentification et non pas du NTLM. En fait, rien que ça, c’est pas si simple que cela. De nombreux billets sont consacrés sur ce thème. Que l’admin SharePoint qui n’a pas transpiré lors de l’activation de l’authentification Keberos sur une ferme SharePoint se lève, je veux le voir, … Donc Si votre ferme SharePoint 2013 est correctement configurée, on peut continuer.

Pourquoi Kerberos?

Par défaut, SharePoint connais les méthodes d’authentifications suivantes :

  • Windows Integrated Authentication
  • Form-Based Authentication
  • SAML token-based authentication

Le dernier repose sur une mise en œuvre intégrée avec ADFS. Sur le papier c’est sexy mais c’est un poil compliqué à mettre en œuvre. Si nous n’avions que des utilisateurs externes (genre partenaires ça a du sens mais de moins en moins avec les solutions hybride). En plus dans un contexte de publication avec Web Application Proxy, c’est tellement simple à mettre en œuvre, presque trop simple.

Le Form-Based Authentication est le plus simple à mettre en œuvre mais dans ce cas, aucune chance de pouvoir faire de la pré-authentification en DMZ avec notre Web Application Proxy. Par exclusion, il ne reste qu’un seul choix : Windows Integrated Authentication.

WIA pour les intimes. Avec lui, on peut faire de la pré-authentification et même du SSO. Problème qui dit SSO, dit aussi Kerberos obligatoire. Le Windows Integrated Authentication n’est qu’un fournisseur qui permet de négocier une méthode d’authentification parmi une liste bien fournie :

  • Kerberos
  • NTLM
  • Digest
  • Basic

Exit les deux derniers et NTLM, on fait tout ce qu’on peut pour s’en débarrasser. Du point de vue de Web Application Proxy, on va fonctionner en Kerberos-Constrained Delegation. Cela signifie qu’une fois authentifié via l’ADFS Proxy (porté par WAP), le WAP va négocier et présenter un ticket Kerberos au nom de l’utilisateur connecté. Pourtant, celui qui fera la demande, c’est le compte de service ADFS. Si vous avez bien tout suivi, en toute logique, notre serveur WAP est donc membre du domaine ou alors membre d’un domaine avec lequel on dispose d’une relation d’approbation bidirectionnelle. Allez relire la section correspondante du document cité dans mon précédent billet.

Subtilités de mise en œuvre

La mise en œuvre est détaillé chez Microsoft à cette URL. Ça aide pas beaucoup pour SharePoint 2013. Une petite recherche sur Internet devrait vous aider sur ce sujet. Passons un peu de temps coté Web Application Proxy. Dans l’interface de configuration de WAP, on ne trouve pas le choix Kerberos Constrained Delegation. C’est vrai. Procédons par élimination. Si on choisissait « Pass-Throught », WAP ne serait utilisé que pour sa fonction de reverse-proxy HTTPS. L’authentification serait déportée sur le frontal SharePoint 2013, pas de Kerberos, pas de SSO. Logiquement, ce sera donc le choix « Active Directory Federation Services (ADFS).

clip_image001

 

Si on continue dans cette logique, on doit sélectionner un ADFS Relying Party. Dans une infrastructure ADFS 3.0 (Windows Server 2012 R2) fraichement installée, on nous propose un unique choix : Device Registration Service. Ce que nous recherchons, c’est une fournisseur d’identité auquel on va soumettre la demande d’authentification pour notre application publiée.

clip_image002

 

L’astuce, c’est comment faire consommer le Claims à notre SharePoint 2013 qui n’a aucune idée de ce que c’est. Lui, c’est WIA (Kerberos) ou rien. La réponse se trouve dans ADFS. Les applications dites « Claims-Aware » reconnaissent en ADFS un fournisseur d’identité de confiance qu’elles peuvent solliciter pour authentifier les utilisateurs. Pour cela on déclare un « relying Party » qui permet d’établir un lien de confiance entre l’infrastructure ADFS et l’application qui va venir consommer ce service. Le problème, c’est que notre SharePoint 2013, tel qu’il est configuré, il est tout sauf « Claims-Aware ». C’est pour cette raison que dans ADFS 3.0, on peut déclarer deux types de Trusts :

clip_image003

 

Les « Non-Claims Aware relying party trusts » ont été introduit pour les applications qui ne savent pas traiter les claims mais qui connaissent WIA. Le Welcome Screen du wizard de la console ADFS est très clair sur ce point.

clip_image004

 

Vu que notre application ignore le concept de claims, on a pas besoin de décrire le contenu du claims à construire, ni à configurer la dite application pour utiliser notre infrastructure ADFS comme fournisseur d’authentification. Les options configurables sur un « Non-Claims Aware relying party trust » sont :

  • Un nom unique clairement identifiable
  • Le fait d’utiliser un facteur d’authentification tier (Multi-Factor Authentication) et les exigences qui vont avec

 

Au final, notre utilisateur obtiendra bien un claims ADFS mais vu qu’il aura été délivré par un Relying Party ne supportant pas les Claims, notre serveur WAP devra jouer de sa personne et obtenir un ticket Kerberos pour le compte de l’utilisateur. C’est là que la Kerberos Constrained Delegation rentre en jeu.

Quelques points de configuration

Pour pouvoir déboguer le bouzin, il faut déjà avoir du contenu. Le problème, c’est que dans sa configuration par défaut, notre infrastructure ADFS ne journalise pas tout. Un peu de Powershell Get-AdfsProperties | Select Loglevel. Rien sur les authentification en elle-même, aucune trace des accès réussi ou des échecs. Certes on pourra retracer les jeton Kerberos mais si c’est pas Kerberos qui est en cause, ça va pas nous aider.

clip_image005

 

Pour cette raison, je recommande de reconfigurer l’attribut LogLevel de la manière suivante : Set-AdfsProperties -LogLevel $((Get-AdfsProperties).LogLevel + « SuccessAudits » + « FailureAudits »)

Get-AdfsProperties | Select Loglevel

clip_image006

 

Qu’est-ce que ça change me direz-vous. Tout.

clip_image007

 

On découvre qu’on est maintenant en mesure de journaliser les authentifications réussies et échouées mais qu’il faut encore un peu plus de travail. Plus précisément, il faut permettre à ADFS de générer des évènements dans le journal de sécurité, c’est un droit qui a été octroyé lors de l’installation d’ADFS. Le compte de service utilisé par ADFS a été configuré pour avoir le privilège de générer des évènements de sécurité.

clip_image008

Note : Si vous avez des GPO qui configurent les droits utilisateurs, pensez à repositionner le privilège, sinon ADFS n’aura rien à vous dire.

Enfin, il faut indiquer ce que l’on veut auditer. Pour les applications, on a un journal spécial nommé « Application Generated ». Avec la commande AuditPol.Exe, on constate que par défaut, ce journal ne contiendra rien. AuditPol.Exe /Get /Subcategory « Application Generated ».

clip_image009

 

Avec un peu de configuration, on arrive à corriger cela.

AuditPol.Exe /Set /SubCategory: »Application Generated » /Success:Enable /failure:Enable

AuditPol.Exe /Get /Subcategory « Application Generated »

clip_image010

 

Dans la GPO locale, c’est plus clair :

clip_image011

 

Pourtant, il reste une subtilité. Nous sommes dans la section « Advanced Audit Policy Configuration » introduite avec Windows Server 2008 R2. Si on remonte d’un niveau, on voit bien que le paramètre précédemment configuré est bien présent. Ce qui m’intéresse, c’est l’avertissement.

clip_image012

 

Allons voir le paramètre qui manque. On a donc besoin de lui.

clip_image013

 

Suivi de bout en bout

Maintenant qu’on a de quoi journaliser les accès, voyons à quoi ressemble un accès utilisateur fonctionnel depuis le Web Application Proxy pour notre application SharePoint 2013 publiée. La première trace, c’est sur le serveur ADFS qu’on va la trouver. C’est notre point de départ. La chose à noter ici, c’est l’Activity ID. Il est unique pour chaque accès, c’est donc lui qui nous permettra de relier les évènements.

clip_image014

Note : L’évènement 403 référence une autre information importante : L’adresse IP source de la demande, donc de notre client.

En suivant l’Activcity ID, on trouve l’évènement 410. Son intérêt, c’est de savoir par quel Endpoint la demande d’accès est arrivée. Avec une infrastructure basique composée d’un seul serveur ADFS c’est facile mais si on a une infrastructure utilisant plus de cinq serveur ADFS (on utilise donc plus le Windows Integrated Database mais une véritable instance SQL Server), ça se complique. En plus, c’est Event nous précise que la demande est arrivée par le serveur Web Application Proxy. C’est un attribut qui sera référencé dans le claims. C’est que qui permettra par exemple d’exiger une authentification additionnelle tel que Multi-Factor Authentication (MFA).

clip_image015

 

Coté ADFS, l’évènement 412 nous indique qu’un jeton a été délivré par notre infrastructure ADFS. L’Activity ID que nous connaissons déjà nous permet de suivre le cheminement de notre demande d’accès. Maintenant, on va garder l’attribut Instance ID dans un coin de notre tête.

clip_image016

 

Car on va suivre l’évènement 501 ou plutôt les évènements 501. Si toutes les informations ne peuvent figurer dans un même évènement, on en aura donc plusieurs. Le lien entre eux, ce sera notre Instance ID. ADFS nous donne le contenu du claims, aussi bien les attributs contenus que les valeurs associées.

clip_image017

 

Dans mon cas, cet évènement est intéressant car il indique les groupes dont mon utilisateur est membre (attribut GroupSid).

clip_image018

 

A ce stade, notre infrastructure ADFS a délivré un claims. Or, notre infrastructure sait que notre application n’est pas Claims-Aware. Elle doit donc demander un ticket Kerberos pour le compte de l’utilisateur qu’elle vient d’authentifier. Sur nos contrôleurs de domaine, on va donc trouver le trace d’un évènement 4768. C’est juste la demande. Au passage, on remarque que celle-ci a été réalisée localement par la mention ::1. Ben oui, sur ma maquette, mon ADFS est installé sur mon contrôleur de domaine, je sais c’est mal.

clip_image019

 

Toujours sur nos contrôleurs de domaine, l’évènement 4769, nous donne un peu plus d’informations, genre l’UPN de l’utilisateur qui fait la demande de ticket Kerberos.

clip_image020

 

C’est maintenant qu’on sait si la délégation Kerberos fonctionne. Notre ADFS tente de l’utiliser pour s’authentifier. On voit bien que c’est le process « C:\Windows\ADFS\Microsoft.Identity.Server.ServiceHost.Exe » qui fait la tentative.

clip_image021

 

L’évènement 4624 nous confirme que la demande d’authentification utilisant mon identité a bien fonctionné. L’évènement précise bien que c’est le compte de service ADFS qui a obtenu une ouverture de session pour mon compte.

clip_image022

 

Dernière étape, le Web Application Proxy. Ça se passe dans le journal « Microsoft-Windows-Web Application Proxy/Admin ». Jusqu’à maintenant mon Web Application Proxy se contentait de jouer son rôle de Proxy ADFS. Maintenant c’est au tour de la publication. Suite à l’authentification, le WAP connecte l’utilisateur en utilisant le Claims ADFS précédemment obtenu. C’est l’évènement 12027 qui va nous intéresser.

clip_image023

 

Pour finir avec l’évènement 14008 qui nous indique que le Web Application Proxy a réussi à présenter le ticket Kerberos obtenu par notre ADFS. On notera que le mode d’authentification auprès du back-end server est bien « Windows Integrated Authentication (WIA) »

clip_image024

 

A ce stade, Web Application Proxy a fini son travail. Si cela échoue à ce niveau, c’est que l’utilisateur connecté n’a pas accès. Il est peut-être pas membre des bons groupes. Si la négociation venait à échouer, c’est que la délégation Kerberos n’est pas correctement configurée, on a alors l’évènement 13022.

clip_image025

Note : Un truc tout bête mais lorsqu’on met en place une nouvelle publication qui repose sur le KDC, on met donc en place de nouveaux SPN sur notre serveur WAP. Pour que ceux-ci soient pris en compte, encore faut-il redémarrer le serveur WAP. Merci pour ce rappel Maxime RASTELLO.

Si cela ne fonctionne toujours pas, il faut se poser les bonnes questions. Pour cela, le document publié par l’équipe produit est excellent. Tout est dit dans l’illustration ci-dessous : clip_image026

 

Conclusion

Si par malheur, notre mise en place ne fonctionne pas avec SharePoint 2013 ou tout autre application, commencez par séparer les problèmes. D’un côté assurez-vous que lorsque vous vous connectez, il y a bien un jeton Kerberos d’obtenu et de présenté, de l’autre utilisez une ressource plus simple que SharePoint 2013 pour tester. Pour cela, je conseille de mettre en œuvre un simple site web IIS tel que documenté ici : Walkthrough Guide: Connect to Applications and Services from Anywhere with Web Application Proxy.

 

Bonus Track

Pour le bonus track, j’ai retenu Windows XP. Par défaut, cela ne fonctionne pas pour ces clients, au motif que seuls les clients supportant SNI sont supportés. Si on observe notre publication WAP au travers d’un outil tel que celui de Qualys SSL Labs. On observe le résultat illustré ci-dessous :

clip_image027

 

Par défaut, c’est donc pas possible. La solution, c’est le mode FallBack de SNI que l’équipe en charge de Web Application Proxy a documenté dans ce billet : How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Software-Defined Storage Design Calculator

Avec la génération Windows Server 2012 / 2012 R2, Microsoft a introduit une nouvelle approche du stockage (qui se poursuivra dans Windows Server 2016) basé sur du JBOB et mis en avant avec les fonctionnalités suivantes :

  • Shared Cluster Volume
  • Scale-Out File Server
  • Storage Pool
  • Storage Spaces

Le tout avec une pointe de tiering SSD pour un stockage bien frappé. Cette nouvelle approche du stockage manquait d’information quant à son design. On dispose maintenant d’un Software-Defined Storage Design Calculator, un peu comme le Storage Calculator pour Exchange. Au moment où j’écris ce billet, c’est déjà la version 1.1 qui est disponible. Logiquement, il est très orienté pour les charges applicatives hébergées sous Hyper-V. Pour commencer, nous devons commencer par causer matériel. Cela implique de :

  • Choisir un template (Pour info le 4 nœuds * 4 châssis, c’est l’architecture stockage de CPS qui envoie du poney)
  • Estimer la consommation en pic de la charge applicative que l’on va héberger
  • Estimer la consommation moyenne de la charge applicative que l’on va héberger
  • Fournir les informations concernant le stockage (nombre de disques, capacité brute, nombre de tiroirs, contenu des tiroirs, …)

clip_image001

Note : Attention, avant de commencer, assurez-vous de disposer de la dernière version du fichier disponible à cette adresse.

Vous disposerez d’une première estimation qu’il faudra affiner avec votre fournisseur favori. A un moment, il faudra valider les hypothèses de calcul et se confronter à la réalité. Pour cela, une bonne adresse à conserver : Server and Storage I/O Benchmarking and Performance Resources. Y a tout ce qu’il faut pour casser du disque. Pour finir quelques conseils :

  • Attention à la taille des clusters pour le formatage
  • Attention aux optimisations matérielles réseau
  • Un antivirus sur un Hyper-V ca peut être fatal avec le SCV. Chaque nœud du cluster peut scanner le même fichier

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Publier une PKI sur Internet (republication)

En lisant le billet de mon collègue Alexandre GIRAUD sur le processus de demande de certificats pour IIS 7.0, je me suis rendu compte que souvent, nos clients ont besoin de certificats mais sont rebutés par la mise en œuvre. Une des principales problématiques se situe au niveau de la publication des listes de révocation à l’extérieur de l’entreprise. Si un système d’exploitation n’est pas capable de télécharger les listes de révocation, il ne peut déterminer si un certificat donné est toujours valable ou non. Or, il y a de plus en plus de scénarios (Windows, Exchange 2007, SCCM 2007, SCOM 2007, …) qui nécessitent la mise en œuvre d’une PKI.

 

Avertissement

Attention, ce billet n’est pas censé se substituer à une réelle mise en œuvre d’une infrastructure PKI. C’est juste un raccourci pour couvrir un certain nombre de scénarios et répondre uniquement au besoin technique (obtenir des certificats), l’aspect fonctionnel est volontairement négligé. L’aspect technique a lui aussi été épuré. Je renvoie donc les puristes vers le “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” ainsi que  l’indispensable référence sur la PKI Microsoft : Windows Server 2008 PKI and Certificate Security de l’immense Brian Komar.

Donc ce qui va suivre est volontairement une forme simplifiée de mise en œuvre de PKI. J’espère que les puristes ne m’en voudront pas.

 

Installation du rôle ADCS

Pour la majorité de nos besoins en certificats, nous avons besoins d’une autorité de certification intégrée à l’annuaire Active Directory (le scénario NAP IPSEC par exemple repose sur une autorité de certification autonome).

Mais alors pourquoi installer le rôle “Certification Authority Web Enrollment”? D’une part, on pourrait en avoir besoin pour certains scénarios, d’autre part, cela m’évite de créer un fichier “CAPOLICY.INF” pour personnaliser la mise en œuvre de mon autorité de certification.

clip_image001

 

Comme indiqué plus tôt, mon choix se porte une une autorité de type “Entreprise”, donc intégrée à l’annuaire Active Directory. On en verra les conséquences plus tard dans ce billet. Pour ceux qui veulent se faire mal, il peuvent consulter le WebCast de François LASSERRE des TechDays 2009.

clip_image002

 

Pour la notion de hiérarchie, on va faire très simple, un seul niveau, donc RootCA.

clip_image003

 

Toujours pour simplifier, je nomme mon autorité de certification RootCA.

clip_image004

 

Pour le chemin de la base de données de l’autorité de certification ou son journal de transaction, je conserve les choix par défaut.

clip_image005

 

Le résumé nous présente la liste des modules de IIS. Les choix proposés me conviennent parfaitement pour l’autorité racine, puisque c’est le choix minimum pour notre cas, donc secure!

clip_image006

 

Une fois l’installation terminée, on peut constater que notre PKI est bien opérationnelle et que ses informations sont publiées mais uniquement localement. La CRL est uniquement publiée dans un chemin HTTP.

clip_image007

 

Jusque là tout va bien. C’est simple finalement la PKI?

Optionnellement, on va configurer l’enregistrement et le renouvèlement automatique de certificats dans la stratégie de groupe “Default Domain Policy”. Ceci permettra aux systèmes d’exploitation clients ainsi qu’aux utilisateurs d’obtenir des certificats automatiquement.

clip_image008

 

Personnaliser les extensions

C’est par là que tout passera. Un raccourci pourrait consister à publier les URL de l’AIA et de la CRL avec ISA Server ou son successeur mais, du pointe de vue de la sécurité, c’est pas terrible. On va donc ajouter les extensions pour publier l’AIA et la CDP sur un serveur tiers que l’on pourra lui publier via ISA Server vers l’extérieur.

clip_image009

 

On constate maintenant la raison de mon choix d’installer le “Certification Authority Web Enrollment”. Si je ne l’avais pas installé, l’installation par défaut du rôle ADCS aurait du être corrigé pour ne pas publier l’AIA et la CDP sous forme HTTP. Il aurait été nécessaire de générer un fichier “CAPolicy.INF”. Je suis en vacances donc, on fait court!

clip_image010

 

Ajoutons notre première extension, à savoir la localisation de notre liste de révocation. Celle-ci devant être accessible d’extérieur, c’est nécessairement un nom pleinement qualifié qui doit être référencé, sous forme d’une URL HTTP. La chaine de caractère illustrée ci-dessous est générique. Elle permet surtout de publier plusieurs listes de révocations à un même emplacement.

clip_image011

 

Note : N’essayer pas de publier en HTTPS surtout avec un certificat issu de votre propre PKI, c’est pas marrant. Comment peut-on vérifier la liste de révocation si on ne peut pas y accéder, on part en boucle!

Subtilité, cet emplacement sera configuré pour stocker les CRL. Par extension, les clients pourront y trouver aussi les CRL “Delta” (qui seront publiées au même emplacement).

clip_image012

 

Voila pour l’accès extérieur mais encore faut-il que notre autorité de certification publie les informations à cet emplacement. Pour cela, on va lui indiquer un chemin UNC (qui correspondra au répertoire virtuel dans IIS) dans lequel l’autorité de certification pourra mettre à disposition les informations nécessaires.

clip_image013

 

Le partage référencé contiendra aussi bien les CRL que les CRL “Delta”.

clip_image014

 

Reste plus qu’à redémarrer le rôle ADCS pour prendre en compte les nouvelles extensions.

clip_image015

 

Voyons voir ce que cela a changé pour l’autorité de certification.

clip_image016

 

On constate qu’il y a bien un nouvel emplacement de publication “externe” pour notre autorité de certifications. Cependant, il ne semble pas opérationnel. A ce stade, c’est normal. Les raisons de cette erreurs sont multiples :

1. La résolution de noms DNS externes n’est peut être pas configurée

2. Le serveur sur lequel on doit publier nos informations n’est pas encore configuré

3. On na pas encore de liste de révocation à publier puisque pas encore de certificats révoqués

 

La résolution de noms externes

Pour que le monitoring de la PKI ne remonte pas d’erreur, il est nécessaire que l’autorité de certification puisse résoudre le nom pleinement qualifié de l’emplacement de publication HTTP. On peut  :

1. Autoriser nos serveurs DNS à joindre les RootHints

2. Configurer nos serveurs DNS pour utiliser des redirecteurs DNS

3. Créer une zone DNS représentant le nom DNS extérieur tel qu’illustré ci-dessous

clip_image017

 

Pour le choix, c’est vous qui voyez!

 

Configuration de la publication

Après l’autorité de certification, passons au serveur sur lequel on va publier les informations. Dans mon cas, j’ai retenu un Windows Server 2008 édition standard. Le choix “full GUI” ou “Core” m’importe peu, cela fonctionne dans les deux cas. Dans ce billet, je ne traiterai que le “Full GUI”, le plus communément

L’autorité de certification va publier dans un partage. Encore faut-il que celui-ci existe? Il sera configuré pour accorder le contrôle total au compte ordinateur de l’autorité de certification.

clip_image018

 

Les informations devant êtres accessibles depuis l’extérieur au format HTTP, nous avons donc besoin d’un serveur web mais uniquement le stricte minimum.

clip_image019

 

Etant donné que je n’ai pas demandé l’installation des outils d’administration de IIS, j’ai quand même besoin d’installer les outils d’administration de IIS en ligne de commande :

clip_image020

 

Notre partage doit disposer des permissions tel qu’illustré ci-dessous (Oups pas core!):

clip_image021

 

Reste plus qu’à créer le répertoire virtuel CRLD tel que déclaré dans l’extension de l’autorité de certification et d’y autoriser le parcours de répertoire (Attention à bien avoir installé les outils d’administration et se positionner dans le sous répertoire %Windir%\System32\InetServ!). La dernière ligne est une subtilité. Elle permet l’utilisation du caractère “+” par le client pour demander la CRL Delta.

clip_image022

 

Pour ceux qui veulent en savoir plus : How to avoid Delta CRL download errors on Windows Server 2008 with IIS7 (Merci Stan!). C’est fini? Nan, par ce que cela ne marche pas encore tout de suite.

 

Dernière passe sur ADCS

On a beau avoir tout mis en place, la console ADCS nous remonte toujours une erreur (Pourquoi tant de haine?).

clip_image023

 

Si on regarde de plus près, un accès HTTP nous retourne l’erreur 404. ce qui signifie que le répertoire est vide.

clip_image024

 

A ce stade, c’est normal, mon autorité de certification n’a pas encore délivré de certificat, donc il n’y a pas eu de révocation, donc pas de liste publiée. Même si la liste est vide, on va quand même demander la publication. Attention, cependant, une liste de révocation reste valide jusqu’à son expiration. La révocation de certificat n’est donc pas instantanée. Pour cela, il faut aller faire un tour du coté de OCSP (Attention, aspirine à prévoir!).

clip_image025

 

Et si tout est opérationnel (veillez à sacrifier une souris au dieux de l’informatique, cela sert toujours), le répertoire doit maintenant être peuplé d’une CRL et une DRL “Delta”.

clip_image026

 

Coté supervision de ADCS, tout est maintenant opérationnel. Notre PKI est maintenant accessible de l’extérieur. Pour finaliser la configuration, une petite publication HTTP avec ISA devrait faire l’affaire.

clip_image027

 

Comment prouver que cela fonctionne?

Bonne question. Une simple commande CERTUTIL permet de demander le téléchargement des CRL et CRLD depuis l’URL extérieure.

clip_image028

 

Conclusion

Ce billet est une réponse technique pour la mise en œuvre d’une PKI pour un besoin “Microsoft”. Cela ne se substitue pas à un réel projet PKI. Je n’ai fait ici qu’effleurer un scénario d’usage de la PKI Microsoft. Les usages des certificats sont très nombreux. l’utilisation des certificats augmentant avec le temps (Windows 2008 R2, Geneva, Exchange 2010?, …), il devient urgent d’intégrer les aspects fonctionnels autour de la sécurité dans nos projets.

Maintenant que c’est aspect a été démystifié, il n’y  plus de raison d’utiliser des certificats pour ADDS, TS Gateway, WINRM, SCVMM, SCOM, SCCM et tout les autres produits qui ne demandent que cela.

Benoîts – Mode Vacances (Pas possible!) + U2 (Yeah!)

Web Application Proxy erreur 0x8007520C

Ça faisait quelques temps que j’avais pas mis les mains dans ma plateforme Windows Azure Pack. C’est lors de la séquence de patch management mensuelle que je suis tombé sur ce problème.

Problème

Mon WAP (Web Application Proxy) qui ne démarrait plus.

clip_image001

Dans les faits, le service ADFS (adfssrv) est bien démarré mais le service Web Application Proxy (AppProxySvc) refuse de démarrer. Il indique même une erreur 401. En cherchant un peu dans le journal « AD FS/Admin », on nous parle d’accès refusé (ce qui correspond au code erreur 401) et d’une empreinte de certificat.

clip_image002

Sur la ferme ADFS, on trouve une erreur en corrélation qui fait référence au même certificat avec la même empreinte numérique.

clip_image003

Analyse

On sait maintenant que cela concerne le certificat « ADFS ProxyTrust -WEBAPPROXY ». On voit bien que cela concerne un certificat auto-signé, dont la durée de vie est de quelques jours (10 jours). Vu que mon infrastructure a été offline pendant plus de 10 jours, il est logique que le certificat ne soit plus valide. Ce qu’on a du mal à comprendre, c’est de ne pas retrouver le certificat en question sur le serveur Web Application Proxy. Avec un peu de lecture ici et là, on finit par tomber sur ce billet de l’équipe produit : Understanding and fixing Proxy Trust CTL Issues with AD FS 2012 R2 and Web Application Proxy.

On y découvre que c’est bien un problème d’authentification par certificat. Le certificat auto-signé généré lors de la configuration du Web Application Proxy doit normalement être injecté dans la configuration de la ferme ADFS ainsi que dans le magasin de certificats AdfsTrustedDevices des serveurs de la ferme ADFS. Allons faire un tour dans le magasin certificats de notre serveur Web Application Proxy pour retrouver notre certificat auto-signé :

Get-ChildItem Cert:\LocalMachine\My | Where {$_.Subject -match « CN=ADFS ProxyTrust »} | Format-Table -Property Subject, NotBefore, NotAfter, Thumbprint -Autosize

clip_image004

 

Correction

Il y a beaucoup trop de certificats auto-signés. Beaucoup de tentatives pour corriger le problème mais sans résultat. Le message sur la ferme ADFS nous recommande de refaire l’initialisation du Web Application Proxy, c’est ce que nous allons faire. Pour cela un peu de Powershell pour retrouver le certificat public que nous avons utilisé pour publier notre infrastructure ADFS :

Get-ChildItem Cert:\Localmachine\My | Where {$_.Subject -match « CN=adfs.Windowsazurepack.Fr »} | Format-Table -Property Subject, Thumbprint

$Cred = Get-Credential

Install-WebApplicationProxy -FederationServiceName ‘adfs.windowsazurepack.fr’ -FederationServiceTrustCredential $cred -certificateThumbprint ‘XXXXXXXXXXX’

clip_image005

Maintenant le service est de nouveau opérationnel. Sur la ferme ADFS, on peut constater la présence d’un nouveau certificat auto-signé sur notre serveur Web Application Proxy.

clip_image006

On retrouve la trace de ce même certificat auto-signé dans le conteneur ADFSTrustedDevices sur ma ferme ADFS.

clip_image007

Le Web Application Proxy est de nouveau opérationnel.

clip_image008

Dans le journal « AD FS/Admin », on constate la présence de l’évènement 245, qui reviendra cycliquement toutes les minutes. C’est ce qui nous indique que le Web Application Proxy est bien opérationnel pour sa fonction Proxy de l’infrastructure ADFS.

clip_image009

Ainsi que l’Event 396, nous indiquant que le certificat auto-signé nouvellement généré est bien reconnu par notre ferme ADFS pour authentification.

clip_image010

Conclusion

Ce problème amène deux réflexions :

  • Si votre maquette ADFS n’est pas online en permanence, oubliez le Web Application Proxy dans votre lab.
  • Quand on va renouveler le certificat public de l’infrastructure ADFS, va y avoir un peu de travail

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

DFSR Dirty Shutdown Recovery

Un sujet un peu “capilo-tracté” pour changer et un petit retour aux sources (Active Directory). Qu’est ce qui se passe au niveau DFSR lors d’un arrêt non planifié d’un contrôleur de domaine ou d’un serveur hébergeant le rôle DFS-R et participant à un groupe de réplication.

Pour rappel DFSR repose sur une base de données Jet qui va tracer tous les changements opérés sur les fichiers dépendant d’un replicated folder donné localisé sur un volume disque particulier. On comprend tout de suite que le bon fonctionnement de cette base de données est essentiel. Sans elle, DFSR n’est plus capable de répliquer les changements opérés localement ou de déterminer s’il doit prendre en comptes les mises à jour opérées sur les autre membres du groupe de réplication.

 

Avant c’était simple

DFSR a été introduit avec Windows 2003 mais réellement généralisé à partir de Windows Server 2008 où il était possible de basculer le SYSVOL vers DFSR avec l’utilitaire DFSRMIG.EXE. Depuis cette époque, lors d’un arrêt non planifié, on avait le message suivant dans le journal dédié à DFSR :

image

 

C’est clair, rien à faire, le système d’exploitation s’occupe de tout. Si le processus de recovery se passait bien, on avait un event 2214 :

image

 

ou 2216 dans le cas contraire :

image

Dans les deux cas, on n’avait rien à faire, DFSR s’occupait de tout. Mais ça c’était avant.

 

Mais c’était avant (2008 R2/2012)

Avec Windows Server 2012, Microsoft a considéré qu’il y avait un risque de perdre des données et que par défaut DFSR ne devait plus auto-réparer sa base de données.

image

 

L’event donne deux informations :

  • Premièrement, il faut que nous nous assurions de ne pas perdre de données lors de la remise en ligne, c’est de notre responsabilité
  • Deuxièmement, que la remise en ligne s’effectue à l’aide d’une ligne de commande qui doit être exécutée localement sur le serveur incriminé.

 

Cela devient problématique car en cas de crash d’un contrôleur de domaine, Active Directory est bien capable de revenir en ligne, le répertoire SYSVOL est bien partagé et visible par les utilisateur mais le contenu des GPO peut avoir été altéré et ne plus être cohérent avec les autres contrôleurs de domaine.

 

Comme Microsoft est cohérent, il a mis à disposition un correctif KB2663685 pour Windows 2008 R2 pour reproduire le mode de fonctionnement de Windows Server 2012. Tant que le correctif n’est pas généralisé sur tous les serveurs membre du groupe de réplication DFSR, le comportement du processus de recovery va donc varier. ce correctif permet aussi de configurer le comportement du processus de recovery avec la commande suivante :

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE/TRUE

 

Maintenant c’est subtil (2012 R2)

Comme c’était pas encore assez compliqué, on change encore. Il faut lire un billet décrivant les changements opérés sur DFSR dans Windows 2012 R2 pour le comprendre :

clip_image002

 

Il faut comprendre que Microsoft a mis à disposition une clé de registre pour configurer le comportement de DFSR dans le scénario du “Dirty shutdown” mais n’a pas réussi à démontrer qu’il y a réellement risque de perte de données. La racine DFS de domaine gui prend en charge la réplication de SYSVOL échappe au processus de “Dirty shutdown”. Seulement pour lui, le recovery redevient automatique. C’est une bonne nouvelle pour les administrateurs Active Directory qui n’ont plus à se soucier du “Dirty shutdown” sur les contrôleurs de domaine Windows Server 2012 R2 (uniquement).

 

Conclusion

J’avais bien annoncé que le sujet était “capilo-tracté”. Donc pour faire simple un petit tableau pour résumer la situation :

  Windows 2008 Windows 2008 R2 (sans KB2663685) Windows 2008 R2 (avec KB2663685) Windows 2012 Windows 2012 R2
Automatic Dirty shutdown recovery pour SYSVOL Oui Oui Non Non Oui

Non sauf reconfiguration avec WMIC

 

BenoîtS – Simple and secure by Design but business compliant