Pb pour rattacher une bdd a un fichier mdw [Résolu]

[sebastien_oasis]

Bonjour à tous,

j avais besoin de sécuriser ma base de donnée et pour ce faire, j ai pu me documenter sur les tutoriels qui sont a disposition sur le site. Apres lecture de ces derniers et etude de mes besoins, j en ai conclu que le tutoriel de loufab etait le plus approprié.

J ai mis cela en place et ca a d ailleurs tres bien fonctionné.... sur mon pc et pour cette bdd. Le problème, c est que, desormais, a partir de mon pc, je suis toujours obligé de me loguer quelque soit la bdd que je veux ouvrir... mais plus ennuyeux: mes collegues n ont pas besoin de se loguer pour l utiliser.. (alors que je voulais qu ils subissent la mise en place de cette sécurité pour cette bdd...)

Apres lecture dans le forum je pense que mon probleme est du au fait que mon access est relié au fichier mdw que j ai créé (avec les groupes contenant mes collegues), mais pas la bdd. Savez vous comment je peux rattacher ma base de donnée a ce fichier mdw?

Par ailleurs, la bdd tout comme le fichier mdw sont sur le reseau et dans le meme dossier. Et a ce sujet, je voulais poser une autre question: si quelqu un supprime le fichier mdw, plus personne ne peux se loguer a ma bdd?

Merci pour votre aide et le temps passé.

Sébastien

[J_Yohan]

Ton fichier mdw peut etre soit declarer a tous le systeme a travers l executable WRKGADM.exe

soit tu peut interresser au option de ligne de commande pour une base de donne specifique

http://loufab.developpez.com/raccourci/

bonne chance
yohan

[sebastien_oasis]

Salut Yohan,

merci pour cette precieuse page je ne l avais pas encore vu. Ca a vraiment l air d etre "puissant".

Sebastien

[sebastien_oasis]

En fait je reviens tout de meme a la charge car meme si ce le fait d utiliser le raccourci marche bien, cela laisse toujours la possibilité aux utilisateurs d ouvrir la bdd sans se loguer (en allant simplement double-cliquer dessus).

Comment fonctionne exactement l executable WRKGADM.exe ? Et surtout, est ce que ca ne va pas demander a tous les utilisateurs du reseau de se loguer quelquesoit la bdd qu ils desirent ouvrir?

Merci encore pour votre aide

Sebastien

[rico63]

Bonjour à tous,
J'ai exactement le même problème !
J'ai sécurisé une base de données et maintenant à chaque fois que j'ouvre une de mes anciennes bases il m'affiche la fenêtre "ouverture de session".

Je cherche ...

[sebastien_oasis]

De mon coté égelement.. des que j ai la solution, j envoie.

[cbleas]

bonjour,

quand vous voulez sécuriser un fichier il ne faut pas utiliser le fichier fourni d'origine par ACCESS car sinon toutes les bases seront protégées.

il faut lorsque vous utilisez l'assistant sécurité créer un nouveau fichier groupe de travail. Ce fichier devra d'ailleurs etre utilisé lorsque vous créerez un fichier backend.
Après lorsque l'on vous demandera si vous souhaitez que ce fichier soit votre fichier de sécurité par défaut il faudra dire non.

Mais comme vous avez déja modifié le fichier par défaut il vous faut reconnecter le fichier d'origine.
Outil/ sécurité/administrateur de groupe de travail bouton rejoindre et trouver le fichier system.mdw qui vous était affecté.



bonne journée

[sebastien_oasis]

Bonjour,

Merci a toi cbleas, je commence a comprendre un petit peu le truc, j ai bien remis le fichier system.mdw en tant que groupe de travail par defaut.

Mais il y a tout de meme quelquechose que je n arrive pas a faire c est rattacher mon fichier .mdw que j avais créé a la base de donnée qúe je souhaite securiser (et juste celle ci... lol).

Par ailleurs, autre question: cette manoeuvre se fait t elle bien lorsqu il s agit de l appliquer a plusieurs postes d un reseau? je suppose qu il faut laisser le fichier mdw sur le reseau egalement et faire en sorte que lorsque la base de donnée s ouvre elle se réfère automatiquement au fichier mdw voulu afin d identifier ou non le utilisateur. Mais comment faire...

Merci par avance a tous pour le temps passé.

Sebastien

[cbleas]

Bonjour,
J'ai pas mal galéré avec ça mais je crois qu'il faut que tu crées une nouvelle base qui sera sécurisée avec le fichier mdw une fois cela fait il faut rappatrier l'ensemble des objets.

Pour le reste c'est vrai qu'il est possible de mettre le fichier de sécurité sur le réseau et de le lié sur le raccourci

Bon courage

[sebastien_oasis]

D accord mais en fait tu supposes que l on lance l application via un raccourci?

Car, dans ce cas, le probleme qui se pose pour moi est que les utilisateurs auront tres vite fait de reperer la cible est d ouvrir la base de donnée sans avoir a s'identifier (etant donné que les autres postes ont comme fichier de groupe de travail par defaut celui qui se trouve dans le "documents and settings"... system.mdw).

En fait, l'ideal serait d'avoir une base de donné qui se lance en "frontal" directement et qui saurait se referer au bon fichier .mdw sans avoir a l implementer dans un raccourci.

[sebastien_oasis]

Bon, j ai pas encore pu resoudre mon probleme, mais je commence a entrevoire une autre solution peut etre que certains d entre vous pourront exploiter cela:

Aller dans l exploreur windows, faites un cclic droit sur votre bdd a securiser:
puis: Propriétés/securité.

Vous arrivez alors sur une liste de groupes: utilisateurs, administrateurs et autres groupes deja presents sur votre reseau.
Vous pouvez donnez des permissions OU NON aux groupes deja constitués et surtout vous pouvez ajouter des utilisateurs (il y a une fonction pour les chercher sur le reseau).

Par contre, il faut pouvoir creer un groupe (avec l aide et l accord de votre administrateur reseau) ne vous contenant pas mais contenant le reste des utilisateurs afin que vous pussiez modifier votre application sans que les autres fassent des aneries dessus.

[=JBO=]

Bonjour,

Je participe à cette discussion pour apporter quelques informations techniques utiles pour comprendre comment est désigné le fichier "groupe de travail" en charge de la sécurité.

1. Access et JET
Pour exploiter les fichiers de base de données MDB, Access utilise le moteur de base de données JET.

Le moteur JET est un composant indépendant d'Access, souvent installé par défaut dans Windows, et qui peut aussi être utilisé par d'autres applications.

Le modèle de sécurité s'applique au niveau de JET.
Mais quand JET est utilisé par Access, alors c'est Access qui impose ses propres paramètres de sécurité à appliquer.

2. Groupe de travail par défaut désigné dans la base de registre
Si on ne spécifie pas explicitement un groupe de travail, alors c'est un groupe de travail par défaut qui est utilisé.
Ce groupe de travail par défaut est inscrit dans la base de registre de Windows.

_ 2.1 JET autonome
Quand JET fonctionne de façon "autonome", il utilise une valeur par défaut placée sous une clé de registre qui varie en fonction de la version de JET:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\<version>\Engines

Pour la version 4.0 de JET on aura la clé suivante:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines

Sous cette clé on trouve une valeur nommée SystemDB qui désigne le chemin du groupe de travail.
Si seul le nom de fichier est donné (sans préciser le chemin complet), je crois qu'il est recherché dans le dossier commun:
(à adapter en fonction de la localisation de Windows)

C:\Program Files\Fichiers communs\System

_ 2.2 JET piloté par Access
Quand c'est Access qui pilote JET, le fonctionnement de JET est alors adapté au moyen d'une sous-clé de la base de registre propre à Access.
Cette sous-clé permet de spécifier des valeurs supplémentaires ou alors des valeurs qui remplaceront celle normalement utilisées par JET.

En ce qui concerne le groupe de travail par défaut utilisé par Access il faut le rechercher à un emplacement qui varie en fonction des versions d'Access et de JET :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\<version>\Jet\<version>\Engines

Pour les versions 2000 d'Access et 4.0 de JET on aura la clé suivante:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Access\Jet\4.0\Engines

Là encore, sous cette clé on trouve une valeur nommée SystemDB qui désigne le chemin du groupe de travail.
Si seul le nom de fichier est donné (sans préciser le chemin complet), il est recherché dans le dossier:

C:\Program Files\Microsoft Office\Office

3. Désigner un groupe de travail différent de celui par défaut

_ 3.1 JET autonome
Quand JET fonctionne de façon "autonome", on peut préciser le groupe de travail avant d'ouvrir la base de données.

Ainsi avec le modèle DAO, JET est accessible à travers l'objet DBEngine. Cet objet possède la propriété SystemDB qui peut être modifiée avant d'appeler la méthode CreateWorkspace.

_ 3.2 Groupe de travail pour Access
Quand c'est Access qui est en première ligne, on peut utiliser une option de la ligne de commande afin de spécifier le fichier de groupe de travail.
Il s'agit de l'option /wrkgrp.

4. Réponses aux questions

Envoyé par sebastien_oasis

Comment fonctionne exactement l executable WRKGADM.exe ?

Cet utilitaire permet de définir un groupe de travail par défaut pour Access.
Dans la base de registre, il va modifier la valeur de SystemDB au niveau de la clé:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\<version>\Jet\<version>\Engines

Jusqu'à la version 2000 d'Access, cet utilitaire était le seul moyen de modifier "expressément" le groupe de travail par défaut d'Access.

Il y a bien l'[assistant Sécurité au niveau utilisateur...] qui permet en une seule opération complexe de créer un nouveau groupe de travail, éventuellement de le définir comme groupe de travail par défaut, et de sécuriser une base de données pour qu'elle fonctionne avec ce groupe de travail.

Dans les successeurs d'Access 2000, il est possible de modifier le groupe de travail par défaut via la commande de menu intégrée:
>> Outils / Sécurité / Gestionnaire des groupes de travail

Envoyé par sebastien_oasis

est ce que ca ne va pas demander a tous les utilisateurs du reseau de se loguer quelquesoit la bdd qu ils desirent ouvrir?

Le changement de groupe de travail par défaut concerne seulement le PC qui utilise cette base de registre. En revanche, il s'applique "naturellement" sur ce PC à chaque fois qu'Access tente d'ouvrir une base de données (qu'elle soit locale ou dans un dossier partagé), à moins qu'on y déroge grâce à l'option /wrkgrp.

Pour appliquer ce groupe de travail "par défaut" à toute une communauté d'utilisateurs utilisant leurs propres PC, il n'y a pas de moyen simple.
A moins de gérer centralement leurs bases de registre.

Envoyé par sebastien_oasis

meme si ce le fait d utiliser le raccourci [avec l'option /wrkgrp] marche bien, cela laisse toujours la possibilité aux utilisateurs d ouvrir la bdd sans se loguer (en allant simplement double-cliquer dessus).

La réponse est OUI et NON...
Ce sera possible si l'application est mal sécurisée.

Si l'application est bien sécurisée, alors le groupe de travail par défaut se révèlera "incompatible" (disons inapproprié) avec elle:
il sera possible de tenter une ouverture directe du fichier MDB, mais les numéros de sécurité utilisés dans l'application n'ayant aucune correspondance dans le fichier groupe de travail, l'ouverture de session échouera.

Pour sécuriser une application il faut respecter 2 points:
(1) Un fichier groupe de travail pour cette application doit être créé dans les "règles de l'art". Il ne faut surtout pas réutiliser le fichier groupe de travail issu de l'installation d'origine d'Access.
(2) Pour tous les objets de l'application, la personne en charge de la sécurité doit désigner leur propriétaire et définir toutes les permissions des groupes et/ou utilisateurs afin de ne laisser aucun "trou de sécurité".

L'outil [Assistant Sécurité au niveau utilisateur...] intégré dans Access permet d'arriver à ce résultat.

Envoyé par sebastien_oasis

Savez vous comment je peux rattacher ma base de donnée a ce fichier mdw?

Il n'est pas possible d'associer un fichier MDW à une base de données spécifique.

Envoyé par sebastien_oasis

la bdd tout comme le fichier mdw sont sur le reseau et dans le meme dossier. Et a ce sujet, je voulais poser une autre question: si quelqu un supprime le fichier mdw, plus personne ne peux se loguer a ma bdd?

En effet, si le fichier MDW est supprimé, il ne sera plus possible d'ouvrir une session qui le désigne comme groupe de travail.

Envoyé par sebastien_oasis

Je veux appliquer la sécurité Windows pour sécuriser l'accès à ma base de données. Est-ce une bonne idée ?

NON, parce que les utilisateurs et groupes de travail de Windows ne sont pas connus dans le système de sécurité de JET.
Il n'est pas possible de gérer finement les permissions sur les objets de la base de données.
Au final, il est bien plus "simple" de bien sécuriser la base de données en utilisant un fichier groupe de travail créé pour cette application.
_

[sebastien_oasis]

Tout d abord, merci a toi pour cette explication riche en details!

Malheureusement, j ai encore une question relative a ton passage suivant:

Envoyé par =JBO=

Si l'application est bien sécurisée, alors le groupe de travail par défaut se révèlera "incompatible" (disons inapproprié) avec elle:
il sera possible de tenter une ouverture directe du fichier MDB, mais les numéros de sécurité utilisés dans l'application n'ayant aucune correspondance dans le fichier groupe de travail, l'ouverture de session échouera.

Pour sécuriser une application il faut respecter 2 points:
(1) un fichier groupe de travail pour cette application doit être créé dans les "règles de l'art".
(2) pour tous les objets de l'application, l'administrateur de la sécurité doit définir toutes les permissions des groupes et/ou utilisateurs afin de ne laisser aucun "trou de sécurité".

Car en ce qui me concerne, j ai pu sans aucun probleme gerer mes utilisateurs/groupes ainsi que leurs permissions via le .mdw que j ai créé (et effectivement cela marche bien... depuis mon pc comme tu la souligné). Mais qu en est il des "numeros de securités utilisés dans l application" qui semblent donc intrinseques a mon application? Si je comprends bien, c est grace a cela que la bdd refusera de s ouvrir si on n utilise pas le bon groupe de travail. Donc ma question est la suivante: comment puis-je agir sur ces numeros?

Car en lisant bien ta reponse je m appercois qu il ne me reste plus que cette issue la pour m en sortir tout en ne polluant pas mes collegues lorsqu ils souhaitent ouvrir une autre bdd (je pense que ca doit etre tout con a realiser mais la je ne vois pas... )

En tout cas, merci a tous pour toutes ces explications

[cbleas]

Bonjour,

En créant un fichier Mdw spécifique pour ton application tu l'affectes uniquement au fichier concerné. Donc les autres utalisateurs n'auront aucun problèmes pour les autres fichiers car il utiliseront le fichier standard et non celui pas créé précedemment.

Bonne journée

[=JBO=]

Envoyé par sebastien_oasis

Mais qu en est il des "numeros de securités utilisés dans l application" qui semblent donc intrinseques a mon application? Si je comprends bien, c est grace a cela que la bdd refusera de s ouvrir si on n utilise pas le bon groupe de travail. Donc ma question est la suivante: comment puis-je agir sur ces numeros?

Avant tout, si tu as appliqué fidèlement le tutoriel de loufab,
>> Comprendre et mettre en oeuvre la sécurité sous Microsoft Access

Tu dois maintenant posséder:
(1) un nouveau fichier de groupe de travail
_ >> dont l'utilisateur Admin est authentifié par un mot de passe,
_ >> et qui comporte au moins un nouveau compte utilisateur membre du groupe des administrateurs Admins;
(2) un fichier base de données sécurisé (en particulier les comptes Admin et Users ne doivent plus être propriétaires d'un quelconque objet et leurs permissions doivent toutes être révoquées ou alors drastiquement limitées).

Comptes et SID: Security Identifier
Un groupe de travail contient des comptes d'utilisateurs et des comptes de groupes.
A chacun de ces comptes est associé un n° unique appelé Security Identifier (SID).
Un SID est généré à partir du nom du compte, du nom de l'organisation et du n° personnel (PID).
Dans un fichier de base de données sécurisé, seuls sont utilisés les SID pour la gestion des permissions ainsi pour que la désignation des propriétaires d'objets .

Quand un utilisateur ouvre une session de travail, il s'identifie (nom d'utilisateur) et s'authentifie (mot de passe) dans le groupe de travail.
A l'issue de cette opération, la session se voit associer un ensemble de SID:
_ >> le SID du compte utilisateur,
_ >> les SID des groupes auxquels l'utilisateur appartient.

Pour qu'un utilisateur puisse travailler dans une base de données, il faut que celle-ci contienne des permissions pour au moins un des SID obtenus à l'ouverture de session.
Sinon, un message d'erreur est affiché qui signale qu'aucune autorisation n'a été trouvée.
C'est comme ça qu'on se protège de l'utilisation d'un groupe de travail "inappropié".

Bien entendu, un tel groupe de travail peut très bien être utilisé avec une ou différentes bases de données (c'est d'ailleurs ce qui se passe dans une architecture de type back-end/front-end).
Dans le cas d'un groupe de travail en réseau, le fichier de groupe de travail peut être partagé par l'ensemble des utilisateurs (dans un dossier partagé) ou bien être dupliqué sur chacun des PC... L'emplacement importe peu, ce qui est primordial est l'obtention d'un ou plusieurs SID valides.

Les comptes spéciaux: Users, Admins et Admin
Le compte Users (Utilisateurs) qui désigne le groupe des utilisateurs est créé automatiquement lors de la création du groupe de travail. Quel que soit le groupe de travail, le SID du groupe Users est toujours le même.
Lorsqu'un nouveau compte utilisateur est créé, il est automatiquement ajouté dans le groupe Users.

Le compte Admins (Administrateurs) qui désigne le groupe des administrateurs est créé automatiquement lors de la création du groupe de travail. Le SID du groupe Admins est généré à partir du n° d'identification du groupe de travail (en plus nom de l'organisation et du nom du groupe de travail).

Le compte Admin (Administrateur) possède toujours le même SID, quel que soit le fichier de groupe de travail.

Le fait que les SID des comptes Users et Admin soient tout le temps identiques est bien pratique lorsqu'on ne veut pas appliquer la sécurité au niveau utilisateur: en effet, dans une telle configuration, n'importe quel groupe de travail "par défaut" peut être utilisé.
En revanche c'est une brêche potentielle de la sécurité d'un groupe de travail: il suffit que dans une base de données des permissions soit accordées aux SID des comptes Admin ou Users pour que n'importe quel groupe de travail "traverse" la sécurité.
C'est pourquoi il est nécessaire de "désactiver" ces comptes:
_ >> assigner un mot de passe au compte Admin,
_ >> retirer le compte Admin du groupe Admins,
_ >> révoquer toutes les permissions accordées à ces comptes (ou les limiter fortement),
_ >> et surtout s'assurer que ces comptes ne sont propriétaires d'aucun objet.
_

[sebastien_oasis]

Bonjour a tous,

et merci pour toutes ces explications et le temps que vous passez pour cela.

J ai bien compris comment un groupe d utilisateur pouvait ou ne pouvait pas etre utilisé par une bdd via les SID mais j ai tout de meme une question concernant le point 2:

Envoyé par =JBO=

(2) un fichier base de données sécurisé (en particulier le compte Admin ne doit plus être propriétaire d'un quelconque objet et ses permissions doivent toutes être révoquées).

En relisant le tuto, j ai du mal a voir comment je specifie le fichier base de donné car en fait, on ne travaille apparament que sur le groupe de travail (ie: j ai bien gérer les permissions et les possessions pour le groupe Admins ainsi que pour le compte Admin). Pourtant, en te lisant je comprends tout a fait que c est le fichier base de donnees qui doit les contenir (ie: ces fameux SID).

CF ce passage:

Envoyé par =JBO=

Pour qu'un utilisateur puisse travailler dans une base de données, il faut que celle-ci contienne des permissions pour au moins un des SID obtenus à l'ouverture de session.
Sinon, un message d'erreur est affiché qui signale qu'aucune autorisation n'a été trouvée.
C'est comme ça qu'on se protège de l'utilisation d'un groupe de travail "inappropié".

Pourrais tu m indiquer a quoi correspond le point 2 dans le tutoriel de loufab car je ai vraiment du mal a voir comment on obtient un fichier securisé (un groupe de travail oui, mais pas une bdd securisee). Car pour l instant des que je remets le groupe de travail "system.mdw" par defaut, mon application ne demande plus de mot de passe, dans ce cas,je peut aussi supprimer toutes les permissions et possessions au niveau de ce groupe de travail mais cela ne change pas vraiment le pb dans la mesure où mes collegues utilisent par defaut leur system.mdw qui est sur leur dur.
Est ce qu il faut créer un fichier MDE? (j ai essayé mais meme sans erreur dans mon code, il y a message d erreur me disant que les TablesIDs sont trop nombreux ou je ne sais plus trop quoi.)

Je suis vraiment désolé si ma question parait stupide, mais je vous assure que pour l instant je suis vraiment coincé avec cette histoire de sécurité. Je pense que vous m avez tout expliqué, mais j ai qd meme du mal a capter le truc...

Merci par avance.

Sebastien

[sebastien_oasis]

Alors en fait meaculpa a tous...

j ai enfin trouvé mon erreur, c est vraiment de ma faute..

j avais pas fait une totale degradation des permissions et possessions pour les groupes Users et Admins.

En tout cas, merci pour tout le temps passé la dessus et les exhaustives explications car en plus du probleme resolu j ai pu comprendre un max de choses.

Sebastien

[sebastien_oasis]

Bonjour,

j ai a nouveau besoin de votre aide au sujet de la sécurisation d'une bdd.

Je refais la même opération que sur la bdd de mois de mai relative aux messages précédents.

J'ai tout bien refait comme il le faut, mais j'ai tout de même du oublier quelquechose... car ma bdd s'ouvre toujours sans probleme depuis un poste avec access reglé sur le system.mdw par défaut.... c'est à dire que le "admin" que tout le monde utilise dans le monde entier arrive à trouver ces repères dans ma bdd.

Pourtant je lui ai tout supprimé et lorsque j'ouvre le fichier avec le workgroup que j'ai créé, il est bien entendu impossible pour l'admin de microsoft de se loguer (boite de dialogue dès le debut, disant qu'en gros on ne peut pas ouvrir la bdd).

Le problème c est que je n ai plus acces à ma base de donnée du mois de mai que j'avais réussi à sécuriser.

Par contre, j'ai un doute sur un petit detail: l'admin n'est bien entendu plus le propriétaire d aucun objet mais reste le proprietaire de la base de données et cela, je n arrive pas à le changer.. est ce un point révélateur du problème?

Je sens qu il ne manque pas grand chose car tout c'est passé comme dans le tuto de loufab mais...

En tout cas, merci par avance pour votre aide et le temps passé.

Sébastien

[sebastien_oasis]

Alors, alors...

encore un meaculpa...

le probleme s est resolu en enlevant les droits des admins et users depuis le workgroup par defaut (system.mdw) avec la bdd en question ouverte et ce pour les objets qu'elle contient...

C est un collegue qui m a suggerer de faire cela mais je suis tout de meme un peu surpris je pensais qu il fallait faire uniquement des modifs avec access réglé sur le workgroup créé pour la securisation de la bdd en question.

Bref, access se comporte en tout cas tres bien avec les autres bases de donnees, je suis réglé sur le worgroup par défaut et il ne me demande pas de me loguer, lorsque j ouvre une autre base de données, par exemple.

J ouvre (tout comme mes utilisateurs) la bdd via un raccourci contenant l'adresse du workgroup (méthode classique)