AD-Domäne beigetretenes Linux-Server-Äquivalent von NLA

Question

Zunächst einige Hintergrundinformationen.

Wenn Sie sich heute in einer Umgebung befinden, die hauptsächlich aus Windows Server AD und nur einer kleinen Anzahl von Linux-Servern besteht, können Sie sich bei den Servern wahlweise über SSH authentifizieren:

1. Verwalten Sie die Linux-Server über SSH mit Zertifikatsauthentifizierung (die normale Linux-Methode).
2. Fügen Sie die Linux-Server zu Ihrer AD-Domäne (Realm+SSSD) hinzu und verwalten Sie sie über SSH mit Benutzername/Passwort-Authentifizierung.

Das Problem besteht darin, dass bei Option 1 die Administratoren einen separaten Satz Anmeldeinformationen verwalten müssen, der vom Rest der Umgebung getrennt ist, während bei Option 2 die Administratoren den Remote-Servern Passwörter direkt über das Netzwerk bereitstellen müssen, bevor die Maschinen sich gegenseitig vollständig identifiziert haben.

In der Windows-Welt wird dies (zumindest für RDP, das meines Wissens vermieden werden sollte) über die Authentifizierung auf Netzwerkebene gelöst. Eine vereinfachte Version des Prozesses sieht folgendermaßen aus:

1. Der Benutzer beginnt, eine Verbindung zum Remotecomputer herzustellen
2. Der Remotecomputer antwortet mit dem AD-Computerkontotoken
3. Der lokale Computer validiert das Token, erkennt die NLA-Unterstützung und zeigt dem Benutzer einen Anmeldeinformationsdialog an.
4. Der Benutzer vervollständigt den Dialog mit Anmeldeinformationen
5. Der lokale Computer validiert die Anmeldeinformationen mit der Domänensteuerung (nicht der Remotecomputer).
6. Der DC stellt dem lokalen Computer ein Authentifizierungstoken zur Verfügung
7. Der lokale Computer präsentiert dem Remotecomputer das Token
8. Der Remotecomputer validiert das Token anhand der Domäne
9. Bei Erfolg wird dem Benutzer der Zugriff auf den Remotecomputer gestattet.

Tatsächlich kann der Vorgang sogar noch einfacher sein: Dann kann bereits das vorhandene Authentifizierungstoken verwendet werden, das für den Benutzer bei der ersten Anmeldung am lokalen Computer erstellt wurde.

Dies ist ein komplexer Prozess, und ich habe bei der Beschreibung sicherlich Fehler gemacht. Der Punkt ist, dass das Authentifizierungstoken den Platz des Zertifikats aus der Linux-Geschichte einnimmt, sodass der Benutzer niemals tatsächliche Anmeldeinformationen an einen möglicherweise unbekannten Computer übermittelt. Darüber hinaus ist die Abhängigkeit aller Parteien vom vertrauenswürdigen DC sogar noch besser als bei der Linux-Geschichte, da der Benutzer seine Zertifikate nicht selbst verwalten muss, auch nicht über seine eigene Software (sondern es ist die Software, die für ihn bereitgestellt wird).

---

Nun zur Frage. Gibt es eine Möglichkeit, etwas Ähnliches für die Authentifizierung einer SSH-Sitzung mit einem in AD eingebundenen Linux-Server zu erhalten, bei dem der Server die Benutzeranmeldeinformationen nie sieht, die Benutzererfahrung aber immer noch die native Windows-Anmeldeinformationsüberprüfung ist?

Answer 1

Das ist eine Menge, was angesprochen werden muss, aber im Wesentlichen ist ein „kerberisiertes“ SSH oder etwas Ähnliches erforderlich. NLA bietet außerdem einen zusätzlichen Schritt (hier nicht näher erläutert), bei dem keine Konsolensitzung bereitgestellt wird (deren Erstellung ressourcenintensiv ist), bis die Authentifizierung validiert ist.

Genauer gesagt, abgesehen von den untragbaren Komplexitäten sehe ich hier kein großes Interesse, da es bereits eine Problemumgehung gibt. Verwenden Sie einen Bastion-Jump-Host als Frontend für die Linux-Hosts und sperren Sie die Zugriffsart/Port(s) anderer Hosts. Dieser Bastion-Host kann ein Windows-Host sein und alle fehlenden Funktionen unterstützen.

Bastion-Jump-Hosts kommen in AD-Umgebungen auch immer häufiger zum Einsatz, da sie Zugriffsarten wie RDP auf geschützte Ressourcen ermöglichen.

Auch im RDP-Beispiel sind die Anmeldeinformationen nicht wirklich vor dem Server geschützt. Dies wird durch die Verwendung des Schalters /RemoteGuard behoben.

https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc