Forum Tranquil IT

Bonjour,

Nous avons actuellement un serveur Wapt (entreprise) 2.3.0.13516 (en bullseye).

Actuellement, ce dernier n'est accessible que sur notre réseau interne (adressage privé) ou en VPN.
Afin de pouvoir utiliser les unit d'OU AD, nous avons activé l'authentification kerberos, tout les clients étant membre du domaine.

Avec la généralisation du télétravail, et la mobilité de certains agents, nous avons malheureusement des machines qui ne sont quasi jamais sur le réseau interne, ne profitant donc pas des mises à jour automatique.

Nous réfléchissons à rendre le serveur WAPT accessible depuis internet, si possible via un reverse proxy, mais nous ne souhaitons pas rendre les contrôleurs de domaine publics pour autant.

Comment procéder ? Peut-on forcer l'enregistrement de l'agent via kerberos, et accepter les agents déjà enregistrés sans ?

Merci pour vos conseils

Bonjour Arnaud,

arnaud.houdelette a écrit : ↑11 avr. 2023 - 11:17 Actuellement, ce dernier n'est accessible que sur notre réseau interne (adressage privé) ou en VPN.
Afin de pouvoir utiliser les unit d'OU AD, nous avons activé l'authentification kerberos, tout les clients étant membre du domaine.

Avec la généralisation du télétravail, et la mobilité de certains agents, nous avons malheureusement des machines qui ne sont quasi jamais sur le réseau interne, ne profitant donc pas des mises à jour automatique.

Nous réfléchissons à rendre le serveur WAPT accessible depuis internet, si possible via un reverse proxy, mais nous ne souhaitons pas rendre les contrôleurs de domaine publics pour autant.

Comment procéder ? Peut-on forcer l'enregistrement de l'agent via kerberos, et accepter les agents déjà enregistrés sans ?

Les postes ont besoin de voir les serveurs AD pour l'enregistrement initial (si la registration kerberos est activée). Au moment de l'enregistrement le poste va faire une CSR (certificate signing request) pour générer un certificat client. Par la suite le poste va utiliser le certificat client pour l'authentifier sur le serveur WAPT.

Il est donc possible de faire l'enregistrement du poste sur le réseau local où l'active directory est accessible. Pour la suite il n'est pas nécessaire d'avoir l'AD accessible par le poste client (uniquement le serveur WAPT) [1].

Il est ensuite possible de sécuriser le serveur WAPT au niveau du serveur nginx en activant l'authentification par certificat client directement dans la configuration nginx (dispo en version wapt entreprise). Alors le serveur WAPT est correctement configuré et sécurisé pour être mis en DMZ en direct sur internet.

Pour ce qui est du reverse proxy, il est assez compliqué de le configurer correctement (à cause justement de l'authentification par certificat client). Il est donc recommandé de mettre le serveur Wapt directement en DMZ sans reverse proxy.

Cordialement,

Denis Cardon

[1] note : pour ce qui est du self-service, il faut faire attention d'être en mode authentification waptserver-ldap (cf. documentation) si le poste est dans la nature.

Merci pour ces précisions.

Notre AD n'est pas accessible de la DMZ. Nous ne pouvons donc pas y placer le serveur wapt.
Mais vu la conf nginx du serveur, je ne devrais pas rencontrer trop de difficultés pour trouver une solution de ce coté.
Je souhaitais simplement m'assurer que l'absence de connexion a l'AD des clients n'allait pas interférer avec le client wapt (sur l'affectation des unit OU, par exemple).

dcardon a écrit : ↑11 avr. 2023 - 12:11 [1] note : pour ce qui est du self-service, il faut faire attention d'être en mode authentification waptserver-ldap (cf. documentation) si le poste est dans la nature.

Bonsoir.
J'ai réussi assez facilement à poser un reverse proxy. (avec l'authentification par certificat forcée, sauf pour le websocket).
Les clients arrivent bien à se connecter au serveur, à se mettre à jour, etc ...

J'ai par contre eu un peu de mal a faire fonctionner le self-service.
La doc donne 3 méthodes pour activer l'auth ldap, mais ne précise qu'il faut un compte AD que pour la 3ème ... ou alors j'ai mal compris.
Cela fonctionne maintenant.

idem ici on passe aussi par un reverse Nginx, qui nous permet aussi par exemple de restreindre l'usage de la console depuis l'extérieure de notre réseau.
De mémoire ça nous permet aussi de garder le certificat autosigné du backend quelque soit sa validité. Ça fonctionne plutôt bien.

Bonjour j'ai un problème pur accéder au self-service a distance, je peut y accéder seulement en précisant le Dn par exemple : INT\aurouze.e alors quand local cela fonctionne sans.
Merci d'avance pour vos retour.

@eliott merci d'ouvrir un nouveau topic pour une nouvelle question. Je passe le topic en locké
Cordialement,
Denis