none
Possibilité pour l'accès Fichiers par UNC et non locale ? RRS feed

  • Question

  • Bonjour,

    Ma demande est un peu particulière où j'avais prévu à la base la virtualisation suivante pour une infrastructure en Win2012R2

    - SRV-RDS01 (Bureau à distance) pour Service Administratif & Direction

    - SRV-RDS02 (Bureau à distance) pour le reste employés

    - SRV-FS01 (Serveur de Fichiers répliqués en DFS) pour l'accès aux ressources selon des permissions NTFS

    - SRV-FS02 (Serveur de Fichiers répliqués en DFS) idem

    Un consultat de Microsoft m'a conseillé pour éviter trop d'I/O & de consommation de licences de consolider les rôles tel que

    - SRV-RDS01 (Bureau à distance & Fichiers/DFS)

    - SRV-RDS02 (Bureau à distance & Fichiers/DFS)

    Mais comment éviter que les utilisateurs (non-admin) n'accédent pas aux fichiers par disques locaux mais juste par accès réseaux ?

    merci de votre retour

    lundi 11 juin 2018 11:54

Réponses

  • Tu peux facilement cacher les lecteurs locaux avec des GPOs, mais ce n'est pas une interdiction. Il est difficile d'interdire complètement l'accès à un lecteur comme c: à un utilisateur qui ouvre la session localement.

    https://support.microsoft.com/fr-fr/help/231289/using-group-policy-objects-to-hide-specified-drives

    L'idée de mettre RDS et serveur de fichier sur le même n'est pas la meilleur solution. Les autorisations d'accès par un partage est le cumul du droits sur le partage avec les permissions NTFS. L'accès local dépend des droits NTFS. Donc interdire en local et autoriser en chemin UNC c'est pas simple.

    Si le serveur de fichier est séparé du serveur RDS le problème ne se pose pas. De plus séparer les rôles permet d'être plus souple. En cumulant les rôles, si tu dois redémarrer le RDS tu redémarre le serveur de fichier. Les migrations sont plus simple à gérer.

    A première vue je ne rejoins pas le conseil du consultant, mais je n'ai pas le contexte dans le lequel cette remarque a été faites. Pour tes IO cela dépendra de ton infrastructure le gain que tu vas avoir ne compense pas les inconvénients de ce type de solution. Enfin le calcul des perfs des IO sur un serveur de fichiers et sans doute plus arbitraire que lorsque tu parles d'une base de données SQL par exemple qui a certaine exigence.

    Lorsque l'on donne ce genre de conseil, l'important c'est de comprendre quels avantages, quels inconvénients, le conseil tout seul peut être un parti pris dont tout le monde ne tire pas le profit espéré.


    lundi 11 juin 2018 12:16
    Modérateur
  • Bonjour,

    dans un premier temps, je dirais que ce n'est pas grave, du moment qu'ils ont bien les droits sur les fichiers.

    Sinon, on peut toujours filtrer l'affichage des lecteurs/disques locaux par stratégie... ce qui peut avoir d'autres impacts.

    A+


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(83 MCPs). MCSA Office 365 https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660 http://base.faqexchange.info

    lundi 11 juin 2018 12:19

Toutes les réponses

  • Tu peux facilement cacher les lecteurs locaux avec des GPOs, mais ce n'est pas une interdiction. Il est difficile d'interdire complètement l'accès à un lecteur comme c: à un utilisateur qui ouvre la session localement.

    https://support.microsoft.com/fr-fr/help/231289/using-group-policy-objects-to-hide-specified-drives

    L'idée de mettre RDS et serveur de fichier sur le même n'est pas la meilleur solution. Les autorisations d'accès par un partage est le cumul du droits sur le partage avec les permissions NTFS. L'accès local dépend des droits NTFS. Donc interdire en local et autoriser en chemin UNC c'est pas simple.

    Si le serveur de fichier est séparé du serveur RDS le problème ne se pose pas. De plus séparer les rôles permet d'être plus souple. En cumulant les rôles, si tu dois redémarrer le RDS tu redémarre le serveur de fichier. Les migrations sont plus simple à gérer.

    A première vue je ne rejoins pas le conseil du consultant, mais je n'ai pas le contexte dans le lequel cette remarque a été faites. Pour tes IO cela dépendra de ton infrastructure le gain que tu vas avoir ne compense pas les inconvénients de ce type de solution. Enfin le calcul des perfs des IO sur un serveur de fichiers et sans doute plus arbitraire que lorsque tu parles d'une base de données SQL par exemple qui a certaine exigence.

    Lorsque l'on donne ce genre de conseil, l'important c'est de comprendre quels avantages, quels inconvénients, le conseil tout seul peut être un parti pris dont tout le monde ne tire pas le profit espéré.


    lundi 11 juin 2018 12:16
    Modérateur
  • Bonjour,

    dans un premier temps, je dirais que ce n'est pas grave, du moment qu'ils ont bien les droits sur les fichiers.

    Sinon, on peut toujours filtrer l'affichage des lecteurs/disques locaux par stratégie... ce qui peut avoir d'autres impacts.

    A+


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(83 MCPs). MCSA Office 365 https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660 http://base.faqexchange.info

    lundi 11 juin 2018 12:19
  • Merci Beaucoup !
    lundi 11 juin 2018 14:10