2012 Migration: Kennt sich jemand mit AD FS (= Federation Services) aus?

[Misdemeanor]

Hallo zusammen!

Ich bin damit beauftragt, ein bestehendes Konstrukt zweier AD FS Knoten (2012 R2) auf 2019 zu migrieren. Trotz des Umstandes, dass ich damit keine wirkliche Erfahrung habe. Habe das noch nie aufgesetzt, noch nie betreut und habe leider keine Ahnung vom Troubleshooting. Jaaaa, ich weiß - fragt bitte nicht, ich muss es halt machen ... 🧐

Aber es gibt "Schwierigkeiten", oder im einfachsten Fall zumindest Unklarheiten, und da wollte ich mal fragen, ob sich damit jemand auskennt und ein wenig Erfahrung hat.

Das gesamte Konstrukt besteht, wie gesagt, aus zwei Knoten WS 2012 R2 mit gesonderter SQL-Datenbank (keine WID). Das Ding ist produktiv im Einsatz, soweit ich weiß, gibt's kein Load Balancing und keine Web Application Proxies, drum habe ich als "Opferhost" einen neuen WS 2019 Server zu integrieren versucht. Dies insofern, als dass ich den neuen Server zur bestehenden Farm hinzugefügt habe (SSL-Zertifikat importiert, AD FS Rolle hinzugefügt, auf bestehenden Knoten verwiesen) und das scheint auch gewissermaßen geklappt zu haben, da sich in der 2019 FS Konsole nun einige Informationen der bestehenden Farm befinden – aber ich habe davon wirklich zu wenig Ahnung, als dass ich die Funktionsweise bestätigen könnte. Noch scheint alles zu laufen, aber ich habe keine Ahnung, wie's weitergeht.

Daher mal frei heraus: kennt sich damit jemand aus und könnte mir ein bisschen Schützenhilfe leisten?
Danke vorab!

 

[mortiferus93]

Ganz ehrlich, wenn das Ding produktiv im Einsatz ist, würde ich da nicht rumfummeln, sondern wen externen beauftragen...
Das kann doch nur schief gehen, und dann bist du schuld

 

[kartoffelpü]

Kennst du das Dokument von MS zum Thema? https://learn.microsoft.com/de-de/w...ment/upgrading-to-ad-fs-in-windows-server-sql

 

[Misdemeanor]

Nein, diese Seite kannte ich noch nicht - aber herzlichen Dank für den Verweis.
Bisher habe ich mich an Blogs und anderen Community-Beiträgen entlanggehangelt.

Ich denke, soweit alles richtig gemacht zu haben. Der Fachmann mag das anders bewerten, aber m.M.n. kann man dabei nicht sehr viel falsch machen. Ist das SSL-Zertifikat nicht importiert, kann man nicht fortfahren. Verweist man nicht auf einen bestehenden Knoten, kann man nicht fortfahren. Stimmen die "Prerequisite"-Checks nicht, kann man nicht fortfahren, kurzum: ich habe es so gemacht, wie es auch in der Anleitung steht.

Evtl. gibt es auch kein Problem. Das ist ja der Casus knacksus. Nur weiß ich einfach nicht, wie ich fortfahren soll.
Natürlich habe ich eine Vermutung. Aber da ich kein Experte bin, wie eingangs erwähnt, schaue ich erst einmal halbwegs ratlos aus der Wäsche.

PowerShell hilft nicht weiter, da WS 2012 R2 mit PowerShell v4.0 daherkommt und das Cmdlet nicht kennt:

Ich gehe davon aus, dass der neue Server bereits sauber in der Farm integriert mit läuft. Aber ich weiß nicht wirklich, wie ich das prüfen kann.

Ergänzung (24. Oktober 2023)

Ganz ehrlich, wenn das Ding produktiv im Einsatz ist, würde ich da nicht rumfummeln, sondern wen externen beauftragen...
Das kann doch nur schief gehen, und dann bist du schuld

Ein gut gemeinter Rat, Danke. Willkommen in meiner Welt. 🧐

 

[Rickmer]

Aber ich weiß nicht wirklich, wie ich das prüfen kann.

Schon die ADFS Testseite bemüht?
https://<ADFS FQDN>/adfs/ls/IdpInitiatedSignon.aspx

Du musst natürlich drauf achten, dass für das Testgerät der FQDN auf den neuen Server zeigt, im Zweifelsfall temporär in der Hosts Datei überschreiben -_-

 

[Misdemeanor]

Eehm ... das ist ja der Knaller! Vielen Dank! 😀 bisher wusste ich noch nicht einmal, wie ich dieses teste!

Links der neue Server, rechts einer der beiden alten:

Beide Seiten lassen sich über dieselbe URL aufrufen (Zertifikat greift), beide Dropdown-Listen zeigen dieselben Einträge. Ein (Teil-)Erfolg?

Gut, ich kenne die dahinterstehenden Services nicht und faktisch kann ich diese nicht öffnen (Timeouts), aber das ist beim alten wie beim neuen so, muss also nicht an mir liegen. Habe heute noch ein Gespräch mit den Verantwortlichen, das klärt es hoffentlich. Aber zumindest sieht es so aus, als würde der neue Server arbeiten.

Eine Sache, die mich wirklich stutzig gemacht hat, ist/war aber diese:
Da, wie oben erwähnt/gezeigt, das Get-AdfsFarmInformation-Cmdlet nicht funktioniert, habe ich nach anderen Wegen gesucht, herauszufinden, wer alles an der Farm "beteiligt" ist. Und da bin ich auf einen Eintrag in der erwähnten SQL-Datenbank gestoßen, Tabelle "IdentityServerPolicy.FarmNodes". Hier hätte ich erwartet, alle AD FS-Knoten zu finden, aber de facto zeigt diese Tabelle lediglich den neuesten 2019er-Knoten an. Das kann doch aber nicht korrekt sein, oder?

 

[kartoffelpü]

Das kann doch aber nicht korrekt sein, oder?

Doch. Ich verweise nochmal auf den MS-Link und die entsprechende Warnung: https://learn.microsoft.com/de-de/w...-server-sql#raise-the-farm-behavior-level-fbl

Ich vermute mal, dass sich das deswegen auch in der von dir genannten Tabelle so darstellt.

 

[Misdemeanor]

Doch. Ich verweise nochmal auf den MS-Link und die entsprechende Warnung: https://learn.microsoft.com/de-de/w...-server-sql#raise-the-farm-behavior-level-fbl

Danke für Deinen Input!

Aber sei doch bitte so gut und hilf' mir auf die Sprünge:
Weiter oben ist ein Screenshot von meiner WS 2019 Installation auf dem neuen Knoten und dieser zeigt, dass der FBL nach wie vor auf '1' steht – und das muss, meines Wissens nach, auch so bleiben (will der Betreibende).

Nur was heißt das jetzt? Weist der Eintrag in der SQL-DB darauf hin, dass die alten Knoten gar nicht mehr Teil der Farm sind, seit ich den neuen hinzugefügt habe? Denn wenn ich den Level nicht manuell erhöhe, bleibt er meinem Verständnis nach, wo er war, richtig? Also erwarte ich doch, da ich den FBL eben nicht angepasst habe, das alle beteiligten Server hier angezeigt werden müssen.

 

[Misdemeanor]

Nachdem ich gestern nochmal meine Recherchen intensiviert und weiter nach dem "Problem" geschaut habe, darf ich wohl (für mich) vorerst so etwas wie Entwarnung geben.

Der neue Knoten ist nach bestem Wissen und Gewissen eingerichtet und scheint in Ordnung, das konnte ich mit einem Fachkollegen anhand weiterer Konfigurationen soweit prüfen; in ca. 3 Wochen wird diesbezüglich ein Test gemacht, und sämtlicher Anmeldeverkehr über diesen neuen, einzelnen Knoten laufen (ist nur eine 2-minütige Änderung im Load Balancer, von dem ich bis zu einem klärenden Gespräch gestern Vormittag nichts wusste). 🙄

Wie dem auch sei: entweder, es läuft dann, oder ich muss weiter prüfen, was Sache ist, aber Stand heute gehe ich davon aus, dass bei/nach diesem Test zumindest Klarheit entsteht, wie fortzufahren ist.

Ich vermute mal, dass sich das deswegen auch in der von dir genannten Tabelle so darstellt.

Meine neue Vermutung ist die, dass diese Tabelle erst durch das Hinzufügen des neuen Knotens unter WS 2019 der Datenbank hinzugefügt wurde; das klingt zumindest plausibel.

Danke euch schon mal vielmals für euren Input!