19
RDS single sign on - Server 2019
Hallo zusammen,
ich bin gerade dabei, eine RDS Landschaft zur Nutzung von RemoteApps aufzubauen (Server 2019) und habe ein Problem mit der Implementierung von SSO.
Alle Rollendienste -außer RDGateway- sind durchkonfiguriert und funktionieren (solange man sich manuell anmeldet).
Für die Einrichtung von SSO habe ich mich beim Aufbau an folgender Anleitung orientiert:
SSO Single-Sign-On to your onPremise RDS Remote Desktop Services 2016/2019 Environment
Was offenbar funktioniert, ist die Weitergabe von Credentials an RDWebAccess. Nach Einrichtung der entsprechenden GPOs muss ich mich dort nicht mehr anmelden, sondern bekomme sofort die verfügbaren WebApps angeboten.
Beim Aufruf einer dieser Apps werde ich dann aber doch wieder aufgefordert, mich zu authentifizieren.
Folgende Einstellungen habe ich per GPO gesetzt:
Computerkonfig:
In den Zonenzuweisungen habe ich sowohl die FQDN als auch die Servernamen beider Maschinen (Sitzungshost / RDWeb) eingetragen, also:
server.domain
server
Benutzerkonfig:
Ich habe mir zum Vergleich auch noch weitere Anleitungen zum selben Thema angeschaut und kann hier keine Unterschiede finden.
Ich sehe im Moment nicht, wo der Hund begraben liegt... Kann mir bitte jemand bei der Fehlersuche helfen?
Danke und beste Grüße,
Chris
ich bin gerade dabei, eine RDS Landschaft zur Nutzung von RemoteApps aufzubauen (Server 2019) und habe ein Problem mit der Implementierung von SSO.
Alle Rollendienste -außer RDGateway- sind durchkonfiguriert und funktionieren (solange man sich manuell anmeldet).
Für die Einrichtung von SSO habe ich mich beim Aufbau an folgender Anleitung orientiert:
SSO Single-Sign-On to your onPremise RDS Remote Desktop Services 2016/2019 Environment
Was offenbar funktioniert, ist die Weitergabe von Credentials an RDWebAccess. Nach Einrichtung der entsprechenden GPOs muss ich mich dort nicht mehr anmelden, sondern bekomme sofort die verfügbaren WebApps angeboten.
Beim Aufruf einer dieser Apps werde ich dann aber doch wieder aufgefordert, mich zu authentifizieren.
Folgende Einstellungen habe ich per GPO gesetzt:
Computerkonfig:
In den Zonenzuweisungen habe ich sowohl die FQDN als auch die Servernamen beider Maschinen (Sitzungshost / RDWeb) eingetragen, also:
server.domain
server
Benutzerkonfig:
Ich habe mir zum Vergleich auch noch weitere Anleitungen zum selben Thema angeschaut und kann hier keine Unterschiede finden.
Ich sehe im Moment nicht, wo der Hund begraben liegt... Kann mir bitte jemand bei der Fehlersuche helfen?
Danke und beste Grüße,
Chris
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2253826304
Url: https://administrator.de/contentid/2253826304
Ausgedruckt am: 24.11.2024 um 08:11 Uhr
19 Kommentare
Neuester Kommentar
Hi.
Kleiner Tipp: RDS SSO ist böse.
Wenn Du das wirklich willst, kann ich dir helfen, aber ich rate davon ab, da Angreifer auf diese Weise das Klartextkennwort des Benutzers auslesen könnten.
Kleiner Tipp: RDS SSO ist böse.
Wenn Du das wirklich willst, kann ich dir helfen, aber ich rate davon ab, da Angreifer auf diese Weise das Klartextkennwort des Benutzers auslesen könnten.
1
Hi,
Danke für den Hinweis!
Unsere RDS-Landschaft bleibt definitiv innerhalb unseres Hausnetzes, kein Zugriff von Außen.
Ich werde mich mit der Thematik noch befassen, für den Anfang würde ich dein Hilfeangebot aber gerne annehmen.
Ob es am Ende dann tatsächlich so produktiv gehen wird, entscheide ich später.
Gruß, Chris
Danke für den Hinweis!
Unsere RDS-Landschaft bleibt definitiv innerhalb unseres Hausnetzes, kein Zugriff von Außen.
Ich werde mich mit der Thematik noch befassen, für den Anfang würde ich dein Hilfeangebot aber gerne annehmen.
Ob es am Ende dann tatsächlich so produktiv gehen wird, entscheide ich später.
Gruß, Chris
Moin
Gruß
Doskias
Zitat von @c-webber:
Unsere RDS-Landschaft bleibt definitiv innerhalb unseres Hausnetzes, kein Zugriff von Außen.
Es gibt auch Angreifen von Innen. Ich persönlich würde von SSO auf RDP-Sitzungen dringend abraten.Unsere RDS-Landschaft bleibt definitiv innerhalb unseres Hausnetzes, kein Zugriff von Außen.
Gruß
Doskias
1
Ich bin nicht sicher ob ich das selbe konfiguriert hatte. Jedenfalls konnte ich mich, wenn ich an einer "Sammlung" in einer RDP Sitzung angemeldet war, ohne weiteren Login an einer anderen Sammlung anmelden. Das war praktisch aber man konnte so eine neue Sammlung anmelden auch wenn die laufende Sitzung gesperrt war. Dann einfach die gesperrte Sitzung mit der anderen laufenden Sitzung anmelden und bums, Anmeldesperre umgangen.
Zitat von @Doskias
Es gibt auch Angreifen von Innen. Ich persönlich würde von SSO auf RDP-Sitzungen dringend abraten.
Gruß
Doskias
Es gibt auch Angreifen von Innen. Ich persönlich würde von SSO auf RDP-Sitzungen dringend abraten.
Gruß
Doskias
Wie würden solche Szenarien aussehen?
So wie ich das verstanden habe, ermögliche ich doch lediglich die Weitergabe von credentials an von mir fest definierte und mit Zertifikat versehene Server.
Übersehe ich hier irgendwas?
Die Credentials werden für jeden Prozess, der mit Adminrechten läuft, zugänglich. Mimikatz ist ein Tool, das jeder bedienen kann und das liest diese in einer Sekunde aus.
Zu deinem Problem: die gpos zur Credential Delegation wirken am Client? Hast du das geprüft? Da kann nichts schief gehen. Ich Stelle mir vor, dass du die GPO auf den Server wirken lässt, nicht auf den Client.
Zu deinem Problem: die gpos zur Credential Delegation wirken am Client? Hast du das geprüft? Da kann nichts schief gehen. Ich Stelle mir vor, dass du die GPO auf den Server wirken lässt, nicht auf den Client.
https://www.nsideattacklogic.de/keylogging-mal-anders-wdigest-tspkg/
-> siehe tspkg
Am besten Ausprobieren (Virenscanner dafür deaktivieren), Staunen und dann die Finger davon lassen. Das ist der Komfort nicht wert.
Stattdessen auf PIN-Logon mit Smartcard wechseln, das ist schnell eingetippt und sicher. Mit Cardreader mit Pinpad (keine Eingabe der PIN über die Computertastatur) gelangt noch nicht einmal die PIN in den RAM und bleibt sicher.
-> siehe tspkg
Am besten Ausprobieren (Virenscanner dafür deaktivieren), Staunen und dann die Finger davon lassen. Das ist der Komfort nicht wert.
Stattdessen auf PIN-Logon mit Smartcard wechseln, das ist schnell eingetippt und sicher. Mit Cardreader mit Pinpad (keine Eingabe der PIN über die Computertastatur) gelangt noch nicht einmal die PIN in den RAM und bleibt sicher.
Zitat von @DerWoWusste:
Zu deinem Problem: die gpos zur Credential Delegation wirken am Client? Hast du das geprüft? Da kann nichts schief gehen. Ich Stelle mir vor, dass du die GPO auf den Server wirken lässt, nicht auf den Client.
Zu deinem Problem: die gpos zur Credential Delegation wirken am Client? Hast du das geprüft? Da kann nichts schief gehen. Ich Stelle mir vor, dass du die GPO auf den Server wirken lässt, nicht auf den Client.
Hab ich vergessen zu erwähnen, die GPO habe ich sowohl mit meiner User OU als auch mit meiner RDS-Server OU verknüpft. Auf die User scheint sie zu wirken, da die Zoneneinstellungen übernommen wurden.
Ich kann vermutlich erst am Freitag weitermachen, dann kann ich prüfen ob die gpo an den Server ankommt
Dann verknüpf sie nun mit der Computer-ou der Clients
Zitat von @c-webber:
Wie würden solche Szenarien aussehen?
So wie ich das verstanden habe, ermögliche ich doch lediglich die Weitergabe von credentials an von mir fest definierte und mit Zertifikat versehene Server.
Übersehe ich hier irgendwas?
Zitat von @Doskias
Es gibt auch Angreifen von Innen. Ich persönlich würde von SSO auf RDP-Sitzungen dringend abraten.
Es gibt auch Angreifen von Innen. Ich persönlich würde von SSO auf RDP-Sitzungen dringend abraten.
Wie würden solche Szenarien aussehen?
So wie ich das verstanden habe, ermögliche ich doch lediglich die Weitergabe von credentials an von mir fest definierte und mit Zertifikat versehene Server.
Übersehe ich hier irgendwas?
DWW hat dir ja schon geschrieben, wie das geht. Ja du erlaubst nur bestimmten Servern das automatische Login, dennoch wird das Kennwort lokal auslesbar. Aber dafür braucht man ja schon "technisches Verständnis". Mit einem eingerichteten Single Sign On erlaubst du auch Leuten ohne das entsprechende Verständnis Zugriff auf die Daten. Nämlich zum Beispiel der Putzkraft, die einen ungesperrten Rechner findet, aus Neugier einfach mal die Remote-Apps öffnet und dann dort Dinge lesen kann, die sie nichts angehen.
Du musst immer abwägen zwischen Sicherheit und Usability und an dieser Stelle würde bei mir immer die Sicherheitsfrage gewinnen. Um wie viele Apps handelt es sich hierbei und wie oft werden die gestartet? Ist es wirklich unzumutbar, das Kennwort entsprechend oft einzugeben? Und wenn es wirklich so extrem wichtig ist, dann denke doch über eine alternative zu dem RemoteApps von MS nach, wie z.B. Citrix. Hier muss sich der User dann einmalig im Receiver authentifizieren und bekommt anschließend ihm zugewiesene Apps zum Start zur Verfügung gestellt. Da er schon via Receiver authentifiziert ist, erfolgt keine Kennwortabfrage. Ja dadurch entstehen dir zusätzliche kosten, aber Sicherheit gibt es nun mal nicht umsonst.
Gruß
Doskias
Danke für die Hinweise, mir war tatsächlich nicht bekannt, dass SSO hier solch ein Scheunentor darstellt.
Nochmal zu meinem Verständnis, wie genau würde solch ein "Angriff" ablaufen?
Da ich ja keine Remote Desktops zu Verfügung stelle, kann der User ja keine beliebigen Anwendungen auf dem RDS-Server ausführen. Das heißt, er muss sein Tool am Client starten und könnte damit die Credentials des dort angemeldeten Users abgreifen? Und dazu benötigt er Adminrechte?
Gruß, Chris
Nochmal zu meinem Verständnis, wie genau würde solch ein "Angriff" ablaufen?
Da ich ja keine Remote Desktops zu Verfügung stelle, kann der User ja keine beliebigen Anwendungen auf dem RDS-Server ausführen. Das heißt, er muss sein Tool am Client starten und könnte damit die Credentials des dort angemeldeten Users abgreifen? Und dazu benötigt er Adminrechte?
Gruß, Chris
Also an 3 Stellen verknüpfen?
User-OU, RDS-Server-OU und Client-PC-OU ??
mir war tatsächlich nicht bekannt, dass SSO hier solch ein Scheunentor darstellt.
Das würde ich nicht so nennen, da es ganz andere Scheunentore gibt, aber es ist eben etwas Komfortgewinn und dabei doch ordentlich eingebüßte Sicherheit.wie genau würde solch ein "Angriff" ablaufen?
Der Angreifer bringt einen Mitarbeiter dazu, eine Malware zu starten. Diese Malware beschafft sich falls möglich Adminrechte und kann mit diesen Adminrechten die SSO-Kennwörter im Klartext auslesen (zumindest, wenn der Virenscanner das nicht blockt) - wie Mimikatz dabei benutzt wird, zeigt der Link.Also an 3 Stellen verknüpfen?
Was dir vermutlich fehlt, ist nicht die Zonenzuweisung, sondern die Credential delegation am Client.Diese muss lediglich als Computer-GPO den Clients zugewiesen werden.
Das muss es sein, danke.
Dort habe ich keine Einstellungen verknüpft... Ich teste morgen und geb nochmal Bescheid.
Dort habe ich keine Einstellungen verknüpft... Ich teste morgen und geb nochmal Bescheid.
Ich möchte Dir bei der Gelegenheit noch etwas empfehlen, was Du alternativ machen kannst, um dennoch ein SSO zu behalten: Setze Remote Credential Guard ein. Eine gute Anleitung findest Du hier: https://www.windowspro.de/wolfgang-sommergut/rdp-sitzungen-absichern-rem ...
Versionen: Server 2016 1607 oder höher
Client: Win10 1607, besser 1703 und höher.
Das ist sicher, kann aber funktionale Einschränkungen bieten, die man nicht haben will.
Versionen: Server 2016 1607 oder höher
Client: Win10 1607, besser 1703 und höher.
Das ist sicher, kann aber funktionale Einschränkungen bieten, die man nicht haben will.
Das klingt interessant, da muss ich mich mal in Ruhe reinlesen, Danke!
Was das grundlegende Problem angeht, bin ich zwar einen Schritt weiter, aber gefühlt nicht in der richtigen Richtung unterwegs
Mein erster Test war, wie von dir vorgeschlagen, die GPO auch auf die Client-Computer OU zu verknüpfen.
Ergebnis: Selbes verhalten wie vorher, die GPOs kommen laut gpresult überall an, wo sie verknüpft sind.
Dann ist mir aufgefallen, dass unsere neue AV-Lösung am Client SSL Inspection macht, sprich am Client kommt gar nicht das von mir freigegebene Zertifikat an, sondern ein ganz anderes...
Also hab ich zunächst den Fingerprint des AV-Zertifikats mit in die GPO aufgenommen --> keine Änderung.
Dann hab ich die SSL Inspection am AV-Client abgeschaltet, nun wird das von mir erstellte Zertifikat genutzt, SSO klappt aber immer noch nicht.
Sonst noch Ideen? Irgendwas übersehe ich doch?
Gruß, Chris
Was das grundlegende Problem angeht, bin ich zwar einen Schritt weiter, aber gefühlt nicht in der richtigen Richtung unterwegs
Mein erster Test war, wie von dir vorgeschlagen, die GPO auch auf die Client-Computer OU zu verknüpfen.
Ergebnis: Selbes verhalten wie vorher, die GPOs kommen laut gpresult überall an, wo sie verknüpft sind.
Dann ist mir aufgefallen, dass unsere neue AV-Lösung am Client SSL Inspection macht, sprich am Client kommt gar nicht das von mir freigegebene Zertifikat an, sondern ein ganz anderes...
Also hab ich zunächst den Fingerprint des AV-Zertifikats mit in die GPO aufgenommen --> keine Änderung.
Dann hab ich die SSL Inspection am AV-Client abgeschaltet, nun wird das von mir erstellte Zertifikat genutzt, SSO klappt aber immer noch nicht.
Sonst noch Ideen? Irgendwas übersehe ich doch?
Gruß, Chris
Das hat mit dem Zertifikat nichts zu tun.
Die Credential delegation würde so aussehen, dass, wenn aktiv, das Feld Username in mstsc.exe immer vorausgefüllt und ausgegraut ist sobald ein Zielrechnername eingetragen wird, für den Du das aktiviert hast - da musst Du hin und das ist rein am Client einzustellen.
Es würde ausreichen (für einen Test), lokal gpedit.msc zu öffnen und es dort einzustellen für alle (Termsrv/*), Rechner neu starten ->muss nun ausgegraut sein.
Die Credential delegation würde so aussehen, dass, wenn aktiv, das Feld Username in mstsc.exe immer vorausgefüllt und ausgegraut ist sobald ein Zielrechnername eingetragen wird, für den Du das aktiviert hast - da musst Du hin und das ist rein am Client einzustellen.
Es würde ausreichen (für einen Test), lokal gpedit.msc zu öffnen und es dort einzustellen für alle (Termsrv/*), Rechner neu starten ->muss nun ausgegraut sein.
Ich seh gerade, dass der Beitrag noch immer offen ist, Schande über mich ;)
Danke für die hilfreichen Tipps, ich habe schlussendlich auf SSO verzichtet.
Evtl gehe ich das Thema nochmal an, wenn mehr Anwendungen per RDS zur Verfügung gestellt werden, zur Zeit sind wir in der sog. "Evaluierungsphase"
Danke und Gruß,
Chris
Danke für die hilfreichen Tipps, ich habe schlussendlich auf SSO verzichtet.
Evtl gehe ich das Thema nochmal an, wenn mehr Anwendungen per RDS zur Verfügung gestellt werden, zur Zeit sind wir in der sog. "Evaluierungsphase"
Danke und Gruß,
Chris
