Sinon il faut appliquer les stratégies de sécurité AGLP, préconisé par Microsoft.
Késako AGLP :Accounts Global Local Permissions
Sur un partage on n'autorise que des groupes locaux. Aux groupes locaux (GL), on affecte des groupes globaux (GG).
Aux GG, on affecte des comptes utilisateurs ou d'autres GG.
On ne gère jamais les autorisations sur un partage directement avec un GG ou un compte utilisateur... sinon il n'y a aucun interêt à utiliser un annuaire.
Un ex:
Soit la ressource \\serveur\Partage
On créé 3 GL:
Partage_R: partage avec droit en lecture
Partage_RW:partage avec droit en lecture/ecriture
Partage_CT: partage avec droit control total.
Dans ton partage, tu affectes à ses GL avec les droits correspondants.
Et ensuite, à chaque GL, tu affectes le ou les GG qui vont bien.
Ensuite tu as plusieurs methodes pour les groupes globaux.
En voici une qui pourrait régler ton pb:
Pour chaque GL(R et RW), tu crées un GG
partage_R (GL) => partage_R (GG) [à toi de les nommer de façon à ne pas s'embrouiller en faisant bien la distinction GG et GL]
Dans ton GG, tu peux mettre les groupes existants (par service je suppose) mais aussi des comptes utilisateurs.
La mise en place risque d'être un peu chronophage, par contre la gestion au quotidien sera plus aisée et ce même si ça augmente le nombre de groupes, surtout dans les cas ou tu dois affecter des autorisations provisoires (pour des projets par ex)
Autres avantages de la methode
=> Une fois les GL en place, tu ne touches plus à tes serveurs, toutes les autorisations se gèrent via Active Directory (tout gérer depuis un annuaire, la raison d'être d'AD)
=> Vérification de qui a accès à quoi simplifiée et plus rapide
... en esperant avoir été clair ![:) :)](https://forum-images.hardware.fr/icones/smile.gif)
Message édité par akabis le 15-06-2009 à 16:50:11