[RISOLTO] Server WAPT accessibile dall'esterno in un contesto AD

[arnaud.houdelette]

Salve,

attualmente disponiamo di un server WAPT (enterprise) 2.3.0.13516 (Bullseye).

Al momento, è accessibile solo dalla nostra rete interna (indirizzamento privato) o tramite VPN.
Per utilizzare le unità organizzative (OU) di Active Directory, abbiamo abilitato l'autenticazione Kerberos, con tutti i client membri del dominio.

Con la crescente diffusione del lavoro da remoto e la mobilità di alcuni dipendenti, purtroppo abbiamo computer che non sono quasi mai connessi alla rete interna e quindi non beneficiano degli aggiornamenti automatici.

Stiamo valutando la possibilità di rendere il server WAPT accessibile da Internet, idealmente tramite un reverse proxy, ma non vogliamo rendere pubblici i controller di dominio.

Come possiamo procedere? Possiamo forzare la registrazione degli agenti tramite Kerberos e accettare agenti già registrati senza di esso?

Grazie per il vostro aiuto.

[dcardon]

Ciao Arnaud,

Attualmente, quest'ultimo è accessibile solo sulla nostra rete interna (indirizzamento privato) o tramite VPN.
Per utilizzare le unità OU di AD, abbiamo abilitato l'autenticazione Kerberos, con tutti i client membri del dominio.

Con la diffusione del lavoro da remoto e la mobilità di alcuni dipendenti, purtroppo abbiamo macchine che non sono quasi mai connesse alla rete interna e quindi non beneficiano degli aggiornamenti automatici.

Stiamo valutando la possibilità di rendere il server WAPT accessibile da Internet, se possibile tramite un reverse proxy, ma non vogliamo rendere pubblici i controller di dominio.

Come possiamo procedere? Possiamo forzare la registrazione degli agenti tramite Kerberos e accettare agenti già registrati senza di esso?

Le workstation devono visualizzare i server Active Directory per la registrazione iniziale (se la registrazione Kerberos è abilitata). Durante la registrazione, la workstation invierà una richiesta di firma del certificato (CSR) per generare un certificato client. La workstation utilizzerà quindi questo certificato client per autenticarsi sul server WAPT.

È quindi possibile registrare la workstation sulla rete locale dove Active Directory è accessibile. Per i passaggi successivi, non è necessario che AD sia accessibile dalla workstation client (solo il server WAPT) [1].

È quindi possibile proteggere il server WAPT a livello di server nginx abilitando l'autenticazione tramite certificato client direttamente nella configurazione nginx (disponibile nella versione enterprise di WAPT). Il server WAPT è quindi correttamente configurato e protetto per l'accesso diretto a Internet in una DMZ.

Per quanto riguarda il reverse proxy, è piuttosto complicato configurarlo correttamente (proprio a causa dell'autenticazione tramite certificato client). Pertanto, si consiglia di posizionare il server WAPT direttamente nella DMZ senza un reverse proxy.

Sinceramente,

Denis Cardon

[1] Nota: per quanto riguarda il self-service, è necessario prestare attenzione ad essere in modalità di autenticazione waptserver-ldap (vedere la documentazione) se la workstation è in the wild.

[arnaud.houdelette]

Grazie per il chiarimento.

Il nostro Active Directory non è accessibile dalla DMZ. Pertanto, non possiamo installare il server WAPT lì.
Tuttavia, data la configurazione Nginx del server, non dovrei avere troppi problemi a trovare una soluzione.
Volevo semplicemente assicurarmi che la mancanza di connessione dei client ad Active Directory non interferisse con il client WAPT (ad esempio, con l'assegnazione delle unità OU).

[arnaud.houdelette]

[1] nota: per quanto riguarda il self-service, è necessario prestare attenzione ad essere in modalità di autenticazione waptserver-ldap (vedere la documentazione) se la workstation si trova in una rete esterna.

Buonasera.
Sono riuscito a configurare un proxy inverso abbastanza facilmente (con autenticazione del certificato forzata, fatta eccezione per il websocket).
I client si connettono correttamente al server, effettuano l'aggiornamento, ecc.

Tuttavia, ho avuto qualche difficoltà a far funzionare il self-service.
La documentazione fornisce 3 metodi per abilitare l'autenticazione LDAP, ma specifica che è richiesto un account AD solo per il terzo... o forse ho capito male.
Ora funziona.

[florentR2]

Analogamente, utilizziamo anche un'istanza Nginx inversa, che ci permette, ad esempio, di limitare l'accesso alla console dall'esterno della nostra rete.
Se non ricordo male, ci consente anche di mantenere valido il certificato autofirmato del backend indipendentemente dalla sua validità. Funziona piuttosto bene.

[aurouze.eliott]

Salve, sto riscontrando problemi nell'accesso all'interfaccia self-service remota. Riesco ad accedervi solo specificando il DN, ad esempio: INT\aurouze.e, mentre funziona correttamente anche senza specificarlo quando accedo localmente.
Grazie in anticipo per l'aiuto.

[dcardon]

@eliott, grazie per aver aperto una nuova discussione per una nuova domanda. Chiudo questa discussione.
Cordiali saluti,
Denis