Windows Server 2012 R2 introduit un certain nombre de modifications en profondeur dans le fonctionnement d'AD FS. Cela signifie qu'en tant que praticiens, nous devons rechercher des solutions aux problèmes rencontrés dans de nouveaux endroits inattendus. Par exemple, dans l'ancien monde, si AD FS était complètement insensible, le premier endroit où je prendrais soin d'AD FS lui-même serait IIS. Dans AD FS 2012 R2, IIS ne joue aucun rôle. Les requêtes sont toujours traitées par le pilote de noyau HTTP.SYS, mais nous interagissons avec lui à l’aide de NETSH HTTP, qui se connecte au pilote via l’API de serveur HTTP en mode utilisateur. Auparavant, IIS et d'autres composants familiers interagissaient également avec cette API, mais ils fournissaient une couche d'abstraction plus conviviale entre un administrateur et l'API. Interaction avec HTTP.SYS à l'aide de NETSH HTTP apporte une courbe d'apprentissage, en particulier lorsqu'il s'agit de comprendre ce qui est contrôlé et ce qui ne l'est pas. En outre, il n'y a pas d'interface graphique et la sécurité appliquée par HTTP.SYS est plus stricte que la couche abstraite qu'IIS a historiquement ouverte. Ce changement d’architecture de serveur Web et d’autres nouvelles différences ajoutent à la difficulté de dépister les problèmes lorsque les choses ne fonctionnent pas comme prévu, comme indiqué dans cet article.\nMise à jour du certificat de communication de service, du nom de service de fédération et de l'identificateur\nLors de la mise à jour de l'URL d'un service AD FS, les premières et les plus évidentes choses à modifier sont le certificat, le nom et l'identifiant de communication de service. Il s’agit de toutes les modifications exposées via la console d’administration AD FS ou via Set-ADFSProperties et Set-ADFSCertificate.\nMise à jour: 14 janvier 2015Il y a quelques semaines, Adam Lepkowski a recommandé une amélioration de cette section avec l'applet de commande Set-AdfsSslCertificate, qui résout certaines des lacunes que je décris ci-dessous. Par souci de cohérence, je laisserai mes mots intacts et inclurai ici le commentaire d’Adam en tant qu’amélioration dont tout le monde peut tirer parti. Je pense que le fait de voir mon approche la plus sobre aide à révéler ce qui se passe sous le capot. Je ne changerai donc pas ce contenu, mais j’utiliserai moi-même la méthode d’Adam à l’avenir.\nCommentaire / approche d’Adam Lepkowki:
"},{"id":"text-2","type":"text","heading":"","plain_text":"Adam Lepkowski a déclaré:31 décembre 2014 à 7h36\nLa liaison SSL peut être ajoutée de la manière suivante:– Exécutez Set-AdfsSslCertificate -Thumbprint thumbprint_hereCette commande ajoutera de nouvelles entrées pour les ports 443 et 49433 et mettra à jour la liaison localhost existante.\nMalheureusement, vous devez toujours supprimer l'ancienne liaison manuellement:netsh http delete sslcert hostnameport = sts..com: 443netsh http delete sslcert hostnameport = sts..com: 49443","html":"Adam Lepkowski a déclaré:31 décembre 2014 à 7h36\nLa liaison SSL peut être ajoutée de la manière suivante:– Exécutez Set-AdfsSslCertificate -Thumbprint thumbprint_hereCette commande ajoutera de nouvelles entrées pour les ports 443 et 49433 et mettra à jour la liaison localhost existante.\nMalheureusement, vous devez toujours supprimer l'ancienne liaison manuellement:netsh http delete sslcert hostnameport = sts..com: 443netsh http delete sslcert hostnameport = sts..com: 49443
"},{"id":"text-3","type":"text","heading":"","plain_text":"Retour à l'article d'origine…\nPour plus de simplicité, je vais montrer les écrans de l’interface graphique ici:","html":"Retour à l'article d'origine…\nPour plus de simplicité, je vais montrer les écrans de l’interface graphique ici:
"},{"id":"text-4","type":"text","heading":"","plain_text":"NB: Je ne recommande pas d’utiliser .local. C’est en fait un domaine dans lequel nous nous sommes éloignés, mais pour cet article, il était plus facile pour moi d’utiliser ces ressources.\nQuoi qu’il en soit, ces changements fonctionnent, comme ils l’ont toujours fait. Nous pouvons voir les changements dans Get-ADFSProperties et Get-ADFSCertificate clairement après les avoir faites.","html":"NB: Je ne recommande pas d’utiliser .local. C’est en fait un domaine dans lequel nous nous sommes éloignés, mais pour cet article, il était plus facile pour moi d’utiliser ces ressources.\nQuoi qu’il en soit, ces changements fonctionnent, comme ils l’ont toujours fait. Nous pouvons voir les changements dans Get-ADFSProperties et Get-ADFSCertificate clairement après les avoir faites.
"},{"id":"text-5","type":"text","heading":"","plain_text":"Cependant, comme auparavant, nous devons également appliquer ces modifications à l'infrastructure sous-jacente. Dans le passé, il s’agissait de mettre à jour la liaison de IIS, mais il faut maintenant invoquer le NETSH HTTP commandes pour interagir avec HTTP.SYS. le NETSH HTTP SHOW URLACL Cette commande dévoile des écouteurs, mais par défaut, AD FS réservera un écouteur générique (+) pour un port et un chemin, par exemple https: // +: 443 / adfs / ou https: // +: 49443 / adfs /, de sorte qu'il rien à changer pour les en-têtes d'hôte (réservations d'URL).","html":"Cependant, comme auparavant, nous devons également appliquer ces modifications à l'infrastructure sous-jacente. Dans le passé, il s’agissait de mettre à jour la liaison de IIS, mais il faut maintenant invoquer le NETSH HTTP commandes pour interagir avec HTTP.SYS. le NETSH HTTP SHOW URLACL Cette commande dévoile des écouteurs, mais par défaut, AD FS réservera un écouteur générique (+) pour un port et un chemin, par exemple https: // +: 443 / adfs / ou https: // +: 49443 / adfs /, de sorte qu'il rien à changer pour les en-têtes d'hôte (réservations d'URL).
"},{"id":"text-6","type":"text","heading":"","plain_text":"D'autre part, il peut être nécessaire de mettre à jour les liaisons SSL et de les configurer de manière beaucoup plus stricte que celle que nous voyons normalement dans IIS (sauf si nous utilisons SNI). En effet, la configuration HTTP.SYS par défaut dans Windows Server 2012 R2 suppose l'utilisation d'extensions TLS telles que SNI. En utilisant le NETSH HTTP SHOW SSLCERT Je vais voir que ma configuration actuelle fait toujours référence aux liaisons SSL de mon ancien certificat SSL et de mes anciennes URL.","html":"D'autre part, il peut être nécessaire de mettre à jour les liaisons SSL et de les configurer de manière beaucoup plus stricte que celle que nous voyons normalement dans IIS (sauf si nous utilisons SNI). En effet, la configuration HTTP.SYS par défaut dans Windows Server 2012 R2 suppose l'utilisation d'extensions TLS telles que SNI. En utilisant le NETSH HTTP SHOW SSLCERT Je vais voir que ma configuration actuelle fait toujours référence aux liaisons SSL de mon ancien certificat SSL et de mes anciennes URL.
"},{"id":"text-7","type":"text","heading":"","plain_text":"Comme je mets également à jour mon certificat en même temps que mon URL, toutes ces liaisons doivent être mises à jour (pour utiliser à la fois le certificat et l’URL corrects). En référençant l’ancien GUID pour l’ID d’application, nous pouvons apporter ces modifications à l’aide de NETSH HTTP ADD SSLCERT. Remarque: en raison de la manière dont PowerShell gère les accolades entourant le GUID, nous devons le construire de manière assez délicate:\n$ guid = “5d89a20c-beab-4389-9447-324788eb944a”\n$ certhash = “e1f71e1560fc00f8bee989ee6abbf07119bc7276”\n$ hostnameport = “sts.sp2010.local: 443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"\n$ Command | Netsh\nCeci doit être répété pour la liaison du port 49443 responsable de l’authentification du certificat également, lorsque cela est nécessaire: \n$ hostnameport = “sts.sp2010.local: 49443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = enable"\n$ Command | Netsh\nEt les anciennes liaisons doivent être supprimées manuellement:\n netsh http delete sslcert hostnameport = sts..com: 443\nnetsh http delete sslcert hostnameport = sts..com: 49443\nBien que nous ne devrions pas compter sur le localhost nous mettrons également à jour cela, sinon il sera toujours sécurisé en utilisant l’ancien certificat. Vous ne savez jamais quand le fait de ne pas mettre à jour cela pourrait causer un problème. Et vous remarquerez qu’il n’ya pas de commande de mise à jour (que je puisse trouver), nous devons donc supprimer l’ancienne liaison et la créer à nouveau.\nnetsh http delete sslcert hostnameport = localhost: 443\n$ hostnameport = “localhost: 443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"\n$ Command | Netsh\nAprès avoir apporté ces modifications, il devrait être possible de naviguer avec succès vers la nouvelle URL de métadonnées de fédération, afin de vérifier que tout fonctionne correctement:","html":"Comme je mets également à jour mon certificat en même temps que mon URL, toutes ces liaisons doivent être mises à jour (pour utiliser à la fois le certificat et l’URL corrects). En référençant l’ancien GUID pour l’ID d’application, nous pouvons apporter ces modifications à l’aide de NETSH HTTP ADD SSLCERT. Remarque: en raison de la manière dont PowerShell gère les accolades entourant le GUID, nous devons le construire de manière assez délicate:\n$ guid = “5d89a20c-beab-4389-9447-324788eb944a”\n$ certhash = “e1f71e1560fc00f8bee989ee6abbf07119bc7276”\n$ hostnameport = “sts.sp2010.local: 443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"\n$ Command | Netsh\nCeci doit être répété pour la liaison du port 49443 responsable de l’authentification du certificat également, lorsque cela est nécessaire: \n$ hostnameport = “sts.sp2010.local: 49443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = enable"\n$ Command | Netsh\nEt les anciennes liaisons doivent être supprimées manuellement:\n netsh http delete sslcert hostnameport = sts..com: 443\nnetsh http delete sslcert hostnameport = sts..com: 49443\nBien que nous ne devrions pas compter sur le localhost nous mettrons également à jour cela, sinon il sera toujours sécurisé en utilisant l’ancien certificat. Vous ne savez jamais quand le fait de ne pas mettre à jour cela pourrait causer un problème. Et vous remarquerez qu’il n’ya pas de commande de mise à jour (que je puisse trouver), nous devons donc supprimer l’ancienne liaison et la créer à nouveau.\nnetsh http delete sslcert hostnameport = localhost: 443\n$ hostnameport = “localhost: 443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"\n$ Command | Netsh\nAprès avoir apporté ces modifications, il devrait être possible de naviguer avec succès vers la nouvelle URL de métadonnées de fédération, afin de vérifier que tout fonctionne correctement:
"}],"sections":[{"id":"text-1","heading":"Text","content":"Windows Server 2012 R2 introduit un certain nombre de modifications en profondeur dans le fonctionnement d'AD FS. Cela signifie qu'en tant que praticiens, nous devons rechercher des solutions aux problèmes rencontrés dans de nouveaux endroits inattendus. Par exemple, dans l'ancien monde, si AD FS était complètement insensible, le premier endroit où je prendrais soin d'AD FS lui-même serait IIS. Dans AD FS 2012 R2, IIS ne joue aucun rôle. Les requêtes sont toujours traitées par le pilote de noyau HTTP.SYS, mais nous interagissons avec lui à l’aide de NETSH HTTP, qui se connecte au pilote via l’API de serveur HTTP en mode utilisateur. Auparavant, IIS et d'autres composants familiers interagissaient également avec cette API, mais ils fournissaient une couche d'abstraction plus conviviale entre un administrateur et l'API. Interaction avec HTTP.SYS à l'aide de NETSH HTTP apporte une courbe d'apprentissage, en particulier lorsqu'il s'agit de comprendre ce qui est contrôlé et ce qui ne l'est pas. En outre, il n'y a pas d'interface graphique et la sécurité appliquée par HTTP.SYS est plus stricte que la couche abstraite qu'IIS a historiquement ouverte. Ce changement d’architecture de serveur Web et d’autres nouvelles différences ajoutent à la difficulté de dépister les problèmes lorsque les choses ne fonctionnent pas comme prévu, comme indiqué dans cet article.\nMise à jour du certificat de communication de service, du nom de service de fédération et de l'identificateur\nLors de la mise à jour de l'URL d'un service AD FS, les premières et les plus évidentes choses à modifier sont le certificat, le nom et l'identifiant de communication de service. Il s’agit de toutes les modifications exposées via la console d’administration AD FS ou via Set-ADFSProperties et Set-ADFSCertificate.\nMise à jour: 14 janvier 2015Il y a quelques semaines, Adam Lepkowski a recommandé une amélioration de cette section avec l'applet de commande Set-AdfsSslCertificate, qui résout certaines des lacunes que je décris ci-dessous. Par souci de cohérence, je laisserai mes mots intacts et inclurai ici le commentaire d’Adam en tant qu’amélioration dont tout le monde peut tirer parti. Je pense que le fait de voir mon approche la plus sobre aide à révéler ce qui se passe sous le capot. Je ne changerai donc pas ce contenu, mais j’utiliserai moi-même la méthode d’Adam à l’avenir.\nCommentaire / approche d’Adam Lepkowki:"},{"id":"text-2","heading":"Text","content":"Adam Lepkowski a déclaré:31 décembre 2014 à 7h36\nLa liaison SSL peut être ajoutée de la manière suivante:– Exécutez Set-AdfsSslCertificate -Thumbprint thumbprint_hereCette commande ajoutera de nouvelles entrées pour les ports 443 et 49433 et mettra à jour la liaison localhost existante.\nMalheureusement, vous devez toujours supprimer l'ancienne liaison manuellement:netsh http delete sslcert hostnameport = sts..com: 443netsh http delete sslcert hostnameport = sts..com: 49443"},{"id":"text-3","heading":"Text","content":"Retour à l'article d'origine…\nPour plus de simplicité, je vais montrer les écrans de l’interface graphique ici:"},{"id":"text-4","heading":"Text","content":"NB: Je ne recommande pas d’utiliser .local. C’est en fait un domaine dans lequel nous nous sommes éloignés, mais pour cet article, il était plus facile pour moi d’utiliser ces ressources.\nQuoi qu’il en soit, ces changements fonctionnent, comme ils l’ont toujours fait. Nous pouvons voir les changements dans Get-ADFSProperties et Get-ADFSCertificate clairement après les avoir faites."},{"id":"text-5","heading":"Text","content":"Cependant, comme auparavant, nous devons également appliquer ces modifications à l'infrastructure sous-jacente. Dans le passé, il s’agissait de mettre à jour la liaison de IIS, mais il faut maintenant invoquer le NETSH HTTP commandes pour interagir avec HTTP.SYS. le NETSH HTTP SHOW URLACL Cette commande dévoile des écouteurs, mais par défaut, AD FS réservera un écouteur générique (+) pour un port et un chemin, par exemple https: // +: 443 / adfs / ou https: // +: 49443 / adfs /, de sorte qu'il rien à changer pour les en-têtes d'hôte (réservations d'URL)."},{"id":"text-6","heading":"Text","content":"D'autre part, il peut être nécessaire de mettre à jour les liaisons SSL et de les configurer de manière beaucoup plus stricte que celle que nous voyons normalement dans IIS (sauf si nous utilisons SNI). En effet, la configuration HTTP.SYS par défaut dans Windows Server 2012 R2 suppose l'utilisation d'extensions TLS telles que SNI. En utilisant le NETSH HTTP SHOW SSLCERT Je vais voir que ma configuration actuelle fait toujours référence aux liaisons SSL de mon ancien certificat SSL et de mes anciennes URL."},{"id":"text-7","heading":"Text","content":"Comme je mets également à jour mon certificat en même temps que mon URL, toutes ces liaisons doivent être mises à jour (pour utiliser à la fois le certificat et l’URL corrects). En référençant l’ancien GUID pour l’ID d’application, nous pouvons apporter ces modifications à l’aide de NETSH HTTP ADD SSLCERT. Remarque: en raison de la manière dont PowerShell gère les accolades entourant le GUID, nous devons le construire de manière assez délicate:\n$ guid = “5d89a20c-beab-4389-9447-324788eb944a”\n$ certhash = “e1f71e1560fc00f8bee989ee6abbf07119bc7276”\n$ hostnameport = “sts.sp2010.local: 443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"\n$ Command | Netsh\nCeci doit être répété pour la liaison du port 49443 responsable de l’authentification du certificat également, lorsque cela est nécessaire: \n$ hostnameport = “sts.sp2010.local: 49443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = enable"\n$ Command | Netsh\nEt les anciennes liaisons doivent être supprimées manuellement:\n netsh http delete sslcert hostnameport = sts..com: 443\nnetsh http delete sslcert hostnameport = sts..com: 49443\nBien que nous ne devrions pas compter sur le localhost nous mettrons également à jour cela, sinon il sera toujours sécurisé en utilisant l’ancien certificat. Vous ne savez jamais quand le fait de ne pas mettre à jour cela pourrait causer un problème. Et vous remarquerez qu’il n’ya pas de commande de mise à jour (que je puisse trouver), nous devons donc supprimer l’ancienne liaison et la créer à nouveau.\nnetsh http delete sslcert hostnameport = localhost: 443\n$ hostnameport = “localhost: 443”\n$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"\n$ Command | Netsh\nAprès avoir apporté ces modifications, il devrait être possible de naviguer avec succès vers la nouvelle URL de métadonnées de fédération, afin de vérifier que tout fonctionne correctement:"}],"media":{"primary_image":"https://tutos-gameserver.fr/wp-content/uploads/2019/05/ADFSLostUrl1.png"},"relations":[{"rel":"canonical","href":"https://tutos-gameserver.fr/2019/05/04/elements-qui-ne-sont-pas-mis-a-jour-lors-de-la-modification-dune-url-ad-fs-dans-windows-server-2012-r2-bien-choisir-son-serveur-d-impression/"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/05/04/elements-qui-ne-sont-pas-mis-a-jour-lors-de-la-modification-dune-url-ad-fs-dans-windows-server-2012-r2-bien-choisir-son-serveur-d-impression/llm","type":"text/html"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/05/04/elements-qui-ne-sont-pas-mis-a-jour-lors-de-la-modification-dune-url-ad-fs-dans-windows-server-2012-r2-bien-choisir-son-serveur-d-impression/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}