none
Mappage de lecteur réseau ne remonte pas sur les PC en VPN RRS feed

  • Question

  • Bonjour à tous !

    Je viens de constaté un petit détail, lorsque mes collaborateurs se connectent à distance (en télétravail), j'ai l'impression que le lecteur réseau ne remonte pas, savez vous ci cela est normal et si il y a une manipulation à effectuer pour forcer le mappage du lecteur réseau même si celui-ci n'est pas accessible ?

    Actuellement le lecteur est paramétré sur l'ad dans l'onglet Profil "connecter".

    Mon VPN démarre quelques secondes voir minutes après l'authentification de l'utilisateur sur le poste.

    J'ai constaté ce cas sur un poste Windows 10 2004, nous sommes sur un SAMBA4 AD (qui n'a rien de différent par rapport à un AD classique)

    Merci à vous !

    lundi 19 octobre 2020 07:32

Réponses

  • Bonjour,

    le fonctionnement est normal !

    La connexion dans le profil est liée à l'ouverture de session.

    Si l'utilisateur ouvre sa session, puis se connecte au VPN. L'ouverture de session est déjà faite, donc la connexion n'a plus à se faire.

    Maintenant, si le profil de l'utilisateur reste ouvert ou que les connexions sont marquées permanentes, les lecteurs restent souvent utilisables après la connexion VPN.

    On peut palier à cela par :

    - Un script de reconnexion (que l'on parfois intégrer au client VPN ou mettre sur le bureau)

    - une stratégie de mapping (qu'il faut forcer après connexion VPN pour éviter les délais de réapplication d'une stratégie)

    Sinon, il faut utiliser DirectAccess ou équivalent qui monte le "VPN" en tant que service, avant que l'utilisateur n'ouvre sa session.

    A bientôt, 


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    mardi 20 octobre 2020 07:16

Toutes les réponses

  • Il faut établir la connexion VPN avant l'ouverture de session.

    Créer la connexion VPN via Windows en donnant l'accès à tous les utilisateurs permet de la lancer avant l'ouverture de session.

    lundi 19 octobre 2020 07:46
  • Sauf que le VPN se base sur un certificat de l'utilisateur et que si l'utilisateur n'est pas connecté, le VPN n'est pas lancé et nous ne pouvons nous connecter.

    Nous sommes sur OpenVPN et je doute que Pfsense permette d'ouvrir un VPN en amont de la session surtout que nous voulons que chaque utilisateur soit authentifié côté VPN pour pouvoir révoquer un utilisateur si besoin

    lundi 19 octobre 2020 07:49
  • Salut,

    dans ce cas, décales les GPO en arrières plan, dans un premier temps je t'invites à ajouter les lecteurs à la main sur un poste si cela abouti, tu n'as qua faire un script parexemple en arrière plan qui vérifies les lecteurs s'ils sont présent et force un gpupdate /force ou un truc du genre,

    j'en avais fait un agent qui tournait et permettait de faire cela, mais j'ai plus de trace


    Dakhama Mehdi : Windows developper https://github.com/dakhama-mehdi

    lundi 19 octobre 2020 10:23
  • Bonjour,

    le fonctionnement est normal !

    La connexion dans le profil est liée à l'ouverture de session.

    Si l'utilisateur ouvre sa session, puis se connecte au VPN. L'ouverture de session est déjà faite, donc la connexion n'a plus à se faire.

    Maintenant, si le profil de l'utilisateur reste ouvert ou que les connexions sont marquées permanentes, les lecteurs restent souvent utilisables après la connexion VPN.

    On peut palier à cela par :

    - Un script de reconnexion (que l'on parfois intégrer au client VPN ou mettre sur le bureau)

    - une stratégie de mapping (qu'il faut forcer après connexion VPN pour éviter les délais de réapplication d'une stratégie)

    Sinon, il faut utiliser DirectAccess ou équivalent qui monte le "VPN" en tant que service, avant que l'utilisateur n'ouvre sa session.

    A bientôt, 


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    mardi 20 octobre 2020 07:16
  • Thierry a tout expliqué et donné 3 solutions de contournement possible ... tout en faisant plus court que mes posts. :-)

    Excellent.

    cordialement

    Olivier

    mardi 20 octobre 2020 07:57