INFO : Comment Visual Basic 3.0 handles sécurité définie par Microsoft Access

Traductions disponibles Traductions disponibles
Numéro d'article: 105990 - Voir les produits auxquels s'applique cet article
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Agrandir tout | Réduire tout

Sommaire

Résumé

Visual Basic version 3.0 comprend le moteur de base de données Microsoft Access. Contient la syntaxe pour manipuler une base de données Microsoft Access dans presque tous façon que Microsoft Access. Une exception majeure se trouve dans la zone de sécurité. Uniquement de Microsoft Access peut définir ou modifier les options de sécurité (telles que les ID d'ouverture de session et les mots de passe pour le système) et définir ou modifier les autorisations sur des objets spécifiques dans une base de données particulière.

Visual Basic version 3.0 contient deux instructions (SetDataAccessOption et SetDefaultWorkspace) qui permettent à une application Visual Basic pour satisfaire le mécanisme de sécurité qui implémente de Microsoft Access et ouvrez une session à l'aide de code Visual Basic. À l'aide de ces instructions, vous pouvez obtenir les autorisations accordées à un utilisateur particulier.

Cet article explique les mécanismes de sécurité de Microsoft Access qui s'appliquent à Visual Basic version 3.0 et le programmeur Visual Basic. Les fonctionnalités de sécurité de Microsoft Access n'entrent pas dans le cadre de cet article.

Pour obtenir une description complète des fonctionnalités de sécurité de Microsoft Access, consultez l'article suivant de la base de connaissances :
122036WX1051 : Assistant sécurité et le livre blanc App. Note 2.0

Plus d'informations

La sécurité est implémentée en deux parties :
  • Chaque utilisateur et le groupe possède un ID de code de sécurité unique.
  • Ce code de SID est stocké dans la base de données along with les autorisations associées pour ce SID.
Les deux sections suivantes donnent les détails.

Chaque utilisateur et de groupe ont l'ID de sécurité unique (SID)

Dans Microsoft Access, chaque utilisateur et de groupe ont un ID de sécurité (SID). Le SID est une chaîne binaire qui identifie de manière unique l'utilisateur ou un groupe. Lorsqu'un utilisateur ouvre une session, ou non à partir de la boîte de dialogue d'ouverture de session dans Microsoft Access ou à partir du code dans Visual Basic (illustrée plus loin dans cet article), le moteur Microsoft Access lit à partir de la table MSysAccounts de la base de données System.mda. Cette base de données est créé uniquement par Microsoft Access et un autre (vide) sera créé si la copie d'origine est supprimée.

Remarque : Si le System.MDA d'origine est accidentellement supprimé, tous les SID uniques sont perdues. Par conséquent, tous les capacité d'accéder aux bases de données protégées est également perdue. Par conséquent, il est conseillé de sauvegarder la base de données et le fichier System.MDA en place lorsque les autorisations ont été définies sur la base de données.

Lors de l'ouverture de session, l'utilisateur fournit le nom d'utilisateur (pas la casse) et le mot de passe (respectant la casse). Si le nom d'utilisateur et le mot de passe sont corrects, le SID de l'utilisateur est récupéré et enregistré dans une structure interne du moteur. Le mot de passe est utilisé uniquement pour valider l'utilisateur. À partir de ce point, une fois que l'utilisateur devient un utilisateur validé, le mot de passe n'a aucun effet sur la sécurité.

Voici un point important qui se rapporte au comportement de Visual Basic. Par défaut, le moteur Microsoft Access tente de valider l'utilisateur et le mot de passe d'administrateur et «» respectivement. Visual Basic version 3.0, sans aucun code enverra cette combinaison de touches pour le moteur Microsoft Access par défaut. Cela signifie que, même sans avoir recours à des instructions Visual Basic liés à la sécurité, le programme Visual Basic bénéficieront d'admission à la base de données, si l'utilisateur «Admin» du groupe Administrateurs de groupe n'a pas son mot de passe modifié par rapport à sa valeur par défaut d'aucune ("").

Une fois connecté, le SID de l'utilisateur est récupéré. Ce SID est utilisé pour toutes les opérations suivantes dans le moteur Microsoft Access.

Le SID est stocké dans la base de données System.mda

Le SID est stocké dans la base de données elle-même. Par conséquent, toutes les autorisations accordées à un utilisateur particulier ou un groupe sont également stockées dans la base de données associé avec le SID unique.

Ceci fait apparaître un autre point clé relatives au comportement de Visual Basic. Le programme Visual Basic peut accéder à la base de données et ont des autorisations complets, seeming pour ignorer le mécanisme de sécurité de Microsoft Access si une des actions suivantes est remplie :
  • Le programmeur Visual Basic n'a pas pris l'emplacement de la System.MDA base de données en compte dans le code de programme.
  • L'utilisateur «Admin» n'a pas son mot de passe modifié à partir de la valeur par défaut d'aucune ("").
Cela se produit en raison du comportement par défaut du moteur Microsoft Access et Visual Basic. L'effet combiné consiste à permettre l'entrée de la base de données et ses objets par le code Visual Basic.

La liste des types d'objets dans Microsoft Access sont : table, requête, formulaire, état, macro et module. Parmi celles-ci, uniquement les deux premiers sont accessibles à partir du code Visual Basic, afin que les autres peuvent être omis dans cette explication.

Les deux sections suivantes expliquent chacune des deux Visual Basic sécurité liées instructions (SetDataAccessOption et SetDefaultWorkspace). Les deux instructions sont conçues pour offrir un choix de fichiers System.mda et écritures d'ouverture de session à une base de données Microsoft Access, avec la sécurité définie par Microsoft Access. Ces deux sections est une section qui associe les deux instructions au comportement du moteur Microsoft Access en termes de sécurité.

Déclaration de SetDataAccessOption--Comportement et de la syntaxe

SetDataAccessOption possède les paramètres suivants :
   SetDataAccessOption option, value

   option is a numeric value with only one legal value (1).
				

Par exemple :
   SetDataAccessOption 1, "E:\VBPROJ\MY.INI"
				

Dans le fichier DATACONS.TXT fourni à la racine du répertoire \VB, une constante est définie pour cette valeur :
   Global Const DB_OPTIONINIPATH = 1
				

SetDataAccessOption définit le nom et le chemin d'accès du fichier d'initialisation (.ini) de votre application. Fichier .ini de l'application ne prend effet que lorsque SetDataAccessOption est utilisé avant que la fonctionnalité d'accès aux données est chargée et initialisée. Une fois l'accès aux données a été initialisé, ce paramètre ne peut pas être modifié sans quitter l'application au premier. La valeur est une expression de chaîne. Pour l'option DB_OPTIONINIPATH, l'argument valeur contient une expression de chaîne fournissant le chemin d'accès et le nom du fichier d'initialisation (.ini) de votre application. Fichiers d'initialisation sont généralement stockés dans le répertoire \Windows de l'utilisateur et ont le même nom que le fichier exécutable, mais avec une extension .ini. Utilisez cette instruction uniquement si le fichier d'initialisation de votre application a un nom différent ou se trouve dans un répertoire autre que le répertoire \Windows.

L'instruction SetDataAccessOption n'est pas nécessaire lorsque vous exécutez le projet Visual Basic dans l'environnement VB.EXE si le fichier VB.INI (dans le répertoire \Windows) contient les lignes suivantes :

[Options]
SystemDB=T:\ACCESS\SYSTEM.MDA
UtilityDB=T:\ACCESS\UTILITY.MDA

Remarque : l'emplacement réel de la System.MDA n'est pas significatif fourni par Microsoft Access et Visual Basic ont une entrée pointant vers le System.MDA elles partagent. L'instruction SetDataAccessOption n'est pas nécessaire si le fichier .exe de l'application possède son propre fichier .ini dans le \Windows et les fichiers .exe et .ini partagent le même nom.

Déclaration de SetDefaultWorkspace--Comportement et de la syntaxe

SetDefaultWorkspace possède les paramètres suivants :
   SetDefaultWorkspace username, password
				

Si cette instruction est omises, Visual Basic envoyer l'équivalent de la ligne suivante au moteur de base de données Microsoft Access qui est inclus avec Visual Basic :
   SetDefaultWorkspace "Admin" , ""
				

Cette instruction a pour effet de l'obtention d'un SID valide et l'entrée à tous les objets table et requêtes dans la base de données.

Relation entre Visual Basic et de sécurité de Microsoft Access

Pour comprendre la relation entre la sécurité de Visual Basic et Microsoft Access, vous devez comprendre le mécanisme de sécurité de Microsoft Access. Voici une explication détaillée au profit du programmeur Visual Basic qui le n'a pas largement utilisé Microsoft Access. Il existe une hiérarchie d'autorisations dans Microsoft Access. Au niveau supérieur, il existe de groupes. Groupe contenus dans un particulier sont des utilisateurs. Pour accorder des autorisations sélectivement à des utilisateurs particuliers, toutes les autorisations doivent tout d'abord être désélectionnées ou supprimées du groupe des utilisateurs. Ensuite et uniquement puis, peuvent autorisations être accordées ou révoquées pour les utilisateurs individuels.

Autorisations répertoriées pour un utilisateur individuel sont appelées autorisations explicites. Les autorisations définies pour le groupe contenant le compte d'utilisateur sont appelées autorisations implicites. Autorisations implicites ont priorité sur les autorisations explicites.

Vous pouvez utiliser le menu sécurité pour définir des autorisations dans Microsoft Access après une base de données a été ouvert et l'utilisateur a ouvert une session. Dans le menu sécurité, cliquez sur autorisations pour affecter des autorisations sur chaque objet dans la base de données, qui ne signifie que les objets table et requêtes dans Visual Basic.

Par exemple, s'il n'y avait un groupe dans Microsoft Access base de données nommée analystes contenant les utilisateurs Bob et Sue et que vous souhaitez limiter uniquement Robert à lire les données et accorder des autorisations total Sue, procédez comme suit :
  1. Ouvrez une session sur Microsoft Access en tant qu'utilisateur dans le groupe Administrateurs. Par exemple, entrez Admin ou Fred.
  2. Dans le menu sécurité, cliquez sur les autorisations (ALT S P).
  3. Objets de la table sont du type par défaut. Sélectionnez le nom de la table que vous souhaitez définir des autorisations sur. Par exemple, sélectionner TestTbl.
  4. Définissez l'option dans le cadre de l'utilisateur/groupe à des groupes. Cliquez sur la zone de liste déroulante vers le bas, puis cliquez sur analystes pour sélectionner ce groupe.
  5. Désactivez toutes les cases à cocher pour révoquer tous les autorisations pour le groupe entier.
  6. Redéfinissez le bouton d'option de liste sur utilisateurs et sélectionnez Bob. Désactivez les cases à cocher pour toutes les autorisations de Bob.
  7. Sélectionnez Sue dans la liste et cochez la case à cocher autorisations complet.
  8. Cliquez sur le bouton affecter pour appliquer les modifications à la table.
À ce stade, vous possédez un programme Visual Basic contenant le code suivant dans l'événement de chargement du formulaire :
Sub Form_Load ()
   Dim db As database
   Dim ds As dynaset
   Dim scenario as integer

   scenario = 'insert a value between 1 and 4 here

   select case scenario
      case 1:
         ' Do nothing

      case 2:
         SetDefaultWorkspace "bob", "leftout"

      case 3:
         SetDataAccessOption 1, "E:\VB.INI"    ' not in \WINDOWS directory

      case 4:
         SetDataAccessOption 1, "E:\VB.INI"    ' not in \WINDOWS directory
         SetDefaultWorkspace "bob", "leftout"
   end select

   Set db = OpenDatabase("E:\DATACON\BASES\ACCESS11\ASAMPLE.MDB") ' point 1
   Set ds = db.CreateDynaset("TestTbl")                           ' point 2

   autoredraw = True   ' to make Print  statement persist on the form
   Print ds(0), ds(1)

End Sub
				

Voici plusieurs scénarios pour illustrer la relation entre Visual Basic et de sécurité de Microsoft Access :

SCÉNARIO ONE : il n'y a dans ce cas, aucune référence à l'emplacement du fichier System.mda. Windows et le moteur Microsoft Access ne parvenez pas à trouver le fichier .ini avec la section [options] répertoriée précédemment dans cet article. Par conséquent, le System.MDA est ignorée et la valeur par défaut Visual Basic est sa combinaison utilisateur et mot de passe par défaut ("Admin", ""). Toutefois, auparavant, le mot de passe par défaut de l'administrateur de l'utilisateur a été modifiée pour quelque chose autre que «». En outre, toutes les autorisations ont été révoquées pour les administrateurs de groupe et l'utilisateur «Admin» dans le groupe Administrateurs. Par conséquent, le message d'erreur Visual Basic suivant s'affiche au point 2 :
Couldn't Read; No Read permission for table or Query 'f)) '

Vous avez fermé la porte dérobée pour Visual Basic et de n'importe quelle application Visual Basic tente de contourner les ouvertures de session dans le fichier System.mda.

SCÉNARIO TWO : dans ce cas, parce que vous appelez l'instruction SetDefaultWorkspace sans avoir un pointeur vers le fichier System.MDA, le moteur Visual Basic Microsoft Access hunts pour le fichier System.mda et, ne pas de recherche, donne le message d'erreur suivant au point 0 dans le code :
Impossible de trouver le fichier 'SYSTEM.MDA'

Remarque : Les erreurs qui se produisent dans les deux scénarios 1 et 2 sont les mêmes que ceux se produirait si le fichier System.MDA a été déplacé, renommé ou supprimé.

SCÉNARIO 3: dans ce cas, vous indiquez au moteur de Visual Basic Microsoft Access dans lequel se trouve le fichier System.MDA mais ne fournissez pas une combinaison utilisateur et mot de passe. Par conséquent, là encore, Visual Basic met à votre disposition la combinaison utilisateur et mot de passe uniquement, il sait ("Admin", ""), qui n'est plus une combinaison valide, car vous avez ajouté un mot de passe pour le compte d'utilisateur administrateur. Par conséquent, Visual Basic propose l'erreur suivante au point 1 dans le code :
Pas un compte valide ou un mot de passe.

SCÉNARIO 4: dans ce cas, vous fournir les deux paramètres correctement. Par conséquent, étant donné que vous avez accordé Bob l'autorisation «Lecture de données», ainsi que «Définitions de lecture» pour autoriser l'accès de Microsoft Visual Basic moteur pour lire, l'application Visual Basic imprime les deux premiers champs dans le premier enregistrement de la table nommée TestTbl.

Si vous répète les quatre scénarios avec l'utilisateur Sue, tout serait identique. Toutefois, Clara peut aller plus loin et modifier la structure de la table et les données. N'oubliez pas que vous sélectionné les analystes de groupe et révoqués toutes les autorisations pour la première fois. Puis vous rajoutés toutes les autorisations à Sue, mais uniquement les définitions de lecture et les lire les données ont été ajoutées à Bob.

Remarque : Le groupe d'administrateurs a une signification particulière en termes de sécurité. Cela s'applique à n'importe quel utilisateur dans ce groupe. SID du groupe Administrateurs est stocké dans le System.MDA lors de la création d'une base de données. Par conséquent, le groupe Administrateurs disposent toujours autorisé à modifier les autorisations sur tous les objets dans la base de données. Cette autorisation ne peut pas être imputée absent (e) par une personne. Cette autorisation reste même lorsque toutes les autorisations ont été révoquées à partir du groupe Administrateurs, et elle n'est pas affichée dans la boîte de dialogue autorisations. Il s'agit d'une autre raison pour conserver une copie de sauvegarde et de garder une trace des qui System.MDA était en cours d'utilisation lors de la base de données a été créée.

Avec l'option OwnerAccess dans une requête SQL


Un dernier point du risque de confusion repose sur l'utilisation de l'expression suivante dans une requête SQL :
   ... With OwnerAccess Option
				

Par exemple, regardez ce code :
   Sub Form_Load ()
      Dim db As Database
      Dim qd As querydef

      Set db = OpenDatabase("C:\ACCESS\DB1.MDB")

      ' Enter the following two lines of code as one, single line:

      Set qd = db.CreateQueryDef("myQD", "select * from [TableDetails]
         with owneraccess option ;")
      db.Close
   End Sub
				

Ce code génère cette erreur :
ID de base de données non valide.

Cela est dû au fait que OwnerAccess fait référence au propriétaire de la base de données. Le propriétaire est le créateur de la base de données. En d'autres termes, OwnerAccess fait référence à du propriétaire de l'utilisateur et un mot de passe (SID unique) qui est stocké dans la base de données (BD1.MDB dans ce cas). Toutefois, le code ne contient-elle pas les deux instructions nécessaires pour pointer vers le fichier System.MDA d'une base de données sécurisée. En fait, dans ce cas, seule l'instruction SetDefaultWorkspace est essentielle si le fichier .ini de du fichier .exe compilé qui contient une section [options] valide, se trouve dans le répertoire \Windows.

Le code utilise la porte dérobée. Il n'a pas fourni le SID unique du propriétaire de la base de données au moteur, afin que le moteur ne sait pas la combinaison de nom et le mot de passe par défaut (Admin, "") de l'utilisateur est le propriétaire de la base de données. Même s'il s'avère que l'utilisateur Admin est le propriétaire de la base de données, sans avoir lu le fichier System.MDA, le moteur ne peut pas vérifier ce fait, il permet de limiter l'erreur.

Notes pour les utilisateurs de Microsoft Access Version 2.0

À l'aide de la publié récemment Microsoft Jet 2.0/Visual Basic 3.0 couche de compatibilité, Visual Basic peuvent accéder aux bases de données Microsoft Access version 2.0. Voici quelques remarques pour pouvoir convertir une base de données de version sécurisée 1.1 en format Microsoft Access version 2.0.

Si une base de données de version 1.x est sécurisée, il reste sécurisé si vous l'ouvrez avec Microsoft Access version 1.x ou 2.0. Toutefois, Microsoft Access version 2.0 ne peut pas servir à modifier ou ajouter des autorisations dans la base de données, même par l'administrateur, jusqu'à ce que la base de données est convertie vers la version 2.0.

Lorsque vous installez Microsoft Access version 2.0, il crée son propre fichier de groupe de travail (System.mda). Si Microsoft Access version 2.0 est installé dans le même répertoire que la version 1.x, la version 1.x du fichier System.MDA sera renommé SYSTEM1X.MDA.

Pour apporter des modifications à la sécurité d'une base de données convertie, vous devez utiliser une version 2.0 System.MDA a identiques des groupes et utilisateurs (et identiques PID) que le System.MDA d'origine.

Remarque : Le PID (ID personnel) dans Microsoft Access version 2.0 est l'équivalent des codes PIN (numéros d'identification personnel) dans la version 1.x

Pour créer un groupe de travail sécurisé :
  1. Utilisez l'outil administrateur de groupe de travail 2.0 pour créer un groupe de travail. Il s'agit d'un fichier de version 2.0 System.mda.
  2. Recréer tous les utilisateurs et de regrouper les comptes à l'aide du même nom et PID numéros qui ont été utilisés dans Microsoft Access version 1.x.
Pour convertir une base de données de 1.x Secure Format 2.0 :

Remarque : Dans un groupe de travail sécurisé, seuls les utilisateurs disposant des autorisations de Modify Design pour tous les objets peuvent convertir un version 1.x format au format de la version 2.0. En outre, vous devez affecter des autorisations Modify Design à la base de données 1.x de version dans Microsoft Access version 1.x utilisant le groupe de travail version 1.x.
  1. Assurez-vous que personne n'utilise la base de données de version 1.x.
  2. Ouvrez une session Microsoft Access 2.0 en tant que membre du groupe administrateurs qui n'est pas l'utilisateur Admin.
  3. Dans le menu fichier, choisissez la commande convertir une base de données.
  4. Sélectionnez la version de la base de données 1.x que vous souhaitez convertir. Vous serez invité pour le nom de base de données 2.0 version.

    Remarque : La commande convertir une base de données vous forcera à choisir un nouveau nom pour la base de données. Cela vous permet de vous conserver une copie de sauvegarde de votre base de données version 1.x, comme une fois que vous avez converti une base de données à partir de la version 1.x vers la version 2.0, que vous ne pouvez pas la reconvertir en version 1.x.
  5. Demandez à vos utilisateurs rejoignent le groupe de travail version 2.0 nouvelles (System.mda) à l'aide de l'outil administrateur de groupe de travail.

    Remarque : Vous pouvez également accomplir ceci en modifiant le fichier MSACC20.INI dans votre répertoire Windows. Dans la section [options] du fichier, modifiez l'entrée SystemDB pour pointer vers la version 2.0 System.MDA fichier. La section [options] du fichier sera semblable à l'exemple ci-dessous :
          [Options]
          SystemDB=<microsoft access path>\SYSTEM.MDA
    
    						

Points clés à mémoriser

  1. Uniquement de Microsoft Access peut créer et modifier le fichier System.mda.
  2. Le fichier System.MDA contient l'identificateur de sécurité unique utilisée dans une base de données avec des autorisations pour trier qui est qui, pour Microsoft Access de moteur pour appliquer ces autorisations. Le SID est obtenu en fournissant le moteur Microsoft Access avec un utilisateur valide et une combinaison de mot de passe, à partir duquel il obtient l'identificateur de sécurité unique le moteur stocke en mémoire pour mettre en ?uvre la sécurité sur une base de données ouverte.
  3. Vous devez être pointé à l'emplacement du fichier System.MDA pour obtenir l'accès aux bases de données qui ont implémenté des autorisations de sécurité et Microsoft Access et Visual Basic.
  4. Il existe une porte dérobée disponible pour le programme d'application Visual Basic Si le mot de passe pour la valeur par défaut, l'utilisateur dans le groupe Administrateurs (nommé Admin) n'est pas modifié à partir de la valeur par défaut aucune ("").
  5. Si la phrase "Avec Option OwnerAccess" est utilisée dans la requête SQL d'une méthode CreateQueryDef, CreateDynaset ou CreateSnapshot, un pointeur vers le fichier System.MDA doit exister. Même si vous utilisez la porte dérobée (la combinaison par défaut de l'utilisateur et mot de passe d'administrateur et "") et ne semblent pas avoir besoin System.MDA, lorsque vous utilisez "Avec Option OwnerAccess" dans une requête SQL, le moteur doit voir le fichier System.MDA pour refléter le SID du propriétaire (créateur) de la base de données à l'utilisateur connecté.
  6. Les combinaisons d'utilisateur et mot de passe d'ouverture de session valides sont stockés dans le fichier System.MDA mais les autorisations sont stockées dans la base de données (.mdb fichier) lui-même. Une clé unique (SID) est extraite de la System.MDA à l'aide d'un utilisateur valide et une combinaison de mot de passe, fournies pour le moteur Microsoft Access par la boîte de dialogue d'ouverture de session dans Microsoft Access ou par le code dans Visual Basic.

Propriétés

Numéro d'article: 105990 - Dernière mise à jour: mercredi 12 février 2014 - Version: 2.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Visual Basic 3.0 Édition professionnelle
  • Microsoft Visual Basic 3.0 Édition professionnelle
Mots-clés : 
kbnosurvey kbarchive kbmt kbinfo KB105990 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 105990
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com