locked
Partages conditionnés sur 2 sous-réseaux distincts RRS feed

  • Discussion générale

  • Bonjour,

    Je viens de déployer un serveur sous Windows Server 2008 x64 (Hostname = SERVER). Il contrôle un domaine DOMAIN sur lequel j'ai 2 sous-réseaux (192.168.1 et 10.0.0). Seuls les clients du réseau 192.168.1 accèdent à Internet par l'intermédiaire du serveur (DHCP activé pour gérer les clients des 2 sous-réseaux, SERVER dispose de 2 interfaces physiques: 1 par sous-réseau).

    J'ai besoin de créer un partage nommé INTERNET (chemin E:\INTERNET sur SERVER) visible par 2 utilisateurs USER1 et USER2 depuis un PC client du réseau 192.168.1 (Hostname = OUT) et non accessible à ces mêmes utilisateurs depuis un PC client du réseau 10.0.0 (Hostname = IN). J'ai aussi besoin de créer 2 autres partages:

    - PRIVDATA accessible par USER1 depuis IN mais pas depuis OUT (l'inverse du cas précédent)

    - BASEDATA accessible par USER1 et USER2 depuis IN mais pas depuis OUT

    J'ai créé mes groupes de sécurité pour que les ordinateurs IN et OUT aient un compte sur le domaine et appartiennent respectivement à des groupes gloIN et gloOUT. L'utilisateur USER1 appartient à un groupe de sécurité gloPRIV. L'utilisateur USER2 appartient à un groupe de sécurité gloBASE.

    Je n'arrive pas à trouver la bonne combinaison de paramètres pour réaliser cela à l'aide des autorisations de partage et des autorisation NTFS. Soit mes utilisateurs peuvent monter TOUS les partages avec le respect de leurs droits NTFS, sans distinction du PC client sur lequel ils sont connectés (ce qui est important pour moi), soit ils ne voient pas du tout les partages sur aucun sous-réseau. Quelqu'un a-t-il une solution ou des recommandations, svp?
    Merci d'avance!

    jeudi 29 mars 2012 08:35

Toutes les réponses

  • Pour information, j'ai testé les combinaisons suivantes:

    - 1 -
    Partage INTERNET:
    Autorisations de partage: gloIN (non configuré OU Refuser contrôle total), gloOUT (Autoriser lecture+modifier)
    Autorisations NTFS: gloPRIV et gloBASE (Autoriser TOUT sauf appropriation et suppression)

    Partage PRIVDATA:
    Autorisations de partage: gloOUT (non configuré OU Refuser contrôle total), gloIN (Autoriser lecture+modifier)
    Autorisations NTFS: gloPRIV (Autoriser TOUT sauf appropriation et suppression), gloBASE (non configuré OU Refuser contrôle total)

    Partage BASEDATA:
    Autorisations de partage: gloOUT (non configuré OU Refuser contrôle total), gloIN (Autoriser lecture+modifier)
    Autorisations NTFS: gloPRIV et gloBASE (Autoriser TOUT sauf appropriation et suppression)

    Résultat = pas d'accès aux partages du tout, quel que soit le sous-réseau.

    - 2 -

    Partage INTERNET:
    Autorisations de partage: gloIN (non configuré OU Refuser contrôle total), gloOUT (Autoriser lecture+modifier), gloPRIV et gloBASE (Autoriser lecture+modifier)
    Autorisations NTFS: gloPRIV et gloBASE (Autoriser TOUT sauf appropriation et suppression)

    Partage PRIVDATA:
    Autorisations de partage: gloOUT (non configuré OU Refuser contrôle total), gloIN (Autoriser lecture+modifier), gloPRIV (Autoriser lecture+modifier), gloBASE (non configuré OU Refuser contrôle total)
    Autorisations NTFS: gloPRIV (Autoriser TOUT sauf appropriation et suppression), gloBASE (non configuré OU Refuser contrôle total)

    Partage BASEDATA:
    Autorisations de partage: gloOUT (non configuré OU Refuser contrôle total), gloIN (Autoriser lecture+modifier), gloPRIV et gloBASE (Autoriser lecture+modifier)
    Autorisations NTFS: gloPRIV et gloBASE (Autoriser TOUT sauf appropriation et suppression)

    Résultat = accès aux partages autorisés (respect des droits NTFS appliqués) quel que soit le sous-réseau (pas de cloisonnement par sous-réseau comme espéré).


    jeudi 29 mars 2012 08:46
  • Les autorisations d'accès réseau et NTFS ne prennent pas en compte le sous réseau d'origine, vous ne pourrez pas créer la gestion voulue par ces mecanismes. Vous pouvez bloquer tous les partages dans l'un des sous réseau, ou tous les autorisés via le parefeu avancé, mais pas interdire l'un des partages dans un sous réseau en autorisant l'autre.

    Les SID ordinateurs n'apparaissent pas dans l'accès aux partages ou fichiers : c'est le SID de l'utilisateur qui est utilisé, hors vous avez le même utilisateur AD quelque soit le sous réseau.

    Une solution serait de déployer un serveur de fichier dans chaque sous réseau, vous pouvez ensuite utiliser des mécanismes DFS-R pour réaliser une sychronisation des données entre les serveurs si besoin, et le pare-feu avancé pour bloquer le file sharing depuis l'un des sous-réseau.

    lundi 2 avril 2012 10:04
  • Merci Bruce pour votre réponse. Serait-il alors préférable selon votre description que les utilisateurs aient chacun un compte d'utilisateur différent par sous-réseau dans AD?

    Vincent BOSQUIER [Directeur Technique chez 'ASA - Advanced Solutions Accelerator' (Partenaire Microsoft)]

    lundi 2 avril 2012 10:10
  • Si c'est la solution que vous retenez, vous allez être confronté à un autre problème : qui à le droit de se connecter sur chaque sous-réseau?

    En effet sans configuration particulière, vos utilisateurs pourront utiliser l'un ou l'autre des comptes sur chaque sous-réseaux.

    Une autre façon de procéder serait la suivante :

    Sur chaque site une GPO lié au site, dans cette GPO dans la partie Ordinateur, une boucle de rappel en mode fusion (http://support.microsoft.com/kb/231287).

    Dans la partie Utilisateur de cette boucle, avec les nouvelles options de préference des GPO NT6, un mappage vers l'un des partages avec un compte de service dédié au sous réseau.

    Vous devez aussi donner aux utilisateurs le droit de lire la GPO pour qu'elle s'applique, et installer la KB Group Policy Preference Client Side Extensions  (http://www.microsoft.com/download/en/details.aspx?id=3628) pour les postes XP/2003.

    Et enfin vous positionnez les droits de Partage&NTFS pour chaque compte de service.

    De cette façon l'utilisateur aura un lecteur vers le partage utilisant un compte de service, il ne pourra pas y accéder directement avec son propre compte. Il faudra aussi prendre en compte les éléments suivants :

    - les fichiers / dossiers crées auront pour propriétaire le compte de service

    - les droits ne prendront en compte que le compte de service (pas de différenciation par utilisateur)

    lundi 2 avril 2012 11:58
  • Encore merci pour cette réponse éclairée. Je vais regarder tout cela en détails, ce sont des procédures d'administration avancée auxquelles je n'ai jamais été confronté.

    - Choisissant cette solution (compte de service et GPO par sous-réseau), comment gérer des partages PRIVATE1, PRIVATE2, PRIVATEn nécessitant des accès différenciés (selon qu'on est de la Direction ou un simple stagiaire) puisqu'il semble que les droits individuels soient abandonnés au profit des droits d'un compte de service unique?- L'article s'applique à Windows Server 2000 et Windows 2000, mais est-ce applicable de la même façon sous Windows Server 2008 (non R2)?

    Si cette solution reste la meilleure:

    - Que signifie exactement pour vous "mapper vers l'un des partages avec un compte de service dédié au sous-réseau"? Est-ce simplement "attribuer des droits d'accès au partage au seul compte de service créé spécifiquement pour l'occasion"?

    - Idem pour les comptes de services qui semblent souffrir de limitations sous Windows Server 2008 : me confirmez-vous qu'une procédure semble devoir être appliquée pour permettre d'utiliser correctement les comptes de services gérés? (voir lien: http://technet.microsoft.com/en-us/library/dd548356%28v=ws.10%29.aspx , section Requirements)

    - Selon le lien ci-dessus, la création d'un compte de service implique de nombreux attributs à définir: avez-vous des recommandations particulières pour l'usage qui pourrait être le mien?

    - Vous m'indiquez comment installer un patch pour la prise en charge de telles stratégies avec des postes clients sous XP SP2 et SP3, mais qu'en est-il des postes clients sous Vista ou 7?

    Sinon:

    - Quelle alternative recommandez-vous?


    Vincent BOSQUIER [Directeur Technique chez 'ASA - Advanced Solutions Accelerator' (Partenaire Microsoft)]

    lundi 2 avril 2012 13:39
  • - Choisissant cette solution (compte de service et GPO par sous-réseau), comment gérer des partages PRIVATE1, PRIVATE2, PRIVATEn nécessitant des accès différenciés (selon qu'on est de la Direction ou un simple stagiaire) puisqu'il semble que les droits individuels soient abandonnés au profit des droits d'un compte de service unique?- L'article s'applique à Windows Server 2000 et Windows 2000, mais est-ce applicable de la même façon sous Windows Server 2008 (non R2)?

    Il faudra un compte par type de droit à appliquer. La stratégie par boucle de rappel est applicable de la même façon sous Windows 2008 R2.

    - Que signifie exactement pour vous "mapper vers l'un des partages avec un compte de service dédié au sous-réseau"? Est-ce simplement "attribuer des droits d'accès au partage au seul compte de service créé spécifiquement pour l'occasion"?

    Les GPO introduites sous 2008 R2 permette dans la partie Utilisateur \ Préférences de mapper (faire un NET USE) un partage vers une lettre de lecteur, en spécifant le compte utilisateur à utiliser. Sur le partage vous devez ensuite positionner les droits vis à vis de ces comptes.

    - Idem pour les comptes de services qui semblent souffrir de limitations sous Windows Server 2008 : me confirmez-vous qu'une procédure semble devoir être appliquée pour permettre d'utiliser correctement les comptes de services gérés?

    - Selon le lien ci-dessus, la création d'un compte de service implique de nombreux attributs à définir: avez-vous des recommandations particulières pour l'usage qui pourrait être le mien?

    Si vous n'êtes pas à l'aise, vous pouvez utiliser un compte utilisateur dédié.

    - Vous m'indiquez comment installer un patch pour la prise en charge de telles stratégies avec des postes clients sous XP SP2 et SP3, mais qu'en est-il des postes clients sous Vista ou 7?

    Il n'y en a pas besoin, la prise en charge des GPO de Préférences est prise en charge nativement depuis Vista.

    Sinon:

    - Quelle alternative recommandez-vous?

    Plus votre architecture est simple, plus elle est facile à gérer et moins sujette à erreur lors d'évolution. Deux serveurs de fichiers, un dans chaque sous réseau. Si vous avez besoin de synchroniser des données entre les deux serveurs, vous pouvez utiliser DFS-R.

    lundi 2 avril 2012 14:12
  • Plus votre architecture est simple, plus elle est facile à gérer et moins sujette à erreur lors d'évolution. Deux serveurs de fichiers, un dans chaque sous réseau. Si vous avez besoin de synchroniser des données entre les deux serveurs, vous pouvez utiliser DFS-R.

    SI je suis contraint par un seul serveur physique (pas de budget pour un second serveur) comment gérer 2 serveurs de fichiers? Puis-je créer 2 domaines distincts gérés par le même serveur Windows physique (1 forêt contenant 2 domaines par exemple) pour gérer mon problème?

    Vincent BOSQUIER [Directeur Technique chez 'ASA - Advanced Solutions Accelerator' (Partenaire Microsoft)]

    lundi 2 avril 2012 14:27
  • Si vous ne pouvez avoir qu'un seul et unique serveur, je vous conseille dans ce cas le système par GPO avec boucle de rappel. J'ai ajusté un point de détail concernant la configuration avec 2 sous réseaux : les GPO seront liés à une OU contenu les comptes d'ordinateur d'un sous réseau. Pour résumé, voici le scénario pour un sous réseau, à vous d'adaptez pour chaque situation :

    • Créer une OU contenant les ordinateurs du sous réseau IN
    • Créer un compte utilisateur "SRV_IN_PARTAGE"
    • Ajout des droits de lecture/modification sur le partage et le NTFS pour le compte SRV_IN_PARTAGE
    • Création d'une GPO "IN_PARTAGE" sur chaque OU avec une boucle de rappel en mode fusion (loopback processing)
    • Ajout dans la même GPO "IN_PARTAGE" dans la partie Utilisateur / Préférences d'un Mapped Drive pointant vers le partage avec le compte SRV_IN_PARTAGE
    • Ajout des droits de lecture sur la GPO pour tous les utilisateurs devant utiliser ce partage

    Idéalement redémmarer le poste avant de tester pour être sur d'appliquer la GPO. Sinon un gpupdate /target:computer sur l'ordinateur.

    Lors de la connexion depuis IN, l'application de la GPO va ajouter la partie contenue dans les paramètres Utilisateurs aux paramètres qui doivent s'appliquer, ajoutant un lecteur pointant vers le partage mais en utilisant le compte SRV_IN_PARTAGE.

    Bien sur, plus vous avez d'exigeances de droits et partages différents, plus cela devient compliqué à gérer.

    lundi 2 avril 2012 14:48
  • Waouh... Effectivement, je suis assez loin de la stratégie à laquelle j'avais pensé au départ (et qui ne fonctionnait pas bien sûr!).

    Je vais préparer toute ma stratégie sur une procédure bien rigoureuse et détaillée puisque, vous l'avez compris, il y a d'autres partages en jeu. Et je vais probablement devoir abandonner mon pauvre script . bat d'ouverture de session qui me montait les lecteurs réseau (via NET USE) par utilisateur en fonction des droits d'accès réels attribués.

    2 dernières questions:

    - pourrai-je jouer avec ces partages en utilisant au rang N+1 des répertoires utilisateurs spécifiques "Partage/%USERNAME%" avec les droits définis spécifiquement (suppression de l'héritage par copie puis modification des droits pour les restreindre sur 1 USER comme je le fais généralement) afin de les monter automatiquement (toujours via NET USE)?

    - une telle config est-elle compatible avec la fonctionnalité ABE (énumération basée sur les accès)?


    Vincent BOSQUIER [Directeur Technique chez 'ASA - Advanced Solutions Accelerator' (Partenaire Microsoft)]

    lundi 2 avril 2012 15:05
  • - pourrai-je jouer avec ces partages en utilisant au rang N+1 des répertoires utilisateurs spécifiques "Partage/%USERNAME%" avec les droits définis spécifiquement (suppression de l'héritage par copie puis modification des droits pour les restreindre sur 1 USER comme je le fais généralement) afin de les monter automatiquement (toujours via NET USE)?

    Je crains que non : de mémoire les variables %USERNAME% ne fonctionne pas avec les préférences GPO. Par contre en faisant F3 sur le chemin à entrer vous aurez accès à un jeu de variables intéressantes.

    - une telle config est-elle compatible avec la fonctionnalité ABE (énumération basée sur les accès)?

    Non, c'est SRV_IN_PARTAGE qui ouvre le partage pour tous les utilisateurs de la GPO... Si vous avez plusieurs GPO avec plusieurs comptes de ce type pour des droits différents, l'ABE devrait s'appliquer, mais je n'ai pas testé cette configuration, n'oublier pas que l'ABE fonctionne sur du DFS.



    • Modifié Bruce JDC lundi 2 avril 2012 15:46
    lundi 2 avril 2012 15:44
  • Non, c'est SRV_IN_PARTAGE qui ouvre le partage pour tous les utilisateurs de la GPO... Si vous avez plusieurs GPO avec plusieurs comptes de ce type pour des droits différents, l'ABE devrait s'appliquer, mais je n'ai pas testé cette configuration, n'oublier pas que l'ABE fonctionne sur du DFS.



    Là, je ne suis pas sûr de comprendre... Peut-être n'ai pas compris depuis le début d'ailleurs? Les utilisateurs finaux ouvrent des sessions sous LEUR PROPRE USERNAME ou doivent-ils ouvrir des sessions sous le nom SRV_IN_PARTAGE sur le PC distant pour que la GPO s'applique? Le compte SRV_IN_PARTAGE est-il bien, comme j'ai cru le comprendre, un compte de façade destiné à ouvrir et autoriser l'accès au partage par le biais d'une GPO à un ensemble d'utilisateurs identifiés?

    Vincent BOSQUIER [Directeur Technique chez 'ASA - Advanced Solutions Accelerator' (Partenaire Microsoft)]

    mardi 3 avril 2012 06:11
  • Le compte SRV_IN_PARTAGE est-il bien, comme j'ai cru le comprendre, un compte de façade destiné à ouvrir et autoriser l'accès au partage par le biais d'une GPO à un ensemble d'utilisateurs identifiés?

    Oui c'est cela, mais cela signifie aussi que toutes les opérations des utilisateurs sur le partage sont réalisés au nom de SRV_IN_PARTAGE. Du point de vue du serveur, c'est SRV_IN_PARTAGE qui se connecte, il ignore quel est l'utilisateur derrière.

    mardi 3 avril 2012 08:09
  • OK, mais pour le USER, merci de me confirmer que c'est bien avec son compte personnel qu'il s'authentifie sur le PC client, svp. :-)

    Vincent BOSQUIER [Directeur Technique chez 'ASA - Advanced Solutions Accelerator' (Partenaire Microsoft)]

    mardi 3 avril 2012 21:51
  • En effet.
    mercredi 4 avril 2012 07:23