[GELÖST] WAPT-Server von extern in einem AD-Kontext erreichbar

[arnaud.houdelette]

Hallo,

wir betreiben derzeit einen WAPT-Server (Enterprise) Version 2.3.0.13516 (Bullseye).

Dieser ist aktuell nur über unser internes Netzwerk (mit privater Adresse) oder via VPN erreichbar.
Um die Active Directory-Organisationseinheiten (OUs) nutzen zu können, haben wir die Kerberos-Authentifizierung aktiviert, wobei alle Clients Mitglieder der Domäne sind.

Aufgrund der zunehmenden Verbreitung von Remote-Arbeit und der Mobilität einiger Mitarbeiter befinden sich leider einige Rechner fast nie im internen Netzwerk und profitieren daher nicht von automatischen Updates.

Wir erwägen, den WAPT-Server über das Internet erreichbar zu machen, idealerweise über einen Reverse-Proxy, möchten die Domänencontroller aber nicht öffentlich zugänglich machen.

Wie können wir vorgehen? Können wir die Agentenregistrierung über Kerberos erzwingen und bereits registrierte Agenten ohne Kerberos akzeptieren?

Vielen Dank für Ihre Hilfe.

[dcardon]

Hallo Arnaud,

Derzeit ist der Server nur über unser internes Netzwerk (private Adresse) oder per VPN erreichbar.
Um die AD-OU-Einheiten nutzen zu können, haben wir die Kerberos-Authentifizierung aktiviert, wobei alle Clients Mitglieder der Domäne sind.

Aufgrund der zunehmenden Verbreitung von Remote-Arbeit und der Mobilität einiger Mitarbeiter gibt es leider Rechner, die sich fast nie im internen Netzwerk befinden und daher nicht von automatischen Updates profitieren.

Wir erwägen, den WAPT-Server über das Internet zugänglich zu machen, wenn möglich über einen Reverse-Proxy, möchten die Domänencontroller aber nicht öffentlich zugänglich machen.

Wie können wir vorgehen? Können wir die Agentenregistrierung über Kerberos erzwingen und bereits ohne Kerberos registrierte Agenten akzeptieren?

Die Arbeitsstationen müssen die Active Directory-Server für die Erstregistrierung erreichen (sofern die Kerberos-Registrierung aktiviert ist). Während der Registrierung sendet die Arbeitsstation eine Zertifikatsignierungsanforderung (CSR), um ein Clientzertifikat zu generieren. Anschließend verwendet die Arbeitsstation dieses Clientzertifikat zur Authentifizierung auf dem WAPT-Server.

Es ist daher möglich, die Workstation im lokalen Netzwerk zu registrieren, in dem Active Directory zugänglich ist. Für die nachfolgenden Schritte ist es nicht erforderlich, dass die Client-Workstation auf Active Directory zugreifen kann (sondern nur der WAPT-Server) [1].

Anschließend kann der WAPT-Server auf Nginx-Serverebene abgesichert werden, indem die Clientzertifikatsauthentifizierung direkt in der Nginx-Konfiguration aktiviert wird (verfügbar in der Enterprise-Version von WAPT). Der WAPT-Server ist dann korrekt konfiguriert und für den direkten Internetzugang in einer DMZ gesichert.

Die Konfiguration eines Reverse-Proxys ist recht kompliziert (insbesondere aufgrund der Client-Zertifikatsauthentifizierung). Daher wird empfohlen, den WAPT-Server direkt in der DMZ ohne Reverse-Proxy zu platzieren.

Aufrichtig,

Denis Cardon

[1] Hinweis: Bei der Nutzung von Self-Service-Lösungen ist darauf zu achten, dass sich die Workstation im waptserver-ldap-Authentifizierungsmodus befindet (siehe Dokumentation).

[arnaud.houdelette]

Vielen Dank für die Klarstellung.

Unser Active Directory ist von der DMZ aus nicht erreichbar. Daher können wir den WAPT-Server dort nicht platzieren.
Angesichts der Nginx-Konfiguration des Servers sollte es mir jedoch nicht allzu schwerfallen, eine Lösung zu finden.
Ich wollte lediglich sicherstellen, dass die fehlende Verbindung der Clients zum Active Directory den WAPT-Client nicht beeinträchtigt (beispielsweise die Zuweisung von Organisationseinheiten).

[arnaud.houdelette]

[1] Hinweis: Bei der Selbstbedienung muss darauf geachtet werden, dass sich die Workstation im waptserver-ldap-Authentifizierungsmodus befindet (siehe Dokumentation), wenn sie sich in einem externen Netzwerk befindet.

Guten Abend.
Ich konnte einen Reverse-Proxy recht einfach einrichten (mit erzwungener Zertifikatsauthentifizierung, außer für den WebSocket).
Die Clients stellen erfolgreich eine Verbindung zum Server her, aktualisieren sich usw.

Ich hatte allerdings ein paar Schwierigkeiten, den Selbstbedienungsbereich zum Laufen zu bringen.
Die Dokumentation nennt 3 Methoden zur Aktivierung der LDAP-Authentifizierung, gibt aber nur für die dritte Methode an, dass ein AD-Konto erforderlich ist... oder vielleicht habe ich das falsch verstanden.
Es funktioniert jetzt.

[florentR2]

Wir verwenden ebenfalls eine Reverse-Nginx-Instanz, die es uns beispielsweise ermöglicht, den Konsolenzugriff von außerhalb unseres Netzwerks einzuschränken.
Soweit ich mich erinnere, sorgt sie auch dafür, dass das selbstsignierte Zertifikat des Backends unabhängig von seiner Gültigkeitsdauer gültig bleibt. Es funktioniert einwandfrei.

[aurouze.eliott]

Hallo, ich habe Probleme beim Zugriff auf die Remote-Self-Service-Oberfläche. Ich kann sie nur über die DN (z. B. INT\aurouze.e) erreichen, lokal funktioniert der Zugriff ohne DN.
Vielen Dank im Voraus für Ihre Hilfe.

[dcardon]

@eliott, vielen Dank, dass Sie ein neues Thema für Ihre neue Frage eröffnet haben. Ich schließe dieses Thema.
Viele Grüße,
Denis