c-webber
Goto Top

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. face-smile

Beim Aufruf einer dieser Apps werde ich dann aber doch wieder aufgefordert, mich zu authentifizieren. face-sad

Folgende Einstellungen habe ich per GPO gesetzt:

Computerkonfig:

2022-03-22 15_05_48-clipboard

In den Zonenzuweisungen habe ich sowohl die FQDN als auch die Servernamen beider Maschinen (Sitzungshost / RDWeb) eingetragen, also:
server.domain
server

2022-03-22 15_06_50-gruppenrichtlinienverwaltung

Benutzerkonfig:

2022-03-22 15_07_10-gruppenrichtlinienverwaltung

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

Content-Key: 2253826304

Url: https://administrator.de/contentid/2253826304

Printed on: June 12, 2024 at 22:06 o'clock

Member: DerWoWusste
DerWoWusste Mar 22, 2022 at 14:48:15 (UTC)
Goto Top
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.
Member: c-webber
c-webber Mar 22, 2022 at 15:15:04 (UTC)
Goto Top
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
Member: Doskias
Doskias Mar 22, 2022 updated at 15:17:24 (UTC)
Goto Top
Moin
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.

Gruß
Doskias
Member: ukulele-7
ukulele-7 Mar 22, 2022 at 15:24:07 (UTC)
Goto Top
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.
Member: c-webber
c-webber Mar 22, 2022 at 19:08:31 (UTC)
Goto Top
Zitat von @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?
Member: DerWoWusste
DerWoWusste Mar 22, 2022 at 19:40:33 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste Mar 22, 2022, updated at Mar 23, 2022 at 08:09:39 (UTC)
Goto Top
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.
Member: c-webber
c-webber Mar 22, 2022 at 22:16:43 (UTC)
Goto Top
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.

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
Member: DerWoWusste
DerWoWusste Mar 23, 2022 at 05:27:12 (UTC)
Goto Top
Dann verknüpf sie nun mit der Computer-ou der Clients
Member: Doskias
Doskias Mar 23, 2022 at 08:01:58 (UTC)
Goto Top
Zitat von @c-webber:
Zitat von @Doskias
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
Member: c-webber
c-webber Mar 23, 2022 at 12:11:48 (UTC)
Goto Top
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
Member: c-webber
c-webber Mar 23, 2022 at 12:29:55 (UTC)
Goto Top
Zitat von @DerWoWusste:

Dann verknüpf sie nun mit der Computer-ou der Clients

Also an 3 Stellen verknüpfen?

User-OU, RDS-Server-OU und Client-PC-OU ??
Member: DerWoWusste
DerWoWusste Mar 23, 2022 at 12:41:16 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste Mar 24, 2022 at 09:31:15 (UTC)
Goto Top
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.
Member: c-webber
c-webber Mar 24, 2022 at 12:01:39 (UTC)
Goto Top
Das muss es sein, danke.

Dort habe ich keine Einstellungen verknüpft... Ich teste morgen und geb nochmal Bescheid.
Member: DerWoWusste
DerWoWusste Mar 25, 2022 updated at 10:32:40 (UTC)
Goto Top
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.
Member: c-webber
c-webber Mar 25, 2022 at 13:01:46 (UTC)
Goto Top
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 face-sad

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
Member: DerWoWusste
Solution DerWoWusste Mar 25, 2022 at 13:17:11 (UTC)
Goto Top
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.
Member: c-webber
c-webber Jul 26, 2022 at 11:57:29 (UTC)
Goto Top
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