Anmeldung via ADFS(->SAML) an MS Terminal Server

[mifritscher 0]

Folgende Konstellation:

 

Organisation hat eine AD + eine ADFS Infrastruktur, steht also als SAML IdentityProvider(IdP) zur Verfügung.

 

Kann ein externer Windows Terminal Server, der _keine_ Anbindung an diese AD hat (und auch nicht haben kann), als SP(ServiceProvider) auftreten, sodass User über SAML Windows Sessions eröffnen können? Der für diese Windows Session verwendete Windows Benutzer kann dabei ein temporärer sein, es geht dabei nur darum, via RemoteApp auf eine Applikation zuzugreifen. Diese Applikation würde als I-Tüpfelchen wiederum zumindest den Usernamen, dass im SAML-Token war, wissen müssen.

bearbeitet 15. Dezember 2021 von mifritscher

[NilsK 2.939]

Moin,

 

SAML ist für Web-Applikationen gedacht. Die Windows-Anmeldung lässt sich damit nicht durchführen.

 

Gruß, Nils

 

[mifritscher 0]

Auch nicht via RDWeb?

 

Oder allgemeiner ausgedrückt: Es gibt also kein RDP-Gateway, dass dies übernehmen kann?

Also dass sich der Benutzer sich via SAML an das RDP Gateway anmeldet, und sich dieses dann mit "irgendwelchen" Windows-Zugangsdaten an den Terminalserver anmeldet?

 

Noch abstrakter:

Wir haben die strikte Anforderung erhalten, dass man via SAML-Token Zugriff auf eine Windows Applikation erhält, die in einer "fremden" Umgebung lebt. Wie dies geschieht ist erstmal egal - eine extrem brachiale Möglichkeit wäre ein VNC-Server, dem ein Web-VNC Client vorgeschaltet wird, auf dem wiederum man sich per SAML anmeldet. Diese Möglichkeit würde technisch definitiv gehen - nur schön ist was anderes. Nun geht es darum, diesen Ansatz soweit aufzubessern, dass sie in der Praxis einsatztauglich ist:

 

  * einigermaßen performant

  * Übertragung einer einzelnen Applikation, keinen Desktop

  * Dateiaustausch zw. Applikation und Client-Rechner

  * Diese Applikation soll "irgendwie" wissen, welcher SAML-Benutzer das jetzt eigentlich ist

  * Automatisiert.

 

VMWare Horizon, XenDesktop/XenApp (letzteres klingt auf den ersten Blick sinnvoller) oder eine ähnliche VDI Lösung wäre übrigens auch denkbar. Völlig andere Ansätze auch :-D

 

bearbeitet 15. Dezember 2021 von mifritscher

[cj_berlin 1.323]

Moin,

 

keine (mir bekannte) Lösung wird lokale Benutzer provisionieren. View und XenDesktop können beide SAML, aber die haben ja auch einen Agenten, der diese Authentifizierung empfängt. Und dennoch wird vorausgesetzt, dass es diesen User schon gibt und dass er sich da anmelden kann.

 

Die von Dir angestrebte Lösung hat aber auch lizenzrechtliche Auswirkungen, die Du beleuchten solltest, bevor Du technisch weiter designst. Soll der Zugriff per User oder per Device lizenziert werden? Falls per Device, fallen jegliche Gateway-Lösungen vermutlich flach. Falls aber per User, wie sollen Lizenzen ausgestellt werden? Dafür muss der Server zwingend in einem AD sein, und die User aus diesem AD oder einem Forest, der diesem AD vertraut, kommen.

[mifritscher 0]

Es wäre denkbar, vorher User anzulegen, die dafür verwendet werden. Dann müsste es halt ein Mapping geben, für welchen SAML-User welche Windows-User verwendet werden soll. Dies kann durchaus auch manuell geschehen, solange man den Prozess als solches irgendwie automatisieren/scripten kann. Ich gehe von ca. 50 Benutzern aus, die von 8 verschiedenen IdPs kommen. Alle SAML Benutzer eines IdPs können sich durchaus einen lokalen Windows-Benutzer teilen, solange es eine Möglichkeit gibt, dass der Anwendung mitgeteilt wird, welcher SAML-User da aktiv ist.

 

Ein AD-Forest ist laut Kundenaussage ein no-Go. Allerdings kann der Server, ich nenne ihn mal abstrakt Applikation Server, seine eigene (isolierte) AD haben, in der die Windows-User, die für die Windows-Sessions verwendet werden, existieren. Allerdings muss die Authentifizierung von außen zwingend einzig und alleine über SAML stattfinden.

 

[testperson 1.680]

Hi,

 

bei Citrix ist das hauptsächlich (ADC), Storefront und der Federated Authentication Server (FAS). Die User müssen aber definitiv vorhanden sein für ein Mapping: Federated Authentication Service architectures overview (citrix.com)

(Den FAS kenne ich aber auch nur aus den Schulungen.)

 

Gruß

Jan

[mifritscher 0]

@testperson: Das klingt doch schonmal nicht schlecht! Drei Fragen (ich bleibe einfach mal bei der von dir verlinkten Übersicht):
1. Muss das ein 1:1 Mapping sein, oder können mehrere User der ADFS.EXT auf einen User der AUTH.LOCAL gemappt werden?

2. Falls 1. geht: Unterstützt Citrix es, dass gleichzeitig mehrere Sessions eines Users der AUTH.LOCAL gleichzeitig laufen?

2. Kann ein User automatisch angelegt werden, wenn noch kein Mapping existiert? Wobei ich hier auch Workarounds ala "Erster Login schlägt wegen fehlendem Mapping fehl, irgendein Script liest die Logs, legt den User an und erzeugt das Mapping, zweiter Login funktioniert" akzeptiere. Ganz notfalls liese sich das aber vermutlich auch andersweitig (=Prozessseitig) lösen.

bearbeitet 16. Dezember 2021 von mifritscher

[testperson 1.680]

zu 1) 1:1.

zu 2) Ja, ist aber auch wie bei RDP Murks.

zu 3) Das würde ich prozessseitig lösen.

[NilsK 2.939]

Moin,

 

zwei Dinge:

 

Erstens wäre es hilfreich, wenn du künftig den Kontext einer Frage mitlieferst. Oft werden in Foren Detailfragen gestellt und später stellt sich heraus, dass Antworten nicht passen, weil das Detail je nach Kontext ganz unterschiedlich bewertet werden kann.

 

Zweitens: Auch bzw. gerade weil wenn sich jetzt ein Workaround abzeichnet, rate ich entschieden dazu, bei Szenarien wie diesem keine Schnellschüsse an den Start zu bringen. Das geht immer wieder nach hinten los.

 

Gruß, Nils

 

[mifritscher 0]

Ok, danke!

2) Inwiefern "Murks"? Wenn ich mich recht entsinne können bei Windows Profile als "nicht persistent" (im Sinne von https://www.windowspro.de/wolfgang-sommergut/virtuelle-desktops-nicht-persistent-persistent-pooled ) gesetzt werden, das würde hier dicke ausreichen. In diesen Sessions würde genau eine Fachanwendung ausgeführt werden (deren Hersteller im Projekt ist...)

 

 

@NilsK : Ich bin gerade noch in der "Ideenfindungsphase", ich sammle noch einige Zeit. Deswegen bin ich für Ideen aller Art dankbar, auch als Impuls für weitere Ideen/Ansätze. Keine Sorge, ich werde mich jetzt nicht auf die erstbeste Idee stürzen, sondern sehe sie eher als Grundlage für weitere Recherchen, Anfragen etc. Von daher: Immer her mit den Ideen. Aussortieren können wir sie immer noch - oder im besten Fall verfeinern

bearbeitet 16. Dezember 2021 von mifritscher

[NilsK 2.939]

Moin,

 

schon was du als "strikte Anforderung" referierst, klingt nach, sorry, Murks. Wenn wir hier schon Ideen finden, dann bringe ich die Idee ins Spiel, noch mal ein paar Schritte zurück zu machen und das Problem zu betrachten, das es wirklich zu lösen gilt. Dafür ist dann eine Lösung zu suchen, die vorhandene Techniken nutzt - und zwar gemäß ihrer Spezifikation, nicht irgendwie daran vorbei. Man kann doch nicht zusehen, wie alle Welt unter einer IT-Sicherheitslücke stöhnt und dann selbst krude Hacks entwerfen, die Sicherheitsmechanismen außer Kraft setzen.

 

Gruß, Nils

 

[mifritscher 0]

@NilsK: Ich habe ehrlich gesagt nur wenig Motivation für eine Metadiskussion, lasse uns bitte auf technische Lösungsansätze beschränken.

 

Nur kurz: Das, was ich als "strikte Anforderung" beschrieben habe, _ist_ eine Entscheidung auf höchster Projektebene. War jetzt nicht unsere präferierte Lösung, aber das tut an dieser Stelle nichts zur Sache. Ich weiß, dass die Architektur sagen wir mal komplex/herausfordernd werden wird, aber da müssen wir jetzt nunmal durch.

 

Vielleicht hilft es dir, die Problemstellung max.  abstrakt zu beschreiben, wie es 1:1 aus den bisherigen Entscheiden kommt:

Personen, die in einer Organisation (Hier müssen 8 eingebunden werden) mit AD, ADFS inkl. einer IdP für SAML, organisiert sind, müssen eine Win32 Anwendung bedienen, die in einer völlig externen Umgebung (technisch wie organisatorisch) läuft. Daneben muss SSO unterstützt werden, das heißt, wenn sich sich die Person an ihren Client der Organisation anmeldet muss diese Person ohne weitere Eingabe von Logindaten diese Win32 Anwendung verwenden können. Diese externe Umgebung soll als SP dienen. AD-Thrusts etc. sind explizit _nicht_ erwünscht.

 

Kurzzusammenfassung ist eben:

[quote]

Wir haben die strikte Anforderung erhalten, dass man via SAML-Token Zugriff auf eine Windows Applikation erhält, die in einer "fremden" Umgebung lebt.

[/quote]

 

Zu deinem letzten Satz:

[quote]

selbst krude Hacks entwerfen, die Sicherheitsmechanismen außer Kraft setzen

[/quote]

An welcher Stelle siehst du einen kruden Hack, an welcher Stelle werden Sicherheitsmechanismen außer Kraft gesetzt? Ah, falls das zu einem Missverständnis geführt hat: Die VNC "Lösung" ist jetzt wirklich nicht das, was wir planen umzusetzen.

[NilsK 2.939]

Moin,

 

"krude" ist, ein Auth-Verfahren, das für Webanwendungen entworfen wurde, für den Zugriff auf Nicht-Webanwendungen zu verwenden. Krude ist, Accounts on-the-fly zu erzeugen. Krude sind einige andere Dinge, die hier genannt wurden.

 

Wir müssen das auch nicht diskutieren, das ist korrekt. Es gehört aber zum Anspruch dieses Boards, Dinge in eine professionelle Perspektive zu setzen, und daher wirst du Hinweise dieser Art hier eben bekommen. Ich kenne Zwänge, wie du sie genannt hast, nach über 25 Jahren als IT-Berater sehr gut, aber ich habe die Erfahrung gemacht, dass Nachhaken durchaus manchmal hilft.

 

Gruß, Nils