Serveur d'impression

Éléments qui ne sont pas mis à jour lors de la modification d'une URL AD FS dans Windows Server 2012 R2 – Bien choisir son serveur d impression

Par Titanfall , le 4 mai 2019 - 6 minutes de lecture

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.

Mise à jour du certificat de communication de service, du nom de service de fédération et de l'identificateur

Lors 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.

Mise à jour: 14 janvier 2015
Il 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.

Commentaire / approche d’Adam Lepkowki:

Adam Lepkowski a déclaré:
31 décembre 2014 à 7h36

La liaison SSL peut être ajoutée de la manière suivante:
– Exécutez Set-AdfsSslCertificate -Thumbprint thumbprint_here
Cette commande ajoutera de nouvelles entrées pour les ports 443 et 49433 et mettra à jour la liaison localhost existante.

Malheureusement, vous devez toujours supprimer l'ancienne liaison manuellement:
netsh http delete sslcert hostnameport = sts..com: 443
netsh http delete sslcert hostnameport = sts..com: 49443

Retour à l'article d'origine…

Pour plus de simplicité, je vais montrer les écrans de l’interface graphique ici:

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.

Quoi 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.

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).

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.

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:

$ guid = “5d89a20c-beab-4389-9447-324788eb944a”

$ certhash = “e1f71e1560fc00f8bee989ee6abbf07119bc7276”

$ hostnameport = “sts.sp2010.local: 443”

$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"

$ Command | Netsh

Ceci doit être répété pour la liaison du port 49443 responsable de l’authentification du certificat également, lorsque cela est nécessaire:

$ hostnameport = “sts.sp2010.local: 49443”

$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = enable"

$ Command | Netsh

Et les anciennes liaisons doivent être supprimées manuellement:

netsh http delete sslcert hostnameport = sts..com: 443

netsh http delete sslcert hostnameport = sts..com: 49443

Bien 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.

netsh http delete sslcert hostnameport = localhost: 443

$ hostnameport = “localhost: 443”

$ Command = "http add sslcert hostnameport = $ hostnameport certhash = $ certhash appid = $ guid certstorename = MY sslctlstorename = AdfsTrustedDevices clientcertnegotiation = disable"

$ Command | Netsh

Aprè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:

FedMeta "width =" 762 "height =" 557 "srcset =" https://tristanwatkins.com/wp-content/uploads/FedMeta.png 762w, https://tristanwatkins.com/wp-content/uploads/FedMeta- 300x219.png 300w "tailles =" (largeur maximale: 709px) 85vw, (largeur maximale: 909px) 67vw, (largeur maximale: 984px) 61vw, (largeur maximale: 1362px) 45vw, 600px "/></span></p>
<p><span style=Ce serait un très bon moment pour s'assurer que les approbations de certificats sont en place, tout au long de la chaîne, au besoin. Les choses se casseront plus tard si cela n’est pas fait. Et avec cela, les premiers changements sont effectués.

Modification des parties utilisatrices pour utiliser la nouvelle URL

Une fois que nous avons un service de jeton de sécurité réactif sur notre nouvelle URL, nous devons mettre à jour les parties utilisatrices desservies par AD FS. Je n’ai aucun moyen de documenter tout cela, mais comme ce processus est étonnamment mal documenté pour SharePoint, je vais vous en donner une description détaillée ici. Avant d’exécuter cela, il est important de comprendre que la mise à jour de la valeur .Name va casser les profils utilisateur, je recommande donc généralement de ne pas le faire. Vous devez vivre avec l'ancien nom et le nom d'affichage, ce qui peut prêter à confusion, mais l'alternative consiste à migrer tous les comptes d'utilisateurs et à mettre à jour tous les fournisseurs d'authentification, ce qui perturberait l'environnement de production.. Faire cette mise à jour à la SPTrustedIdentityTokenIssuer nécessite l'utilisation des cmdlets Get et Set pour effectuer la modification dans son intégralité.

#Note: Le paramètre ProviderUri dans la cmdlet Get équivaut à SignInUrl dans la cmdlet Set.

$ TrustedIdentityTokenIssuer = Get-SPTrustedIdentityTokenIssuer

Set-SPTrustedIdentityTokenIssuer $ TrustedIdentityTokenIssuer -SignInUrl “https: //sts.sp2010.local/adfs/ls/”

$ TrustedIdentityTokenIssuer.Update ()

Remarque: ce processus est bien meilleur que l’approche alternative consistant à supprimer et à recréer le SPTrustedIdentityTokenIssuer, car cela rompra toutes les connexions de synchronisation de profil utilisateur qui en dépendent. Éviter!

Après avoir apporté ces modifications, nous devrions avoir un AD FS totalement mis à jour. Mais que se passe-t-il si nous avons publié des AD FS et des parties utilisatrices en dehors du réseau de l'entreprise à l'aide du proxy d'application Web? Si c'est le cas, notre travail n'est pas encore terminé.

Mise à jour des mandataires d'application Web pour utiliser la nouvelle URL

Avant de me lancer trop profondément, je dois mentionner que je ne suis pas sûr de savoir laquelle de ces étapes (le cas échéant) sera nécessaire si le proxy d'application Web est déployé. pour la première fois après que les modifications ci-dessus ont été faites. J’ai le sentiment qu’aucun d’entre eux ne sera nécessaire, mais pour des raisons qui deviendront plus claires plus tôt, je ne peux parler de ce scénario avec clarté pour le moment.

À ce stade, il convient de récapituler où nous en sommes. Actuellement, le proxy d'application Web a perdu sa relation avec AD FS, car l'URL AD FS a changé et le proxy d'application Web continue à demander à l'ancienne URL de mettre à jour ses données de configuration (AD FS contient toutes les informations de configuration du proxy d'application Web. ). Ces demandes échoueront systématiquement et seront consignées dans les journaux AD FS sur le ou les serveurs proxy d'application Web:

ADFSLostUrl "width =" 1221 "height =" 500 "srcset =" https://tristanwatkins.com/wp-content/uploads/ADFSLostUrl1.png 1221w, https://tristanwatkins.com/wp-content/uploads/Uploads/ADFSLostUrl1- 300x122.png 300w, https://tristanwatkins.com/wp-content/uploads/ADFSLostUrl1-1024x419.png 1024w "tailles =" (largeur maximale: 709px) 85vw, (largeur maximale: 909px) 67vw, (max- largeur: 1362px) 62vw, 840px "/></p>
<p>Le proxy d'application Web dispose d'une méthode de mise à jour de l'URL du service de fédération qu'il utilise comme proxy. le <em>Install-WebApplicationProxy</em> La cmdlet peut être utilisée pour modifier le certificat utilisé pour publier AD FS ou les URL internes et externes. Dans le cas où je suis passé par là, la mise à jour ressemble à ceci:</p>
<p style=$ FSCredential = Get-Credential

Install-WebApplicationProxy -CertificateThumbprint e1f71e1560fc00f8bee989ee6abbf07119bc7276 -FederationServiceName sts.sp2010.local -FederationServiceTrustCredential $ FSCredential

Malheureusement, cette modification était insuffisante pour assurer le proxy avec succès pour les applications Web qui avaient été inversées par ce serveur. J'ai réussi à rétablir la communication avec AD FS et mes anciennes applications publiées étaient toutes visibles dans la console d'administration Web Application Proxy, mais je ne pouvais accéder à rien de l'extérieur du réseau, à l'exception de AD FS lui-même (via l'URL de métadonnées de fédération, comme décrit ci-dessus). Toutes mes parties utilisatrices ont été redirigées vers l'ancienne URL AD FS, mais cela ne se produisait que via le proxy inverse.

Confronté à ce problème, j’ai tenté sans succès un certain nombre de choses:

  • A examiné tout dans HTTP NETSH pour les changements possibles.
  • Double et triple-vérifié que tous les certificats ont été approuvés par des éléments qui doivent les faire confiance à l'intérieur de l'infrastructure et sur les ordinateurs clients.
  • Désinstallez / réinstallez le rôle de proxy d'application Web.
  • Applications publiées supprimées et recréées.
  • Désactiver le pare-feu Windows (saisir les pailles).
  • Considéré désarmer mon serveur d’une manière ou d’une autre (comme je devais réactiver WinRM afin de supprimer le rôle de proxy d’application Web (ce qui m’a amené à réfléchir).
  • Révocation de tous les serveurs proxy dans AD FS avant la désinstallation / la réinstallation.
  • J'ai essayé de comprendre pourquoi mon serveur Web Application Proxy avait un service appelé AD FS (qui, étrangement, avait une description différente de celle du service AD ​​FS du serveur AD FS).

Service AD ​​FS du serveur AD FS

Service AD ​​FS du proxy d’application Web

Je trouve ce dernier moment particulièrement surprenant. Le proxy d’application Web est un rôle Routage et accès distant qui fournit un service appelé «Services de fédération Active Directory», qui porte le même nom que le service provisionné par le rôle Services de fédération Active Directory. Chacun possède sa propre description.

À ce stade, je me suis assuré de défaire tout ce qui était fou et je suis retourné au début. J'avais déjà passé en revue les réservations d'URL dans NETSH HTTP SHOW URLACL. J'ai trouvé les réservations de port / chemin comme sur mon serveur AD FS, ainsi que mes URL à proxy inversé. Rien ici ne semblait justifier un changement. De même, quand j'ai examiné NETSH HTTP SHOW SSLCERT, J’ai constaté que mes URL avec proxy inverse continuaient à utiliser le même certificat qu’avant, et ma nouvelle URL AD FS était liée à mon nouveau certificat par le biais de l’original. Install-WebApplicationProxy changement.

Après avoir examiné tout cela, j’ai inspecté le Get-WebApplicationProxyConfiguration informations et a constaté que mon ADFSUrl et OAuthAuthenticationUrl utilisaient toujours l'ancienne URL. Pour être clair, j’ai mis à jour toutes les informations qui devraient contrôler cela dans AD FS et j’ai complètement désinstallé / réinstallé le proxy d’application Web. les données de configuration de Web Application Proxy contenues dans AD FS n'ont jamais été mises à jour avec ces modifications, même après leur désinstallation et leur réinstallation. Afin de résoudre ce problème, j'ai dû mettre à jour ces informations de configuration sur le serveur proxy d'application Web à l'aide du Ensemble-WebApplicationProxyConfiguration cmdlet:

Set-WebApplicationProxyConfiguration -ADFSUrl “https: //sts.sp2010.local/adfs/ls” -OAuthAuthenticationURL “https: //sts.sp2010.local/adfs/oauth2/authorize“

Enfin, après avoir apporté cette modification, je pouvais accéder à mes applications Web à proxy inversé. Et avec cela, je comprends maintenant un peu mieux à la fois les services AD FS et le proxy d’application Web. Les commandes HTTP NETSH ne contrôlent pas grand-chose en dehors de ce que vous auriez fait auparavant dans IIS, bien qu’elle applique SNI par défaut. Et bien que les serveurs proxy d'application Web soient effectivement sans état, une partie de l'état de la configuration n'est jamais mise à jour à moins que la mise à jour ne soit forcée à partir d'un serveur proxy d'application Web. Tout cela est nouveau pour un administrateur (certains d’entre eux sont peut-être familiers) et très peu de ce comportement est documenté aujourd’hui, aussi espérons-t-il que ce message aidera une autre personne occupant un poste similaire.

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.